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

Bitchfight!

[Anonymous Coward]

3..., 2..., 1... Go! :)

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

[Anonymous Coward]

Indeed. The other question is why pick Ceylon. Nobody seems to ever mention it. I hear about groovy and scala all the time.

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/

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

[pmontra]

More compact but people without a *nix background won't understand it without looking at the docs. Anyway I think I'll start using it :-)

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

[quintesse]

Well, we only just started on Ceylon and are not even finished yet, so it's a bit early to start comparing how many times it gets mentioned in relation to the rest, but people have to start some time :)

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

[Jane Q. Public]

"Overall, this article seems to be devoid of content..."

It is also devoid of meaning.

Not to discount Nutter's contribution to the Ruby world, but he hasn't been a significant contributor to the language itself. Rather, he's been working on porting Ruby to the Java VM (Jruby). Not the same things at all. Not even close, really.

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

[PCM2]

Programmers with zero *nix background puzzle me.

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

[Jane Q. Public]

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

Actually your "Perlish" form is the preferred way to do it in Ruby.

On the other hand, that's one of the nice things about Ruby. There are different ways to get things done. There are a few people who might consider that a flaw, but that does not seem to be the general consensus.

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

[Hognoxious]

Programmers with zero *nix background make sure you get your dole check and ensure that the local kwik-e mart has goods for you to spend it on.

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

[Brian Feldman]

I prefer the more concise "".methods[/sub/].

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

[pmontra]

Does that work?

> "".methods[/sub/]
TypeError: can't convert Regexp into Integer

I tried it with 1.9.3 and 1.8.7. Array's rdocs don't list a [] method with a regexp argument.

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

[Anonymous Coward]

String.instance_methods.select {|m| m.match("sub")} => ["sub", "gsub!", "gsub", "sub!"]
I have been a programmer for over 40 years and the simplicity of the above statement is enough to make my head spin.

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

[Anonymous Coward]

# or, simpler yet:
String.instance_methods.grep /sub/ #=> ["sub", "gsub!", "gsub", "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:Mad

[Anonymous Coward]

so.. yet another FP fanatic with a persecution complex

Success

[phantomfive]

And yet none of these languages is actually simple. Ruby is readable and consistent, Clojure is sparse but confusing, and Ceylon is unknown (ok, maybe it's simple, but I'm not going to learn it to find out).

Re:Success

[Osgeld]

apparently its a java remix

Re:Success

[Jane Q. Public]

"apparently its a java remix"

Not even close.

Its syntax is nothing like Java's. Its structures are nothing like Java's. Both being high-level languages, of course it is almost inevitable that they deal with some of the same data structures, like strings and arrays. But program structure is markedly different.

When it was first becoming popular outside Japan, various comparisons showed Ruby to average about 20% as many lines of code to get the same job done as Java programs that did the same things.

Granted, those demonstrations might have been somewhat slanted and not completely "fair". Nevertheless, to say that there are very significant differences is an understatement.

Re:Success

[Osgeld]

thats great and all but I was responding to the line about Ceylon

Re:Success

[quintesse]

It's not really, but of the 3 it's the most similar maybe. We're trying not to stray too far away from familiar territory for Java developers.

Re:Success

[Anonymous Coward]

Ruby is neither readable nor consistent. However, if you know it well, you need less key strokes then in other languages.

Re:Success

[Jane Q. Public]

" thats great and all but I was responding to the line about Ceylon"

Pardon me then. My comments were well-meant.

java backend is not simple.

[billyswong]

Sorry. In my head, "simple" and java is incompatible.

Re:java backend is not simple.

[sribe]

The problem is the designers assumed that all programmers are simple minded idiots.

For a large market that Java was originally aimed at, that assumption was a reasonable first-order approximation.

It is why I never liked Java (that, and Sun's ridiculously exaggerated claims about it)--but it is still arguably a feature, and one that is appropriate in many situations.

Re:java backend is not simple.

[billyswong]

But then they forgot one thing: NEVER underestimate humans stupidity.

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.

[solidraven]

Java is fairly simple for a beginner. No need to worry about memory management. But it still exposes enough to be useful for any goal.
I wouldn't call Ruby, Clojure and Ceylon easy though. Ruby has a horrible syntax, it's slow and unreliable. Ceylon has another problem, it tries to make Java easier, and indeed the basic parts are easier. But the behaviour is unpredictable for more complicated situations. Clojure on the other hand has horrible syntax. I'd say in terms of readability it might actually be ranked below SPARC assembly (and that's not a compliment).

Re:java backend is not simple.

[0123456]

Java is fairly simple for a beginner. No need to worry about memory management.

So long as you don't mind your UI regularly freezing for 2-3 seconds while it cleans up your garbage.

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:java backend is not simple.

[jbolden]

Clojure has an incredibly hard job.

Take language A and use libraries from language B where A and B have totally different ideologies about everything. We need a good LISP and we need a good set of modern libraries for that LISP. But yeah mixing them kinda sucks.

Re:java backend is not simple.

[solidraven]

I agree that was the case on the older systems. Luckily with the increase in processor speed it's not that much of a problem any longer. But I must say I have noticed that Java does seem to work smoother on Intel processors. Probably might have something to do with the compiler Sun/Oracle has been using.

Re:java backend is not simple.

[solidraven]

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

Re:java backend is not simple.

[Anonymous Coward]

Ruby has a horrible syntax

I find most of Ruby's syntax refreshing and simpler than Java's. Java's syntax is bloated. Does it really need to be that verbose?

it's slow and unreliable

Same thing has been said of other languages which over time have much faster implementations. Java and Javascript quickly come to mind. The same amount of effort hasn't been put into Ruby yet.

Clojure on the other hand has horrible syntax.

Well yeah, if you don't grok Lisp. The C-style syntax is hardly a thing of beauty and elegance. It's more a matter of so many programmers being familiar with it. And then they see something different and it's unfathomable that you wouldn't use curly braces and semicolons all over the place.

Re:java backend is not simple.

[rubycodez]

oh my, Ada. COBOL meets Pascal. ;P

Re:java backend is not simple.

[jbolden]

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.

Re:java backend is not simple.

[Xest]

Out of interest, what languages do you think are simple?

Re:java backend is not simple.

[Anonymous Coward]

Well, there are different metrics of simple. For example, I enjoy the RSI-mitigating aspects of Unary programming language.

Re:java backend is not simple.

[Xest]

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

Re:java backend is not simple.

[Jesus_666]

HQ9+ and DWIM?

Re:java backend is not simple.

[AuMatar]

Which is a bad idea, because they're very frequently useful. A better idea would have been to reverse the default- make it not fall through unless you use a special keyword.

Re:java backend is not simple.

[AuMatar]

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.

Re:java backend is not simple.

[solidraven]

