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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.50.13.97 with SMTP id g1mr25662467igc.13.1432583667292; Mon, 25 May 2015 12:54:27 -0700 (PDT) X-Received: by 10.140.109.35 with SMTP id k32mr275643qgf.34.1432583667161; Mon, 25 May 2015 12:54:27 -0700 (PDT) Path: buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!h15no8390923igd.0!news-out.google.com!k20ni44923qgd.0!nntp.google.com!z60no3789905qgd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 25 May 2015 12:54:26 -0700 (PDT) In-Reply-To: <3277d769-6503-4c7f-885f-3a730762b620@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.237.110.115; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.237.110.115 References: <127b004d-2163-477b-9209-49d30d2da5e1@googlegroups.com> <59a4ee45-23fb-4b0e-905c-cc16ce46b5f6@googlegroups.com> <46b2dce1-2a1c-455d-b041-3a9d217e2c3f@googlegroups.com> <3277d769-6503-4c7f-885f-3a730762b620@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3e343282-202d-48e0-b8ab-2f427c1d8c3c@googlegroups.com> Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? From: jan.de.kruyf@gmail.com Injection-Date: Mon, 25 May 2015 19:54:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:193294 Date: 2015-05-25T12:54:26-07:00 List-Id: 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: > >=20 > >=20 > > 1. Does a program become easier to prove formally when the language has= more baroque features? >=20 > Quite possibly. > One simple instance of this is case-coverage -- Ada is one of the [relati= vely] few languages that requires all possibilities to be specified, this i= s due to the prevalence of C and its influence on language design (in parti= cular 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. >=20 > > 2. Does it become easier to write when the language has more baroque fe= atures? >=20 > 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 G= ENERIC, which is more complex than many other languages, which can have val= ues 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 us= ed it on occasion and to me it is easy to use, but at the same time I am ha= ppy without it if it makes the language overly complex. >=20 > > 3. Does the program production process become faster when the language = used has more baroque features?=20 >=20 > Quite possibly. > Consider Ada's package system: it is essentially a module-system, but in = conjunction with generics provides a much saner parametrization/template me= chanism than text-substitution mechanisms. The package system comes from the days of Modula and is firmly embedded in = the 17 pages. >=20 > > 4. Does the program become easier to maintain when the language has mor= e baroque features?=20 >=20 > Given the above: quite possibly. > (You have to take advantage of the facilities to gain the benefit, obviou= sly.) Shark, the features you bring up are not at all the issue. It is much deepe= r than that and I would love a good discussion about it, because to be hone= st I am totally puzzled by the 1500 pages.there is something deeply wrong w= ith the thinking behind it. And I am the least of all to say that. Much gre= ater brains have before me. I love the language, I like working in it, except when the compiler is thro= wing its toys. And dont misunderstand me, it is always for good reasons (ac= cording to the RM, and my logic brain tells me it is right) but the dichoto= my stays: How is it possible to _not_ have all these issues and work fast w= ith the _same_ precision and security and provability as what we are used t= o in Ada. It boggles the mind. >=20 > > 5. Do we attract more programmers to a language that is clearly over-sp= ecified and difficult to learn? >=20 > 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-fi= nd tutorials and fun/open projects (esp for Ada 2012)... but that is a tang= ential issue. True and I am aware of the McCormick paper, And broadly speaking I would ag= ree with it. And yes the C crowd gets pissed off because the lack of featur= es 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 falleximb= le.=20 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 bon= us. When you are coding, your immediate working knowledge consists of exact= ly those 17 pages. And you know them off by heart in no time, from doing th= em again and again. And when you do your program design you dont get sidetracked by language co= mplexities. So obviously it was ever only a teaching language and it needs a lot of dee= p thinking and hard work to get it up to todays needs. The few tries were r= ather 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 h= ave 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 wa= y", that for me merely points to a vested interest). Cheers, j. =20