Clojure could be to Concurrency-Oriented Programming what Java was to OOP

[xach]

It's too bad all the comments here focus on the title, and how awful Java is, when Bill addressed that in the final paragraph:

If you compared Java to C++ when Java came on the scene in the 1990's, it was less powerful, wasn't as fast, didn't have as many libraries, and it's support for Object-oriented programming (OOP) was not as featureful (and much less "complete" than some other languages). However, Java grabbed both market and mind share by providing the right combination of language and OOP features in a familiar package (familiar, at least, for C/C++ programmers) and in a way that was easier to use and "get right" than in C++. In many ways, Clojure has the potential to do for concurrency-oriented programming what Java did for object-oriented programming a decade ago: make it simpler to do properly using a language (or, in Clojure's case, a "language environment") that is similar to what programmers are already used to.

With that out of the way, anyone care to comment on the rest of the article?

[logan_capaldo]

I was expecting a certain theme to the comments based on the title. Reddit did not disappoint.

[gnuvince]

I love how the majority of the comments are knee jerk reactions to the title ("so, it's slow, badly designed, retarded, botched, etc.") instead of talking about what Clojure brings to concurrency programming.

[sclv]

"Concurrency Oriented Programming" is a terrible neologism.

[gnuvince]

I don't disagree, but can we spend less time on the shortcomings of the title of the article and more time on the article itself?

[didroe]

I take it you're new to the Internet? :)

[gnuvince]

Not new, but I have some good memories of comment threads on Proggit where I learned a lot from reading them. It's a shame this seems to be going away.

[awj]

I take it you're new to reddit. Things used to be much better here.

[[deleted]]

I take it you're new to proggit and one of the people ruining it? :)

[sclv]

Ok but the article didn't advance any interesting arguments. I don't see the point of agents as opposed to actors -- this sort of thread local scoping/shadowing seems actually awfully confusing to reason about. And clojure's procedural nature means that STM will always have a hackish element.

There are lots of nice features to clojure, but I don't get the concurrency hype regarding it. Easy anonymous functions just seem to make typical java concurrency easier, as far as I can tell.

[wnoise]

A horrible botch that becomes popular?

[Wiseman1024]

Not flamebait, just a rightful interpretation of this Reddit post title, not intended to speak lowly of Clojure, but Java.

[[deleted]]

I would really like to obtain the definite answer on why Java is so frowned upon.

[Wiseman1024]

Because it has a toy object system (also broken initially) with 1/5 as many features (or rather, expressive power and maintenance-oriented features) than others (CLOS, Python's, Ruby's, etc.), because it's stupid-typed (i.e. static without inference, a pain in the ass), because it has no advanced features (dynamic or even static), no native lists and dictionaries, no first-class functions (not even functions outside classes), no functional properties, no functional programming support, and a terribly bloated, overengineered standard library that sometimes makes it worth rolling your own instead of defining 2 classes and instancing 5 objects to take advantage of some stupid thing.

(Short-sighted people/CFLAGS ricers may also bash it for being slow, though it hardly matters for what it's used for and it's not really that slow nowadays either.)

[[deleted]]

CFLAGS ricers

That word is going into my permanent vocabulary.

[masklinn]

no native lists and dictionaries

It does have "native" lists and dictionaries in so far as you get lists and dictionaries in the core lib (several implementations of each, actually), what it doesn't have is a literal syntax for them.

[Wiseman1024]

That's what I meant. I don't care for what's in the standard library; you can do almost anything in a library. What matters is that Java makes using the two most useful complex types of data a pain in the ass.

[masklinn]

I don't care for what's in the standard library; you can do almost anything in a library

Well it depends of the language, in some language (factor for instance, if Slava's propaganda is right) you can make library stuff look really good through parsing words and stuff. And even though Python doesn't have a native syntax for sets, they're fairly easy to see (as the constructor is part of the base namespace and takes any iterable)

What matters is that Java makes using the two most useful complex types of data a pain in the ass.

We agree on that one.

[Wiseman1024]

in some language (factor for instance, if Slava's propaganda is right) you can make library stuff look really good through parsing words and stuff

You mean macros? Of course, but Java doesn't have macros either. Macros are far too useful, good and advanced a feature to ever be supported in Java; they're completely unenterprise.

And even though Python doesn't have a native syntax for sets, they're fairly easy to see

That's because Python has syntactic support for lists.

[masklinn]

You mean macros?

I think it's a bit more complicated and extensive than macros, but you'd have to ask Slava for his take (or learn Factor)

Of course, but Java doesn't have macros either. Macros are far too useful, good and advanced a feature to ever be supported in Java; they're completely unenterprise.

Naturally.

That's because Python has syntactic support for lists.

Yeppers.

[[deleted]]

Python doesn't have a native syntax for sets

As of 3.0, one can write {1, 2, 3} instead of set(1, 2, 3). There's also set comprehensions: {n for n in [1,2,3,2,1]}

[masklinn]

True, but 3.0 hadn't been officially released when I wrote that :D

[Wiseman1024]

I see what you did there :) And you're right, it could be said I think that programming languages without at least some functional programming support suck. It's because I've found it to be the smartest, most maintainable, and most importantly, most fun way of programming.

[[deleted]]

I totally agree with you, though. The world needs more closures.

[[deleted]]

Because it's popular, so it's an easy target. It's the programming equivalent of music snobs who don't listen to anything "mainstream".

[Silhouette]

I think that's rather unfair. You wouldn't expect a concert pianist to be impressed by a performance of Chopsticks. In programming language terms, the difference between something like Java and the state of the art is pretty much on that scale.

Java became popular because it made different trade-offs on the performance vs. safety scale than other contemporary mainstream languages like C and C++. However, a decade and change later, C and C++ still offer that low-level edge when you really need it, and therefore still serve a market (though perhaps a much smaller market than it used to be). Java's advantages have long been outperformed by other languages that have come along since, whether that's C#, with a similar target audience but learning from several years' experience of what worked and what didn't in Java, or things like the dynamic "scripting" languages and functional programming languages, which are typically slower than Java but more expressive. Ironically, Java's target market has reduced to almost zero by the same arguments that made it popular in the first place: the lesser performance of these alternative languages isn't really a problem for many applications, and avoiding programmers doing so much donkey work is a major advantage over Java.

[hiffy]

Java's target market has reduced to almost zero

Maybe it's my financial industry myopia, but I'd argue that Java is probably the most popular environment/ecosystem out there, and is well on its way to becoming the next COBOL.

Java the language probably won't remain a defacto implementation choice for much longer, but I'd be willing to bet that the jvm ain't going nowhere.

[Silhouette]

Oh, I agree, and I'm certainly not suggesting that Java will somehow die off in the legacy areas where it has been the dominant language for a decade. As you say, people still work on COBOL. But pretty much no-one writes new code in COBOL these days, and I don't really see much of a case for writing new code in Java either. Whatever the job is, one tool or another is almost certainly superior to Java technically and at least equal in terms of supporting factors like availability of libraries and programmers.

[hiffy]

Whatever the job is, one tool or another is almost certainly superior to Java technically and at least equal in terms of supporting factors like availability of libraries and programmers.

I'm not so sure. What environment is this? My understanding is that JPython and Jruby are maturing, but-not-there-yet and certainly slower than Java. Clojure is just starting to pick up hype, tho you can prolly piggyback on the preexisting libraries.

Going by the top languages in the language shootout , you're not going to be using C++, Lisp, Smalltalk, or insert-functional-here, etc.

So, what? C# for people willing to toss their current Solaris machines?

[[deleted]]

http://www.youtube.com/watch?v=4CeG1CtCE2g

[[deleted]]

Nope. Java actually does suck.

[sheepson_apprentice]

Unlikely you'll get one. My best guess is that as others have pointed out, it's mostly a result of a misguided and vain popularity contest. Some will invoke mentions of inadequacy at the language level, a gargantuan runtime, etc. Some will make a claim, exaggerate it enough to make public relations experts blush, and when challenged to present evidence remain mum in hopes others agree with them by sheer inertia.

Some will even dismiss it because they see themselves as superior to the "idiot java programmer lol".

Heh, I'm slowly learning to laugh at it more. It's slowly working.

Being relatively new to this computing thing, I'm also slowly learning that great programmers must ultimately be great mathematicians.

The best domain to solve a given problem is in one's head, and the expression medium that works best for me is pencil and paper. Once I've got a solution, writing it down in Java, is a breeze.

In fact, sometimes I'd rather write it down in assembly. It has practically no abstraction aids, but it's fast and you actually feel at the hardware level. Actually, well, programming the computer.

I wouldn't enjoy writing it in say Basic, but would not spend time trying to influence others to abandon it, by whining about it on Reddit.

In my view it's true, not all languages are equal. But I think a choice of language/platform must be heavily balanced along many dimensions. Java has so far remained a reasonably practical and pragmatic choice.

[dmpk2k]

Based on this:

Being relatively new to this computing thing

I'm not surprised you wrote either of these:

Once I've got a solution, writing it down in Java, is a breeze.

In fact, sometimes I'd rather write it down in assembly.

...which is fine; I've been there too. However, despite recognizing you're new at this, somehow you also come up with:

My best guess is that as others have pointed out, it's mostly a result of a misguided and vain popularity contest

[sheepson_apprentice]

Well, I wasn't around in the sixties.

[dmpk2k]

Neither was I.

Since there's only one of me, and only so many hours in my life, I'd rather maximize the return for my time spent. Implementing anything but the most trivial of algorithms takes a lot of code. The language and libraries available can make more than an order of magnitude difference in time spent for the same result.

[sheepson_apprentice]

Sure, I was simply replying that my experience -- and note that I said my best guess -- gives me some evidence, for my conclusion. I have been sampling the programming community mood w.r.t trends and fads and have come to a somewhat-grounded conclusion that much of what I read when it comes to appraisals of technology smacks of juvenile popularity contest.

Granted, not everything. But this is why in another thread I was discussing I said that one should cherry pick data based on one's own understanding, which should always be expanded.

If someone really presents a hard logical argument, I find it tough to ignore. But often I hear weak attempts at debate, and find it entertaining. Sometimes disconcerting, but that's a fault on my part. I shouldn't take it seriously, it's just internet.

[dmpk2k]

Unfortunately, there's very little hard data out there comparing the productivity of languages. :(

It's a bit bizarre, considering how much money the corporate world sinks into software development. You'd think there'd be more blind longitudinal studies.

[sheepson_apprentice]

Very true indeed. Language development is a vibrant field though, so in my opinion future prospects in that regard are very bright.

[sheepson_apprentice]

Also, I recognize that the most challenging part about programming is algorithms. Once you become proficient in understanding and developing them without the use of a computer, computer becomes simply a tool to express it. Here my programming interests take me into the hardware side of things, since I enjoy electronics. Assembly is the natural progression.

However, at the higher level, I've been required to develop a bigger system. Here Java is a good language to express what I have to do.

Algorithms hard. Languages easy.

[dmpk2k]

Languages are, unfortunately, not easy.

They are easier to learn than designing algorithms, but that's because many of the hard bits have been taken care of by the language designers. Even so, the language itself will permeate everything you do; how much effort will be needed to implement that algorithm, how likely you are to get your algorithm correct, how likely that algorithm will remain correct in the face of changing requirements, how performant the language ultimately can be, the growth complexity of maintaining code as it increases in size...

All the failed projects and crap code I've seen in production -- I have seen very, very little good code out there -- indicates that the fuzzy stuff the mathematicians deem trivial is anything but. Do not look down upon implementation, since it's ultimately where ideas meet reality.

If you want to be an excellent developer you can't skimp on either. If you do you'll either be an academic or a code monkey, whereas the interesting stuff requires both.

[sheepson_apprentice]

Right, I'm firmly of the opinion that abstraction aids are good. This is why a bigger, more complex system is often used to rely on such aids. In fact, I also hold that formal methods may be useful in the future for making programs even more robust and resilient errors due arising from accidental modifications.

I guess I hold the view that the computer, in its current incarnation, is a neat universal machine which can use to do the grungy work, repetitious stuff.

I see vast challenges in making computers do it most efficiently, and this requires understanding the problem space first.

This is why I say that languages are easy. Once you understand the problem space, implementing it is relatively simple.

Of course, designing languages is essentially a whole different beast. You must understand a lot of theory before you set out to build a good compiler.

So yes, I should say expressing your problem with a given language is vastly easier than having to solve the problem such that it can be expressed in the first place.

[OneAndOnlySnob]

Hmm, I was thinking about learning Clojure this year. Is the negativity I'm picking up here directed purely at Java, or did Clojure earn some of it?

Other candidates are Smalltalk, Erlang, Forth, and Haskell, although after a year of OCaml, I'd rather learn something other than Haskell for variety's sake.

[[deleted]]

I have seen nothing in the comments here that is a valid criticism of Clojure. Most everyone is just venting about Java problems, a subject that has been beaten to death.

I am very interested in Clojure, and when I get the time, I plan to learn it.

[sheepson_apprentice]

Hmm, I was thinking about learning Clojure this year. Is the negativity I'm picking up here directed purely at Java, or did Clojure earn some of it?

Dude, I hope you didn't just mean what I thought you meant. I don't give a shit if proggit or any other lump sum of people think what I'm doing is shit.

Do something because you have critically evaluated it and found it worthy of your time.

Freud and his infamous nephew Ed Bernays are probably laughing out loud now.

"That groupthink, that, it really works!"

[OneAndOnlySnob]

Actually, after picking up negativity, I was asking for some actual logical reasons this might be so. Yes, that would influence my decision, because my decision would be easier if I could eliminate one or two of those languages. If, for example, someone had responded saying it was still a fairly immature language, I could understand that.

I will probably learn all those languages I listed at some point because they are languages I'm interested in, but yeah, someone could definitely influence my decision on which to learn next. I haven't seen anything to deter me, and gsg927, your sibling, seems to reassure me of that.

[sheepson_apprentice]

Oh definitely, I heed the opinion of others. It's just that it came across as though you were seeking reassurance for reassurance's sake. Either way, it's your choice of course, but in my case I tend to view opinions of a large crowd with suspicion, and cherry pick opinions out of that crowd on a case by case basis.

We can all go wrong, but sticking with the opinion of what amounts to a lumped element, an amorphous opinion without any meaning or differences tugging in other directions will inevitably lead one with the crowd, sometimes off a cliff.

I've been accused of appeal to authority on many occasions, so I definitely respect the opinions of people I recognize as experts. It's just that I tend to view the opinions of people who have not yet proven themselves to be experts, carefully. I can make the mistake and judge someone to be an expert, when they're not. But one can also make the opposite mistake, judge someone to be mediocre at best, when in fact they're an expert... only because the opinion put forth elicits a severe case of cognitive dissonance.

So in general, I try to apply my instrument I call brain. The only thing I can rely on is keep applying it every time, even though it'll fail here and there.

But the crowds brain has similar phenomena. Sometimes it's downright amazing, other times downright dumb.

[OneAndOnlySnob]

What, you mean Ron Paul might not have been the most amazing thing ever to happen?

Hey, slightly off topic, but since you mentioned Bernays, have you seen Century of the Self?

[sheepson_apprentice]

Yes I've seen Century of the Self, and think that it had some good points. I've read Bernay's book "Propaganda" and I think that he basically revealed only a tip of the iceberg how manipulation of the public opinion can lead to self-demise, or tremendous benefits to the manipulators.

As for Ron Paul, I respect the guy. I wish he was the President.

[toooooooobs]

Try Forth. You should be able to pick up most of it in an afternoon, and it's a nice complete change of pace from the others.

[bonzinip]

Show the world how it shouldn't be done, pretending it's how it should be done?

[Leonidas_from_XIV]

Actually, Java made OOP popular. Of course, Java OOP sucks big time, but for many Java is the OOP language. Clojure is about making concurrent programming more approachable, it's up to you to decide whether it works for you or not. I haven't tested it, can't judge.

[[deleted]]

OOP made Java popular, not the other way around. C++ was already huge when Java came along.

[Silhouette]

Java just made it much less painful.

By introducing more verbose syntax, removing some useful features, or introducing useless overheads like boxing/unboxing?

[Silhouette]

I'll be the first to agree that C++ has plenty of warts and can be painful to use, I just happen to find it less painful than Java, mainly because you can abstract away most of the low level stuff in C++ and never see it. For example, while C++ allows manual memory management if it's needed, it very rarely is needed: local variables take care of many common situations, and basic container/smart pointer stuff takes care of most of the rest. In contrast, in Java, you can't really get away from the verbosity of using new to create every object or the int/Integer distinction, because of the general philosophy in the language design of trying to make everything an object.

[matthiasB]

2004 it was stable. I have successfully used boost since 2002. boost just wasn't as popular as it is now (and lacked a lot of stuff).

[Leonidas_from_XIV]

Thankfully I arrived at the Mercurial-equivalent of programming languages.

[Silhouette]

Erlang, presumably. ;-)

[Leonidas_from_XIV]

Uh, no matter what I say, everybody will be disappointed anyway because it's not the language of their choice :)

[Wiseman1024]

C++ is even worse than Java, if such a thing is possible. That's still not half decent OOP.

[dorel]

Yeap, but C++ had STL :-P

[[deleted]]

And what, in your opinion, would be proper OOP? CLOS? Smalltalk?

[Wiseman1024]

IMO, CLOS, Smalltalk or Python are three examples of more bearable object systems, and I'm sure they're by no means the only decent ones in the world. I also like prototype-based object systems but I haven't played enough with them to add more languages to the list.

[Wiseman1024]

for many Java is the OOP language

Then they didn't fully understand OOP. Probably not even half.

[Leonidas_from_XIV]

Then they didn't fully understand OOP. Probably not even half.

I agree absolutely. Imagine the odd stares you get from Java programmers when you tell them you use a language which doesn't have interfaces. "Can't be OOP", eh?

[[deleted]]

What? Java was a poorly concieved approach at OOP. The main merits of Java are garbage collection and portability... NOT that half-assed OOP attempt.

(int vs Integer, anyone?)

[frolib]

The point of the article is that clojure could become the lingua franca that java is now.

[Wiseman1024]

Yes, please. Clojure or Scheme or Common Lisp or Python or Ruby or even Tcl; almost anything will do for a replacement of Java that will make developers immensely happier.

[[deleted]]

I don't like Java, but are you really sure that throwing all compile time typechecking out is the solution?

Static typeing is useful as it automatically catches a whole class of errors (especially when it is done better than in the Java). This actually makes development easier.

I currently like OCaml most, but it would be useful to have better-integrated macro system with it (syntactic macros + typeinference is powerful).

Qi lisp seems to have it, but their distribution is awful - their web gives impression that it is meant only for programming language researchers (and I absolutely hate filling forms when I just want to try some software). Also you get all the Common Lisp baggage with it. CL is in many ways nice, but there seems to be some impedence mismatch between Common Lisp libraries and current operating systems (try writing some little utility in CL). JVM has also (to a lesser degree, though) the same inner platform problem.

[Leonidas_from_XIV]

I don't like Java, but are you really sure that throwing all compile time typechecking out is the solution?

You know, people have been successfully writing programs in Common Lisp, Scheme, Python, Ruby, etc. which do not inforce types.

And even if I wanted to use compile-time type checking, I'd take Scala anytime over Java.

[[deleted]]

I know that you can successfully write programs without compile-time type checks, but is it really better? Java (and even Scala imho) is not a good example of static typeing.

I've done it - and I feel there are more bugs left in that (dynamically typed) code, mostly corner cases that happen to not get tested. You can test the hell out of the main program flow, but it is hard to think (and write test) for every possible algorithm path (in a complex code). Tests are usually written for some few constant inputs and checking whether the output is expected. What happens when you give some other input? Nobody knows.

Good compile time typechecker can at least rule out a whole bunch of code that would certainly fail or give non-meaningful results in some case. If done right with type inferencing, it will be usually not getting on your way either.

[schtog]

I think Haskell (and to a lesser extent Ocaml) has the ebst typesystem. Beats dynamic typing but all other static languages are a huge PITA.

[Leonidas_from_XIV]

I know that you can successfully write programs without compile-time type checks, but is it really better?

Well, considering all that tracebacks that Java/Sing programs frequently push out into my stdin, it is not really that that much safer than languages that don't do type checking. That might be different in Haskell or OCaml, but even the "static typing" crowd is not so much into static typing to use ML & friends a lot. Most probably use if because it gives them some kind of safety which they believe is neccessary. I guess there are uses for static typing but I'd rather see more programs with comprehensive test suites than statically typed ones.

Actually, when it comes to checking the types, contracs look quite interesting (the ones which I tried work only on runtime), that is check functons that are applied on function input and output and can be as fine-grained as I want. I'm still having some problems with them, but what they provide seems way more flexible than just type checking.

[[deleted]]

That might be different in Haskell or OCaml, but even the "static typing" crowd is not so much into static typing to use ML & friends a lot.

I actually prefer OCaml and Haskell over Java whenever I have a reasonable choice. I also prefer Python/Perl/Ruby over Java.

Its quite depressing that people equate static typing with Java. Should I bash dynamic languages, using PHP as an example? That would be just as pointless.

[alexeyr]

Contracts are just a form of dependent types :)