And that's the common miss conception. The latest standard versions of Ada are fully capable of dealing with objects.
Actually Ada pretty much fits the description you've given except for the extensive library. The financial backing is already there due to the military projects attached to it. If you want reliable software for potentially dangerous things Ada is the only acceptable choice.

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. Now this might sound efficient to you. But actually decreasing/increasing a value and jumping back is far more efficient in terms of CPU cycle usage. Additionally it's easier to debug software that does not employ recursion. Stack overflow is a nasty thing that you really don't want to happen in programming language that was designed from the ground up to be as reliable as possible.

Re:java backend is not simple.

[solidraven]

Comparing Ada to COBOL is an insult. Yes, it was based on Pascal, but you should educate yourself about the language before you wish to make a conclusion about it. Ada isn't meant for your fancy programming. Ada is meant to get the job done. And it's very good at that.

Re:java backend is not simple.

[Anonymous Coward]

D does that. "case 3: something(); case 4: somethingmore(); break;" is a compile error, but you can say ""case 3: something(); goto case; case 4: somethingmore(); break;" for fallthrough (or goto case $specificcase;, or goto default;)

D really needs more love.

Re:java backend is not simple.

[0123456]

I agree that was the case on the older systems. Luckily with the increase in processor speed it's not that much of a problem any longer.

I can only assume you've never used Eclipse.

Dumb programmer approach to Java:

1. Don't even think about memory allocation. Forget to free up references to objects you're not using and lose references to objects you still need, so your program leaks memory or randomly stops working.
2. Notice that the program freezes regularly when the garbage collector runs.
3. Increase the amount of RAM allocated to the program to stop the garbage collector running and compensate for those memory leaks you forgot to clean up.
4. Now the program runs for a few hours without garbage collection, but takes up half the RAM in the machine and when the garbage collector does run it freezes for thirty seconds as it has to scan through gigabytes of RAM looking for unreferenced objects.
5. Fortunately you relied on the garbage collector to close open files rather than doing so explicitly, so in normal use the program runs out of file descriptors and crashes before that happens.

Re:java backend is not simple.

[svick]

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.

Re:java backend is not simple.

[AuMatar]

I actually kind of like that. It also enables you to have 3 or 4 cases that all need different minor initializations (say they all want to initialize a starting condition to different values) to then jump to a common case, which was actually a frequent pattern in assembly programming that's unfortunately difficult in modern languages.

Re:java backend is not simple.

[Jane Q. Public]

"Ruby has a horrible syntax, it's slow and unreliable."

Ruby's syntax is exactly why most people who like it, use it. And it's not as if its syntax were unusual; almost all of it was "borrowed" from existing languages, though in a generally consistent way, so it is still coherent.

But okay. You don't like the syntax. That's your prerogative. About being "slow and unreliable", however:

It is no slower than other modern "dynamically typed" languages. While it is generally true that as a group they are slower than compiled languages like C or even Java. (And even Java is very slow, when compared to truly compiled languages; Java is only bytecode-compiled.)

But comparing those languages to statically-typed languages like Java is not really calid. They are different kinds of animals.

But of course, that is Nutter's motivation for porting Ruby to the JVM: to get Ruby to run at Java-like speeds. And with significant (though not 100%) success. But I must repeat that dynamically-typed languages present unique challenges when it comes to compiling.

As for your last assertion, that it is unreliable: hogwash. It is no more "unreliable" than any other modern language. One is tempted to wonder where and how you got that idea.

Re:java backend is not simple.

[Jane Q. Public]

Slip of the fingers: that should have read "... not really valid."

Re:java backend is not simple.

[jbolden]

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.

Re:java backend is not simple.

[amorsen]

I'd say in terms of readability it might actually be ranked below SPARC assembly (and that's not a compliment).

What do you have against SPARC assembly? It is an extremely straightforward three-address instruction set without complications. The only slightly challening part is register windows. It is by far my favourite instruction set to write for (admittedly I don't really write assembler anymore...)

Now PA-RISC on the other hand... Luckily that is dead.

Re:java backend is not simple.

[amorsen]

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.

Re:java backend is not simple.

[Xest]

"Program in Java? Everywhere you see interfaces, that's multiple inheritance"

Yes, but when most people talk about MI they're talking about the ability to perform actual inheritance of real classes, rather than the ability to implement interfaces - it's that that I'm referring to.

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

I find this nearly always boils down to a poor inheritance hierarchy. Chances are it means you should have another class somewhere up the chain that implements that common interface, rather than reimplement it for each class in a similar way.

Re:java backend is not simple.

[Anonymous Coward]

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.

Re:java backend is not simple.

[dkf]

That and I've still not really seen many, if any convincing arguments where multiple inheritance is a good idea.

There is value in declaring that instances of a class can participate in a some pattern or other. The concept of interfaces is a way of doing this that is used in Java (and in variations in a number of other languages too). However, it uses a different dispatch model to direct inheritance: straight indexing into a vtable won't work (the point of dispatch doesn't have enough information at compile time, so a more complex — and somewhat slower — lookup is required).

Ontologically, multiple inheritance is not a problem either: it's just the is-a (well, strictly the is-a-specialization-of) relationship. The real problems come when people use it to model has-a relationships. If you ever see someone doing that, do us a favor and bitchslap them; you know it makes sense.

Re:java backend is not simple.

[Xest]

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.

Re:java backend is not simple.

[Xest]

"There is value in declaring that instances of a class can participate in a some pattern or other. The concept of interfaces is a way of doing this that is used in Java (and in variations in a number of other languages too)."

Agreed, you at least need the facility to do that.

"Ontologically, multiple inheritance is not a problem either: it's just the is-a (well, strictly the is-a-specialization-of) relationship."

Indeed, but how often is something actually two things? that's what multiple inheritance implies. Part the problem when a lot of people use MI is that they miss the hierarchy, they'll say "Well a Frog is an Animal and an Amphibian so it should inherit from both!", when in reality the hierarchy is that an Amphibian is an Animal, so Frog should inherit from Amphibian, which should inherit from Animal. That's the most common mistake I see when people claim MI is important - they miss the fact that they've missed the correct hierarchy and use MI as a fudge to fix that.

I know as I say there are rare cases where it does make sense, but they seem so rare to the point that where direct multiple inheritance is available, it's misused a thousand times over for every time it's used correctly.

Re:java backend is not simple.

[jbolden]

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.

That's what happens without tail recursion which is why you want tail recursion. What happens with tail recursion is the call gets rewritten for iterative execution. Wikipedia has a good article describing the difference is C and assembler: http://en.wikipedia.org/wiki/Tail_call You don't get stack overflow from tail recursion anymore than you would in any procedural approach with iterators.

As for well written software not needing recursion of course of it does. Many problems can be handled by:

If complex do a simple computation that results in a modifier and a simpler input
If simple do a simple computation.

