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.182.135.163 with SMTP id pt3mr26156148obb.11.1434205281785; Sat, 13 Jun 2015 07:21:21 -0700 (PDT) X-Received: by 10.140.101.22 with SMTP id t22mr279903qge.32.1434205281666; Sat, 13 Jun 2015 07:21:21 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!h15no2419149igd.0!news-out.google.com!k20ni1537qgd.0!nntp.google.com!q107no1005583qgd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 13 Jun 2015 07:21:21 -0700 (PDT) In-Reply-To: <90baaa9f-8d9b-48bc-9b26-bb005fde9192@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.210.1.171; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.210.1.171 References: <4f4cd4b1-0a6d-441b-a4f7-98add70e4e1e@googlegroups.com> <1p71vf5ckbudu$.1qcb9ot1jpysk.dlg@40tude.net> <90baaa9f-8d9b-48bc-9b26-bb005fde9192@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1e967e01-706b-41bc-b961-a426a05d7b6c@googlegroups.com> Subject: Re: Is this a bug in my code or the compiler? From: jan.de.kruyf@gmail.com Injection-Date: Sat, 13 Jun 2015 14:21:21 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:26305 Date: 2015-06-13T07:21:21-07:00 List-Id: On Saturday, June 13, 2015 at 12:10:22 AM UTC+2, David Botton wrote: > > Or, uh . . . A language designer having to worry about... :) >=20 David, > Actually it is exactly what a designer should think about. Want to preven= t when and how reasonable errors by the use of that language. > =20 Of course I agree with you there; but there is a fine line, that we as prog= rammers are not always aware of. Which is the balance between nannying the = programmers and giving them true power. (not in the C sense) >=20 > Yes, I could just write in assembly, but that would remove the efficiency= of my creativity as a programmer :) I choose my tools to assist me in both= beautiful expression of the idea that others can read (and as Wirth points= out in Programming in Oberon, Assembly is unreadable) and to assist me in = correctness. Which is fully my sentiment. But I grew up with those 8 bitters. So histori= cally I might be more inclined not to trust my tools, unless I fully unders= tand them. Which is very hard of course these days. >=20 > Not sure I got that one. I assume first I was wrong and the tool had a di= fferent idea than I, as was evident.=20 I always blame the tool first (shame faced . .) but that got me quite far b= ecause then I start taking the tools apart, to see what is cooking. (and mo= st of the time find it is me) > Not sure though how Wirth fits in I was just repeating the sentiment of the group in a joking way, as I under= stood it a while back. > (I wish he would have qualified his statements a bit more. He killed his life's work by not communicating. And what is worse, the facu= lty had no real way forward when he left. Nothing is happening there anymor= e. His secrets are revealed in his code. > I would say that concatenation operations with order of evaluation not si= gnificant is an unexpected gotcha for most human readers and so a language = should not tolerate it. Or perhaps this "must have" runs amok with the limitations Dmitry pointed o= ut in the second post of this thread, but the designers did not realize at = the time (it was still single processors then). This touches the deepest levels of computer science. Many thick books have = been written about order of evaluation and concurrent execution. Look at the amount of work it took to clean up the linux kernel so it could= be more or less real time and pre-emptible. Now it will take a lot of courage to go back a few steps and see if we can = implement this thing in a different way, which automatically resolves the c= oncurrency issue. If you are interested in that kind of thing, have a look at the chapter abo= ut texts in Project Oberon (the book that describes the operating system, a= nd the compiler) He found a very clever way to deal with strings, texts, st= reams fonts etc. Any text consists of a collection of pieces (strings) in a double linked li= st. And each piece has attributes (font, color, anything). And a text knows= how to load itself and store itself (That is also where the mess gets sort= ed and the pieces are collected into bigger pieces, where the attributes al= low) So if you want to insert some text you just split the piece in two and inse= rt a new piece, and so on. The concept looks very messy at first, but it wo= rks very fast and it automatically deals with wide strings etc. by virtue o= f the attributes. As a programmer you have a unified and coherent view of the whole text busi= ness, except for the most trivial strings, there you just roll your own if = needed. enjoy your weekend, j.