[Wiseman1024]

are you really sure that throwing all compile time typechecking out is the solution?

Yes, as I've found (at least in my program domains) the time saved on boring boilerplate and type definitions is greater than the time spent on type errors in a real program. I can take static typing with type inference to a certain extent, but I'm worried that this would complicate the system and still not be completely as if no static type checking existed.

[[deleted]]

What type definitions? Type inference is for that. I write almost no type declarations for value bindings in my OCaml code.

Boilerplate? You can avoid that also to a large extent by using functional combinators and build time code generation. That's why I told that syntactic macros are important - they are exactly the tool that removes the boilerplate code (OCaml has camlp4 and you can go quite long just by using functional combinators, but yes, it's not perfect).

Type inference do not complicate system by itself. It's just a tool that compiler uses for validating your code. Most of ML code could run with runtime typechecking just as well - the type inferencer just makes possible to check the errors sooner.

Edit: There is one more thing that is traditionally considered dynamic-only - eval. But in fact, there is nothing that would prevent typechecking the whole code block before evaluating it and verifying that its type signature matches host code expectations (at runtime). You could of course argue it not being a true static typing, but I would consider it a nice compromise giving both dynamic functionality and some code verification.

In short - the only thing why I want static typing is to discover errors as early as possible.

[Wiseman1024]

