More keywords? Or fewer?

[Me Here]

Davidson Corry wrote:


>If the kind of whole-system inference I am suggesting is possible (and I 
>don't know whether or not it is), then a programmer /wouldn't have to/ use 
>keywords to declare explicit contracts for constness, exception safety, 
>multiprogramming etc. The compiler would just figure out what was needed 
>and optimize for it.
>

Haskell attempts this. And does a pretty good job of it too. But at what 
cost?

A binary install occupies nearly 70 MB--it's hard to isolate how much of 
that is stricty necessary for its operation.

The last time I built it from sources, it took nearly 40 hours to compile.

But, most damning of all, is the extraordinary loops the programmer has to 
go through to do anything that involves processing large volumes of data 
efficiently. The purity ethic, ie. referential transparency, means that 
any time you want to modify a piece of information, you have to swap it 
for a newly allocated piece of memory holding the transformed entity and 
discard the old one as you pipeline them from one function to another.

Its a bit like a car assembly line. Except that every time you add a new 
component, you have to transfer what you've built so far to a new bogie. 
But of course you don't have an unlimited supply of bogies (memory) so you 
have to constantly recycle the bogies back to the beginning of the line 
and pick up a new one. Every step of the way, Bogie Control (BC) has to 
supply you with a new bogie and take back a (slightly) used one. Half of 
your total effort is spent in recycling bogies instead of building cars.

Yes. Haskell does have (unsafe) arrays, and you can use them to modify 
data in-place, to avoid the GC overhead. To use them, you have to give up 
most of the (supposed) benefits of purity, and revert to impure, 
procedural pseudo-C in Haskell. But to do that, you have to wrap 
everything up in a wrappers (Monads) to protect the precious purity from 
pollution. And in large part, you've discarded much of the reason for 
having the purity in the first place.

Before you get caught up in the hype of purity and the promises of 
lock-free, transparent multi-processing, ask to see a real world example 
of processing large amounts of data. It either doesn't exist; runs very 
slowly; or reverts to procedural techniques and non-referentially 
transparent data storage to achieve efficiency. And in the process forces 
the use of clumsy and inelegant syntax to do it.

There is a lesson to be learnt here. And it goes right back to the 
original mission statement for D's design philosophy. In a word: pragmatism.

Cheers, b.
--