HACKER Q&A
📣 open-source-ux

Programming language size – does it matter?


Does the size of a programming language matter? By size I refer to the features and keywords that make up the language. It excludes supporting libraries.

Examples of languages of different size (subjective):

- Small languges: Lua, Go, Oberon, V

- Medium-sized languages: Crystal, Julia, Nim, Rust

- Large (or large-ish) languages: Ada, C#, Java, JavaScript, PHP, Python, Ruby

JavaScript, PHP, Python and Ruby were probably once small(ish) in language size but have grown in features over the years and no longer count as small, although you might disagree and consider them medium-sized rather than large.

Pros and cons of small vs larger

- Small languages: you can actually learn or master the whole language. Arguably, you lose the convenience of features found in larger languages. Does that mean more code to achieve the same feature found in a larger language? Also, small doesn't always mean simple. There has been much discussion by developers over Go's supposed simplicity.

- Larger languages: more features arguably make things it easier to tackle problems. However, understanding the full scope or reach of the language can be difficult (but not necessarily required). Does that expansive language scope make it harder to understand large codebases? Or does it make the language more expressive?

What do I think? Overall, I favour smaller languages over larger ones and that 'small' is a better language goal over something larger.

Niklaus Wirth, the creator or Pascal, Modula-2 and Oberon is very much in the small language camp. When he created the Oberon programming language, he purposefully wanted a new language smaller than his previous creation Modula-2. (Modula-2 had a language specification of 45 pages. In contrast, the first version of Oberon had a definition report of just 16 pages).

Wirth's thoughts on the matter:

"...it is hard to design a powerful and reliable system, but even much harder to make it so simple and clear that it can be studied and fully understood. Above everything else, it requires a stern concentration on what is essential, and the will to leave out the rest, all the popular "bells and whistles".

What are your thoughts?


  👤 mikewarot Accepted Answer ✓
Lisp is one of the smallest languages of all, and a variant of it powers this site (as far as I know)

Forth is almost as simple, but it is more tightly coupled to the stack.

Having fewer rules should result in smaller and less error prone implementation. Most languages can eventually do anything, but generally there is a type of problem a given language is best suited to handle.


👤 PaulHoule
There is the language and there is the standard library.

In C for instance it is common to throw out the stdlib. A language like Java has a big stdlib and also has the maven central repository which is like the stdlib in that you are always going to be using it if you work on other people’s code.

JavaScript has a small stdlib, although it is typically attached the the browser which is a universe in itself. Npm is its own universe.

In small languages people are often reinventing the wheel in dangerous ways, for instance string parsing is hard to get right, you don’t want to write urlencode/decode, yaml serdes.

For doing innovative and challenging things a big language with attention to detail (Java) frees you to think about specifics as opposed to being the first person (it seems) to discover and work around problems in your platform.


👤 muuvmuuv
For me keyparts are more syntax decisions that are being made to a language and how easy it actually is to write, import and export parts of a program. This is why I really like V or Deno. When it comes to size I only care about the output size and compilation times. If I import one part of a file I really just one only that part and ofc dependences.