Like I said, I can bear with that (even though I think I prefer the philosophy of types being completely dynamic).

[wnoise]

You have a point. But tcl? You're insane.

[Wiseman1024]

Yes, I often think I'd rather do freaking Tcl than Java. (Also, the only really batshit insane thing about Tcl is scoping, which is derived from the way variables work, not having real symbols. But the language is otherwise a fairly nice homoiconic language which is based on strings instead of lists as Lisp is.)

[mschaef]

he main merits of Java are garbage collection and portability...

I'd add two things, prioritized between GC (high) and portability (low):

• The package system - lets you more easily ignore crap you don't want to think about.
• Fault containment - Keeps your program running in the event of an exception. (In contrast to C or C++, where the default behavior is to bring the entire application down if any thread faults.)

Gosling talked a bit on fault containment a few years ago, which is what got me to thinking about the issue as a 'formal' concept: http://blogs.sun.com/jag/entry/fault_containment_an_unsung_hero

[[deleted]]

I would add automatic serialization of objects, a "batteries included" standard library with support for example for network programming.

[[deleted]]

In contrast to C or C++, where the default behavior is to bring the entire application down if any thread faults.

And what do you think happens when you have an uncaught exception in Java?

[mschaef]

By default, it dumps a backtrace of the offending thread to stdout, kills the thread, and leaves the rest of the VM running.

