Slashdot Mirror
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.'"
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...
Palm trees and 8
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.
Simple leads to different results because it usually means something more like "quality". Simple is in itself not an absolute value. Instead, the simplicity of something is a ratio of its value to its sucking. So what they're really saying is "I'd like to achieve high value outcomes with the least amount of sucking along the way." There's a lot of ways to do that.
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.
Rich Hickey's keynote talk from Strange Loop: Simple Made Easy. Unlike the posted fluff article, this talk is easily the most insightful talk you've seen this year, or your money back.
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".
It was, and still is, simple compared to C++, or ADA.
Although at the time, there was the quote "Claiming Java is easier than C++ is like saying that K2 is shorter than Everest." And there is some truth to that.
"First they came for the slanderers and i said nothing."
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.
I'd rather see Ada come into common use. Ada actually has a lot of uses, supports some of the more exotic programming paradigms, it's easy to read and it'll smack you in the head if you write something in a bad way (as in, it won't even compile).
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
Ada wasn't bad and certainly capturing more bugs at compile time is wonderful. One of things I love about Haskell is that generally if the program compiles it does what you wanted it to. I save a ton of time with debugging.
A new Ada like language prodecedural with light object orientation, static and strong compile time checks with extensive libraries and financial backing would be good.
As an aside, Ada doesn't have closures, it doesn't have tail recursion... even in the 1970s this was the reason ironically enough that the LISP community wasn't worried about Ada. So in term of Clojure... no it wouldn't solve the problems that Clojure is best suited for.
"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."
That and I've still not really seen many, if any convincing arguments where multiple inheritance is a good idea. We've had a few MI zealots extoll their virtues here and give us examples of why MI was essential to their project. The problem is, each time they've done so so far on Slashdot at least, they've only served to prove they have absolutely no idea how to write good OO code and seemed completely oblivious of the fact that not only did they not use MI, but their example was an example of why MI leads to bad code.
Well, I suppose I did see one good C++ example years ago, but it was about one example in a decade, and I can't even remember what it was now.
HQ9+ and DWIM?
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Program in Java? Everywhere you see interfaces, that's multiple inheritance, they just restricted you to only inherit from the interface, not the implementation. Which means every class that implements it has to rewrite that code. Depending on the interface and the class, that may or may not be a good idea. But I'll frequently find myself writing very similar code for multiple classes that implement the same interface.
What they really needed to do was just block diamond inheritance- inheriting from two classes with the same base class. Of course since in Java everything derives from Object, that would be impossible unless you allow that as an exception.
I still have more fans than freaks. WTF is wrong with you people?
Maybe that would be a good idea in an ideal world. But in reality, such behavior would be deeply confusing for people who know C, C++ or Java. And I think that "it should be easy to write correct code" applies to people who already know another language too.
Also, from my experience, fall-through is not that useful anyway. I don't think I ever wrote code in C# where it would be useful. Having two cases for the same code sometimes is useful, and C# does support that.
Well in languages like Haskell I use them all the time. For example if I'm doing algebra on a matrix I want to inheret from the algebra library and the matrix library.
So something like 3x^2 + 4x + 7, where x = [[2,3], [1,1]] can be used.
And Ada doesn't support tail recursion for the simple reason that well written software shouldn't need recursion. Additionally it's actually terribly inefficient, Ada was also meant for embedded systems. Do you realise what happens every time you call a function? Your processor puts the program counter and other registers on the stack and then jumps to the function call.
When a language supports "tail recursion" that actually means it does "tail recursion elimination". Which means that the processor does NOT put anything on the stack per iteration. There is nothing inefficient about tail recursion when the language supports it.
Finally! A year of moderation! Ready for 2019?
Interfaces are about type checking and making your compiler happy, MI is about sharing implementation (which is mixed with type-checking in most of programming languages). Part of the confusion about interfaces and MI in Java is caused by tutorials and docs which wrongly mentions interfaces as a way of doing MI (Sun training I'm blaming you!).
The biggest problem with MI is the implementation: it leads to lots of "exceptional" cases in the handling on instance variables and method dispatch. If you google for "Principles of design behind Smalltalk" at the end of the article it mentions that future work will be to add MI to Smalltalk (that was in the 80's). They never added that "feature", because they found very little gains compared to the lots of exceptional cases and added complexity.
An alternative that's better from the implementation point of view is Traits. You can find examples of traits in Self, Smalltalk, Scala, and (I think) Dart.
Sure, but in an OO language it makes far less sense, which is what I was referring to - specifically why the lack of support for actual MI in Java isn't a problem - apologies for not making that explicit.
In an OO language you'd recognise that algebra defines actions upon an object, and so you'd simply implement algebra the interface against a Matrix class, and define the Matrix specific implementations of algebraic actions there. Then anything that is a matrix, is a matrix, and anything that is a matrix, can have algebraic actions performed upon it.
Tail recursion doesn't imply the compiler rewriting what the programmer wrote to me, it simply means using recursion in the return line.
A "tail recursive call" is one where recursion happens in the return line.
For any language that allows recursion at all, "Tail recursion" as a language property means the language rewrites tail recursive calls as iterative during compile or execution.
In any case if the language wanted to allow recursion and offer reliability it could just flag on recursive calls it couldn't see how to transform.
You should really consider what the language was designed for. Anything that's unpredictable or might lead to problems at runtime was eliminated. And then people complain about not having them.
You can't simultaneously offer Ada as a general purpose language and then fall back on embedded systems and reliability when someone mentions Ada's limitations. Particularly when you were offering it as alternative to Clojure.
Either you want to argue that:
a) Ada is a special purpose language offering reliability at the expense of many paradigms
b) Ada is a general purpose language.
And if (b) then its flaws get examined in contexts where reliability are not necessarily a primary concern. Clojure doesn't even pretend to offer a high degree of reliability. What is offers is the ability to use LISPs powerful abstraction and at the same time Java's vast libraries neither of which is particularly reliable.
Liking a special purposes languages isn't a problem, I was very sorry to see PostScript die. But you kind of have to decide in your own head how you want to pitch Ada. Ada is not a replacement for Clojure because it doesn't offer abstractions. It doesn't offer full closures (partial execution) either. That's a paradigm I use in virtually every program I write. Even memoizing is kinda painful (again it makes sense since easy memoizing means the run time engine makes choices about how to allocate tables).
So anyway I think you get my point. I agree with you that Ada might have been a good replacement for Java or for Visual Basic or any number of languages that don't encourage abstraction. This particular thread though, but Clojure is on the opposite extreme.
You are very right.
May I recommend Paul Grahams "On Lisp"?
Use of functional programming, and macros to build dsm's reduces the code you need to write, and can simplify things.
You then need good ffi (foreign function interfacing) to utilize external libraries.
My favorite system (currently) is Gambit-C Scheme. It supports define-macro as well as hygenic macros. It compiles to C, so the ffi is simply writing "in-line" C code if needed. Best of all is it has a 20 year history behind it.
Just another "Cubible(sic) Joe" 2 17 3061