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 06:21:01 -0700 (PDT), jan.de.kruyf@gmail.com wrote:

> On Saturday, May 30, 2015 at 1:12:20 PM UTC+2, Dmitry A. Kazakov wrote:
> 
>> BNF describes the language syntax or a formal language. Formal language <<<
>> programming language. Since 60's there is nothing interesting you could
>> describe in BNF or in any other syntactic formalism. We do know how "good"
>> syntax looks like.
> 
> yes we do know that. But you did not address what I said yet. 
> 
> I am trying to stress this here:
> "The mathematical aspect dictates that the language be elegant, but simple
> to describe mathematically.

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.

> Lisp-like languages are an example of
> languages for which this aspect is especially noticeable.

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

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

It is the programming techniques and paradigms that make problems, not
solvable, that is a precondition, but manageable, solutions economically
feasible, safe etc.

> 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).
 
>> That is less than 0.1% of what constitutes a programming language.
> 
> No it is not, unless you call the library the other 99.9 %.
> In other words I suspect we are arguing about semantics here.

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.

>>> And the biggest bonus will be that we will be able to work faster, once we
>>> have a good understanding of the mathematical underpinnings of the
>>> language.
>> 
>> Which ones? There is no problem parsing Ada. It is trivial, in fact. 
> 
> Yes it _is_ trivial . . . for a computer or a highly trained person like you.

Nobody ever claimed Ada less readable than C, Lisp, you name it. But yes,
the language must be comfortable for trained people. How much of your
productive time do you stay untrained? Either it takes one month to learn
and then you are using it professionally all your time, or it is wasting
time altogether. Ergo, learning curve is irrelevant. Though I bet that Ada
is far easier to learn than C, C++ or any other fancy language.

> Or we can argue that they need to be educated in the syntax of Ada, as you say.

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.

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

>> Few syntax problems Ada has come straight from Wirth himself. E.g.
>> different syntax for declarations of subprogram types and values (bodies)
>> from other types and values. Wirth seems never cared much about types.
> 
> Believe it or not he did, but he has never been known to be paranoid. 

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

> Dmitry, when I first got to know Ada I jumped on it specially for the nice
> multitude of types (since that is what I learned from the old man, to be
> typesafe) But after a few years of experience I find that I have often
> confused myself plainly with having too many types.

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

> So you could perhaps say that that was for lack of solid design. Could be.
> But then I find the same multitude of unchecked conversions back in gnat.
> So apparently it is not only me. 

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.

> By the way the other day I looked at your website and I stood in awe of
> the artworks you display there.

Thanks.

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