Clojure could be to Concurrency-Oriented Programming what Java was to OOP(bc.tech.coop)
bc.tech.coop
Clojure could be to Concurrency-Oriented Programming what Java was to OOP
http://bc.tech.coop/blog/081201.html
7 comments
I think Clojure might succeed even without its great concurrency features - and by succeed I mean gaining a Porsche-like marketshare.
It has all the good Lisp stuff, but ditches all the historical Lisp cruft, actually has a little syntax. And because it runs on the JVM, it's stable, fast, debuggable, has a wealth of libraries and runs on Windows, Mac and Linux.
And there's already a (beta) book: http://pragprog.com/titles/shcloj/programming-clojure
It has all the good Lisp stuff, but ditches all the historical Lisp cruft, actually has a little syntax. And because it runs on the JVM, it's stable, fast, debuggable, has a wealth of libraries and runs on Windows, Mac and Linux.
And there's already a (beta) book: http://pragprog.com/titles/shcloj/programming-clojure
Clojure is clean and lean while Scala is heavy weight. I'm learning them side by side but enjoying Clojure way more, especially the pragmatism of feature decisions.
Clojure just might become a popular lisp. :-)
In terms of Scala, it's built on top of the JVM (as is Clojure) and so it's underlying model is the same -- Java threads mapped to OS threads. Scala does give people a variety of syntactic constructs.
In terms of Scala, it's built on top of the JVM (as is Clojure) and so it's underlying model is the same -- Java threads mapped to OS threads. Scala does give people a variety of syntactic constructs.
Is this due to something inherent with Lisp? This argument also works for each aspect of Lisp that's been borrowed by other languages:
Clojure does fix one of the last things holding it back: it removed "Lisp" from the name, and added a trendy "J".
(format t "~{~A has been around for ~D years so it seems there perhaps is something about it that doesn't fit with most programmers?~^ ~}"
'("Structured programming" 10
"Lexical scoping" 20
"GC" 30
"Closures" 40))
Clojure does fix one of the last things holding it back: it removed "Lisp" from the name, and added a trendy "J".
This title is horrifying!!! Java set back good OOP by about 20 years!!! We're still recovering from what Java did to the OO community.
The damage was done by C++. Java was a step up from there.
Not really since the masses never used C++, Java on the other hand saw massive adoption and did much damage to OOP.
Uh, C++ was huge in the mid-90s. Nearly all your Windows desktop software is in C++ - as were a lot of Web1.0 sites, before they were rewritten in Java.
Let me rephrase then, Java saw mass adoption from unskilled programmers similar to VB. C++ has always been big among skilled programmers, but skilled programmers are not the masses. Compare C++ numbers to Visual Basics numbers and then tell me C++ had mass adoption. I could be wrong, but I don't think so.
C++ was (and is) pretty widely used - even in places where java is now (the dreaded enterprise, yes C++ was very big there too).
Yes, yes they did.
This is quite an accusation, could you please back it up? I assume you use OO also?
an object is something that has identity and responds to messages. this is not what java is.
http://www.appliedthought.com/peter/smalltalkvsjava.html
If anything, Java promotes class-oriented programming, not object-oriented programming.
edit: if you disagree, please explain so i can learn.
http://www.appliedthought.com/peter/smalltalkvsjava.html
If anything, Java promotes class-oriented programming, not object-oriented programming.
edit: if you disagree, please explain so i can learn.
The link you provided just seems to be some guy who prefers Smalltalk to Java, but does not in any way say that Java is not Object Oriented Programming, or that Java sucks at Object Oriented Programming.
OOP, at the moment, is recognized as being what C++, Java, .NET are. There are certain concepts that allow you do OOP, and Java fulfills all of these concepts pretty well. Java, as a language, is really not bad at all. As a representative of the contemporary definition of OOP, it performs very well.
Now, if you have worked a lot with OOP, and you have independently come to the conclusion that Java is a worse OO language than C++ or .NET, then you are entitled to your opinion. If, however, you are primarily a scripting language user, and you read the opinion on Slashdot or so, then I would suggest that you first read in somewhat more detail about this before making such judgements.
OOP, at the moment, is recognized as being what C++, Java, .NET are. There are certain concepts that allow you do OOP, and Java fulfills all of these concepts pretty well. Java, as a language, is really not bad at all. As a representative of the contemporary definition of OOP, it performs very well.
Now, if you have worked a lot with OOP, and you have independently come to the conclusion that Java is a worse OO language than C++ or .NET, then you are entitled to your opinion. If, however, you are primarily a scripting language user, and you read the opinion on Slashdot or so, then I would suggest that you first read in somewhat more detail about this before making such judgements.
I made the original statement that Java set back OOP by 20 years. And I stand by it. I used Java extensively for 8 years. I also programmed in Smalltalk for 10 years prior. Your assertion that "OOP, at the moment, is recognized as being what C++, Java, .NET are" is precisely the problem. People don't know their history.
Java is not a horrible language. It did set back good OOP by about 20 years. There is no reason to bring C++ into the debate. Prior to Java, the C++ community understood that C++ was not a great OOP language. C++ was C++ and people chose it for its unique characteristics, none of which was that it was a great OO language.
Next invested heavily in Objective-C for precisely the reason that they needed to get closer to the metal but knew that C++ was not great at OOP.
Java is not a horrible language. It did set back good OOP by about 20 years. There is no reason to bring C++ into the debate. Prior to Java, the C++ community understood that C++ was not a great OOP language. C++ was C++ and people chose it for its unique characteristics, none of which was that it was a great OO language.
Next invested heavily in Objective-C for precisely the reason that they needed to get closer to the metal but knew that C++ was not great at OOP.
I am not suggesting that Java is bad! In fact, it is pretty interesting, and facilitates a certain kind of development that has a huge place in the world. But it isn't really OOP. It is something different, that has some OOP features. I agree with jhancock's post that is a sibling to this one, and won't repeat his explanation about history, or his contention about the hijacking of the term OOP here.
If only we could convince someone to create Projure -- a Prolog-like language that compiles to JVM bytecodes. I'd be the first (and only?) customer.
On Lisp shows a Prolog implementation in CL. Port it to Clojure.
There's got to be one out there - some Master's student's project if nothing else.
We can't keep stepping backwards to support changing processor technologies. Concurrency should be abstracted away from the programmer, and handled on a compiler level, irrespective of your programming language.
I think the fact that we need to step back when processor technology changes shows that we (the software community) lack a truly pervasive concurrent programming model. Does Clojure really offer a truly orthogonal solution to this problem?
And when I say "problem" I'm really talking about the scalability of fine-grained concurrency techniques formalized by Dikjstra (http://en.wikipedia.org/wiki/Semaphore_(programming)).
I agree that programmers will eventually have to be relieved of concerns such as critical section but we will never escape questions like "what are the parallel aspects of this algorithm (or library or application)". A compiler will never "discover" large-scale concurrency patterns in any mainstream language (at least to my reckoning). Maybe interpreted languages will ultimately lead the way.
And when I say "problem" I'm really talking about the scalability of fine-grained concurrency techniques formalized by Dikjstra (http://en.wikipedia.org/wiki/Semaphore_(programming)).
I agree that programmers will eventually have to be relieved of concerns such as critical section but we will never escape questions like "what are the parallel aspects of this algorithm (or library or application)". A compiler will never "discover" large-scale concurrency patterns in any mainstream language (at least to my reckoning). Maybe interpreted languages will ultimately lead the way.
sure, and you can get a very minor boost. the problem is that the computer can only safely do so much concurrently. if you think otherwise, then go ahead and make a compiler that supports concurrency "irrespective of your programming language" in a way that is sane and performs well.
Clojure is neat and all, but I can't see it being anything but a proving ground for some more esoteric technologies or methods. Lisp has been around too long to get mainstream acceptance and the "power vaccum" of which PG is fond of mentioning is marginal these days due to Ruby, Python, etc. Clojure has the attractiveness of running people's existing infrastructure (i.e. the JVM) but its nowhere near being alone in that regard. Its neat but don't look for it to be a world-changer.
I'd be interested to see concurrency baked into Ruby or Python the way it is with Erlang and Clojure. Until then, my eye is on Clojure.
I thought that was Erlang.
But Lisp has been around for 50 years and never hit the mainstream so it seems there perhaps is something about it that doesn't fit with most programmers?
Also it only offers one form of concurrnecy and while I like it there is still much speculation and research in the area. Scala for example kind of builds on the whole Java-language and offers a more recognizable language for Java-developers and more opportunities to roll your own concurrency-mechanisms, or at least that's the impression I've gotten.
And then we have Haskell and Erlang.