[Haskell-cafe] A Procedural-Functional Language (WIP)

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Oct 28 00:49:32 UTC 2016



On 27/10/16 6:17 PM, Joachim Durchholz wrote:
> Am 27.10.2016 um 01:05 schrieb Richard A. O'Keefe:
>> This means that in the foreseeable future we are going to need
>> to learn a new style of programming because the antique style,
>> as exemplified by say Java, just isn't going to scale.
>
> I think you underestimate the adaptability of existing languages.

Well, I don't think so.
>
> Java has been preparing to move towards immutability&FP. At glacier-like
> speed, admittedly, but once those massively multicore systems appear,
> Java will be prepared to move.

Nobody ever said Java (or any other language) can't ADD things.
The problem is that Java can't REMOVE the things that get in the
way without ceasing to be Java.

It's just like the way you can ADD things (complex arithmetic in C99,
threads in C11) to C, but you can't REMOVE the things that make C
horribly dangerous without it ceasing to be C (and thereby ceasing to
be useful in its admitted niche).

The fundamental operation in Java is the assignment statement.
It is fundamental to the Java Memory Model that when optimising
memory references the compiler is explicitly allowed to pretend
that threading doesn't exist.

If you fix those issues, you don't have Java any more.

> Haskell can claim to be already there, but wrt. how many issues have
> been staying unaddressed, it's no better than Java, it's just different
> issues.
> IOW this is not a predetermined race.

Nobody ever said it was.  To be honest, I don't think ANY existing
language will survive unscathed.  I really wasn't talking about a
race, simply making the point that we need new ideas, not just a
rehash of the old ones.

A very simple point:  the more cores are running at once, the
sooner your program will run into trouble, if it runs into trouble
at all.  And the more cores are running at once, the nastier it
gets for a human being trying to debug the code.  So we're looking
for a language that can give us strong guarantees that certain
kinds of mistakes either CAN'T happen because the language cannot
express them or WON'T happen because it can verify that your
particular program doesn't do those bad things.



More information about the Haskell-Cafe mailing list