This blog has moved here and this post can be found at http://blog.khigia.net/wp-import/general/2006/11/02/what-is-my-next-programming-language.html
… This is a personal message address to me in future …
What is my next programming language?
Scala , F# , Haskell , OCaml or Erlang?
Yes, my next language will be functional, and I will focus on improving my skills in concurrent programming and distributed applications. And here come the reasons for the choice of the above shortlisted languages:
- I just experimented the threading system of Python … that really not fair guys, so I quit Python!
- Scala use the Java threading model, that’s good as far as I know (and Scala looks fine!);
- F# enable to use all .NET library so I could experimented Tao on Mono (.NET threading is also good, IronPython rocks);
- Haskell is pure … I’m curious to understand those mysterious monads;
- OCaml mixes functional and imperative … really efficient and yet simple;
- Erlang embed asynchronous model inside the language … concurrent and yet simple.
Why concurrent programming? Why distributed?
Nowadays computers aim to solve complex systems: large amount of data to process, large number of interactions, or naturally distributed systems. Parrallelism and distribution seems to be in the pipeline with multi-core processors and clusters supported onto a network more and more efficient (optic-fiber at home by example). Without looking at language theory (see Future of software design?), my next language has to enable a software design with those intrinsic features: parallelism (data or computing) and distribution.
And why functional?
I don’t really know … for the fun??? I read a lot about Haskell recently; I just want to change my mind with another programming paradigm, and I secretly hope that my functional code will be better optimized on multicore machine. If you want real justification you may have a look at Functional Programming For The Rest of Us or Everything Your Professor Failed to Tell You About Functional Programming.
Final choice of my future language
Still have to choose one in the shortlisted choices, but with which criteria?
Type inference is a must (coz above all, any good programmer has a special quality: he’s lazy). But I don’t see a strong typing as a must-have: it sure solves problem, but not all, and in the end you still rely on unittesting.
Let’s do a first cut in the shortlist based on personal assumption: .NET is a better platform than Java (wow!). So:
- remove Scala: F# offer same kind of possibilities using .NET;
- remove OCaml: shares a common ML-like syntax with F# but F# offer .NET platform access where OCaml offer efficiency.
Haskell is pure but I prefer easy development aiming at concurrent and distributed programming, which is not part of the Haskell language itself. Then I have to choose between Erlang or F#: let’s go for Erlang, let’s concentrate on distributed development embedded in Erlang language. If later I really need/want .NET platform, it will still be good time to review all those choices adding new languages progress!
November 2, 2006 at 11:32 pm
Concurrency and parallelism has been part of the Haskell since the
beginning:
http://groups.google.com/group/comp.lang.functional/msg/20a80be2e0c567f0?hl=en&
For more resources on multicore parallel and concurrent Haskell:
http://haskell.org/haskellwiki/Libraries_and_tools/Concurrency_and_parallelism
http://haskell.org/haskellwiki/Research_papers/Parallelism_and_concurrency
November 3, 2006 at 12:27 am
I probably don’t know enough about Haskell and concurrency (I enjoy all the work and discussions about Haskell but I’m just a newby in this domain).
What I meant is that it seems “more easy” to use the Erlang environment to learn some design (at least the Erlang way) of distributed system because distribution is the base of Erlang and all the documentation always care about this aspect.
Anyway, thank you for the links, I will have to read a bit more to avoid to say again something wrong
November 8, 2006 at 6:53 pm
Haskell’s concurrency support is actually very deep, and it contains some worthwhile ideas. Because Haskell is purely functional, the base language has no notion of state. And state is the great evil of distributed systems.
On top of the stateless core, Haskell then builds several abstractions for state–some of them very general and unrestricted, and others highly specialized.
Erlang is a marvelous language, but it prefers to implement concurrency using a message-passing abstraction. Haskell offers a wide variety of abstractions: Software Transactional Memory, regular threads, purely functional parallelism, and so on.
So if you want to study one form of concurrency (implemented very well), take a look at Erlang. But if you want to investigate a wider range of concurrency abstractions, you might want to check out Haskell. At least for me, it’s a more promising testbed for experimenting with various odd-ball paradigms.
November 9, 2006 at 11:16 pm
Haskell gives you at least 3 types of concurrency: parallel precomputation of pure code with par, message passing with MVars, and transactional shared state with STM
November 10, 2006 at 1:24 am
Thanks for all those informations about distribution and concurrency in Haskell.
But I still want to give Erlang a try. Not because it is more powerfull (Haskell seems really more efficient from benchmark) but because the “Erlang way” to create a distributed system with asynchronous message is consistent and well documented. I continue to think that it’s a good start to experiment distribution with all design issues exposed: process tree, error handling, monitoring etc.
And choosing Erlang today enable me to learn Haskell later (I guess that choosing Haskell today would not encourage me to come back to Erlang after
).
I really think Erlang is more simple to learn (one implementation of) distributed system design. Am I wrong?
November 25, 2006 at 10:05 am
[...] It took a long time to decide to learn Erlang instead of Haskell or OCaml/F#. What I really want to learn for now are the OTP principles of distributed application. So I wrote my first Erlang script (not yet an application) and it confirmed my point of view: Erlang make easy the development of distributed program! really!!! [...]
February 6, 2007 at 12:13 am
I just find another usefull “resource of resources” about concurrency and parallelism in Haskell.
. Thanks
http://www.haskell.org/pipermail/haskell-cafe/2007-January/021716.html
And it seems to be from the same author as the first comment on this blog entry
March 26, 2007 at 3:53 am
Python has libraries/modules for parallel execution, for example: http://www.parallelpython.com
Although learning Haskell is definitely a good idea.
November 25, 2007 at 12:31 am
I’m on a bit of a language binge at the moment.
Why learn just the one eh?
November 25, 2007 at 2:29 am
Sure! Why just one!? … thatś why you will some blog entry about F#/Ocaml
… I still keep Haskell for later 
January 18, 2008 at 5:31 am
Scala has both a Java binding and a .NET binding. I would be really interested how you would choose between them.
January 18, 2008 at 5:32 am
Sorry:
Scala has both a Java binding and a .NET binding. I would be really interested how you would choose between the .NET Scala implementation and F#.
January 18, 2008 at 5:51 am
Did not know about the .NET implementation of Scala … interesting, thanks Jerry.
If I had to choose between .NET Scala and F#, I would probably give F# a try.
In fact I know too few about Scala to have a very strong opinion on this point, but it seems fairly easy in Scala to have both style of programming: functional and imperative. While it is good to have this possibility, when working in a team it’s also good to have a common style so that everybody easily understand the code approach.
But as I said, this is just a first impression … I have never written even one line of Scala code.
October 29, 2008 at 6:19 pm
Heh. Nice. Do you have a sense of wonder about my happy kid Wanna very nice joke?)) Why does a turtle live in a shell? Because it can’t afford an apartment.