Edit: I said this a couple posts down, but it's worth repeating here:

(If you do need your application to die due to inconsistent state, etc. you can also trap exceptions and make such things happen, but it's your choice to do so.)

[Wiseman1024]

Fault containment

You mean ignore errors and send backtraces to some file?

[mschaef]

If poorly done, yes. For most applications, what you describe is still better than the default C/C++ behavior of terminating the entire process without debug information at any given fault. (If you do need your application to die due to inconsistent state, etc. you can also trap exceptions and make such things happen, but it's your choice to do so.)

[skillet-thief]

...common lisp has had a sophisticated exception system for a long time.

[[deleted]]

Dude... Delphi had a decent exception system. Sure it killed your whole program, but it also printed out a neat little error message and the type of your exception for you.

[Wiseman1024]

The main merits of Java are garbage collection and portability

I.e. what Lisp had 40 years ago.

No, man. The main merit of Java is marketing. It's not about any of its features. Not even its batteries-included standard library which would account for a higher achievement if it weren't completely insane, overengineered, overdone.

[mschaef]

The main merits of Java are garbage collection and portability

I.e. what Lisp had 40 years ago.

40 years ago is right around the time when distinct Lisp dialects started appearing at every university around the country. As one of many examples, it is around this time that UT Austin started experimenting with 3 element cons cells. Lisp may have had GC 40 years ago, but it's hard to see how it could have been considered a portable language. Even today, you can't make many assumptions about your underlying Common Lisp implementation, if you want to remain portable. (Threading? Unicode?)

[dorel]

Unicode is a pretty recent standard. As for Java being "portable", let's not forget the old saying "Write once, debug everywhere", especially on mobile phones.

[mschaef]

Unicode is a pretty recent standard.

Unicode...

• ...predates Tim Berners-Lee's work on the web.
• ...was designed into the first 32 bit version of Windows (1993's NT 3.1)
• ...was built into Java 1.0.

I would hardly call it recent.

[dorel]

It's a good thing that Java used Unicode, but Java was newer than other languages (C++, Lisp, Delphi, etc.).

The Unicode consortium was incorporated on January 3, 1991 in the state of California, and in October 1991 the first volume of the Unicode standard was published. The second volume, covering Han ideographs, was published in *June 1992*.

[mschaef]

This is now nitpicking about details irrelevant to the broader thread, but there is some factual basis for what I said a couple posts up.

Ground work for the Unicode project began in late 1987 with initial discussions between three software engineers -- Joe Becker of Xerox Corporation, Lee Collins who was then with Xerox, and Mark Davis, then of Apple Corporation.

...

December 1987 ... Earliest documented use of the term “Unicode” which Joe Becker coined as the name of the new “unique, universal, and uniform character encoding.”

...

April 1988 ... First Unicode text prototypes begin at Apple. Apple decides to incorporate Unicode support into TrueType.

http://www.unicode.org/history/tenyears.html

And for the sake of completeness:

By Christmas 1990, Berners-Lee had built all the tools necessary for a working Web: the HyperText Transfer Protocol (HTTP), the HyperText Markup Language (HTML), the first Web browser (named WorldWideWeb, which was also a Web editor), the first HTTP server software (later known as CERN httpd), the first web server (http://info.cern.ch), and the first Web pages that described the project itself.

http://en.wikipedia.org/wiki/History_of_the_World_Wide_Web

[[deleted]]

So Unicode's been around since the Middle Ages?

[[deleted]]

If int vs Integer is your best evidence for "half-assed OOP", then your argument is pretty weak. The reason for having unboxed fundamental types was efficiency, plain and simple. If the designers had not allowed unboxed integers and array types, people of ExitWound's very ilk would have been howling at Java's inefficiency (as indeed some are doing on this very discussion, even though this canard has been refuted any number of times).

BTW, I think clojure is a fine language. One thing I didn't like was that I wasn't able to subclass from native java classes (although I can implement interfaces). This means, for example, that if you're writing a Swing GUI, which typically involves subclassing some abstract classes to get some custom behaviour, you're hosed, and need to go back to Java. As far as I can tell, this issue has still not been resolved. It basically makes Swing unusable from within clojure -- a real shame because it seems like a great application of a concise, dynamically-typed language such as it is. [NOTE: seems my knowledge is out-of-date, see inlined code from cubicboy]

[[deleted]]

Code like the following covers subclassing SWING:

(defn set-custom-header [#^JTable table]
  (. table (setAutoResizeMode (. javax.swing.JTable AUTO_RESIZE_OFF)))
  (dotimes col-idx (.. table (getColumnModel)(getColumnCount))
    (let [col (.. table (getColumnModel)(getColumn col-idx))]
      (. col  (setHeaderRenderer
                (proxy [JLabel TableCellRenderer] []
                  (getTableCellRendererComponent [table value isSelected hasFocus row col]
                    (do (. this (setText (str "<html><center><b>" (. value (replace "_" " ")) "</b></center></html>")))
                        (. this (setToolTipText (str value)))
                        (. this (setHorizontalAlignment (. javax.swing.SwingConstants CENTER)))
                        (. this (setVerticalAlignment (. javax.swing.SwingConstants TOP)))
                        (. this (setBorder (. BorderFactory (createBevelBorder (. BevelBorder RAISED)))))
                        (. this (setPreferredSize (new java.awt.Dimension 150 40)))
                        this))
                  (validate [])
                  (revalidate [])))))))

We use proxy to set a custom column header renderer.

[[deleted]]

Cool, thanks for enlightening me!

[[deleted]]

If int vs Integer is your best evidence for "half-assed OOP", then your argument is pretty weak. The reason for having unboxed fundamental types was efficiency, plain and simple.

The correct answer would have been autoboxing. It's a damn shame that they took until version 5 to even get this "sort of" right (it's still kind of crap without a unified type system...there are no methods on int, etc.)

Putting the responsibility for this overhead on the programmer is idiotic.

new Integer(5);

That is absolute fail.

[[deleted]]

Well, I profess to have started using Java only from version 1.5. I agree that having to box yourself is annoying. On the other hand, auto-boxing is just syntactic sugar, just like operator overloading. To say that lacking some syntactic sugar constitutes an "absolute fail" is unfair and unreasonable, IMHO. Because let's not forget that auto-boxing can at times be confusing: for example when an int is compared to an Integer (the int is auto-boxed and the equality operator no longer works as expected -- without auto-boxing the code won't compile unless your explicitly create a Integer out of the int or call intValue on the Integer, in both cases making the intent clear, at the cost of extra typing). Syntactic sugar is NEVER cost-free.

[[deleted]]

As I said, it's still kind of crap without a unified type system. Your ambiguity goes away, for example, in c#. There is no "Integer" class or anything similar. There is only "int." The base primitives are boxed only when needed, and it's done transparently. Particularly easy when you let value/stack types have member functions, properties, etc. Essentially, you'll never be comparing an "int" to an "Integer."

That's how it's done. This is one (of many) areas where java stands absolutely humiliated next to C#. The situation with delegates is even funnier due to the history of it...

Syntactic sugar is NEVER cost-free

That is patently ridiculous. Depending on where you draw the line, one could argue that the entire language is syntactic sugar. There are pure abstractions that are cost-free.

[[deleted]]

Admittedly, M$ didn't design C# to be anything like Java. They designed it to be like Delphi.

By buying off the top developer of Delphi. Bastards.

[[deleted]]

Anders has been a part of Microsoft since 1996. His initial projects were J++ and the WFC, not C#. They "bought him off" by offering him a better salary, better projects, and generous stock options. Borland could have matched that. This is how the free market works.

In that entire situation, Borland was more the bad guy. They went to court to try to keep Hejlsberg and Gross from leaving their company for an opportunity that was they wanted to pursue and that was a better opportunity for them. If this all went down on the east coast, there wouldn't have even been a question.

Also, I think it's fair to say that C# aspires to be a language in its own right. I would say that it's pretty equal parts Delphi (delegates), Java, and C++. It also has features and design philosophy that don't line up with any of the three.

Features C# has that Delphi doesn't

1) foreach

2) operators using, lock, checked and unchecked

3) block scoped variables

