2

I have done some Java programming and very little C and PHP programming as well. Recently I started to learn Python because the language seemed interesting.

But several posts on SO seemed to point that Python is not suitable for concurrent programming. And also is slower compared to those languages that have a compiler. I also like to have the merits of a statically typed language but Python is dynamically typed. So my question is, is there a language that satisfies the following criteria.

1) Has an interpreter ( for faster development )

2) Has a compiler ( because compiled code would run faster )

3) Has OO capabilities

4) Statically typed

I came across OCaml which satisfies the above criteria. But posts on SO led me to believe that OCaml is not suitable for concurrent programming. So the fifth criteria is

5) Suitable for concurrent programming.

PS :- I'm not an expert in programming languages so bear with me if any of my above observations are wrong.

Onorio Catenacci
  • 14,928
  • 14
  • 81
  • 132
Can't Tell
  • 12,714
  • 9
  • 63
  • 91
  • 1
    An interpreter doesn't guarantee faster development. – Blender Apr 10 '12 at 05:11
  • 4
    ...starts with "J" and ends with "a" and has four letters? – Joel Cornett Apr 10 '12 at 05:13
  • @JoelCornett: http://stackoverflow.com/questions/1326071/is-java-a-compiled-or-an-interpreted-programming-language – Blender Apr 10 '12 at 05:14
  • 1
    You might consider [Scala](http://www.scala-lang.org/), [Erlang](http://www.erlang.org/), or [Haskell](http://www.haskell.org/). – Jerry Coffin Apr 10 '12 at 05:14
  • Scala has loose typing, yes? Duck typing or whatever. – QED Apr 10 '12 at 05:15
  • It would entirely depend on what you are planning on using it for. – Joel Cornett Apr 10 '12 at 05:20
  • @Joel when I said interpreted I meant that the code should be directly runnable without a compilation step. – Can't Tell Apr 10 '12 at 05:27
  • @Blender doesn't not having a compile step speed up the process of development? – Can't Tell Apr 10 '12 at 05:28
  • It all depends upon the project. I use Python for just about everything, but that doesn't mean I run my script every 10 seconds. I write my Python code the same way I write my C++ and Java code, except the last two take a few more seconds in the end to compile. – Blender Apr 10 '12 at 05:31
  • @JerryCoffin I thought Erlang and Haskell didn't support Object Orientation. Didn't know that Scala had an interpreter. Thanks for the answer. Will look into those languages more. – Can't Tell Apr 10 '12 at 05:42
  • Erlang isn't exactly OO, but is based heavily on message passing, which is a major part of some people's idea of OO. It also has a number of other OO-like features, so you do at least somewhat OO-style coding if you want. For "purer" OO, there's also ECT. Haskell supports polymorphism and overloading, so although it isn't exactly conventional OO, it has some of the same properties. Since Scala runs on the JVM so you compile the source code, then interpret/JIT compile the byte codes. – Jerry Coffin Apr 10 '12 at 05:48
  • Google Go might be a candidate? – Devraj Apr 10 '12 at 06:00
  • @JerryCoffin Scala does have an [interactive interpreter](http://www.scala-lang.org/node/2097) as well. – Can't Tell Apr 10 '12 at 06:24
  • 3
    OCaml is perfectly suitable for _concurrent_ programming. Maybe you meant that the current official implementation of runtime doesn't support SMP _parallelism_ - that's true. – ygrek Apr 10 '12 at 11:31

7 Answers7

5

Yes, OCaml is suitable for concurrent programming. It does have a Thread module that allows you to program network applications the way you would do it in Java.

Note that it currently does not support true parallelism (you won't have two threads running OCaml code in parallel), but it doesn't matter as OCaml is much faster than many other languages (for example, on a QuadCore, the Language Shootout shows that OCaml outperforms even Haskell with multicore capabilities).

Fabrice Le Fessant
  • 4,222
  • 23
  • 36
5

OCaml is suitable for concurrent programming. The standard library supports two concurrency models: threads with shared memory (with mutexes and condition variables for synchronization), and events based on John Reppy's Concurrent ML.

OCaml does not include support for symmetric multiprocessor parallelism. The runtime executes on a single processor. If you want to take advantage of a multicore machine, you need to run at least one runtime per processor and use message passing between the runtimes. Message passing has a higher latency but is a lot harder to get right than shared memory. As a bonus, programs can be distributed across several machines on a network without changing anything except the way the runtimes find each other when they start up.

JoCaml is an extension of OCaml with a better concurrency and distribution model (the join calculus). It's not as polished as the official OCaml distribution, but has the advantage of providing transparent communication (send a message on a channel without worrying whether the other side is in the same runtime or even on the same machine) and a mostly typed framework to communicate between multiple programs.

Gilles 'SO- stop being evil'
  • 104,111
  • 38
  • 209
  • 254
3

Depending on what you mean with suitable for concurrent programming I would recommend OCaml or SML (Standard ML):

  1. Multiple threads for not having to wait for I/O (networking/file system/..); take OCaml -- its compiler generates very fast code and has a lot of excellent libraries
  2. If concurrency means native threads that allow you to use multiple cores on one machine within the same shared memory segment; take SML (polyml) -- it has a decent compiler and supports native threads

Beware that with either solutions you will start using type inference! Once you get used to it, programming in any language without will make you cry! ;)

lambdapower
  • 1,022
  • 6
  • 12
1

Python satisfies most of your needs aside from static typing, however, because of its design it has something called the GIL or Global Interpreter Lock. This means that python threads don't truly execute separately. This might explain the criticisms you spoke about in reference to python and concurrent programming. However, python has the multiprocessing module which provides an api to use processes like threads. Also implementations of python which run under different vm's don't have a GIL, if you are already familiar with Java, perhaps you should look into Jython which is a python implementation which runs on JVM.

Also it is not obvious but worth noting that Python does compile to byte code. It does it on first import of any script, meaning that if a python source file is edited and imported it is compiled once, all further attempts to import that same module use the byte-complied version and do not re-execute the script. This behavior is more like java than PHP which literally re-interprets the source on every run.

john-charles
  • 1,417
  • 4
  • 17
  • 30
  • Also, there's http://www.stackless.com/ Python--in contrast to the C-python that is most common. Other variants of Python exist, and in this case, stackless Python aims to address exactly the concurrency issue with the elegance of the Python language. – hexparrot Apr 10 '12 at 06:06
  • Note also that you need either native threads or multiple processes to take advantage of multiple cores, so in practice python's limitation makes little difference to performance. – Marcin Apr 10 '12 at 07:26
1

I will like to introduce three languages that might to a large extent satisfy all the features you are looking for

  1. Haskell

    • Has an interpreter (for faster development): Ghci and the Hugs interpreter
    • Has a compiler (because compiled code would run faster): The Glasgow Haskel Compiler
    • Has OO capabilities: To an extent, please read the article Haskell vs OOP
    • Statically typed: Yes without requiring type declarations
    • Suitable for concurrent programming.: Yes, of course

  2. Erlang

    • Has an interpreter (for faster development): Well the way Erlang works, you may not have an REPL, but then not always interpreter can help for faster development. But to some extent you can use erl for the purpose.
    • Has a compiler (because compiled code would run faster): Yes
    • Has OO capabilities: Nope, but there are experimental extensions available. But if you are developing in Erlang, you should better stick with functional programming
    • Statically typed: No
    • Suitable for concurrent programming: Yes, thats what Erlang is known for.

  3. Groovy

    • Has an interpreter (for faster development) : Yes
    • Has a compiler (because compiled code would run faster) : Yes
    • Has OO capabilities: Yes, after all its based on Java
    • Statically typed: No
    • Suitable for concurrent programming: Yes, it inherits from Java.

Finally

  • Java has something called BeanShell which can work as a Java Interpreter, if thats what stopping you from using Java.

  • You have twisted in Python to add concurrency to the language.

If you want to research further, use the following wiki links

akoprowski
  • 3,297
  • 1
  • 18
  • 26
Abhijit
  • 62,056
  • 18
  • 131
  • 204
1

First of all its more important to think about other resources.

1) Has an interpreter ( for faster development ) - imo un true

2) Has a compiler ( because compiled code would run faster ) - really ? what about different archs on dev and server machines and deployment ?

