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

[jan.de.kruyf@gmail.com]

On Saturday, May 30, 2015 at 6:40:59 PM UTC+2, Dmitry A. Kazakov wrote:


> I think this is untrue. Mathematical descriptions are based on the language
> of mathematics. Actually there are a lot of such languages depending on the
> sets of axioms taken and the methods of proofs considered acceptable, e.g.
> constructive mathematics etc. But that is beside the point, which is that
> whatever mathematical language you took, it is far more powerful than any
> programming language because its "computational" framework is infinite,
> sometimes uncountable infinite etc. Trivial mathematical descriptions may
> be incomputable, thus whatever elegancy of triviality they posses, you
> could not express that in any programming language. And conversely, trivial
> things in a programming language might be quite impossible to describe
> mathematically. E.g. anything that involves constraints. For example, brute
> force methods working fine just because it is a finite number of states.

The Dijkstra - Wirth school differs from you here, whether justified or not I cannot say, I am not a trained mathematician. All I can say is that 
1. they came to their conclusions mainly because of their experience teaching undergraduates and through struggling with the matter themselves.
2. that I personally work a lot easier in a well defined elegant language.
3. Some great discoveries in computer science were made in those days by applying their homegrown mathematical rules. it is fascinating reading.

At the same time I gladly give you that something as strictly defined as that does not fit well with Windows or Linux or you name it. I am doing a kernel module adaption at the moment and also Ada and Linux kernel fit very badly.

> 
> Or pattern matching languages, or relational algebra languages, elegant to
> someone's, should I say pervert, mind and unusable for decent software
> developing.

Yes I did try to make emacs behave on the odd occasion, but then I did not want to destroy the quote since it brings some worthwhile issues to debate.

> 
> > Other ways to describe this aspect are to say that the language should
> > have an inherent simplicity and be easy to learn, expressive and
> > orthogonal. Expressiveness is the power of a language to solve problems.
> 
> That yardstick is too crude. Most languages are Turing-complete, you can
> solve any solvable problem in practically any programming language.

True but not all are easily applied to a particular problem. Ada is very nice for big technical projects, C is good if you want curly brackets, Oberon is excellent when you dont know yet which language fits best, because you make up what you need out of the lowlevel blocks, but as soon as there is an operating system involved you are stuffed again. 
So perhaps the expressiveness and the simplicity are in relation to the problem you want to solve.

> 
> > Orthogonality requires combinations of legal constructs to be themselves
> > legal constructs."
> 
> I understand the intention, but taken literally this is an evident rubbish.
> There are certain rules (an algebra) to apply to the language entities in
> order to obtain new entities. It is not just combinations (there are
> operations in the algebra) and not any combinations (there are constraints
> to which operations apply to which entities, yep, those pesky types again).
>  
I am with you but
Perhaps he means to say something, more in relation to the dangling else and similar issues. An if then else might be legal, but the combination of 2 of them might not be in some circumstances.
After all this piece of text was written for an undergraduate class.

> Of course it is the semantics which makes these 99.9%. Of course the
> popularity vote disregards semantics and see if there are curly brackets
> here.

I note that here we move away from computer science and into woollen socks science. (Named after the habitual foot wear of the members of faculty)
i.e. we will have to look at social science for an answer here. 
I am attracted to the D-W school exactly because it was shaped by the daily interaction with dumb people. Although Wirth might deny that.

We may sit and talk here till the cows come home, but the convincing arguments will only come about in discussion with the curly bracket programmers.


> We can safely say that Ada is far more readable than EBNF. Even highly
> trained people could not say whether given sequence were legal according to
> given EBNF.

I just meant to say that I am comfortable using the EBNF as a reference to Oberon. It tells me everything I need to know in almost all cases.

I just had a giggle and tried to look up "pure" in the bnf. It is not there. Then I went back to the index which referred me to some place about 10 lines below where I should have read.On reading the right section I decided better wait until tomorrow when I am fresh, my digestion will work better. So all in all I might perhaps say that the social sciences where not involved when the ARM was written, because believe it or not, there are certain editing rules that promote clarity.
This is not to drag the ARM editors down, its just to point out that logically it is no doubt correct, but there are almost no people whose first language is "logic".

> 
> > But the crowd likes to turn this into a language war around every corner,
> 
> Not really. What I am trying to stress is that problems lie elsewhere.
> These problems are huge and nobody gives a damn. Curly brackets that's
> important!

I was not blaming you really. But it does get annoying when a person has to take a week fighting all kind of attacks, just to get the crowd to do at least some reflexion on where we all are going with Ada. 
And based on social science I would say that the picture is not good. But then there is a lot of money behind it from a source that will never dry up (armaments)

> 
> He himself wrote as a title: Algorithms + Data Structures = Programs

Yes I got that book. What it covers is not bad, What is left out is the problem.
But types hardly belong there. They are in chapter 2, 8, 9, 11 and 12 of the undergraduate book (at least in the Oberon version of those books)
He turns that issue over and over and over until it is correct and elegant. 
That is not to say we cant expand on it, but the basis and more importantly the reason why, are there.

> There is never too many types. It is simply so that you probably confined
> to the idea of algorithms and data being programs.
> 

My first experience of the issue was when I was barely literate in basic and started to do assemlby. I learned then to draw some circles representing the functions (algorithms if you like) and lines connecting them, representing function calls.
In those function-call-lines I used to draw a big spiel, meticulously specifying the data that was exchanged. Those interfaces were much bigger than any of the rest. That was my first experience with (homegrown) typing of my data. And it worked like a bomb. All of a sudden I saw structure. This was long before the universities tought anything like it. 
So I am all for types, they bring clarity and abstraction in my programs, they might indicate units for physical quantities etc.

But once we get to the very same unsigned quantity or menory address defined in 5 different places by 5 different people who then at the last minute quickly made a kludge to be able to read each others data, then I say let types be damned. I need to get on with the job here. 

> 
> Even in c.l.a lot of people honestly believe in that idea. Then GNAT was
> started in Ada 83 times. And even now Ada's type system is too weak to
> express great many things. That is how you get Unchecked_Conversion, access
> types and Constraint_Error.
> 

Yes I am aware of your work with unit measures. So there I agree. But when the programmers just use types cause you need to use types cause the boss says so, then the problem is not having this type or that type, then the problem is a lack of knowledge, clarity and elegance in the methods those programmers have been taught. This problem can only be fixed by taking there toys away from them for a bit.
Then all the typing becomes meaningless, and suprise suprise gnat also suffers of that. I posted an example the other day involving passing a string to printk.
I am aware that part of gnat is quite old, but then we come to the issue of the vested interests, which also must be listened to of course, but that is not about language that is about money. So we will have to see how the 2 can meet.

cheers,

j.