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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 30 May 2015 13:52:56 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> On Saturday, May 30, 2015 at 6:40:59 PM UTC+2, Dmitry A. Kazakov wrote:
> 
>>> 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.

Yes, repeating the old saying - if C is a solution what was the problem?

> So perhaps the expressiveness and the simplicity are in relation to the
> problem you want to solve.

That is abstraction level in relation to the problem space. But, Ada, C,
etc thought to be universal purpose languages. If you wanted to define
expressiveness for such languages you should forget the escape to
relativism.

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

As if social "science" could give answers.

> I am attracted to the D-W school exactly because it was shaped by the
> daily interaction with dumb people.

Students aren't dumb, not as programmers are! (:-))

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

That is strange because syntax is such a minor part and because in case of
Ada it is very difficult (at least to me) to understand its BNF, because
they tried to push precedence (and some other) rules into it.

Luckily nobody, except maybe you, cares, since precedence rules are evident
from the titles of ARM table of contents.

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

Since 1995, nowhere.

> And based on social science I would say that the picture is not good.

Well, bringing relativism back, since there is no progress in programming
languages anyway Ada's position remains basically same. Nothing lost,
nothing gained. Some bad features added, but we are free not to use them.

> But
> then there is a lot of money behind it from a source that will never dry
> up (armaments)

There is no money behind. Even if military contractors were interested in
Ada, they are not, their money is miniscule compared to what is thrown into
rubbish languages by civilians and that together is nothing compared to
what is wasted on so-called tool-chains.

>> 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 do. The error is in trying to decompose any problem in terms of
standard numeric types. This starts with the notion of algorithm (operating
this rudimentary set of types) and data structures (amorph aggregation of
the same limited set of entities). This is inherently low-level with no
chance of abstraction to address complex or large problems. It looks
minimalist and fine only in a text book. But those "dumb students" must
become software engineers, some day...

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

And? You will use some type for that anyway. What you describe, provided it
is indeed the *same* problem space entity, is lack of reuse. This can have
reasons as well, e.g. being a result of modular, separate design.

This is solvable without Unchecked_Conversion, e.g. by ad-hoc supertypes,
if Ada had them.

> But when
> the programmers just use types cause you need to use types cause the boss
> says so,

Really? I never saw such bosses. Usually a boss does not even know that
there are types.

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

See above. You still believe that everything is int. This is a clarity and
elegance of machine code. Good luck with that!

> I posted an example the other day involving passing a string to printk.

As I said Ada lacks means for handle this. Just look at
[Wide_][Wide_]{Character|String} mess in ARM. This is a mess because there
is no way to sort it out. It must be the mess. Considering Wide_String and
String same type would not resolve that mess. You will still have to
convert one to another, because they are different entities in the *problem
space*. They are there, whether you wanted or not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de