From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Sun, 31 May 2015 10:52:01 +0200 Organization: cbb software GmbH Message-ID: References: <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com> <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> <3277d769-6503-4c7f-885f-3a730762b620@googlegroups.com> <9fa68fb7-89f0-42b3-8f25-20e70cb34d63@googlegroups.com> <87egm3u662.fsf@adaheads.sparre-andersen.dk> <20c56bea-2803-4aa9-a626-2d25e480df20@googlegroups.com> <1dmgofrqo3xn5$.1p4241xr4z92p.dlg@40tude.net> <1066il1b5nk21.ioykgza5bnsw.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: evoS9sCOdnHjo0GRLLMU1Q.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:26113 Date: 2015-05-31T10:52:01+02:00 List-Id: 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