Concurrency in Java is complex to use and expensive in computational resources. Because of these difficulties, Java-taught programmers conclude that concurrency is a fundamentally complex and expensive concept. Program specifications are designed around the difficulties, often in a contorted way. Biut these difficulties are not fundamental at all. There are forms of concurrency that are quite useful and yet as easy to program as sequential programs (e.g., stream programming as exemplified by Unix pipes). Furthermore, it is possible to implement threads, the basic unit of concurrency, almost as cheaply as procedure calls. If the programmer were taught about concurrency in the correct way, then he or she would be able to specify for and program in system without concurrency restrictions (including improved versions of Java). (Concepts, Techniques and Models of Computer Programming, Peter Van Roy and Seif Haridi)
First of all, I completely agree with the authors. I like learning new languages/paradigms/models and find quite restricting sticking to just One Language, One Platform, One Model. I’m fond of Python (but indeed Python is an excellent imperative/object oriented language that allows functional programming — and logic programming is experimented among other things in pypy). I also like Ruby (again Imperative with functional capabilities). I recently discovered the power of Prolog, and I love Haskell (although I never wrote any substantial piece of software in Haskell).
I can’t imagine working with Java and only with Java (and the same applies to ‘C++ and only C++’ or whatever). However, there is plenty of programmers out there that chose One Language, One Platform, One Model and stick with it. I’m wondering if we can generalize Dijkstra statement
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
In fact it seems that Java has the very same problem. A lot of Java programmers are only able to formulate problems (and solve them) thinking in Java. One may argue that maybe business programmers already had their mind crippled, but I don’t think this is the case.
I’m afraid to say the problem is not limited to Java, of course (it’s just more evident because there a lot of Java programmers). There are a lot of excellent C++ (for example) programmers that simply do not believe that large programs written in dynamically typed languages can work (and of course they are wrong, since we can exhibit such programs). On the other hand some Python/Ruby/etc advocates think that static typing is fundamentally bad. In fact it is not: Java type-system is poorly designed. It’s not that static typing is wrong or clumsy. Haskell and OCaml are statically typed, but types do not get in the way: they are a concrete help for the programmer (but this does not imply that a language should be statically typed).
My opinion is that more programming languages, models, paradigms should be taught to programmers. For two main reasons: first, they know more ways to solve a problem and hopefully they will be able to choose the best one; second, they will be able to adapt concepts coming from other models/paradigms/languages to the language they are currently using, thus making the design more elegant.
Elegance is not a dispensable luxury but a quality that decides between success and failure. (Dijkstra)
4 comments
Comments feed for this article
December 25th, 2006 at 05:19
Lawrence Oluyede
I completely agree with you Enrico. Sticking with one environment for the life is not going to open up your mind. Being that .NET, Java or even Python. I, myself, starting to evaluate the possibility to go deep in one of the many languages/environments I know because maybe one day I’ll become a real Python-zealot and that’s not good at all
Java (or C#) is the worst choice anyway and since I don’t have to do the “programming-for-paying-bills” stuff I’m free to choose right now.
Any hints
? I had a very very brief look at ObjC but I’m not sure I like it and maybe something more “platform indipendent” is better.
Merry christmas Enrico
December 25th, 2006 at 06:47
Enrico Franchi
In fact the reflection that followed the citation was strongly influenced by the discussion we had on the way back from Bologna some days ago.
I agree when you say that Java/C# is the worst choise (if you don’t have to work *right now*). Well, PHP is even worse… but ok, I understand. Java and .Net have wonderful libraries, but this has the drawback that people tend to use only that *and* will think the way they are engineered is *The* way to do things.
I think you already know (and in a quite deep way) more languages/environments than the average programmer. However, if you want to learn something new, I would advise Prolog or Haskell. As far as I know you know Lisp quite well, so the functional paradigm is not new to you (even though working with a statically typed with type inference language like OCaml could be quite different). But Haskell not only is a statically typed with type inference language. It is also a lazy language.
For example starting thinking in a lazy manner improved significantly my understanding of Python generators and the way they can be used.
Prolog is really interesting: there are really hard things in conventional languages that become trivial examples in Prolog (on the other hand there are imperative trivialities that in Prolog must be dealt *very* carefully).
ObjectiveC is a nice language. It’s a dynamic compiled language (even when you specify ObjectiveC types, they are more suggestions than requirements, since the message passing runtime does not take into account types, you get only warnings).
It is reasonably cross platform: the language is part of the gcc suite, so you can compile ObjectiveC programs wherever you have gcc. The library is split in two: Foundation library and AppKit.
Foundation contains low level stuff. Data types, Threads, Processes, Autorelease runtime (that will soon be replaced by a true Garbage Collector), Asynchronous Notifications (both local and remote are *built-in* in the standard library), Sockets, Proxies, all the network stuff etc.
Foundation is completely implemented by the GNUStep library. It is perfectly portable.
AppKit mainly contains gui stuff and desktop oriented classes. They are mostly (but not fully) supported by GNU Step. You *may* build cross platform GUI applications (GNU Mail is an example). I have never done this by myself, so I can’t tell.
And merry Christmas to you too…
December 25th, 2006 at 15:51
Lawrence Oluyede
I just read this: http://www.bitwisemag.com/copy/programming/d/interview/d_programming_language.html
Haskell seems to be a little “mathematician oriented” to me, maybe one of the languages of the ML family?
I’ll try to evaluate two or three of these languages and decide accordingly.
Thanks
December 26th, 2006 at 06:27
Enrico Franchi
The article you linked is really interesting. D is a very interesting language. I’d be glad to use it for something serious. Right now, I suppose one of the first things I’ll be doing in D (if I ever do something in D) could be some high performance Python module. The interface to write Python modules in D seems *really* good.
Unfortunately my group and I are quite skilled in C++. I suppose it is nearly impossible to ‘work’ in D in the near feature, and for my private projects, I tend to use Python or Ruby. It is most likely I will find time to work with Haskell or OCaml.
In fact a good knowledge of the latter could help me a lot even for my ‘main’ work, since a software we are experimenting with (CIL) is written in OCaml.
About Haskell, I don’t really understand what you mean with ‘mathematician oriented’. I mean, most Mathematicians I know aren’t really able to code with good style in any of the few languages they know. Simply programming is *not* their focus. Most of them have been taught programming but didn’t really want to learn (as I have been taught a lot of subjects I cordially hated).
The reasons I chose Haskell over OCaml as the first functional statically typed language are:
1) Books: there are a lot of books on Haskell, while I found none on OCaml. I bought a very interesting Haskell book, that instead of the classical example on parsing or math oriented code, uses Haskell for multimedia applications: animations, computer rendered graphics and even *music*. The last chapters are devoted to writing a musical interpreter in Haskell.
I actually read a few tutorials *before* the book, but in fact I tend to regard to Haskell to a quite practical language, because of the way I learned it. Moreover there are a lot of interesting libraries that can be accessed from Haskell.
Haskell seems also a very good language for system programming. For example:
http://urchin.earth.li/pipermail/debian-haskell/2006-May/000169.html
The main problem with Haskell is that people use to think to Monads as a rather difficult concept. Since Monads are used for I/O, people tend to think that everything in Haskell must be hard.
When learning the language at the beginning, you can forget about Monads. You may use the interactive interpreter (hugs or ghci). You simply write code that deals with data and then use the interpreter for input and output.
In fact, correct software development stresses on separating I/O from actual data processing.
Then you look at the Haskell I/O Monad. It’s written, you don’t really need to understand monads. You just can see that I/O code is executed sequentially. In fact you quite easily build ‘lists’ of I/O commands from the data structures you want to print/get and then ‘execute’ the lists.
Then you see that the very same principles that govern I/O can be used for event driven programming (that is quite natural in Haskell). In Haskell is natural to reason about ’streams’ of data and to code the system so that reacts to the event in those streams. If the events are text lines or keyboard events, nothing really changes.
Then you can learn the full power of Monads. But you can do a lot of interesting things without even knowing what a Monad is, and basically regarding monadic code as a ‘list’ of sequential instructions. Like a place where you get back an imperative feeling (but having it all in one place, lets you reason for most the program in a functional stateless way).
Monads come from Category Theory. But you don’t need to know anything about Category Theory.
If you want to use some ML language, I suggest OCaml. It’s a good language, with good support and all.