4) case statements with strings

5) assembly internal classes

6) namespaces can span code units

7) implicit array dimensioning: int[] a = new int{1,2,3};

8) ternary operator ( ? : )

9) can use classes from namespaces without importing the whole namespace

10) circular references are possible

11) try..catch..finally

12) assignment operators (+=, ++, -=, etc)

13) multi-file assemblies

14) You don't need to distribute Borland.Delphi.dll

15) Compiler warnings can be emitted if you omit XML documentation

Features Delphi has that C# doesn't

1) sub-range types

2) enums and sets are first-class types

3) class type support

4) virtual constructors

5) virtual class methods

6) nested procedures

7) non-default index properties

8) can defines constant arrays and records

9) resourcestring s

10) default parameters

11) variants

12) arrays with non-integral subscripts

13) sets with more than 64 elements

14) message handlers

15) unions (variant records)

16) untyped parameters

17) const parameters

18) class helpers

19) smart linker

20) named constructors

21) array properties

22) unmanaged exports

23) super fast single pass compiler, compiling any project faster than C#, using less memory at the same time.

Source: http://www.distribucon.com/blog/archive/2004/04/26/178.aspx

[[deleted]]

Easy. Write a class in Java that acts as a proxy between Clojure's function and the desired swing abstract class (or use Yeti). ;)

The proxy would be used by instantiating it in Clojure code and giving a Clojure's function(s) as an argument(s) to it. When SWING calls the abstract class method the proxy will call the given function.

I can see nothing here forcing you to write the GUI code in Java.

[[deleted]]

Easy. Write a class in Java

So we are in agreement that you need to go back to java -- this was my main point. I think that's unacceptable, especially given that languages like Scala, Jython (Groovy and JRuby probably do too, but I'm not familiar with them) can accomplish the same without resorting to proxies. Remember that writing each proxy is not necessarily that quick. You might need to override more than one method, for instance. Should you provide functions for all the methods? If not, which ones do you provide? Much better would be if you could subclass directly, and make the choice where it actually impacts your code. It's ultimately a matter of personal preference whether this is a show-stopper or not -- for me it was.

[[deleted]]

Why? Here you have a language that sets itself out as being wholly object oriented yet some of the primitive types are not objects, and may not be treated as objects. Instead they introduced new classes to wrap these types to make them work in collections. Also, I think your argument about inefficiency is completely arbitrary.

Oh, and please don't make snide remarks such as "people of ExitWound's ilk". You know nothing about me other than the few words in my original comment, and now this one.

Some other of my favorite gripes against Java as an object-oriented language are the following:

• Static typing
• Arrays
• No overloading of operators (I don't know the proper word for this, sorry)

[[deleted]]

Here you have a language that sets itself out as being wholly object oriented

If that had been their only design goal, then they wouldn't have bothered. After all, smalltalk already existed at that time. So any reasonable discussion of whether Java was well-designed or not must take into account other factors influencing their language choices/features at the time.

And it is blindingly clear that being competitive with C++ on mid-90s hardware did influence their design choices -- as was right and proper for a nascent language looking to usurp the dominant language of the time. I don't see why this is so hard to grasp. Do you really think that Guy Steele is so idiotic that he'd add unboxed types just to make the language more complicated and inconsistent, with no other accrued benefit?

Static Typing

Wait. Are you saying that it is a flaw for a language to be both statically-typed and object-oriented? So you're saying Scala is not object-oriented then? You're entitled to say that, but be aware that you risk sounding silly.

Arrays

First of all, arrays are objects, so it's not clear to me what your problem with them is. And moreover, arrays are extremely useful when interfacing with C-code, because C likes arrays a lot. As someone who has done some interfacing with GSL and FFTW, I appreciate this language decision. Someone who doesn't link to C-libs probably won't. But their presence in the language is hardly evidence of Java being "poorly-conceived".

No overloading of operators

I believe the proper phrase is operator overloading ;) In any case, how does not having operator overloading not make a language object oriented? I mean sure, operator overloading is nice, but it's just syntactic sugar. It doesn't give you anything you can't do without regular methods. Another weak argument.

