From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:6396:: with SMTP id x144mr3762645qkb.202.1622205468398; Fri, 28 May 2021 05:37:48 -0700 (PDT) X-Received: by 2002:a25:4009:: with SMTP id n9mr9901440yba.73.1622205468200; Fri, 28 May 2021 05:37:48 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 28 May 2021 05:37:48 -0700 (PDT) In-Reply-To: <37c582bb-3012-4954-a26c-5d9614ac0c84n@googlegroups.com> Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <5afvagd0g4uajs1ji35v3lorkgb2kd56qu@4ax.com> <87wnrkf9pr.fsf@nightsong.com> <37c582bb-3012-4954-a26c-5d9614ac0c84n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: why the pascal family of languages (Pascal, Ada, Modula-2,2,Oberon, Delphi, Algol,...) failed compared to the C family? From: Shark8 Injection-Date: Fri, 28 May 2021 12:37:48 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:62037 List-Id: On Thursday, May 27, 2021 at 6:34:08 PM UTC-6, john wrote: > On Thursday, May 27, 2021 at 11:00:18 AM UTC-5, Paul Rubin wrote:=20 > > Dennis Lee Bieber writes:=20 > > >>I/O in Pascal was flawed.=20 > > > Well... It probably worked quite well in the original OS...=20 > >=20 > > It wasn't just the I/O:=20 > >=20 > > http://doc.cat-v.org/bell_labs/why_pascal/=20 > >=20 > > Borland Turbo Pascal was very popular and apparently practical, though.= =20 > > I never used it but I have the impression that it (like most deployed= =20 > > Pascal implementations) somehow supplied workarounds to the limitations= =20 > > described in the paper above. > I used Turbo Pascal in college 40 years ago, and yes! it did supply worka= rounds. Later I realized they looked a lot like features of Modula-2 (also = by Wirth) and of Ada. Wikipedia tells me (And Therefore It Is True (TM) ;-)= ) that some of them come from UCSD Pascal.=20 >=20 > This next paragraph is from memory, which may be corrupted, and I may hav= e misunderstood it first, so don't take it too seriously, but: people who p= aid attention to what Wirth said and wrote about compiler design were able = to produce small and fast compilers. Somewhere you can find a report writte= n by one of Wirth's students about how they tried to modify one of their co= mpilers to use a tree instead of a fixed-size array with linear search for = the symbol table. Everyone except Wirth was sure that the tree would be bot= h better and more useful, and everyone except Wirth turned out to be wrong.= As I say, if it interests anyone I'm sure an online search will find it (b= ut it might not be trivial, which is why I'm not doing it now myself). > > The binary of Turbo Pascal was eventually released for no cost download= ,=20 > > but apparently the source code was never released. That is=20 > > disappointing based on how cool the above articles make it sound. > FreePascal is an open-source reimplementation of Turbo Pascal. It boasts = many of the speed advantages that Turbo Pascal has. I've never used it beyo= nd occasionally downloading & playing with it, then forgetting about it.=20 >=20 > regards=20 > john perry That story comes from the paper "Oberon: The Overlooked Jewel" =E2=80=94 ht= tps://www.semanticscholar.org/paper/Oberon-%E2%80%93-The-Overlooked-Jewel-1= -Oberon-%E2%80%93-The-Jewel-Franz/9a7870c543c19eb4f46fdfbdcfb92d33ae2bf810 = =E2=80=94=20 > In order to find the optimal cost/benefit ratio, Wirth used a highly intu= itive metric, the origin of which is unknown to me but that may very well b= e Wirth=E2=80=99s own invention. He used the compiler=E2=80=99s self-compil= ation speed as a measure of the compiler=E2=80=99s quality. Considering tha= t Wirth=E2=80=99s compilers were written in the languages they compiled, an= d that compilers are substantial and non-trivial pieces of software in thei= r own right, this introduced a highly practical benchmark that directly con= tested a compiler's complexity against its performance. Under the self=02co= mpilation speed benchmark, only those optimizations were allowed to be inco= rporated into a compiler that accelerated it by so much that the intrinsic = cost of the new code addition was fully compensated. >=20 > And true to his quest for simplicity, Wirth continuously kept improving h= is compilers according to this metric, even if this meant throwing away a p= erfectly workable, albeit more complex solution. I still vividly remember t= he day that Wirth decided to replace the elegant data structure used in the= compiler=E2=80=99s symbol table handler by a mundane linear list. In the o= riginal compiler, the objects in the symbol table had been sorted in a tree= data structure (in identifier lexical order) for fast access, with a separ= ate linear list representing their declaration order. One day Wirth decided= that there really weren=E2=80=99t enough objects in a typical scope to mak= e the sorted tree cost-effective. All of us Ph.D. students were horrified: = it had taken time to implement the sorted tree, the solution was elegant, a= nd it worked well =E2=80=93 so why would one want to throw it away and repl= ace it by something simpler, and even worse, something as prosaic as a line= ar list? But of course, Wirth was right, and the simplified compiler was bo= th smaller and faster than its predecessor.