×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ruby, Clojure, Ceylon: Same Goal, Different Results

timothy posted about 2 years ago | from the ways-of-seeing dept.

Programming 138

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

138 comments

Bitchfight! (0, Redundant)

Anonymous Coward | about 2 years ago | (#40351793)

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

Lot's of information about Clojure... (3, Insightful)

betterunixthanunix (980855) | about 2 years ago | (#40351829)

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

Anonymous Coward | about 2 years ago | (#40351899)

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

quintesse (654840) | about 2 years ago | (#40352265)

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... (3, Informative)

pmontra (738736) | about 2 years ago | (#40352053)

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... (3, Informative)

MarchHare (82901) | about 2 years ago | (#40352135)

A slightly better way, IMHO:

    String.instance_methods.grep /sub/

Re:Lot's of information about Clojure... (1)

pmontra (738736) | about 2 years ago | (#40352233)

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

PCM2 (4486) | about 2 years ago | (#40353485)

Programmers with zero *nix background puzzle me.

Re:Lot's of information about Clojure... (1)

Hognoxious (631665) | about 2 years ago | (#40354947)

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

Jane Q. Public (1010737) | about 2 years ago | (#40353489)

"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... (0)

Jane Q. Public (1010737) | about 2 years ago | (#40353479)

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

Every programming language is touted as "simple" (4, Insightful)

Anonymous Coward | about 2 years ago | (#40351909)

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

Re:Every programming language is touted as "simple (1)

billyswong (1858858) | about 2 years ago | (#40352109)

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?

Re:Every programming language is touted as "simple (3, Insightful)

TheLink (130905) | about 2 years ago | (#40352809)

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

Re:Every programming language is touted as "simple (1)

Gideon Wells (1412675) | about 2 years ago | (#40352215)

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.

Re:Every programming language is touted as "simple (1)

Anonymous Coward | about 2 years ago | (#40352353)

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 (1)

Jane Q. Public (1010737) | about 2 years ago | (#40353541)

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

Re:Every programming language is touted as "simple (0)

Anonymous Coward | about 2 years ago | (#40354551)

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 (1)

not-my-real-name (193518) | about 2 years ago | (#40354797)

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.

Re:Every programming language is touted as "simple (1)

JonySuede (1908576) | about 2 years ago | (#40355307)

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 (1)

Nutria (679911) | about 2 years ago | (#40355865)

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

Re:Every programming language is touted as "simple (0)

Anonymous Coward | about 2 years ago | (#40356053)

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

Re:Every programming language is touted as "simple (2, Insightful)

phantomfive (622387) | about 2 years ago | (#40352385)

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.

Mad (3, Insightful)

Anonymous Coward | about 2 years ago | (#40351941)

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.

 

Success (1)

phantomfive (622387) | about 2 years ago | (#40351963)

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 (1)

Osgeld (1900440) | about 2 years ago | (#40352111)

apparently its a java remix

Re:Success (1)

Jane Q. Public (1010737) | about 2 years ago | (#40353623)

"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 (1)

quintesse (654840) | about 2 years ago | (#40353979)

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 (0)

Anonymous Coward | about 2 years ago | (#40354473)

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

java backend is not simple. (0)

billyswong (1858858) | about 2 years ago | (#40352029)

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

Re:java backend is not simple. (-1, Troll)

Anonymous Coward | about 2 years ago | (#40352077)

The problem with Java isn't the simplicity of the language. The problem is the designers assumed that all programmers are simple minded idiots. From what I understand, the general design principal was if they could do away with a feature that a bad programmer could do wrong, then they did. That's why there is no easy to explicitly do things such as pointers, gotos, and operator overloading.

Re:java backend is not simple. (1)

sribe (304414) | about 2 years ago | (#40352119)

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

billyswong (1858858) | about 2 years ago | (#40352147)

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

They didn't forget.. (0)

Anonymous Coward | about 2 years ago | (#40352209)

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:java backend is not simple. (3, Interesting)

svick (1158077) | about 2 years ago | (#40352235)

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

AuMatar (183847) | about 2 years ago | (#40353491)

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

Anonymous Coward | about 2 years ago | (#40353583)

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

AuMatar (183847) | about 2 years ago | (#40353625)

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

svick (1158077) | about 2 years ago | (#40353611)

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. (5, Informative)

jbolden (176878) | about 2 years ago | (#40352659)

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

Xest (935314) | about 2 years ago | (#40353431)

"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. (2)

AuMatar (183847) | about 2 years ago | (#40353513)

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

Xest (935314) | about 2 years ago | (#40354103)

"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. (2, Interesting)

Anonymous Coward | about 2 years ago | (#40354163)

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

Anonymous Coward | about 2 years ago | (#40354521)

"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. (2)

jbolden (176878) | about 2 years ago | (#40353865)

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

Xest (935314) | about 2 years ago | (#40354173)

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

jbolden (176878) | about 2 years ago | (#40354459)

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

lennier (44736) | about 2 years ago | (#40354959)

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

jbolden (176878) | about 2 years ago | (#40355637)

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

dkf (304284) | about 2 years ago | (#40354171)

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

Xest (935314) | about 2 years ago | (#40354279)

"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. (0)

solidraven (1633185) | about 2 years ago | (#40352255)

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. (0, Offtopic)

0123456 (636235) | about 2 years ago | (#40352497)

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

solidraven (1633185) | about 2 years ago | (#40352759)

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

0123456 (636235) | about 2 years ago | (#40353601)

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

Anonymous Coward | about 2 years ago | (#40354411)

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

jbolden (176878) | about 2 years ago | (#40352671)

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

solidraven (1633185) | about 2 years ago | (#40352803)

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

rubycodez (864176) | about 2 years ago | (#40353043)

oh my, Ada. COBOL meets Pascal. ;P

Re:java backend is not simple. (1)

solidraven (1633185) | about 2 years ago | (#40353581)

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

rubycodez (864176) | about 2 years ago | (#40355657)

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

jbolden (176878) | about 2 years ago | (#40353053)

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

solidraven (1633185) | about 2 years ago | (#40353563)

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

amorsen (7485) | about 2 years ago | (#40354089)

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

solidraven (1633185) | about 2 years ago | (#40354461)

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

jbolden (176878) | about 2 years ago | (#40354305)

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 [wikipedia.org] 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. (1)

solidraven (1633185) | about 2 years ago | (#40354547)

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

jbolden (176878) | about 2 years ago | (#40354919)

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

Anonymous Coward | about 2 years ago | (#40353041)

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

Jane Q. Public (1010737) | about 2 years ago | (#40353699)

"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. (1)

solidraven (1633185) | about 2 years ago | (#40354771)

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

amorsen (7485) | about 2 years ago | (#40354037)

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

solidraven (1633185) | about 2 years ago | (#40354827)

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

amorsen (7485) | about 2 years ago | (#40355007)

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 [99-bottles-of-beer.net]

Find/replace "Simple" with "Good" (2)

metrometro (1092237) | about 2 years ago | (#40352093)

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.

Simple Made Easy (2)

slasho81 (455509) | about 2 years ago | (#40352253)

Rich Hickey's keynote talk from Strange Loop: Simple Made Easy [infoq.com]. 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 (0)

Anonymous Coward | about 2 years ago | (#40352331)

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

Re:Simple Made Easy (1)

slasho81 (455509) | about 2 years ago | (#40352571)

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? [infoq.com]

Re:Simple Made Easy (1)

mounthood (993037) | about 2 years ago | (#40353437)

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

Ruby's Principle of Least Surprise (1)

rubycodez (864176) | about 2 years ago | (#40352297)

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 (1)

murdocj (543661) | about 2 years ago | (#40353643)

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

Re:Ruby's Principle of Least Surprise (1)

Jane Q. Public (1010737) | about 2 years ago | (#40353755)

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

Any Non-Relational Language is OVER-Simplified (1)

Baldrson (78598) | about 2 years ago | (#40352921)

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 (0)

Anonymous Coward | about 2 years ago | (#40353215)

Procedures are functions between states (ie: STATEments).

What the fucking fuck?

Re:Any Non-Relational Language is OVER-Simplified (0)

Anonymous Coward | about 2 years ago | (#40353423)

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 (1)

Baldrson (78598) | about 2 years ago | (#40354653)

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

Re:Any Non-Relational Language is OVER-Simplified (1)

Baldrson (78598) | about 2 years ago | (#40354625)

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.

Charles Nutter didn't develop Ruby (0)

Anonymous Coward | about 2 years ago | (#40353055)

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 (0)

Anonymous Coward | about 2 years ago | (#40353259)

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

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

Anonymous Coward | about 2 years ago | (#40353615)

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.

Clojure and Datomic are nothing short of amazing (0)

Anonymous Coward | about 2 years ago | (#40354931)

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.

; )

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...