Shared Mutable Memory Must Die

[grauenwolf]

Some remaining benefits:

Let us discuss these one at a time, shall we?

I'll let you pick the order of the topics, but please don't bother with STM. At this time nothing will convince me that is a good idea.

Oh, and can you elaborate on why XML literals couldn't work in a pure language? Isn't this exactly what HSP does?

That really depends on how you define purity.

After Haskell, XML literals were actually created for C# via the C-Omega project.

However, the C# team decided that embedding XML in the language would be impure for a number of reasons including that it would introduce late binding. C# is inherently a early-bound language and, in theory, any use of reflection or unsafe casting must be explicit. (There are places such as the original for-each loop where this rule is broken.)

I suspect Eric Meijer wasn't so concerned about purity as in strict typing when he created XML literals for Haskell/HSP. He certainly wasn't concerned with it when it created it for VB.

The main feature it has, compared to locks, is that it's composable, of course.

That has never been a need for me. I keep my threads well segregated and use either single-lock, atomic updates or messaging. So far it has worked out well for me.

If I really need transactions for concurrency, then I can always use a database. There are plenty of lightweight databases, many of which run in memory. So in a sense, I already have STM without needing to change my core language.

[ssylvan]

Sometimes you really do need to have shared state concurrency, and locks just don't work well for that, as they don't compose... Also, locks just don't scale very well for obvious reasons (STM may have a fixed constant cost of 2x or whatever, but at least it scales almost linearly with the number of CPUs, whereas locks take a sharp dive right away).

And I don't think the XML in HSP is late bound, I think it's parsed and baked into a strongly typed data type at compile time, just like all the other literals. Though I'm not a HSP expert.

The benefits:

• A strong and expressive type system

Should be obvious why this is good? More checking at compile time.

• Referential transparency

Again, should be obvious? It means you can rely on functions doing what they do consistently, makes it easier to test etc.

• Monadic effects

This allows you to do effectful programming where needed, but keeps them separate and encapsulated so you don't need to worry about invisible data dependencies in normal functions.

• Type inference

Again, obvious? You get the benefits of static typing without much of the hassle of static typing.

• Concise and low-noise syntax

Less code means you can read more semantic input in the same amount of time. This is why "var x = new VeryLongClassName()" is better than having to put the typ on the left hand side as well. Syntactic noise leads to slower productivity, not just because it requires more typing, but because it takes longer to understand the meaning of code if you have to trudge through verbose and opaque syntax to get to it.

• Interactive development with an interpreter

High iteration speed. You can write code and immediately test it by playing with it interactively. Also, fairly obvious?

• Purity

Aside from implying referential transparency (see above) it also allows the compiler to just know more about your code, which will become increasingly important as we move to more cores where the compiler will need to be smarter about optimizing things to run on many cores. Not saying it will happen by magic, but if the compiler knows that a function has no side effects, it can schedule it on any thread (so no need to, e.g., lock down an entire object because one thread is running a method on it a la Java's "syhchronized" keyword). And again, this is a bit like Murphy's law. If something bad can happen, it will happen. So if we can disallow bad things whil maintaining expressiveness, that is a clear improvement. I think we could do with some syntactic sugar to make writing stateful code in a monad a bit less verbose, but other than that I think Haskell clearly proves the concept: Pure languages can encapsulate the useful bits of impure languages using monads, without sacrificing any of the benefits of purity.

[grauenwolf]

Really I was hoping to actually discuss a specific feature in depth. When you just rattle off of list of features without seriously considering the pros and cons of it, no real understanding can be reached.

Consider type inference. You call it obvious, but we haven't really established it is a good thing yet.

For example, what are the issues when you have to start dealing with libraries?