That situation calls for recursion. Of course anything recursive can be expressed iteratively but then the iterative implementation details end up hiding the core algorithm. Boilerplate code hides the function.

So for example here is quicksort written recursively:

quicksort :: Ord a => [a] -> [a]
quicksort [] = []
quicksort (p:xs) = (quicksort (filter (< p) xs)) ++ [p] ++ (quicksort (filter (>= p) xs))

Doing that iteratively gets you involved in all sorts of bounds checking and computing lengths of arrays and....

Re:java backend is not simple.

[Anonymous Coward]

I can only assume you've never used Eclipse.

That's not fair. In my experience most of the slowness of Eclipse is caused by:
- Wrongly configured JVM Heap parameters: if you have tons of plugins, you have to know that the JVM defaults values for the heap size is to conservative triggering more GCs than necessary.
- Eclipse incremental build... works fine until you start using plugins that adds custom builders and validators.

In both cases is more a problem of Eclipse and the bloated "EE" programing frameworks, than a problem of the JVM.

Re:java backend is not simple.

[jbolden]

I don't see how OO changes it. To me you would run into a problem with not wanting to implement everything twice or 100x. For example the connection between sin(x) and the Taylor series I would have in Algebra not Matrix. But if I want to compute a sin function on a matrix space I'm going to want to use the Taylor series. Why should I have to re-implement all that code?

___

Or to be less mathy. I have "imports" and "cars" as classes why not inherit both for Toyota objects?
 

Re:java backend is not simple.

[solidraven]

Tail recursion to me simply means using the output of the function it was called from as return value of a function. It doesn't imply optimization.
So you might want to look at how rewriting what the programmer did is against the Ada philosophy. You should keep in mind predictability is important. Hence using tail recursion really would lead to recursion in Ada, result in possible stack overflows.

Re:java backend is not simple.

[Anonymous Coward]

"Which means every class that implements it has to rewrite that code."

No it does not mean so. For example, you can delegate as in 'favor delegation over inheritance'. Saying that the code has frequently be rewritten is the same as saying that you do not know how to properly solve the situation.

Re:java backend is not simple.

[solidraven]

Tail recursion doesn't imply the compiler rewriting what the programmer wrote to me, it simply means using recursion in the return line. And the problem with that is that Ada will do exactly what you wrote. That's pretty much the entire point of the language. If you read over the code it's completely predictable what will happen on execution. Tail recursion as you state it will lead to unpredictable behaviour. As such Ada will not allow it.

It's not cause you can solve most problems using large explosions that you should is it? The same applies to recursion. Using recursion on a system that requires guaranteed stability is a sign of bad programming practice. Especially if it comes to embedded systems. Programmers seem to have gotten used to having an excess of resources and the ability to press the reset button on the machine if all else fails. There are a few problems with this. Your first assumption is that your compiler will recognize it. Your second assumption is that the compiler is capable of rewriting every recursive call to a loop on its own. Doing any of those things just won't fly in Ada. 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.

Re:java backend is not simple.

[solidraven]

Ruby is far from consistent in my opinion. But that's subjective so I'll skip that one.
Chaining dot operators doesn't add to the readability of a language as some people seem to think it does. Yet for some reason the Ruby crowd seems to assume this is a good idea.

It actually is slower than the competing languages. Python (also dynamically typed) is a lot faster. In fact in certain cases even PHP beats Ruby at speed of execution. And your assumption that Java can only be run by a virtual machine is just plain wrong. There are a lot of processors that offer native support for Java. And I wouldn't call it a significant success. Getting it to run at Java-like speeds means that Perl is still able to beat the crap out of it.

And it's unreliable cause it's layered too much on other technology. Too much that can go wrong.

Re:java backend is not simple.

[solidraven]

I don't have much against SPARC assembly in fact. I'm simply not fond of it's syntax. Its not easy on the eyes, very hard to skim over to get a rough idea of what the code does. Often confusing naming combined with abuse of %. It just doesn't add to the readability. More than once I ended up having to rewrite code simply cause one symbol was missing. Often one that didn't seem to have much use other than to annoy the programmer. So the first language I think of in when comparing something in terms of readability is SPARC assembly.
And can't say that I've ever seen PA-RISC and Google doesn't seem to be willing to help me find a snippet of it.

Re:java backend is not simple.

[jbolden]

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.

Re:java backend is not simple.

[lennier]

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.

While I can't speak for Haskell's implementation of alebra, I'd have to say that mathematically, an algebra is far more than just a definition of "actions upon an object" in the OO sense. An algebra also defines the results of those actions, while in OO, an interface only defines the type signature of those actions. So you can happily define your interface as "supports-add-and-subtract" without defining that "x - x must equal zero". This is only half of an algebra - if that.

And really, isn't this the core problem with our Internet security crisis at the moment? We have all these OO systems implementing whole rafts of interface inheritance hierarchies, yet very few of those interfaces actually guarantee that the method calls will have correct behaviour in all cases. Just that the right class/type of objects are passed in and out (and sometimes not even that). But those types are defined both too strictly and too loosely; we generally don't have a way of saying at the language level "X is a pointer guaranteed to be within memory address range Y and Z", or "W is an XML file that conforms to schemas S1, S2, S2..." or "L1 is a list for which the following list L2 of properties relative to other list L3 is true..."

Personally I think we'll only move forward in language define when we switch from "types as calling signatures of methods which do who knows what" to "types as strong guarantees of results of operations". But I don't see any languages actually working on that. Some of the work on "contracts", maybe, but how many languages that have contracts make this the fundamental design feature?

Re:java backend is not simple.

[lennier]

Typo: "language define" -> "language development"

Re:java backend is not simple.

[amorsen]

Ah right, it's the Sun assembler not the instruction set you don't like :) That makes a lot more sense.

I am not sure what you mean by missing symbols and confusing naming. Coming from MC 68k at the time, SPARC assembler was a great leap forward.

99 bottles of beer in PA-RISC

Re:java backend is not simple.

[jbolden]