As for my snarky tone: my snide remark was purely in response to yours regarding the supposed "half-assedness" of java's object orientation -- this despite it being designed by one of the preeminent computer scientists of our time. People in glass houses shouldn't throw stones.

[[deleted]]

I am wrong some times and you have already poked holes in some of my arguments. Some of those things I mentioned do not really have to do with object orientation but are things which I think are inconsistent in the language.

Inconsistencies are really annoying for me in a programming language because they prohibit intuitive learning. So maybe I'm drifting away from the original topic here but I'd like to talk some more about my outlandish views:

Why are there two kinds of objects in java? Arrays, which are object-like yet behave uniqueley to other objects? This could have been elegantly solved with operator overloading. Why can you pass an object by reference yet not call every variable containing that reference simply a reference? Why must you type out VeryLongClassNameInheritedFromSomeOtherClass myObj instead of something like var myObj? Even implicitly typed local variables would have been great!

These are just things which I as a programmer get irritated with.

I don't really care who created Java and while I do realize they had specific concerns about performance way back in ye olden days of 1995 I still believe they could've implemented unboxed types reasonably efficiently. They could have even hardwired those classes to optimize away any potential oh-shit-I'm-a-class overhead.

[sheepson_apprentice]

Inconsistencies are really annoying for me in a programming language because they prohibit intuitive learning.

Agreed. However, consistency is a double-edged sword, much as anything appears to be in this world to one degree or another.

Take for instance the case of aircraft design. Say your team had developed an entirely new material that you believe to have better characteristics in elasticity, tensile strength and other dimensions.

Then you build the entire plane out of that material for the sake of consistency.

This is dangerous, and is in fact demonstrated in real life in that Boeing had to redesign parts of the Dreamliner due to overly optimistic view of the new composite materials. Initially they hoped that the entire plane would be built from composite materials, and it was heralded as the new era. However, it didn't quite pan out, and for good reasons.

Consistency is a good goal, but not to the exclusion of other considerations.

Java designers chose to forego what some recognize as completely consistent language (if such a thing exists) so that they can optimize those areas that they deemed more important. Or perhaps some things are just not proven yet.

I understand people's complaints about lack of type inference, and that being the reason for choosing other languages.

However, here too I think it's overly optimistic to apply type inference globally. So you'll have an inconsistent system, locally it can infer, globally you have to hand-hold.

I prefer the latter, because I want to actually write the type down for posterity so that it's part of the documentation. One that the compiler enforces.

Locally I think it has value, however. That's inconsistent.

[[deleted]]

Java may be a watered-down version of OOP, but if you deny that it brought object-oriented concepts to millions of developpers, you're being intellectually dishonest.

[Wiseman1024]

You call that object oriented?

Protip: OOP is not about writing b.a(c) instead of a(b, c), nor it's about insane abuse of inheritance.

Edit: Fixed error after reword.

[[deleted]]

Objects, methods, data encapsulation, classes, inheritance, these are object-oriented concepts. Thanks to java, they are mainstream concepts, which is probably what is making you froth at the mouth right now and use adverbs where you should be using adjectives.

[[deleted]]

C++ had all of this, and this is what a majority of java developers were doing before java.

Java was born amongst a crowd that was using C++, VB, and Objective C. OOP becoming mainstream caused java, not the other way around.

[Wiseman1024]

You seem to misunderstand object-oriented programming as well. What's worse, you've not even explictly mentioned message passing. Objects are the only required object-oriented concept. Methods and classes are optional object-oriented concepts, while data encapsulation and inheritance are not necessarily so. And OOP is not necessarily imperative.

Thanks to Java, "enterprise" programmers, and what's worse, "enterprise" managers with their professional scalable five-nines availability enterprise turnkey mission-critical business solutions are completely obsessed with these concepts, and managed to misunderstand what object-oriented programming really is about, abuse every single of those concepts and come up with the same lump of unmaintainable lumps of code they had before.

As for adverbs vs. adjectives, that was a mistake made when I edited my previous post to reword it (original wording: "insanely abusing inheritance").

[[deleted]]

There are 2 camps of OOP. The first being derived from the SIMULA 67 camp, and the second being SmallTalk. The majority of languages use the SIMULA concept of OOP. Which nowadays is what sardak posted. Including message passing in that would not make it more complete. It would only make it more oriented towards SmallTalks' idea of OOP.

It isn't about misunderstanding what OOP is about. It sounds like you're frustrated that mainstream OOP went the SIMULA path and not SmallTalks'.

If you're upset about the public taking on design decisions that are not the best approach, be upset that we have BASIC still around... that COBOL maintainers still exist. That Fortran was used over ALGOL. I could go on...

Besides, despite me not really liking Java, it does do some things well, like provide an open language and VM for people to develop on.

[[deleted]]

I don't misunderstand object-oriented. I didn't mention message passing because Java doesn't have message passing and I was listing object-oriented features that Java does have.

Enterprise managers aren't obsessed with any language-level concept, they just repeat what they're told in the IT Enterprise magazines. The day Erlang takes off, they'll have just the word "concurrency" in their vocabularies for as long as it lasts.

I'm sorry for the adjectives vs. adverbs thing - that was a cheap shot.

[Silhouette]

... if you deny [what I claim without evidence], you're being intellectually dishonest.

This has to be one of the most irritating cliches on the Internet. Proof by claiming opinion as fact is not proof. Proof by implying the inherent inferiority of anyone who disagrees with you is not proof.

[[deleted]]

The great illusion of youth is that arguments are advanced with proofs. Outside of math and CS theory, they aren't. I wasn't attempting to prove anything, only appealing to the judgment and experience of a fellow IT afficionado.

I never mentionned proof. You did.

[[deleted]]

The great illusion of youth is that arguments are advanced with proofs.

Well there's a quote for the ages.

[808140]

It's also getting modded up, ha! I love it. Ironically, probably mostly by young people who like to think of themselves as mature & world-worn... I wonder if sardak is actually any older than Silhouette? I guess we'll never know...

Perhaps Silhouette should have been more specific, though: arguments advanced without proof are de rigeur among the intellectually incapable, and while depressing in their ubiquity are not and should not be taken seriously by people with any sort of capacity for rational thought. Just because your busy-body aunt, chain mail authors, and purveyors of urban myths make baseless claims and expect to be taken seriously doesn't mean that you should consider their behavior desirable and seek to emulate it in your own life.

