Lambda the Ultimate

Surely, pure FP offers a really good way to do it - and I'll bet Guy Steele understands it better than ourselves :) - but it demands muich more training and education than more complex solutions, e.g. OO-ed threads.

IMHO you are partially right: more CS education would bring classical but modern stuff to the busines world, but I think the business itself rejects the academic CS education influence when possible[1], trying to maintain the programmers' work cheap.

[1] Well, I'm talking about mainly small and medium corporations.

I think it's especially the big corps that warm up non-academic kludges when they have all kinds of treasures in their research departments. See Sun or Microsoft.

...it demands muich more training and education than more complex solutions, e.g. OO-ed threads.

As a beginner, I wish we would stop talking about general "threads"...the term covers too much. I've never seen an explanation of threads in terms of monitors, coroutines, futures, promises, data flow, etc. in one place. I've been trying to understand how Oz can create 100 times more threads than Java...but haven't found a simple explanation (something to do with a smaller stack, but not in detail, certianly not for non-experts). Perhaps someone can point to a paper or do a little write-up explaining various kids of 'threads' AND how they are implemented in real compilers.

as in Oz, in Scheme48, and in many other languages (Erlang too I think) are user-level threads, as opposed to kernel-managed threads that involve system calls, overhead in the kernel etc.

User-level threads don't need an extra stack, as they can use other memory management schemes, such as a global garbage-collected heap, or small individual heaps, or smaller-than-usual stacks, if you know they don't need much space. OS-level threads always have to be open to anything, so they pack a full stack that can run arbitrary C code, without the kernel having to know anything about the actual *code* that's run..

One way to implement light-weight threads is to use a language (or rather a language implementation) that provides cheap continuations. That is (AFAIK) basically how Concurrent ML (CML) is implemented on the SML/NJ compiler. The CML book Concurrent Programming in ML has a chapter on the implementation techniques of CML. You can also find examples of how to implement threads using continuations from many sources. For example, see the slides 40-42.

I bet that if someone did tests on which kind of programming is easier to learn (for someone not infected yet with OO-ness), the results would clearly show FP a much better proposition. OO is very hard to use effectively, especially with braindead languages like Java or C++.

man, you changed a lot. I remeber you claiming C++ was the best language out there and imperative programming was king. And that was just a few months ago! New Year's Resolution? ;)

Can you point to any studies/papers about using FP versus explicit threads? (real threads, of course; not coroutines)

The software I work on right now absolutely requires full use of dual-processor machines.

but from what I understand threads are really no different from processes, it just has to do with the level of sharing between the threads/processes. Threads are on the one end where almost everything is shared, and processes are at the other where nothing is shared. As I understand it, there is no fundamental reason why there cannot be more flexability as to what exactly is shared and what is not shared. In fact, if I remember correctly, the Linux Kernel allows such a dynamic in sharing between processes, so that there can be full threads (everything shared), light weight processes (some stuff shared), and heavyweight processes (nothing shared). So, in the end, there is no reason why you would need threads per se, as you don't have to share memory to have concurrent processes. There are other models of concurrency out there besides shared state concurrency, and although shared state concurrency should perform better, once you put in place the nessicary mutexes in place not only is it less effecient, but now you have a whole host of problems with deadlock and starvation. Of course languages could use threads in the background, even though the model of concurrency isn't a threaded model. Erlang, for example, could do such a thing (I don't believe it currently supports true threads yet. Anybody know?)

What I'm interested in is the difference between:

* FP's referential transparency, where no synchronization/mutexes/semaphores/etc are needed (because there is no shared (mutable) state). There is of course synchronization needed when waiting for a return value, but this can be hidden, especially when the semantics of the language don't specify evaluation-order.

and

* "Threads"' need for synchronization methods.

Both can run on multiple-core machines, but where FP would need (?) to provide some kind of indication where a function call should be run, the typical threading mechanisms require explicit management of many more things.

Anyone see any good publications on this?

"bit depressing that a mainstream publication like DDJ"

mainstream is mainstream

Ada?

Re: Ada?

My, a blast from the past. Who is still using it? I've not seen anything about the language since the Occam 3 guidebook, which must have been around 1990 or so.

The good people at the University of Kent at Canterbury have been working on the KRoC occam compiler for some time. KRoC is built on top of the INMOS occam compiler, but adds a bunch of extensions to allow things like mobile channels and mobile processes. Fred Barnes, who is the principal developer on KRoC these days, has also started work on a brand new occam compiler, built from scratch.


You might also be interested in the Transterpreter, which is a VM for Transputer byte code, and runs on Windows, Linux, Macs, and Sun Sparcs (as well as LEGO Mindstorms). It'll run code generated by KRoC, although I don't believe that it implements all of the mobility extensions.

Looks interesting. Very interesting, in fact.

I liked occam as a programming language, but the language environment, at least for UNIX, was simply horrible. It's nice to see people playing with the language again.

I don't think that mandated indentation is a big issue - after all, Python and Haskell (among others) use whitespace for block delineation. Granted, occam is a little more strict on the use of whitespace (although I think that recent versions of KRoC may have an option to be less strict.

The uppercase keywords are a bit of a problem. They make occam seem "old", and they can be somewhat uncomfortable to read for people who are used to thinking of uppercase as "shouting". There are some proposals out there for modifying the syntax to be more palatable . Not sure if they'll ever catch on though.

Having said all of that, I don't think the syntax of occam is all that big a handicap. IMHO,what has really been holding back occam is the lack of a cross-platform compiler or runtime (for some time it's been Linux-only - at least up until recently), awkward I/O (no printf's), very limited libraries, limited documentation on new features, and very little in the way of graphics capabilities (although Fred Barnes has recently done some work on that end of things). In other words, all of the same things that hold back many languages that have some neat features, but are missing enough things that most people aren't willing to give them a go.

Don't get me wrong - I think occam (particularly in its occam-π incarnation) is a great language. And I have high hopes that the transterpreter VM will increase occam usage (especially if they can support the mobile code features of occam-π). But right now occam simply lacks critical mass.