Funny enough Haskell allows you to do that. What you are looking for is Monadic operators (http://en.wikipedia.org/wiki/Monad_(functional_programming))

You can define arbitrary types and then use functions which invoke either

So for example say you are using Nat (natural numbers).
type Nat = Zero | Suc Nat
so for example
8 = Suc (Suc (Suc (Suc (Suc (Suc (Suc (Suc (Zero))))))))

Now you have fromInt:: Integer -> Either Nat
given by
fromInt x = if x >= 0
    then Left x
    else Right "Range Check Failure"

but you don't have to do that, rather you just use a bind (a function that tells you how to treat naturals like integers for computation) and return (a function that tells you how to make integers into Naturals... i.e. fromInt) and the system handles the details everywhere.

Re:java backend is not simple.

[rubycodez]

I can assure you I am very proficient in all three of those languages. Ada had its day, peaking in the late 90s but in decline ever since.

Re:java backend is not simple.

[Anonymous Coward]

I'll have to agree with you. Every time I thought I needed MI I soon realized I was doing something wrong. I've yet to see a real need for it.

Re:java backend is not simple.

[complete loony]

There are cases where the system libraries define something as a class when it should have been defined as an interface, perhaps with a default abstract implementation. InputStream / OutputStream spring to mind.

Re:java backend is not simple.

[LizardKing]

I can only assume you've never used Eclipse.

The slowness in Eclipse is down to SWT, which doesn't even use the garbage collector. For proper Java code, the incremental garbage collector taht has been the default for many years now prevents the kinds of slow downs or pauses that used to be common (and afflicted other languages like most Common Lisp implementations).

Re:java backend is not simple.

[Jane Q. Public]

"Ruby is far from consistent in my opinion. But that's subjective so I'll skip that one. Chaining dot operators doesn't add to the readability of a language as some people seem to think it does. Yet for some reason the Ruby crowd seems to assume this is a good idea. ... It actually is slower than the competing languages."

It must all be kept in perspective. If you think Ruby syntax is inconsistent in comparison to Python, you need your head examined.

And I will grant that Ruby is -- a little, not a lot -- slower than Python on benchmark suites, code maintainability is important and if you want to compare readability (and, as I mentioned, actual syntactical consistency), Ruby is the clear winner. Significant-whitespace languages simply aren't as readable as other infrastructures. I know some die-hards disagree, but blind studies show that pretty clearly. There was one posted on Slashdot not that long ago.

"And your assumption that Java can only be run by a virtual machine is just plain wrong. There are a lot of processors that offer native support for Java."

I "assumed" no such thing. I merely mentioned that it normally is. But I am intrigued: please tell me what current makes and models of processors have "native" support for uncompiled Java. Because this is complete news to me. Really. I want to know.

"And I wouldn't call it a significant success. Getting it to run at Java-like speeds means that Perl is still able to beat the crap out of it."

Significant success commercially. Nobody these days (nobody in their right mind anyway) offers commercial programs written in Perl. But to say that commercial Java programs are a multi-billion-dollar business, just in the US, is an understatement. And some of those are even open-source.

"And it's unreliable cause it's layered too much on other technology. Too much that can go wrong."

Cite this technology, please. I have been using Ruby for years and I know nothing of the "technology" of which you speak.

Re:java backend is not simple.

[Xest]

I don't see why you'd have to implement it many times, you only implement it if it changes, and then you have to implement it.

Most of the solution revolves round breaking down the problem, and reusing those broken down chunks. If you're implementing a functon that has many many lines of code and then complaining about needing to reimplement that then the chances are that you could have broken down that function more and reused parts of it.

"Or to be less mathy. I have "imports" and "cars" as classes why not inherit both for Toyota objects?"

I don't really understand this example. Are you saying you might have imported cars? If not why not have Toyota inherit from ImportedCar, which inherits from Car? If your assertion is that you might have other types of imports than cars, then your base class is Import, from which Car inherits. I don't really see the problem?

Re:java backend is not simple.

[Xest]

"While I can't speak for Haskell's implementation of alebra, I'd have to say that mathematically, an algebra is far more than just a definition of "actions upon an object" in the OO sense. An algebra also defines the results of those actions, while in OO, an interface only defines the type signature of those actions. So you can happily define your interface as "supports-add-and-subtract" without defining that "x - x must equal zero". This is only half of an algebra - if that."

It's the implementation of the interface that defines the actual restrictions on the type signature. The interface may declare addition and subtraction, but it is the Matrix class that implements that interface and defines the limits on how a Matrix can be added and subtracted. This isn't really any different to actual math itself, we have common operators like addition, subtraction, multiplication and so forth, but it is the type that defines how those actions are carried out and what their limitations are. The multiplication symbol (x) says nothing about how multiplication is carried out, it is just a general concept, it is the use of x in conjunction with a type that defines it - the operator acts different whether you're dealing with natural numbers, integers, or matrices and it is those types that determine the implementation.

"Personally I think we'll only move forward in language define when we switch from "types as calling signatures of methods which do who knows what" to "types as strong guarantees of results of operations". But I don't see any languages actually working on that. Some of the work on "contracts", maybe, but how many languages that have contracts make this the fundamental design feature?"

Microsoft have been working on Code Contracts for .NET, and I suspect it'll become a full feature of 4.5 or 5. It's usable now though. Fundamentally though all this is just a set of libraries, you can implement it yourself right now if you need that strict a level of checking.

Whilst I don't disagree with what you say and it being great if we had much better checks on bounds and such, I think there's a more fundamental problem with it though that technology wont solve. The problem is that to correctly bounds check all inputs and outputs is massively time consuming, and is still very error prone - a programmer is just as likely to make a mistake in defining the bounds and a hacker only has to find that one mistake.

We have techniques for writing software that offers this guarantee of rigidity already, and we long have, but the cost of the additional time it takes to put in place just isn't justifiable in business. Even the cost of a hack attack is likely lower than making sure all your code adheres to contracts or whatever.

Re:java backend is not simple.

[bigsexyjoe]

I tend to think "simplicity" was part of the goal in not including those things. As you point out it was more simplicity for the compiler, but still simplicity for the developer flows out of it in this case.

Re:java backend is not simple.

[jbolden]

"Or to be less mathy. I have "imports" and "cars" as classes why not inherit both for Toyota objects?"

I don't really understand this example. Are you saying you might have imported cars? If not why not have Toyota inherit from ImportedCar, which inherits from Car? If your assertion is that you might have other types of imports than cars, then your base class is Import, from which Car inherits. I don't really see the problem?

Then I still have a problem

Car -> ImportedCar -> Mini Cooper
is fine but

Suit -> ImportedSuit -> Gucci
I have to re-implement the entire imported structure again.

A Mini has properties of Car (like wheels) and properties of imports (like international duites)

-----

Most of the solution revolves round breaking down the problem, and reusing those broken down chunks. If you're implementing a functon that has many many lines of code and then complaining about needing to reimplement that then the chances are that you could have broken down that function more and reused parts of it.

True, but the whole idea of object orientation in terms of encouraging reuse is to make that easy. If I have to do that sort of analysis why not just use a procedural language? The whole idea of object orientation is that I can casually inherit without having to have a deep understanding of what I'm inheriting and just use the properties I want. Having to take an already existing piece of code and break in entirely new ways just to add another class, is precisely the kind of problem OO programming was invented to avoid.

Re:java backend is not simple.

[Anonymous Coward]

C# does the same thing, although you have to name the the case explicit: goto case 4;

Re:java backend is not simple.

[chochos]

But the behaviour is unpredictable for more complicated situations

Can you give an example of this? We're working hard to make Ceylon exactly the opposite of what you mention here, and even though it's still a work in progress I don't see why you would say this.

Re:java backend is not simple.

[billyswong]

Out of interest, what languages do you think are simple?

Requirement 1:
When the task complexity increases, the code complexity should NEVER increases superlinearly. Less than linear will be good if achieveable.

Requirement 2:
A program that run okay once, shall run okay ALWAYS. No subtlety induced by the language itself should be there.

Requirement 3:
(For general purpose language) If compilers/interpreters for the language cannot be "simple", then the language itself cannot.

The first general purpose computer language I learned is Pascal. Today I still like it the most. It works, and it is predictable.

Re:java backend is not simple.

[Xest]

"I have to re-implement the entire imported structure again.

A Mini has properties of Car (like wheels) and properties of imports (like international duites)"

So do as I said, if an import sits below a car, then have Import as your base class, so:

Import -> Car -> Mini Cooper

Import -> Suit -> Gucci

Stick your international duties in import, your wheels in car. This only further serves to demonstrate the point that most people think they need MI when they fail to grasp proper OO structure.

"True, but the whole idea of object orientation in terms of encouraging reuse is to make that easy. If I have to do that sort of analysis why not just use a procedural language?"

No, the whole idea of object orientation is to allow you to represent data, and actions on data in terms of objects. It does not do your job for you.

"The whole idea of object orientation is that I can casually inherit without having to have a deep understanding of what I'm inheriting and just use the properties I want."

No this is still completely false, to use OO you still have to understand it. Not understanding it does not make OO bad, it just means it's a tool you do not understand how to use properly.

I guess from your comments such as your mention of Haskell that you're a functional or procedural programmer and that's fine, but as always it seems to be the case that when most people think they need MI the real problem is that they simply don't understand OO. It goes back to my original comments - there are very few situations where MI is useful, where people think it is useful they generally just do not get object oriented architecture, and having to break a problem down doesn't breach OO principles, on the contrary it's a large part of them. I don't know why you'd ever favour great hulking monolithic functions rather than breaking down the problem, not only does this increase scope for errors, but it also reduces testability, it reduces reusability.

It goes back to the point that was made well in this post and my subsequent reply:

http://slashdot.org/comments.pl?sid=2921227&cid=40354171

That it's about understanding relationships between objects. It's about recognising that it's rarely ever the case that something is ever two things. As I say it's not that MI isn't useful in some cases, but those cases are extremely rare and misuse is thousands of times more prominent that sensible use.

Re:java backend is not simple.

[jbolden]

So do as I said, if an import sits below a car, then have Import as your base class, so:

Import -> Car -> Mini Cooper

Import -> Suit -> Gucci

Stick your international duties in import, your wheels in car. This only further serves to demonstrate the point that most people think they need MI when they fail to grasp proper OO structure.

And with that structure how do you handle a GM or a Brooks Brother's Suit? You can't have Import as a base class for Car because not all cars are imports. You can't have Cars fork into Import and Domestic because you also need Import / Domestic for Suits and no Suits are Cars.

No, the whole idea of object orientation is to allow you to represent data, and actions on data in terms of objects. It does not do your job for you.

Why do you think programmers wanted to "represent data in terms of objects"? There was no desire to do this originally, the desire came from wanting to build complex trees of types.

Programmers wanted reusability. They wanted reusability for saving in time and reduction of errors. The approach to get reusability was genericisity (inheritance) and overloading (polymorphism). What made this safe was encapsulation. So yes the whole point is to do this job for you. To make it possible for people to use object libraries they don't understand. The same way people casually hit "square root" on a calculator long before they know how calculators determine a square root.

I don't know why you'd ever favour great hulking monolithic functions rather than breaking down the problem

Because I want software extensible. And that means that the vast majority of my code, hopefully 90% or more is not specific to the problem but is very general. So if the problem changes the code can still be used. That's the whole idea of the STL in C++.

Your point in the side comment "Well a Frog is an Animal and an Amphibian so it should inherit from both!" isn't what's being talked about. A better analogy is a "Well a Tropic Frog is an Amphibian and a tropical animal".

Re:java backend is not simple.

[Xest]

"And with that structure how do you handle a GM or a Brooks Brother's Suit? You can't have Import as a base class for Car because not all cars are imports. You can't have Cars fork into Import and Domestic because you also need Import / Domestic for Suits and no Suits are Cars."

This is the problem though, you can keep on adding cases until you break a solution and say "Hey look, I told you multiple inheritance was the solution!" but you're still completely wrong. In this case you need to then question whether import even needs to be a class, or whether you just have, say, a product class with a country of origin property from which you can derive if it's imported, or just have an isImport property if you want, and a taxes data structure that includes the import taxes in it. It's still just as trivially implemented in OO without any need for MI. This particular solution would be more generic and cater to far more things you can throw at it, but that's the sort of thing you have to decide if you need when you do your analysis of the problem.

"Why do you think programmers wanted to "represent data in terms of objects"? There was no desire to do this originally, the desire came from wanting to build complex trees of types."

Because it's a more natural representation of how the world works, rather than how computers work. That was always the driving force.

"Programmers wanted reusability. They wanted reusability for saving in time and reduction of errors."

Programmers always want reusability, in everything they do and every solution they seek, it's not an OO specific trait or a driving force for OO, it's merely just a factor that was taken into account with OO, just like any other well developed software paradigm. Any new paradigm will always try and improve these fundamental traits like reusability, but that doesn't mean they're the initial driving force behind the creation of a new paradigm.

You have a very computer oriented view of what OO was designed to be which is ironically precisely what OO was about moving away from.

"Because I want software extensible. And that means that the vast majority of my code, hopefully 90% or more is not specific to the problem but is very general."

That's irrelevant to the point. A broken down problem is no less extensible, and no less reusable, it's arguably more so because a broken down component is far likely to be reusable.

"Your point in the side comment "Well a Frog is an Animal and an Amphibian so it should inherit from both!" isn't what's being talked about. A better analogy is a "Well a Tropic Frog is an Amphibian and a tropical animal"."

This just demonstrates that you still don't get OO. You would simply have a property that defines where an animal originates/lives - tropical, temperate, etc.

The world needs people like you - people who understand the functional side of things well, the side of things that's much more closely associated to the way the hardware does things, but it doesn't mean you understand OO well.

Re:java backend is not simple.

[jbolden]

This is the problem though, you can keep on adding cases until you break a solution and say "Hey look, I told you multiple inheritance was the solution!" but you're still completely wrong.

This is the same case from the start. Its just taken several rounds for you to see why you can't use a single hierarchy.

In this case you need to then question whether import even needs to be a class, or whether you just have, say, a product class with a country of origin property from which you can derive if it's imported, or just have an isImport property if you want, and a taxes data structure that includes the import taxes in it.

I don't want a taxes data structure I want hundreds of methods and objects having to do with imported vs. domestic. Imported objects may have far service offices. They have shipping times. They may have multiple conflicting law sets that apply to them.

And the whole point of object orientation is that methods are tied to data. That the object can respond to calls. If I have to go back to dealing with the data of an object and not the method I've just broken the whole OO paradigm and then I am doing procedural code.

You have a very computer oriented view of what OO was designed to be which is ironically precisely what OO was about moving away from.

No it wasn't. I was citing Meyer's Object Oriented Software Construction. I'd like a cite for your position about the origins of OO. Of course OO is computer oriented, it is a computer language design paradigm. I way of designing programming languages.

That's irrelevant to the point. A broken down problem is no less extensible, and no less reusable, it's arguably more so because a broken down component is far likely to be reusable.

Why would it be likely to be reusable? The reason is because it is generic, abstract. It is the abstraction processes not the object hierarchy that creates reusability.

This just demonstrates that you still don't get OO. You would simply have a property that defines where an animal originates/lives - tropical, temperate, etc

What's a property? A property in the OO sense has to respond to a method call. if x is a type of frog I want x.acceptableTemperature() to be a method. I don't want to do: x.origination.acceptableTemperature() otherwise I suddenly need to understand the internal structure of x and then I might as well just do:

acceptableTemperature (x.(*originationFunction())) and I'm back to procedural.

Optimally you Toyota to inherit from dozens of classes:
Show -- that is can export to a string its structure
Read -- that it can import a structure from a string
Eq -- That I can determine if two car objects are the same car or not
Cars -- Discussed
Imports -- Discussed
Database -- That is has methods for saving and recovering itself from the Database

etc... And it should inherit hundreds if not thousands of methods from that chain. Some but not most will be over ridden. When the programmer types "x.==(y)" the fact that way up in the chain equality of cars is inherited and they never even had to consider why this works, is the goal. That's not a failure of OO it is allowing OO to free the programmer for the mundane details of the base class. The person creating the finance component of the import export system shouldn't need to concern themselves with how the Cars class works anymore than they should need to understand in detail how the hard drive works.

Anyway... I think I've made the point that single hierarchies break down very fast. Obviously you can get buy with SI, people got by fine with no inheritance at all.

Re:java backend is not simple.

[Xest]

"This is the same case from the start. Its just taken several rounds for you to see why you can't use a single hierarchy."

But I've done exactly that. I've given you a solution. You're using a really weak argument here.

"I don't want a taxes data structure I want hundreds of methods and objects having to do with imported vs. domestic. Imported objects may have far service offices. They have shipping times. They may have multiple conflicting law sets that apply to them."

Sure, and all this can be represented as I say. You just need to know in your analysis from the outset what kind of level of flexibility you're planning for. You can't plan for no flexibility, then complain when you can't flex the system, sure, I agree, OO will never deal with that kind of abysmal planning, but few if any systems will. If however you have some degree of understanding of the problem domain though all this can be modelled using OO without MI in a perfectly logical and sensible manner as I have continued to prove by providing you examples.

"If I have to go back to dealing with the data of an object and not the method I've just broken the whole OO paradigm and then I am doing procedural code."

I don't even think you get the OO paradigm at all, when I mention that you can store the taxes against an object, I'm not suggesting a raw array of floats or whatever, I'm talking about implementing tax objects. You're at least aware that objects can have has-a relationships with other objects right?

"No it wasn't. I was citing Meyer's Object Oriented Software Construction. I'd like a cite for your position about the origins of OO. Of course OO is computer oriented, it is a computer language design paradigm. I way of designing programming languages."

You can cite a book that came out the best part of 30 years after the foundations for OO were laid all you want, but I'm not sure why you'd think it would be the stand out definition, more so than say, the accounts from the people who were around during the much earlier developments of OO such as here:

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

I guess you missed the whole reason why we decided to try and move away from computing-oriented paradigms.

"Why would it be likely to be reusable? The reason is because it is generic, abstract. It is the abstraction processes not the object hierarchy that creates reusability."

But the more you bundle into a function, the less generic it comes, which is precisely why it's better to break something down into less functions to ensure more components of the whole are generic, rather than writing a single monolithic function to do one single thing in a completely non-reusable manner.

"What's a property? A property in the OO sense has to respond to a method call. if x is a type of frog I want x.acceptableTemperature() to be a method. I don't want to do: x.origination.acceptableTemperature() otherwise I suddenly need to understand the internal structure of x and then I might as well just do:"

Yet again you show a complete failure to understand proper OO design, and yet again you're expanding a case that has previously been analysed with a set of given conditions to say "Hey, look, it's wrong now!". If you want to find out information about a climate zone, then you make that climate zone a more detailed data structure, or an object in itself that can tell you the temperature range. This makes sense because in your example you're saying it's really the climate zone that defines the temperature, so it should be the climate zone from which you find the temperature range, however this is a really dumb examples as species still have different temperature requirements even in existing climate zones, so more realistically you'd just set acceptableTemperature against the species anyway.

"Optimally you Toyota to inherit from dozens of classes:"

No you don't, that's absolutely horrendous design and yet

Re:java backend is not simple.

[jbolden]

Why can't this go in a base class in the way it does perfectly well in Java and .NET? Why would you want a different class for each of these?

I actually like JAVA's implementation with an over rideable .equals operator. The only problem with that implementation is that it kills one of the crucial components of equals, reflexivity i.e. a.equals(b) and b.equals(a) should in general be the same value and in Java you aren't guaranteed that. That solution of adding this sort of functionality into the base class is fine, though it moves away from OO design but in general data equality is what you want.

Read and Show though are exactly what I'm looking for. By bundling these with java.io (writeObject) objects can either have or not have this method, i.e. they can either implement or not implement the interface. And I'd say the fact that Java has this sort of interface approach is an example of the importance of MI that the designers of Java recognized. All interfaces are is multiple inheritance with better handling of the diamond problem. Similarly your comments on Database.

As for Alan Kay, you should read the article yourself, "that objects are a kind of mapping whose values are its behaviors." He talks about the reflexivity of data and functions which came from LISP. And that's precisely what I'm talking about and what is completely lost in languages like Java and C#.

Re:java backend is not simple.

[blackfireuponus]

@Xest jbolden seems to have a much better grasp of object oriented programming than you. Multiple inheritance is a real issue in comp sci that you can't dismiss as a non-problem with a wave of your hand and an ad-hoc solution. Java provides the functionality of MI with interfaces. There is a reason it needed to be provided.

Re:java backend is not simple.

[solidraven]

Oh no, SPARC is a wonderful architecture. Very efficient and well designed. But it's assembly just isn't my thing. But in it's defence it is consistent compared to some of the other assembly languages of that era.
And I agree, PA-RISC wins by a large margin.

Find/replace "Simple" with "Good"

[metrometro]

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.

Re:Every programming language is touted as "simple

[billyswong]

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.

My judgement is, simple things should have simple codes.

Of course, what do "simple" means is always subject to debate, as discussed in the article.
Is it simple to read by human? read by machine? debug?

They didn't forget..

[Anonymous Coward]

But then they forgot one thing: NEVER underestimate humans stupidity.

Most language designers don't forget - they either assume you can handle the responsibilities of the language + the consequences of it's misuse, or they just don't care (which can be prompted by a variety of things: egomaniac, overly opinionated, semi-retarded, etc.)

Re:Every programming language is touted as "simple

[Gideon Wells]

Well, from my understanding changing times/styles also contribute to this. Wasn't C once considered a relatively "high" language when it first emerged and is now more of a "middle" language?

Compared to rubbing two sticks together or use of flint matches are "simple", but now we have lighters.

Simple Made Easy

[slasho81]

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.

Re:Simple Made Easy

[Anonymous Coward]

He's also done a more recent but similar talk at RailsConf 2012: Simplicity Matters by Rich Hickey

Re:Simple Made Easy

[Anonymous Coward]

Messed up the link: Keynote: Simplicity Matters by Rich Hickey

Re:Simple Made Easy

[slasho81]

I've seen it as well, and I recommend seeing everything Rich Hickey on the web. He's incredibly insightful and a great presenter. However, if someone only watches one talk of his, I think the talk from Strange Loop would be the best. Second talk I'd recommend is Are We There Yet?

Re:Simple Made Easy

[mounthood]

He's a smart guy and that's a good talk, but his arguments about simplicity are a little weird. Trying to use the etymology of the word 'simple' as a justification for design choices? I found Clojure to be a language where first you had to make the leap-to-lisp before it was easy, and making that transition wasn't helped by having the JVM/standard lib/Java syntax as prerequisites (not to mention lein/ant/maven/ide configs/etc...).

Heh, consider what this description says about clojures simplicity: "Leiningen is for automating Clojure projects without setting your hair on fire."

Re:Simple Made Easy

[cduffy]

Heh, consider what this description says about clojures simplicity: "Leiningen is for automating Clojure projects without setting your hair on fire."

Keep in mind that Clojure users could use Ant or Maven or Grails for their build system, and all of those work perfectly fine; Leiningen, on the other hand, is simpler than any of them.

Clojure developers have a high bar for simplicity, albeit measured in a way that might not make much sense to anyone who doesn't first grok LISP.

Ruby's Principle of Least Surprise

[rubycodez]

Matz designed Ruby with "principle of least surprise" in mind. No, not for you. you might be surprised or not. It's whatever causes least surprise to the creator Matz. 8D

Re:Ruby's Principle of Least Surprise

[murdocj]

Yes. And perhaps Ruby is simple... to Matz. One important point: simpler != fewer characters in source code.

Re:Ruby's Principle of Least Surprise

[Jane Q. Public]

"One important point: simpler != fewer characters in source code."

But you can be as verbose as you like in Ruby. Unlike many other languages, the "standard" way of getting things done is not mandatory. You have options.

So you can make your source code compact, or, if you think that's not easily readable, expand it to a "simpler" form.

Case in point: while working on a project, one of my fellow workers (very smart guy) refactored some of my code to a single line of nested lambdas.

I examined his code very carefully. But the simple fact was that it was too hard to mentally picture what was going on in his code.

So I changed it back. Readability is important in maintaining code, and who knows who would be looking in the same code in the future? But I maintain that Ruby is usually quite readable, as long as you aren't trying to be too clever with it.

Re:Ruby's Principle of Least Surprise

[binary paladin]

I love Ruby. It's easily my favorite language right now.

With that said, more verbose doesn't always equate to easier to read nor does terse and short equate to simple. I'm very happy with Ruby's flexibility in that regard.

Re:Ruby's Principle of Least Surprise

[Jane Q. Public]

I can hardly wait for Ruby 2.0. They have promised at least the ability to bytecode-compile scripts and that should do a great deal to promote it for making desktop apps. Currently, it is not usually used for desktop apps because your code is 100% exposed.

Even MacRuby does not really compile, but exposes your raw code. JRuby does, of course, but it's not 100% compatible and requires JVM. JRuby is an admirable project, don't get me wrong... but having native bytecode compilation would be tremendous.

One of the reasons for Java's success is that you can use bytecode-compiled programs across desktop platforms. Not much else is really doing that.

Re:Ruby's Principle of Least Surprise

[lucian1900]

It's trivial to decompile Java bytecode, and even decompiling machine code isn't all that hard. It really doesn't matter, just use Ruby for desktop apps if you like it.

Re:Ruby's Principle of Least Surprise

[Anonymous Coward]

shhh

Re:Ruby's Principle of Least Surprise

[Jane Q. Public]

"It's trivial to decompile Java bytecode, and even decompiling machine code isn't all that hard. It really doesn't matter, just use Ruby for desktop apps if you like it."

It is trivial for knowledgeable people to decompile bytecode. It isn't trivial for the majority of commercial software customers. And it is far more trivial to simply read the raw code from non-compiled programs.

Further, don't confuse the task of decompiling with the task of making sense of the decompiled code. In most cases there are no meaningful variable names; instead they get named things like "integer0", or whatever the decompiler decides is a good designation. And it is not generally well-formatted, either. All in all, the decompiled code I have seen is vastly harder to read and make sense of than regular source code.

Re:Every programming language is touted as "simple

[Anonymous Coward]

I remember C was touted as being "lightly typed" back in the day, when compared two of its main rivals PL/1 and Pascal. In retrospect I'm not really sure what that meant, except that it seemed "low ceremony" and less verbose compared to its main rivals at the time, Pascal and PL/1. Blocks were delimited by curly braces instead of begin/end, arrays could be initialized as part of the declaration, most identifiers were lowercase by convention, etc.

Also, specification of data types was optional in some cases, for example, the return type of a function. And casts could be used freely for type conversion. Some of this stuff was tightened by ANSI C (following C++).

Re:Every programming language is touted as "simple

[phantomfive]

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.

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

Any Non-Relational Language is OVER-Simplified

[Baldrson]

Functions are special cases of relations. Procedures are functions between states (ie: STATEments).

Stop looking under the lamp post for the keys.

Re:Any Non-Relational Language is OVER-Simplified

[Anonymous Coward]

Procedures are functions between states (ie: STATEments).

What the fucking fuck?

Re:Any Non-Relational Language is OVER-Simplified

[Anonymous Coward]

Don't worry, there's always a few nutters about when programming languages get mentioned. I'm surprised the COSA troll hasn't visited us yet.

Re:Any Non-Relational Language is OVER-Simplified

[Baldrson]

Procedures consist of a sequence of statements. Each statement is a function mapping one state of the procedure onto the next state of the procedure.

That's what the fucking fuck.

Re:Any Non-Relational Language is OVER-Simplified

[Baldrson]

They should change "anonymous coward" to "anonymous militant ignoramus coward".

Charles Nutter didn't develop Ruby

[Anonymous Coward]

In should be common knowledge that Matz developed Ruby. Charles Nutter and others developed jRuby, an implementation of Ruby on top of Java. That was more than 10 years after Ruby was born. Slashdot summary again.

Re:Charles Nutter didn't develop Ruby

[Anonymous Coward]

> Slashdot summary again.

Why would you clutter a summary of a person's biography when you can google the names? Since you're reading about them, maybe you should know who they are before caring about their opinion? Slashdot commenter again.

Re:Every programming language is touted as "simple

[Jane Q. Public]

"Wasn't C once considered a relatively "high" language when it first emerged and is now more of a "middle" language?"

No, C has never been considered a "high level" language in the Computer Science world, when compared to its predecessors such as BASIC and PASCAL. (Say what you want about BASIC, but it *is* a high level language, and vastly more so today than when it first appeared.)

People who insist that C a "high-level" language (you did not do that) make me cringe. At best, C is a "mid-level" language, lying somewhere between a high-level language and Assembly.

at least Clojure isn't C/Java/C++/Perl/etc syntax

[Anonymous Coward]

At least a language like Clojure is different. What gives me the most problem as a developer is the fact that most languages these days are sort of like C, C++, and Java but different. I can't easily remember how to do something in any given language. I want to take the length of a string, for example, or use an array, and just draw a total blank. len()? length()? strlen()? string.len? string.length? string.len()? string.length()? Who knows? Run the compiler/interpreter and see if it accepts the syntax. Do I put the brackets with the type or the variable when I want an array? Does this language use angle-bracket types for containers? Too many languages are similar, but they're different in small ways, and that causes a lot of cognitive dissonance if I have to switch.

Re:Every programming language is touted as "simple

[Anonymous Coward]

C was considered high level language a long time ago. There was a time when anything more than mnemonics for machine instructions was called "high level".

Re:Every programming language is touted as "simple

[not-my-real-name]

I'm not sure that C is that old. FORTRAN, COBOL, and LISP (and a number of others) are all older than C and are higher level than C. Not to mention that the LISP enthusiasts probably consider all other languages to be lower level languages.

Clojure and Datomic are nothing short of amazing

[Anonymous Coward]

Clojure has very powerful lockless/lockfree concurrency and it's amazingly simple to use. You cannot deadlock Clojure programs: that has to count for something in this day and age of multicores CPUs.

The Rich Hickey also created something else that is totally fascinating: it's some sort of a DB abstraction layer that provides a CRA DB (Create Read Append). There's no Update and no DELETE. It's fully ACID. It can work on top of DBs stored in the cloud on a shitload of servers, it can work in-memory, it can work over PostgreSQL etc.

And you can do queries like: "What would this query have returned as a result if I had executed this query at this particular time in the past?"

This is the future. I'm not saying it works for every single DB use case but it definitely can replace most CRUD DBs out there.

If you've never watch a video by Rich Hickey I really suggest you to Google it: he's a good speaker and he's obviously a very, very, very smart person.

Now of course Clojure is a Lisp dialect so people are going to whine about your father's parentheses... The very funny part regarding this of course is that seen that how few lines of code you typically need in Clojure compared to some bracket-syntax language you basically always end up with less parentheses for a task done in Clojure than for the same task done with Java / C++ / C# etc.

; )