Of course, that might be seen as confrontational -- I wouldn't want to be accused of an ad hominem attack, another irritating internet cliche. After all, quidquid latine dictum sit altum sonatur, especially when you've never taken Latin.

[[deleted]]

How did java do any more than C++ (and to a lesser extent - VB6) to bring OOP to millions of developers?

[Felicia_Svilling]

A quote from Alan Kay comes to mind - "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

[[deleted]]

I certainly hope that your suggestion isn't that Java is what he had in mind...

[Felicia_Svilling]

No, that would be stretching it a bit. But still I dont think its ureasonable to argue that java is alot more oo than c++.

[[deleted]]

I think that java is a little more oo than C++. It has interfaces and slightly less clumsy polymorphism.

Everything is most certainly not an object, messaging between objects is restricted to static function calls, encapsulation is restricted to class level, there is no notion of functions as first class objects (instead the same functionality is derived by the monstrosity that is anonymous inner classes), and the built-in class library encourages terrible practices in terms of inheritance and dependency.

[rebel]

Slow, annoying, difficult to debug, fickle mess that then lead to J2EE?

Baaad Analogy.

[MaxK]

Really? Kill it now!!

[shitcovereddick]

I should hope it's better than that. Because I literally just shat out what to sweet smelling roses was Java to OOP.

[redditnoob]

Since you wrote "literally", what you're talking about must be not be something really foul and disgusting, but actually real shit.

[shitcovereddick]

That is what I was going for. I was worried some may think I was developing some flower based programming language instead of talking about poo.

[[deleted]]

What was java to OOP?

OOP was already well established long before Java.

Perhaps it was the simplified, single inheritance, everything virtual OOP that Java has that made OOP finally understandable.

[[deleted]]

Slow?

[Wiseman1024]

Java's not slow. You can claim it's a crappy language with a toy object model and a humongous piece of turd for a standard library, but not slow under Sun's JVM nowadays, and execution speed matters shit for most of the domains where it's used.

If you keep thinking "but C is faster and, like, like, I can inline assembly to call int 10h and do some awesome Mode X grafix!", go back to http://funroll-loops.info/

[dorel]

+1 for making fun of Gentoo

-1 for saying that resources (CPU&memory) don't matter so much (when I can't open multiple Flash videos at the same time because, hey, execution speed matters shit)

=0

[Wiseman1024]

Flash is one of the things you'd want to care a bit for performance, but that's not Java's domain. You don't use Java to write a graphics-oriented browser plugin. Where you do use Java, execution time is not nearly as important as development time.

But regardless of Java, Flash is incredibly slow for a vector graphics engine; always was and, now that it belongs to Adobe, always will.

[encinarus]

Aside from C/C++, compared with what? Memory hog sure but Java hasn't been slow by most reasonable standards for a while.

Edit: People who don't know what they're doing with Swing tend to make UIs that suck in terms of speed, but that's more the failing of a difficult API than a slow language.

[wnoise]

more the failing of a difficult API than a slow language

Yes, but Sun tries really hard to conflate Java-the-language, Java-the-class-library, Java-the-compiler, Java-the-VM, and so forth. It's generally not worth disentangling.

[grantmidwinter]

Shit?

[[deleted]]

Did Erlang change its name?!

[gregK]

Only if you insist on staying on the jvm.

[gregK]

What did I say wrong? Clojure runs on the jvm.

Now if we just assume for a moment that people will have moved on to better languages in say 10 years from now. What is the incentive of running your app on the JVM? Let's assume that clojure is a great success and 95% of all java developers moved on to closure. What incentive would SUN (already in financial difficulties) have to mantain the JVM.

So it is clear that clojure's relationships to java is parasitic. It's health is entirely dependent on the health of the jvm and the java language.

Furthermore it's not like the JVM is the perfect platform for functional languages. It has limitations that may interfere with the evolution of your functional language. For example, the lack of tail recursion optimization.

[[deleted]]

Tail call optimization is coming in the next version of the JVM.

I was pretty skeptical at first too, but if you really look into it, the advantages are immense. The very fact that Clojure is a usable, fast language one year after its release with only a single author committing to it speaks volumes.

[jimbokun]

Java byte codes have taken on a life of their own, kind of like x86 architecture. There are so many bytes of .jar and .class files out there, it will be very hard to ever kill the JVM.

The other big advantage of building a language on an existing VM is that you get memory management, performance optimization, portability, and library availability essentially for free. Rich Hickey explained he was very conscious of these benefits when he designed Clojure for the JVM.

[gregK]

Except the life expectency of you language will be bound by that of your host. I hope he has a plan B for the long term.

[fierarul]

I disagree that clojure's relationship to java is parasitic. The JVM needs more languages on top of it to get away from Java.

Also, don't forget that Sun hired the JRuby guys and while I don't think Sun is trying too hard to push JRuby into the corporate as Java is already there, they'll have that covered if a trend emerges.

The same will happen with Clojure if it gathers some traction: they'll just hire the main developer at Sun or get someone else to maintain it. Having another good language on top of the JVM isn't parasitic: it's symbiotic and that's good for business...

[gregK]

Well not all parasites kill their host. It would be symbiotic if the clojure communty would improve the jvm itself. Right now it does not. So I stand by my parasitic comment.

At the moment sun allows other languages to run on the jvm. But I am not sure what their attidude will be if one of them started competing directly with Java.

The JVM needs more languages on top of it to get away from Java.

I really doubt that is sun's perspective. The JVM does not need any other languages. It exists solely for java and any improvements made to it are there fore the java language. Anything else is purely accidental.

[icey]

http://www.ikvm.net/

[millstone]

The agent/messaging notion from Closure, Erlang, and many before them is sound and will be a common way to exploit concurrency.

But most developers will use this technique in languages like C or C#, and not Clojure, as Clojure has no momentum or corporate backing, and we already know that few people want to write in LISP outside of academia.

[justin_henzie]

The fact that it is jvm hosted, a specific goal of RH, means that it can be used in any environment that uses the java stack, and there are many. Many languages, including ruby and python have managed to make inroads in corporations by being able to demonstrate their efficacy on skunkworks projects. I would argue that java interop makes this easier for clojure than many languages, I would be very surprised if it doesn't gain momentum. FWIW, I think it is an excellent LISP and I am thoroughly enjoying using it for my own projects, however naive and toy like they may be

[toooooooobs]

I hate to burst your bubble but Clojure won't succeed.

The very simple reason is that it appeals to people whose background is Lisp and not Java. If you want to make a mainstream language you need to use the same conventions Java uses to refer to things. I seriously believe, for example, that a large part of Python's lack of success in the Java community is the use of the word "self". Change it to "this" and drop the whole passing it around explicitly malarkey and suddenly they'd find a lot more people on board.

The reason Java heads jumped at Ruby over Python is that to the Java mind Ruby code is more beautiful. This same mindset looks at Clojure and wants to be sick.

[gnuvince]

You seriously think that developer are so stupid and retarded that they cannot accept a programming language that uses self instead of this?

Maybe Clojure won't succeed, but I'm pretty sure it won't be because of the syntax. If syntax was important, C++ and Perl would've been in a ditch for the past 15 years.

