Hacker News new | past | comments | ask | show | jobs | submit login

>Personally, I’m a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand.

After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing.

I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are:

If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" javascript libraries, etc.

For example, take the concept of "classes" that supposedly nobody needs in Javscript (because protoype chains are superior). What is the longest most complicated chapter of Nicholas Zaka's Javscript books[1]?! It's the long chapter on manually simulating classes using prototypes! Same situation with other books that describe home-grown "modules". Even if one chooses to avoid simulated classes in his own js code, one still has to understand the different variations that others write. If classes are not formally specified in the language spec, it's informally specified in everyone else's books, stackoverflow answers, blog articles, and youtube videos explaining js simulated classes. If Javascript had "classes" earlier than ES6, perhaps the over abundance of informal adhoc "class objects" would have been completely avoided.

Another example would be "optional default" function parameters. Since javascript's formal language spec doesn't have a feature for default params, it is "simpler" and "easier to learn". (Hey, if one doesn't have to memorize the keyword "optional", that's one less thing to worry about, right?) Hmmm... really?! Look again more closely.[2] The "optional" feature is simply moved into an idiom (multiple idioms!) that all competent javascript programmers must learn. The "smaller" language hasn't saved any complexity -- it does the opposite -- it made JS usage more complex overall.

Any language that's used for non-trivial purposes will not be "simple" if looked at holistically by combining both the formal and informal real-world uses of it.

However, within that unavoidable complexity, there can be limited subset cases of "simple" for certain scenarios. What does one want a "simple" Javascript language spec for and what can it do? Make the monkey dance?[3] Ok, that's one mapping of "simple" to an end goal and 1995 Javascript specification is probably enough. However, people want to do much more complex apps with Javascript without having to mess around with Typescript, Babel transpiler, etc.

To blog writers: please stop characterizing languages as "simple" without any qualifications of use cases. That adjective is no longer convincing on its own.




> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild.

This is exactly right, pushing language features into user-land just leads to a load of competing equivalent solutions that developers must learn. The language is simpler but it becomes harder to actually use.

JS used to be a language that was easy to understand. Once you grasped the concept of how object references and scopes were handled (which everyone could who invested a few days in understanding the language and read the specs), you were able to understand any of the user-land implementations. Now there are popping up more and more essentially parallel paradigms, mainly to pull some of the user-land implementations back into the language. As a side effect, the language eventually becomes more and more complex, and, as more concepts are integrated, it becomes less obvious, on what kind of tradition a new feature builds. (E.g., there are now two notions of scopes and two notions of object construction and inheritance — and I'm quite confident that we'll see some new features borrowing from both.) As in CISC vs RISC, there are valid arguments on both sides. But there's a lot of cultural change involved, when venturing from a quite spartanic but powerful definition of the language to a multiple concepts definition. Ironically, it will be the user-land implementations, again, that will force everyone into the new notion of the language and there will be no option of avoiding the migration (like sticking to C and avoiding C++, as some have preferred to do in the past). Libraries will be still with us, but it will be more difficult to understand what's really going on, and eventually, the dependency on them will grow. Still, opinions are opinions and there are probably more than two on it as far as developers are concerned.

But there's another side to it: JS is essentially a language to write code to be run on a foreign machine with quite a vague permission to do so. There's an interest in understanding what some piece of code is actually doing, in order to evaluate, whether the permission should actually be granted or not. (E.g., I might prefer not to use a WebApp, if I find me tracked in a way that doesn't conclude with the nature and value of the service. Even, if a free service, the price might be too high. Or, I could find me integrated into some kind of ad-hoc P2P network [WebRTC] that is far exceeding my planned investment in resources and which's use might not converge with my intentions.) The actual chance of doing so correlates with the learning curve of the language used. IMHO this is quite a strong argument for using a language that is both high level (as opposed to Emscripten + ASM) and of a quite scarce formal definition.

> What does one want a "simple" Javascript language spec for and what can it do?

To write proofs? You don't need to worry about the larger idiom of how the language is used for that.

And to write a correct implementation of a language you don't need anything except a correct simple spec. To perform well for idiomatic code you may need to know about idiom.

> To perform well for idiomatic code you may need to know about idiom.

To enforce idioms you include them in the language. This makes the language easier but less simple. It also means people will use exactly one idiom instead of lots of variants. This improves performance and makes it more predictable.

To perform well for idiomatic code you must know about idiom and have consensus about it and teach it to everybody.

The contrast between simple and complete languages was best (imho) expressed in Guy Steele's convoluted 1998 OOPSLA talk, Growing a Language.

The whole talk is expressed in terms of words of one syllable.


I'm familiar with that talk and it's a good one but Guy Steele's main thesis is not showing the difference between small/simple and large/complex.

Instead, his main point is that a successful language can start small and it is inevitable[1] that it will grow into a larger one. Therefore, let's plan on its growth from user feedback. To help the thinking, he defines a sort of "meta framework" for the directions a language can grow. The idea is that the growth can be more systematic instead of a random chaos of adding keywords and syntax (e.g. PHP).

My message is orthogonal from Steele's. I'm saying that evangelizing that a "language X is simple" in terms of a formal language spec is not useful to real-world programmers. The working programmers actually care about holistic simplicity/complexity that combines Formal specs and Informal idioms.

[1](my description not his because he used 1-syllable words)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact