Ruby, Clojure, Ceylon: Same Goal, Different Results

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.'"

Comments

Lot's of information about Clojure...

[betterunixthanunix]

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...

Re:Lot's of information about Clojure...

[pmontra]

There isn't. But this is how to do it in Ruby

String.instance_methods.select {|m| m.match("sub")}
=> ["sub", "gsub!", "gsub", "sub!"]

instance_methods returns an array. select iterates on it calling a code block on every element. If the block returns true it adds the element to the array it will return at the end of the loop. |var| is how the element is passed to the block. Blocks can span over multiple lines, it's usual to wrap them inside a do..end but { } still work.

String.instance_methods.select {|m| m =~ /sub/}} is the perlish alternative.

I didn't match "last" as in the article because Ruby's String has no methods with "last" in their name.

Re:Lot's of information about Clojure...

[MarchHare]

A slightly better way, IMHO:

    String.instance_methods.grep /sub/

Every programming language is touted as "simple"

[Anonymous Coward]

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".

Mad

[Anonymous Coward]

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.

 

Re:java backend is not simple.

[svick]

That's interesting. The creators of C# have a somewhat similar philosophy: they say that they would like it to be a "pit of quality", it should be easy to write correct code. But that doesn't mean they removed features that can be abused.

As a consequence, the things you mention (pointers, gotos, operator overloading) are all included. But for example in the case of pointers they are "hidden" (they have to be in an "unsafe" block).

On the other hand, for example fall-through switch cases are not allowed in C# at all, they thought those are not worth all the bugs they cause.

Re:java backend is not simple.

[jbolden]

That's why there is no easy to explicitly do things such as pointers, gotos, and operator overloading

The reason there was no pointers was that pointer manipulations were highly machine dependent. Java emerged out of Oak and the slogan "write once run anywhere" was key to its popularity.

Goto -- came from the whole philosophy that goto leads to bad code.

Operator overloading and multiple inheritance are both examples where subtle shifts in code can lead to enormous shifts in how the compiler views the code. One of the key aspects of Java was making sure that side effects to changing code were contained.

Re:Every programming language is touted as "simple

[TheLink]

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 ;).