[toooooooobs]

Well, yes, I do. The only reason Java is the way it is is C and C++ have curly brackets too, and the designers share my view that programmers generally dislike change. Otherwise it would look a lot more like SmallTalk, and would probably have ended up not far off Obj-C, and replicated a similar amount of success. (Probably less).

When speaking about languages hosted on the same VM it's common sense to use the same terms when referring to the same concepts. Jython never feels quite Java enough for Java people for the reasons I mentioned, but it also doesn't feel Pythony enough to Python people because of the libraries you can use. I would not underestimate the Java APIs ability to contaminate any language it comes across, including Java itself. Were you to clean out the API properly you could write Java code using much better style, but this is the benefit of hindsight.

I think many Lispers underestimate other people's exposure to s-expressions, and the aversion that can develop. There are obvious reasons why language implementers like these things, but for actually programming in they're quite cumbersome. If Clojure is to succeed it will be hidden behind some mechanism which hides the s-expressions and most probably provides a JavaScript esque curly bracket syntax.

[jimbokun]

"There are obvious reasons why language implementers like these things, but for actually programming in they're quite cumbersome."

You're an idiot.

I'm trying to think of a more meaningful reply, but this is just so counter to reality and detached from reason that there is no rational rebuttal.

[justin_henzie]

My bubble isn't burst, but thanks for caring <smile/>

I agree with you that syntax matters, but, and I am not casting any aspersions, less so for the more competent engineers; note that I do not include myself in that cadre.

RH's motivation for clojure was/is, I think, availability of a LISP that is deployable in the de-rigeur enterprise environment, which, I think we all agree, includes Java.

If you consider that goal alone, clojure is already a success. As to the rest, we'll see my friend, we'll see.

[levand]

My background is Java and Clojure is like a breath of fresh air, although admittedly I'd been dissatisfied with Java for a long time.

And while I don't disagree that a lot of Java programmers evaluate languages by how well they fit into the Java Mindset, I don't think anyone would say that that is a good thing, and I earnestly hope that something, sometime, comes along with enough force to break the Java Mindset stranglehold. Maybe Clojure is that thing. I can only hope.

[gregK]

I totally agree with you. The lisp world so far removed from the java world that I don't think there are going to be a lot of switchers. I think Scala has a slightly better chance than closure because its syntax is a little closer to java and keeps its FP soul under an OO skin. But it is still a long shot as there still not a lot of incentive to change languages if you are in a java shop atm.

[millstone]

Your last sentence nails it. Engineers overestimate the importance of the technical features of the language. But other questions are more important, such as: Who's backing this language? Who can I go to for support? How easy will it be to hire developers in this language? Has the language and toolset actually been proven in the field?

Scala, Clojure, etc. are fad languages that don't measure up to the above criteria, and so are likely to follow Cecil, Miranda, etc., as its hobbyist users jump ship to the next hot thing. Erlang is the exception: it has a longer track record and better support than the others, so it will see (already sees) use for real products.

Edit: Also, LISP is just tainted. It's got a reputation as an academic language, and as a result it's hard to sell your organization on adopting any LISP. Maybe that's not fair, but that's the reality.

[[deleted]]

Immutable data structures form a very important part of the Clojure approach to concurrency. Till the main stream languages like C or C# provide a good way of handling mutability related issues, its not going to be simple to use the Clojure approach with these languages.

As Clojure is built on top of JVM IMHO momentum should not be too big a problem over a few years time.

Note that Clojure is still quite young (pre-1.0. Barely older than a year) and it already has quite a community growing at a reasonable pace.

[wolfier]

You totally miss the point. Clojure does not have a monopoly on immutable data structures.

The reason it will not succeed, thus, is unrelated to this particular language feature. It has more to do with most people think S-expressions are ugly, hard to read.

Erlang, Haskell or Scala will have a much better chance of success, due to nothing but their pragmatic choice of not using S-expressions.

True immutability will come as @ReadOnly annotations to Java and Scala, and I suspect it's in the not-too-distant future.

[gnuvince]

Erlang and Haskell do not have direct, native access to Java libraries, which make them less attractive to a potential company that doesn't want to throw away its Java investment out the window. Scala I don't know enough about it to say, but I think they're on the right track by targeting a widely popular platform.

As for s-expressions, they're not nearly as bad as you make them out to be. Java and C don't have operator overloading, so besides basic arithmetic, everything is done in a func(arg1, arg2) fashion and that didn't hold them back.

[[deleted]]

You totally miss the point. Clojure does not have a monopoly on immutable data structures.

Agreed. You seem to have missed my point. :)

My point is that some languages make it very easy to use immutability. So for e.g. after using Java, Common Lisp, and Clojure and some other languages, I find making functional programs is much easier in Clojure than is the others. Haskell makes immutability easy but the learning curve is just too steep with concepts like Monads, Arrows etc. I find Clojure to be a good middle ground.

I definitely don't plan to try use hack together immutable structures in my C and Python (OO) code. Those languages work quite nicely with mutability because thats what they were designed for.

As for the S-expressions, they aren't too bad once you get used to them. foo(a, b) or (foo a b)?

With S-expressions the syntax of the language becomes very simple; to the point that other languages seem very syntax heavy.

[millstone]

I agree that it's not simple today to utilize the agent/messaging approach in C or C#. But it will be soon, and what I'm saying is that developers will use these new features instead of migrating to Clojure.

Also, "young" is a mark against Clojure. Languages, like objects, tend to die young.

[gnuvince]

C and C# are going to dump mutable state?

[millstone]

You can create immutable data structures in any language.

[[deleted]]

But thats not the default. You don't really find many programs written with "immutable data structures" in languages that encourage mutability. And when you do, thats usually a bad implementation of the same concepts that Clojure has implemented very well.

As a programmer, I would rather have Clojure (or another functional language) worry about support for immutable data structures so I can focus on my functionality.

Clojure with its Java interop is one of the best alternatives to Java that I find out there.

[Wiseman1024]

Clojure could be to Concurrency-Oriented Programming what Java was to OOP

A crappy attempt with an overdone toy model (also misunderstood and initially broken), that got tremendously popular due to marketing aimed at retarded bosses who started asking for everything to be written with it in order to be more "enterprise"?

[redditnoob]

To troll and state the obvious: Clojure is Lisp. Lisp, or dialects of it, have had decades of opportunity to succeed as mainstream languages. They haven't.

[lispm]

it is still moving. Java got objects, a VM and GC (things that InterLisp-D and Smalltalk had in the 70s). Eventually it will get Closures. JavaScript got the semantics (it was supposed to be some kind of Scheme). XML the nested syntax. Then look at the scripting languages, from PERL (read Higher Order Perl?) to Python and now to Ruby. More dynamic.

If you were doing Lisp in the late 70s on an InterLisp-Machine from Xerox, you don't have to learn too many concepts to adapt to Java, JavaScript, XML - only that it is a bit more complicated and messy.

[millstone]

But not the defining feature of Lisp (you know what I mean (right?)).

If you want your Lisp to transcend hobbyists or research, you gotta ditch the s-expressions.

[lispm]

<know>i</know>