Re: Build language with weak typing, then add scaffolding later to strengthen it?

[jan.de.kruyf@gmail.com]

On Saturday, May 23, 2015 at 2:40:25 PM UTC+2, Georg Bauhaus wrote:


> 
> People who write C scarcely know what they really are writing. 

That sir is a rather shallow statement to make. I would rather say they are experts in that they can produce so much good code with such an oldfashioned language.

> (If cheaper Ada could help, than I think that remembering DOT.COM
> business will prevent a situation that makes Ada have C-like pricing
> for microcontrollers.)
>
Wel, just of my head: there is Ada for avr and for ARM Cortex. Both free of charge, waiting for you to make a good runtime for the processor you want to use.


> 
> What corresponds to the Oberon-1 "manual" (Wirth's 1987 report,
> I take it?) in Ada's ISO reference would be the core language.
> About 1/3 of the LRM, some 350 pages.

George your Oberon commentary is way off the mark. And your argumentation is weak, but I dont need to elaborate on that, since this is not a language shoot out. I merely used it as an example to prove a point.

And statistics prove that point. I have written 1000th's of lines in Oberon and 1000th's of lines in Ada. Both highly technical software.
And I got exactly the same kind of errors on compiling and running: errors caused by my sloppy habits. And both the Oberon compiler that fits on a floppy (a floppy, not a stiffy) and Gcc which stands at over 1Gig of source in the latest implementation, caught them equally well and also the runtime errors that I caused were exactly the same. And otherwise: the precision was exquisite. Oberon has a long and proud history of making things smaller and more precise. While experience teaches that Ada tries to make things more precise, but causes bloat in the process.


So please explain to me why on earth I or DoD or ISO or anybody else needs all the bloat to confuse us. 
1. Does a program become easier to prove formally when the language has more baroque features?
2. Does it become easier to write when the language has more baroque features?
3. Does the program production process become faster when the language used has more baroque features?
4. Does the program become easier to maintain when the language has more baroque features?
5. Do we attract more programmers to a language that is clearly over-specified and difficult to learn? And the group on this list is getting frightfully small and is getting on in years!
6. Do we convince more managers to use a language of which the essence is difficult to grasp at first sight?

You may answer, I rest my case.

Cheers,

j.