Re:Every programming language is touted as "simple

[JonySuede]

It must have been a real long time ago as I did wrote win98 vxd in C and in high level assembly (assembly with complex macros, but not more complex than recursive substitutions). My C driver, that did the exact same thing as my HLA one, was bigger and less understandable than other one. It was that way since function pointers get rapidly ugly. A big contrast to assembly where there are no types, only words sizes and alignment.

According to my anecdotal knowledge, C is only an ubiquitous portable assembly language; nothing more, since a good set of macros in assembly can be more terse than C if you target only one type of CPU.

Re:Every programming language is touted as "simple

[Nutria]

In the 1980s, C was considered a high-level assembly language.

Re:Every programming language is touted as "simple

[Anonymous Coward]

Not in the CS world, but EEs definitely do consider C a high-level language.

Language simplicity

[nbsr]

"For Clojure, it is about keeping the language itself simple."

No, it is not. It is about simplicity and flexibility of composing small pieces of code into complex software systems, something most languages and toolkits seriously suck at. The nice thing about Clojure is that its principles are so easy to grasp - data don't change while you're looking at them, and operations on these data can be arbitrarily composed because they only take a value in and produce a value out. That's all, after using it for a while I wonder why languages weren't like this from the beginning.

The language itself, while simple, is more complex than many other Lisps. OTOH, it is much simpler than Haskell, which has similar goals (among many many others).

