3 ms·

Guy Steele knows a bit about language design (having co-invented Scheme and Fortress, worked on early implementations of TeX and TECO/Emacs, and helped write th

Guy Steele knows a bit about language design (having co-invented Scheme and Fortress, worked on early implementations of TeX and TECO/Emacs, and helped write the specifications for Java, Common Lisp, ECMAScript, Fortran, and C). In Coders at Work he says, "There's this Huffman encoding problem. If you make something concise, something is going to have to be more verbose as a consequence. So in designing a language, one of the things you think about is, 'What are the things I want to make very easy to say and very easy to get right?' But with the understanding that, having used up characters or symbols for that purpose, you're going to have to make something else a little bit harder to say." So it definitely depends on your domain. If you do some of the harder Project Euler problems and then look in the forums, you can see the same problem solved by a hundred different programmers with different approaches. The shortest solutions there are always in APL-family languages like J and K. But it's partly because those languages are so well-suited to the typical problems in Project Euler. If you want to implement a concurrent server for binary network protocol like memcache, then you'll probably find Erlang a more concise language instead, because its syntax, its libraries, and the primitives of the Erlang VM are all better adapted to that domain.

nadam 17y ago
Yes you are right, it probably depends on the domain. But still, I have a feeling that there are some languages which are more concise than others generally because of reasons which are very generic: For example imperative languages with local variables contain a lot of unnecessary information, because we always have to reference the local variables we use, while in stack based languages the arguments don't have to be referenced, because they are implicit. In fact, in an extremely concise language there should be only a very few ways to express a program at a certain size. In not so concise languages you can write the same program in lot of ways ('permutations') (having the same size).

nadam 17y ago

Yes you are right, it probably depends on the domain. But still, I have a feeling that there are some languages which are more concise than others generally because of reasons which are very generic: For example imperative languages with local variables contain a lot of unnecessary information, because we always have to reference the local variables we use, while in stack based languages the arguments don't have to be referenced, because they are implicit. In fact, in an extremely concise language there should be only a very few ways to express a program at a certain size. In not so concise languages you can write the same program in lot of ways ('permutations') (having the same size).