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

[jan.de.kruyf@gmail.com]

On Monday, May 25, 2015 at 8:44:37 PM UTC+2, Shark8 wrote:
> On Monday, May 25, 2015 at 1:14:56 AM UTC-6, jan.de... wrote:
> > 
> > 
> > 1. Does a program become easier to prove formally when the language has more baroque features?
> 
> Quite possibly.
> One simple instance of this is case-coverage -- Ada is one of the [relatively] few languages that requires all possibilities to be specified, this is due to the prevalence of C and its influence on language design (in particular its choice to make enumerations an alias for int-values) -- wich is a feature Ada has had since its inception.

It is also in the 17 pages, notwithstanding Georg's doubts. If it is not it is an oversight in the editing.

> 
> > 2. Does it become easier to write when the language has more baroque features?
> 
> Quite possibly.
> The TASK construct provides a fairly natural way to implement a protocol, in addition to providing a logically parallel thread. There's also Ada's GENERIC, which is more complex than many other languages, which can have values in addition to types (or packages) as parameters.

My example is lame in this respect since obviously Tasks are needed, which were not in original Oberon, although they were easily constructed, but you were in charge and had to watch your running times. That was still single processor world.

You might find the Generic / Template idea indispensable perhaps. I have used it on occasion and to me it is easy to use, but at the same time I am happy without it if it makes the language overly complex.

> 
> > 3. Does the program production process become faster when the language used has more baroque features? 
> 
> Quite possibly.
> Consider Ada's package system: it is essentially a module-system, but in conjunction with generics provides a much saner parametrization/template mechanism than text-substitution mechanisms.

The package system comes from the days of Modula and is firmly embedded in the 17 pages.

> 
> > 4. Does the program become easier to maintain when the language has more baroque features? 
> 
> Given the above: quite possibly.
> (You have to take advantage of the facilities to gain the benefit, obviously.)

Shark, the features you bring up are not at all the issue. It is much deeper than that and I would love a good discussion about it, because to be honest I am totally puzzled by the 1500 pages.there is something deeply wrong with the thinking behind it. And I am the least of all to say that. Much greater brains have before me.
I love the language, I like working in it, except when the compiler is throwing its toys. And dont misunderstand me, it is always for good reasons (according to the RM, and my logic brain tells me it is right) but the dichotomy stays: How is it possible to _not_ have all these issues and work fast with the _same_ precision and security and provability as what we are used to in Ada. It boggles the mind.

> 
> > 5. Do we attract more programmers to a language that is clearly over-specified and difficult to learn?
> 
> I'm not sure it's difficult to learn.
> It's different than the C-family syntax that many younger programmers are familiar with, but that says nothing about the ease of learning. Further, given the results of McCormick's model-train course I would venture to say that it isn't too difficult -- now, granted there is a dearth of easy-to-find tutorials and fun/open projects (esp for Ada 2012)... but that is a tangential issue.

True and I am aware of the McCormick paper, And broadly speaking I would agree with it. And yes the C crowd gets pissed off because the lack of features in Oberon. But then you have not worked in overdrive :)

I think that the problem lies partly a difference in concepts between the 2 languages, although they look surprisingly similar. When you know the one you think you can program the other, but that then proves to be a falleximble. 
Oberon is very much a reduced instruction set language. Anything complex is either a library package or a code pattern. So formal proof, for those who need that, is relatively easy. And for me production-wise it was a big bonus. When you are coding, your immediate working knowledge consists of exactly those 17 pages. And you know them off by heart in no time, from doing them again and again.
And when you do your program design you dont get sidetracked by language complexities.

So obviously it was ever only a teaching language and it needs a lot of deep thinking and hard work to get it up to todays needs. The few tries were rather feeble (Georg's component pascal was one of them) since there were no deep pockets behind it. So I can sit and wish for that to happen but that is not very productive. I would rather make a positive contribution to some language like Ada.

And in the mean time I will just put a small single pass compiler together for the ARM work I do.I did it before for AVR. It is very enjoyable.

And by the way let me say it again: this is _not_ a language shoot out. I have not got time for such crap. But I would certainly like some light over the issues I raised (And beyond "we need it" and "we always done it this way", that for me merely points to a vested interest).

Cheers,

j.