Re:Every programming language is touted as "simple

[cduffy]

"Win98" and "a long time ago" have no business being remotely close to each other -- when we're talking programming language lineages, many of the developments still interesting today happened between the 60s and the 80s, and some (LISP) date back to the 50s.

Now get off my lawn!

Re:Every programming language is touted as "simple

[ratboy666]

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.

Re:Every programming language is touted as "simple

[Jane Q. Public]

"I'm not sure that C is that old. FORTRAN, COBOL, and LISP (and a number of others) are all older than C and are higher level than C."

This is precisely what I was saying. It came later, but was lower-level.

And it was, for the specific purpose of being more performant. It is not easier to use, it is not "simpler" to learn to use wisely. It is just more efficient at the compiled level, which being drastically less "efficient" at the code level. Personally, I can barely stand to look at it.

Re:Every programming language is touted as "simple

[Jane Q. Public]

"According to my anecdotal knowledge, C is only an ubiquitous portable assembly language; nothing more, since a good set of macros in assembly can be more terse than C if you target only one type of CPU."

I would tend to agree with this. That was exactly the purpose of C. It wasn't "high level", but it played well cross-platform while Assembly did not. So it was "higher level" than Assembly, in that it abstracted out much of the hardware interface.

Re:Every programming language is touted as "simple

[TheLink]

I prefer perl instead of Lisp for reasons I gave in my second last paragraph. I find it easier to find and use the libraries (CPAN). Yes there's cliki but it's far from as good - problem/domain coverage, documentation etc.

But Java *IS* simple!

[Qbertino]

Java combines the natural and easy syntax of C with the blazing speed of Smalltalk.

*Tadum* *Crash* *Thud*

Thank you, thank you, I'm here all week. Try the fish and tip your waitor.

Re:Every programming language is touted as "simple

[jeremyp]

C is absolutely fairly and squarely a high level language.

What features do Pascal and Fortran and Cobol have that make them high level and C not?