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

[Georg Bauhaus <bauhaus@futureapps.invalid>]

On 22.05.15 22:04, kalvin.news@gmail.com wrote:
> perjantai 22. toukokuuta 2015 22.41.15 UTC+3 J-P. Rosen kirjoitti:
>>
>> To take an analogy: nobody would be so fool as to use a language
>> designed for making animations on web pages in a real-time context ;-)
>>
>> --
>> J-P. Rosen
>> Adalog
>> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
>> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
>> http://www.adalog.fr
>
> Reality bites.

Sort of.

> And it is quite easy the find developers how are familiar with C/C++.

HR staff think they find people who think they are familiar with C
or even C++. That's good enough, though, if employment is evidence.

People who write C scarcely know what they really are writing. But.
It is perceived risk, though, both on the part of programmers and
on the part of management that counts, also perceived quality of
software in general. So, the risk of using C is reduced if every
programmer and every manager takes the same risks.

(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.)

C is tricky, and its ISO standard is impressively long for a reason,
even though it omits many things to be documented per implementation.
(Some 150 pages for the core language, excl. the library, for a total
of around 500 pages.)

C++---a language that for reasons of historic incident is believed
to be some sort of C, and mentioned curiously in contexts
such as in "C/C++"---is a different beast entirely.
How many microcontrollers can one program in C++ without using
some C++ -> C translator?

> And it is very hard to convince managers to invest to new tools that they do not know or understand, or their knowledge is based on outdated information (like "Yeah, I know Ada. One of my friends worked with Ada in 80's and it was *very* slow, the compiler produced terrible code and they needed Vax-cluster to run the compiler. Ada is so big."). So, we are dealing with a cultural, economical and practical challenges as well as historical burden and bad reputation.
>
> I do not claim that even Ada would be the ultimate solution. Someone made a good point above that, for example Oberon manual is only like 17 pages

Actually …

> and Ada RM is over 1000 pages.

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.

Now why is the Ada LRM still 10x that of Component Pascal (current
Oberon)? In part because of ISO requirements, needed for solid works
of industry, when not "soldering". Precision is needed. In part,
because Ada has task types generic units and elaboration and so
one, as has already been mentioned; things that were needed, and
will be needed even more in the future, provided that microcontrollers,
too, will get more ALUs working in parallel. (ActiveOberon formed
Object + Semaphore constructs; another dozen pages, and again
offloading much on programmers, see below.)

E.g., quoting from the "Component Pascal Language report" (about
30 pages), on CASE statements:

"If the value of the expression does not occur as a label of any case,
  the statement sequence following the symbol ELSE is selected,
  if there is one, otherwise the program is aborted."

Abort? That would not have been acceptable to an Ada compiler from
day one.
But, surely, all programmers will do the right thing, won't they?
And good testing should find the hole in the Oberon program
before it is deployed, right?

To me, this report is a example of how a language definition shifts
responsibility (and definitions) to programmers doing all the work of,
say, keeping case statements right…
This might work well for the self-employed or for small groups
of programmers, and for programs that are sufficiently small; but how
should this help refactoring, say? Changes? What I want to point out is
this: it is not that surprising, then, if the Oberon "manual" can be
very short.


> There might be something wrong here, and may explain partly why Ada has not gain popularity.

Yes. History and pricing.