from Hacker News

Less is more: language features

by neiesc on 4/13/15, 4:41 PM with 63 comments

• by picks_at_nits on 4/14/15, 1:31 AM

  The narrative in Why Functional Programming Matters (“WhyFP”) is that it is not enough to simply remove features, but to take advantage of their removal to add other, more powerful features.

  The paper gives laziness as an example. It’s made possible by idempotency. Which is made possible by the removal (or careful management) of side-effects. Which then allows certain otherwise impossible ways to express infinite data structures.

  http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

• by kmicklas on 4/14/15, 2:17 AM

  I take issue with the single-number-type thing. This guy is conflating two different reasons/ways to divide up number types - for transparency w.r.t. machine (optimization) and by conceptual types (integer vs natural number vs fractional, etc.). The first arguably doesn't belong in a high level language. The second arguably is _exactly_ what a truly high level language should have.

• by efaref on 4/14/15, 9:14 AM

  Yet another article that misses the point of "goto considered harmful."

  The way "goto" is used in modern C (named breaks and defined function escape routes) is perfectly acceptable. Newer languages include these features in the language, in much the same way that C encoded structured "goto"s as "while" loops and "if" statements.

  Dijkstra was complaining about unstructured programming compared to structured programming.

• by mden on 4/14/15, 1:46 AM

  To me this is a weird list. It's a bit like removing the personality of a person and then claiming that made the person better.

  Also a lot of the things he lists are not at all as clearly harmful as he makes them out to be.

  GOTO: Used in some of the cleanest code bases. For example the lua programming language, redis db, and linux kernel OS. Yes the use is limited, but it's there not because of mistakes but rather because it is sometimes the most clean way.

  Numbers: I don't understand this one. In the very least having different types of numbers seems to be a necessity for anything performance oriented such as graphics. JS not having them (they seem to have been added for WebGL as an extension, no?) is not a good reason for all new languages to do the same.

  Mutations: I am personally of the view that mutation often simplifies the informal reasoning complexity of a program. There's a reason functional programming hasn't caught on and it likely never will. A hybrid approach of having both immutability and mutability like Rust seems most sensible.

  Reference equality (Referential transparency?): If you have immutability do you not get this for free? How can you be sure about getting rid of mutations but not be sure you want objects to be equal based on data?

  Each language has it's own quirks that make it special and that's part of the reason programming is fun. There's never a single right way.

• by ruricolist on 4/14/15, 12:15 AM

  I dispute the basic narrative here. If you have tail calls, you have GOTO. If you have closures, you have pointers. The story (so far) is not one of features disappearing, but of features being subsumed by other more general, abstract features.

• by hacknat on 4/14/15, 12:18 AM

  It's interesting to see that recent languages are making strides towards this list.

  * Golang does away with inheritance and exceptions.

  * Rust does away with mutability, or at least makes it explicit.

  I wonder if a convenient language with all of these taken out could exist. I'm skeptical about a single number-type.

  Also, wouldn't reference equality simply be gone if you take away pointers?

  Also, his point about interfaces is pretty narrow, not every interface's manipulation can be characterized by one or one set of manipulations. I think Golang is a fantastic example of a language that forces a role-based interface pattern.

• by thomasfoster96 on 4/14/15, 1:20 AM

  I think it's worrying if language design ever becomes about having higher and higher level features 'protecting' the programmer from making mistakes, at the cost of losing access to lower level features that are considered harmful. Higher level features are much better than a GOTO 99% of the time, but there's always going to be 1% of the time when a GOTO might be better.

• by StefanKarpinski on 4/14/15, 3:05 AM

  This article is nearly its own reductio ad absurdum. By this line of reasoning, we would all be better off programming just with NAND gates – the most minimal programming model of all.

• by sacado2 on 4/14/15, 8:37 AM

  Nice post, although I think the author is cheating a little with his Venn diagrams. Most of the time, his language subset contains almost all the valid programs. I don't think it is true. I'd like to know how one can make hard real-time embedded programming with the only language features he offers, for instance, or anything that requires as much processing power as you can (cryptography, constraint solving, data mining, optimization, simulation, etc.) I am not talking about exotic niches here.

  More generally, I'm still waiting for a massively successful piece of software made in a language that would involve no mutation, no null pointers, only one numeric type, etc. Even John Carmack has not yet delivered a revolutionary game engine programmed in Haskell.

• by Grue3 on 4/14/15, 1:16 PM

  Unlambda [1] is completely functional and has only 2 built-in functions. According to the author, it's the perfect programming language, even though it's extremely inefficient and the code is almost impossible to understand. Many of the features he lists enhance either efficiency (number types) or readability. The languages that lack these things are bound to be slow and hard to understand at least in some cases.

  [1] https://en.wikipedia.org/wiki/Unlambda

• by aikah on 4/14/15, 5:31 AM

  > F# projects have fewer and smaller cycles than C# projects.

  Sure, but maybe the reason is the people that choose to use F# and Caml like languages are a bit smarter that the regular coder. Or maybe F# projects have a different nature and people don't write "enterprise applications" in F#.

• by andrept on 4/14/15, 9:39 AM

  Whilst it is true that the absolute number of possible wrong programs grows as the number of features increases, I don't think that it implies that the proportion of wrong programs actually coded by people grows as well.

• by kragen on 4/16/15, 7:27 PM

  I do not like this article at all. I rebutted it extensively at https://lobste.rs/s/ipml3l/less_is_more_language_features/co....

• by kephra on 4/14/15, 10:01 AM

  I don't understand the point in removing cyclic references, coming from FORTH, Lisp, Smalltalk point of view those are required, if you split a big recursion into smaller factors. The recursion automatically becomes a cyclic reference between words, functions, methods or even classes, as classes are just closures.

  Does he want to forbid factoring? His feature looks more like a deficit of the linker to me.

• by digitalzombie on 4/14/15, 7:56 AM

  I think Erlang hit everything?

  Not sure about Cyclic dependencies and I don't think it have Reflection unless I'm wrong.

• by ticking on 4/14/15, 9:24 AM

  If you install nightly builds on a production system you deserve to get bitten.