Posted
by
timothy
on Sunday June 17, 2012 @10:44AM
from the ways-of-seeing dept.

snydeq writes "Charles Nutter, Rich Hickey, and Gavin King each discovered that 'simplicity' doesn't mean the same thing as they developed Ruby, Clojure, and Ceylon, respectively. 'Languages that are created with similar goals in mind may yield highly disparate final results, depending on how their communities understand those goals,' writes Andrew Oliver. 'At first, it surprised me that each language's creator directly or indirectly identified simplicity as his goal, as well as how differently the three creators and their languages' communities define what simplicity is. For Ruby, it is about a language that feels natural and gets out of your way to do what you want. For Clojure, it is about keeping the language itself simple. For Ceylon, it is a compromise between enabling the language to help, in King's words, "communicating algorithms to humans" and providing proper tooling support: the same general goal, three very different results.'"

Where is the information about Ruby or Ceylon? There are Clojure code snippets designed to illustrate the Clojure philosophy of "simplicity," yet no equivalent Ruby or Ceylon code. Overall, this article seems to be devoid of content...

If it gains traction, then it will have to deal with feature creep (keeping up with the new hot languages), standard library bloat, backward compatiblity, and differing interpretations of the spec by compilers and developers. Then it becomes no longer simple.

Java is the classic example. It's hard not to giggle or mutter "WTF?" when you read Sun's original positional paper claiming the language was "simple".

This makes me mad to see a link to an article about "9 top languages", in which some major (established) players of the field such as Haskell or OCaml are not mentioned, while languages-to-be get some nice coverage.

Creating a programming language boils down to being fashionable, rather than doing something neat.

One way I look at programming is as a form of decision compression. Instead of writing a zillion "if then" statements to solve a problem, you write a lot fewer statements.

Just as there is no compression algorithm that's best at compressing all data, it will be unlikely for anyone to come up with a "decision compression language" that will be the best at compressing "everything". To make things more complicated, you often need to change certain stuff in the future, so you shouldn't pack everything too tightly, even if the language allows it.

Last but not least, I prefer a language not because of the code I need to write, but because of all the code I won't need to write ( and debug and document etc). In other words - the libraries and modules are important. Even if a language is very good and simple, and you only have to write one third the lines to do something, it still is not as good if you have to write everything you may need (database connectors, xml parsers, web clients, big number support, strong crypto, etc). In contrast a language that is 3 times more verbose but has libraries for nearly everything you need would actually result in you writing a lot fewer lines, and if the libraries aren't crap, supporting, documenting a lot fewer lines.

So a language that makes my life simple, isn't necessarily a simple language;).