3) Has OO capabilities - why ? functional languages are better suited for parallel programming

4) Statically typed - why ? if it has "null" value in type system then there is no difference between this and non statically typed imo.

Better criteria are

  1. How many good quality libraries are there and frameworks for you to use.
  2. How you will deploy this solution
  3. How easy it is to bring new developers to your project

  4. What is the quality of community :)

    • Ocaml is a great language and with Lwt library you can do async code even while having 1 process easy. Ocaml also is blazing fast! This seems to be nice solutions but you don't have a lot of production ready frameworks.

    • Erlang has the libraries, its cool, fast and seems to be best solutions for your needs.

    • Ruby and Ruby On Rails will not enable you to write concurrent code easy but you will be able to build solution fast and start to earn money on it :) I mean like 10 times faster then in other languages because you have ready blocks. Also deployment is easiest in this case.

    • Node.js great speed, easy to pickup languages ( javascript ) but early stage of development so not many production ready things.

Now this is how i approach solutions:

In terms of performance you have a trade of

  1. Memory cap

  2. CPU cap

    • Memory cap ( ram ) means that solution written in this language will consume more and more ram and in the end you will have to buy new boxes fast and boxes to scale will have to be "fat":)
    • CPU cap means that the solution has really agressive garbage colector and allocates a lot of small objects that are cleaned often.

Node.js and Rails in this context are Memory capped, Rails will consume on avg ~250mb of ram per worker on production. Ocaml / Oscigen , Erlang / Webmachine are CPU capped, most of functional languages will be going this route.

I did small test for webmachine on my macbook pro with i5 CPU https://gist.github.com/1996858 This resource was serving simple json pulled each time from redis without caching.

1 million requests Total: connections 1000 requests 1000000 replies 1000000 test-duration 463.413 s

Connection rate: 2.2 conn/s (463.4 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 390.6 avg 463.4 max 3245.7 median 453.5 stddev 101.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 1000.000

Request rate: 2157.9 req/s (0.5 ms/req)

Now the best part i was monitoring memory usage. it was at about 19.3 mb ram.

If you would ask me i would build prototype in of application in Rails then extract json api's and build them in Erlang using webmachine. Or just build app in Erlang using webmachine and just use some nice features of some ruby libs like capistrano for deployment :)

Jakub Oboza
  • 5,291
  • 1
  • 19
  • 10
0
  1. Learn Scala.
  2. If not satisfied and you are willing to work with MS Visual Studio, learn F#.
  3. If not satisfied and you can reconsider your point (3), learn Haskell.
  4. If not satisfied and you can reconsider your point (5), learn OCaml.

Note that OCaml programs can relatively easily work across separate processes, since it can even marshal closures.

lukstafi
  • 1,883
  • 15
  • 22