On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi wrote:
> The first language I really liked was Pascal.
> But the Pascal family of languages (including Ada) have
> clearly failed to become popular,
..
Pascal and Algol 60 did not have string handling.
Algol 60 did not have a defined I/O.
I/O in Pascal was flawed.
..
> at least compared
> to the C-family (C, C++, C#, ....)
>
> The question is why did this happen?
>
> My theory: C was used to develop Unix/Linux and
> Windows, and this made it easier for applications
> to be written in C/C++ since the interface to the OS
> was easier.
..
I do not think that this has anything to with it at all.
..
> VMS did not choose C (considered a huge
> blunder by many. They choose Bliss
> http://en.wikipedia.org/wiki/BLISS instead! and we
> all know what happens to VMS.
>
> What is your theory on this? Was there another
> reason or set of reasons?
>
> Can we all blame this success of the C family of
> languages on Dennis Ritchie and Brian Kernighan
> brilliance and it being used for Unix?

Op 27-5-2021 om 8:53 schreef Robin Vowels:
> On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi wrote:
>> The first language I really liked was Pascal.
>> But the Pascal family of languages (including Ada) have
>> clearly failed to become popular,
> .
> Pascal and Algol 60 did not have string handling.
> Algol 60 did not have a defined I/O.
Algol 60 wasn't a programming language but a method of describing a
mathematical proces in such a way that you could not fail in the way you
used that proces. That explained the lack of communicating with the
outside world.
But that made it simple to use it as a programming language. My first
sniff with programming was in 1966 on an Electrologica X8 which used
Algol 60 with its own set of I/O functions.
Seen the fact that Algol 60 was much earlier as Pascal I would not speak
of the Pascal-family but the Algol 60-family
For people interested there is on internet the Algol Reprt available.
> I/O in Pascal was flawed.
> .
>> at least compared
>> to the C-family (C, C++, C#, ....)
>>
>> The question is why did this happen?
>>
>> My theory: C was used to develop Unix/Linux and
>> Windows, and this made it easier for applications
>> to be written in C/C++ since the interface to the OS
>> was easier.
> .
> I do not think that this has anything to with it at all.
> .
>> VMS did not choose C (considered a huge
>> blunder by many. They choose Bliss
>> http://en.wikipedia.org/wiki/BLISS instead! and we
>> all know what happens to VMS.
>>
>> What is your theory on this? Was there another
>> reason or set of reasons?
>>
>> Can we all blame this success of the C family of
>> languages on Dennis Ritchie and Brian Kernighan
>> brilliance and it being used for Unix?

On Wed, 26 May 2021 23:53:18 -0700 (PDT), Robin Vowels
<robin.vowels@gmail.com> declaimed the following:

>
>Algol 60 did not have a defined I/O.

<?> Just curious -- do you mean the I/O was all by linked in
function/subroutines rather than being keywords in the language?

If so, that also applies to the C-family, and many of the more modern
languages. I think FORTRAN, COBOL, and REXX are the only languages I know
where the I/O is a built-in/keyword.

>I/O in Pascal was flawed.

Well... It probably worked quite well in the original OS (a batch
environment I believe, with no concept of interactive terminals) -- which
preread one "record" for each (externally defined) file connection.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>Algol 60 did not have a defined I/O.
> <?> Just curious -- do you mean the I/O was all by linked in
> function/subroutines rather than being keywords in the language?

Yeah, something like that. But there were successful Algol 60
implementations, including on Burroughs and Univac mainframes.
C. A. R. Hoare supposedly called Algol 60 "a language so far ahead of
its time, that it was not only an improvement on its predecessors, but
also on nearly all its successors.

>>I/O in Pascal was flawed.
> Well... It probably worked quite well in the original OS...

It wasn't just the I/O:

http://doc.cat-v.org/bell_labs/why_pascal/

Borland Turbo Pascal was very popular and apparently practical, though.
I never used it but I have the impression that it (like most deployed
Pascal implementations) somehow supplied workarounds to the limitations
described in the paper above.

These were interesting:

* Things Turbo Pascal is Smaller Than:
https://prog21.dadgum.com/116.html

* Personal History of compilation speed part 2 (scroll down for the
part about Turbo Pascal):
https://prog21.dadgum.com/47.html

The binary of Turbo Pascal was eventually released for no cost download,
but apparently the source code was never released. That is
disappointing based on how cool the above articles make it sound.

On Thursday, May 27, 2021 at 5:55:42 PM UTC+10, ldries46 wrote:
> Op 27-5-2021 om 8:53 schreef Robin Vowels:
> > On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi wrote:
> >> The first language I really liked was Pascal.
> >> But the Pascal family of languages (including Ada) have
> >> clearly failed to become popular,
> > .
> > Pascal and Algol 60 did not have string handling.
> > Algol 60 did not have a defined I/O.
..
> Algol 60 wasn't a programming language
..
FALSE. ALGOL 58, the predecessor of ALGOL 60, was designed as a
programming language.
..
> but a method of describing a
> mathematical proces in such a way that you could not fail in the way you
> used that proces. That explained the lack of communicating with the
> outside world.
> But that made it simple to use it as a programming language. My first
> sniff with programming was in 1966 on an Electrologica X8 which used
> Algol 60 with its own set of I/O functions.
> Seen the fact that Algol 60 was much earlier as Pascal I would not speak
> of the Pascal-family but the Algol 60-family
> For people interested there is on internet the Algol Reprt available.
> > I/O in Pascal was flawed.
> > .
> >> at least compared
> >> to the C-family (C, C++, C#, ....)
> >>
> >> The question is why did this happen?
> >>
> >> My theory: C was used to develop Unix/Linux and
> >> Windows, and this made it easier for applications
> >> to be written in C/C++ since the interface to the OS
> >> was easier.
> > .
> > I do not think that this has anything to with it at all.

On Friday, May 28, 2021 at 2:00:18 AM UTC+10, Paul Rubin wrote:
> Dennis Lee Bieber <wlf...@ix.netcom.com> writes:
> >>Algol 60 did not have a defined I/O.
> > <?> Just curious -- do you mean the I/O was all by linked in
> > function/subroutines rather than being keywords in the language?
>
> Yeah, something like that. But there were successful Algol 60
> implementations, including on Burroughs and Univac mainframes.
> C. A. R. Hoare supposedly called Algol 60 "a language so far ahead of
> its time, that it was not only an improvement on its predecessors, but
> also on nearly all its successors.
> >>I/O in Pascal was flawed.
..
> > Well... It probably worked quite well in the original OS...
..
But it didn't. That's the point. You couldn't write general algorithms in it.
>
> It wasn't just the I/O:
>
> http://doc.cat-v.org/bell_labs/why_pascal/
>
> Borland Turbo Pascal was very popular and apparently practical, though.
> I never used it but I have the impression that it (like most deployed
> Pascal implementations) somehow supplied workarounds to the limitations
> described in the paper above.
>
> These were interesting:
>
> * Things Turbo Pascal is Smaller Than:
> https://prog21.dadgum.com/116.html
>
> * Personal History of compilation speed part 2 (scroll down for the
> part about Turbo Pascal):
> https://prog21.dadgum.com/47.html
>
> The binary of Turbo Pascal was eventually released for no cost download,
> but apparently the source code was never released. That is
> disappointing based on how cool the above articles make it sound.

On Thu, 27 May 2021 09:00:16 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>It wasn't just the I/O:
>
> http://doc.cat-v.org/bell_labs/why_pascal/
>

I believe the original goal for Pascal was to be a teaching language
for algorithm development, and wasn't meant to be a real application
programming language. Heck -- the earlier VMS Pascal required one to link
into the FORTRAN libraries if one needed things like sin()/cos() functions.

>Borland Turbo Pascal was very popular and apparently practical, though.
>I never used it but I have the impression that it (like most deployed
>Pascal implementations) somehow supplied workarounds to the limitations
>described in the paper above.
>
Which made it a "lock-in" language -- it wasn't Pascal as defined by
Wirth and UCSD. One had to use compatible hardware (Windows, as I recall).
Not much use when writing a satellite control (ground station) system on a
VAX/Alpha machine (and yes, one such WAS written in VMS Pascal*... A few
years later the new version was on HPUX [or whatever they called it]
written in C -- they went from PDP-11 assembly to VAX Pascal to HP C)

>
>The binary of Turbo Pascal was eventually released for no cost download,
>but apparently the source code was never released. That is

I believe Turbo Pascal evolved into Borland's Delphi, which added OOP
features. Now Embarcadero... And available in a "community edition"
https://www.embarcadero.com/products/delphi/starter (interesting: they
allow either Delphi OR C++Builder community editions, but not both on a
computer [time for virtual machine images <G>]) Community license needs to
be renewed annually (though is a free download as I read the site). OUCH --
Professional level is $1600 to start, and $400/year renewal (the initial
$1600 is "perpetual", the $400/year is a subscription for updates/upgrades)

>disappointing based on how cool the above articles make it sound.

It feels bloated to me, but there is FreePascal with the Lazarus IDE.

My last Python exposure was on my TRS-80 model 4; Alcor Pascal (under a
RatShack license name -- Model 3 was pure Alcor release). It had the odd
feature of allowing one to manually edit the "object" files. Once one
learned the structure (they were ASCII) one could cut&paste
functions/subroutines).

http://www.trs-80.org/alcor-pascal/

I seem to recall having Blaise II (editor) configured to work like VMS
EDT (a bit of a trick, as the numeric pad only had 3 PF keys, not the 4
found on a VT100)

* The realtime group did a survey of languages when they upgraded from
the PDPs -- choices were VMS assembly, FORTRAN77, Pascal, and C. We had
something like 30 people in the realtime group, and 70 people in the rest
of the program skilled in F77. They tossed out C as error-prone, F77 as
"old", assembly as "why change processor, then", and argued that many
graduates at the time were learning Turbo Pascal in college.
When I saw the evaluation email, I sent back one that pointed out that
Turbo Pascal had a lot of add-ons that would not be meaningful in a Wirth
level Pascal (VMS did allow separate compilation, and linking to libraries
written in other languages -- DEC had a common set of built-ins to define
passing arguments as value/reference/descriptor so one could match the
convention of the library language). I also pointed out that, having
ignored the expertise of the 80+ F77 programmers, and gone the mile to
choose Pascal, they might have fallen onto their faces and picked DEC VMS
Ada -- a language designed for realtime processing...

A few years later, the department manager confessed that Pascal had
been a mistake (I believe the lead realtime programmer had threatened to
leave if Pascal was not picked -- manager caved in).

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On 5/27/2021 3:55 AM, ldries46 wrote:
> Op 27-5-2021 om 8:53 schreef Robin Vowels:
>> On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi
>> wrote:
>>> The first language I really liked was Pascal.
>>> But the Pascal family of languages (including Ada) have
>>> clearly failed to become popular,
>> .
>> Pascal and Algol 60 did not have string handling.
>> Algol 60 did not have a defined I/O.
> Algol 60 wasn't a programming language but a method of describing a
> mathematical proces in such a way that you could not fail in the way you
> used that proces. That explained the lack of communicating with the
> outside world.
> But that made it simple to use it as a programming language. My first
> sniff with programming was in 1966 on an Electrologica X8 which used
> Algol 60 with its own set of I/O functions.
> Seen the fact that Algol 60 was much earlier as Pascal I would not speak
> of the Pascal-family but the Algol 60-family
> For people interested there is on internet the Algol Reprt available.
>> I/O in Pascal was flawed.
>> .
>>> at least compared
>>> to the C-family (C, C++, C#, ....)
>>>
>>> The question is why did this happen?
>>>
>>> My theory: C was used to develop Unix/Linux and
>>> Windows, and this made it easier for applications
>>> to be written in C/C++ since the interface to the OS
>>> was easier.
>> .
>> I do not think that this has anything to with it at all.
>> .
>>> VMS did not choose C (considered a huge
>>> blunder by many. They choose Bliss
>>> http://en.wikipedia.org/wiki/BLISS instead! and we
>>> all know what happens to VMS.
>>>
>>> What is your theory on this? Was there another
>>> reason or set of reasons?
>>>
>>> Can we all blame this success of the C family of
>>> languages on Dennis Ritchie and Brian Kernighan
>>> brilliance and it being used for Unix?
>

Another reason that C became so widespread was cost. In the 1970s many
organizations (including universities) used the PDP 11 series of
computers because they were cheap hardware.

Their OS for the PDP 11 on the other hand cost thousands of dollars per
computer whereas C and UNIX were free. This was a bargain most owners
found irresistibly. Many schools made UNIX and C their standard
educational language. This in turn generated graduates who only knew C
putting pressure on employers to use C. Alas, it quickly became was a
self feeding runaway success.

In short, a free lunch is hard to turn down no matter what comes with it.

On Thursday, May 27, 2021 at 11:00:18 AM UTC-5, Paul Rubin wrote:
> Dennis Lee Bieber <wlf...@ix.netcom.com> writes:
> >>I/O in Pascal was flawed.
> > Well... It probably worked quite well in the original OS...
>
> It wasn't just the I/O:
>
> http://doc.cat-v.org/bell_labs/why_pascal/
>
> Borland Turbo Pascal was very popular and apparently practical, though.
> I never used it but I have the impression that it (like most deployed
> Pascal implementations) somehow supplied workarounds to the limitations
> described in the paper above.

I used Turbo Pascal in college 40 years ago, and yes! it did supply workarounds. 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.

This next paragraph is from memory, which may be corrupted, and I may have misunderstood it first, so don't take it too seriously, but: people who paid attention to what Wirth said and wrote about compiler design were able to produce small and fast compilers. Somewhere you can find a report written by one of Wirth's students about how they tried to modify one of their compilers 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 both 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 (but 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,
> but apparently the source code was never released. That is
> 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 beyond occasionally downloading & playing with it, then forgetting about it.

regards
john perry

Op 27-5-2021 om 18:45 schreef Robin Vowels:
> On Thursday, May 27, 2021 at 5:55:42 PM UTC+10, ldries46 wrote:
>> Op 27-5-2021 om 8:53 schreef Robin Vowels:
>>> On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi wrote:
>>>> The first language I really liked was Pascal.
>>>> But the Pascal family of languages (including Ada) have
>>>> clearly failed to become popular,
>>> .
>>> Pascal and Algol 60 did not have string handling.
>>> Algol 60 did not have a defined I/O.
> .
>> Algol 60 wasn't a programming language
> .
> FALSE. ALGOL 58, the predecessor of ALGOL 60, was designed as a
> programming language.
Read the Algol reort then you can see that its intention was not
primarily to be a computer language and not a mathematical language.
> .
>> but a method of describing a
>> mathematical proces in such a way that you could not fail in the way you
>> used that proces. That explained the lack of communicating with the
>> outside world.
>> But that made it simple to use it as a programming language. My first
>> sniff with programming was in 1966 on an Electrologica X8 which used
>> Algol 60 with its own set of I/O functions.
>> Seen the fact that Algol 60 was much earlier as Pascal I would not speak
>> of the Pascal-family but the Algol 60-family
>> For people interested there is on internet the Algol Reprt available.
>>> I/O in Pascal was flawed.
>>> .
>>>> at least compared
>>>> to the C-family (C, C++, C#, ....)
>>>>
>>>> The question is why did this happen?
>>>>
>>>> My theory: C was used to develop Unix/Linux and
>>>> Windows, and this made it easier for applications
>>>> to be written in C/C++ since the interface to the OS
>>>> was easier.
>>> .
>>> I do not think that this has anything to with it at all.

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:
> > Dennis Lee Bieber writes:
> > >>I/O in Pascal was flawed.
> > > Well... It probably worked quite well in the original OS...
> >
> > It wasn't just the I/O:
> >
> > http://doc.cat-v.org/bell_labs/why_pascal/
> >
> > Borland Turbo Pascal was very popular and apparently practical, though.
> > I never used it but I have the impression that it (like most deployed
> > Pascal implementations) somehow supplied workarounds to the limitations
> > described in the paper above.
> I used Turbo Pascal in college 40 years ago, and yes! it did supply workarounds. 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.
>
> This next paragraph is from memory, which may be corrupted, and I may have misunderstood it first, so don't take it too seriously, but: people who paid attention to what Wirth said and wrote about compiler design were able to produce small and fast compilers. Somewhere you can find a report written by one of Wirth's students about how they tried to modify one of their compilers 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 both 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 (but 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,
> > but apparently the source code was never released. That is
> > 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 beyond occasionally downloading & playing with it, then forgetting about it.
>
> regards
> john perry

That story comes from the paper "Oberon: The Overlooked Jewel" — https://www.semanticscholar.org/paper/Oberon-%E2%80%93-The-Overlooked-Jewel-1-Oberon-%E2%80%93-The-Jewel-Franz/9a7870c543c19eb4f46fdfbdcfb92d33ae2bf810 —

> In order to find the optimal cost/benefit ratio, Wirth used a highly intuitive metric, the origin of which is unknown to me but that may very well be Wirth’s own invention. He used the compiler’s self-compilation speed as a measure of the compiler’s quality. Considering that Wirth’s compilers were written in the languages they compiled, and that compilers are substantial and non-trivial pieces of software in their own right, this introduced a highly practical benchmark that directly contested a compiler's complexity against its performance. Under the selfcompilation speed benchmark, only those optimizations were allowed to be incorporated into a compiler that accelerated it by so much that the intrinsic cost of the new code addition was fully compensated.
>
> And true to his quest for simplicity, Wirth continuously kept improving his compilers according to this metric, even if this meant throwing away a perfectly workable, albeit more complex solution. I still vividly remember the day that Wirth decided to replace the elegant data structure used in the compiler’s symbol table handler by a mundane linear list. In the original compiler, the objects in the symbol table had been sorted in a tree data structure (in identifier lexical order) for fast access, with a separate linear list representing their declaration order. One day Wirth decided that there really weren’t enough objects in a typical scope to make 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, and it worked well – so why would one want to throw it away and replace it by something simpler, and even worse, something as prosaic as a linear list? But of course, Wirth was right, and the simplified compiler was both smaller and faster than its predecessor.

On Friday, May 28, 2021 at 7:37:49 AM UTC-5, Shark8 wrote:
> That story comes from the paper "Oberon: The Overlooked Jewel" — https://www.semanticscholar.org/paper/Oberon-%E2%80%93-The-Overlooked-Jewel-1-Oberon-%E2%80%93-The-Jewel-Franz/9a7870c543c19eb4f46fdfbdcfb92d33ae2bf810 —
>
> > In order to find the optimal cost/benefit ratio, Wirth used a highly intuitive metric, the origin of which is unknown to me but that may very well be Wirth’s own invention. He used the compiler’s self-compilation speed as a measure of the compiler’s quality.

Yes, that's it! and alas, I did slightly misremember it.

thank you
john perry

On 2021-05-28 15:07, John Perry wrote:
> On Friday, May 28, 2021 at 7:37:49 AM UTC-5, Shark8 wrote:
>> That story comes from the paper "Oberon: The Overlooked Jewel" — https://www.semanticscholar.org/paper/Oberon-%E2%80%93-The-Overlooked-Jewel-1-Oberon-%E2%80%93-The-Jewel-Franz/9a7870c543c19eb4f46fdfbdcfb92d33ae2bf810 —
>>
>>> In order to find the optimal cost/benefit ratio, Wirth used a highly intuitive metric, the origin of which is unknown to me but that may very well be Wirth’s own invention. He used the compiler’s self-compilation speed as a measure of the compiler’s quality.
>
> Yes, that's it! and alas, I did slightly misremember it.

I remember that Turbo Pascal had only one error message, something like
"Syntax error in expression" with, God forbid, no column number.

Otherwise yes, it was pretty fast, much faster than MS-DOS C/C++
compilers of the time, Borland's own C++ including.

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

On Friday, May 28, 2021 at 5:22:16 PM UTC+10, ldries46 wrote:
> Op 27-5-2021 om 18:45 schreef Robin Vowels:
> > On Thursday, May 27, 2021 at 5:55:42 PM UTC+10, ldries46 wrote:
> >> Op 27-5-2021 om 8:53 schreef Robin Vowels:
> >>> On Wednesday, July 16, 2014 at 10:25:17 PM UTC+10, Nasser M. Abbasi wrote:
> >>>> The first language I really liked was Pascal.
> >>>> But the Pascal family of languages (including Ada) have
> >>>> clearly failed to become popular,
> >>> .
> >>> Pascal and Algol 60 did not have string handling.
> >>> Algol 60 did not have a defined I/O.
> > .
> >> Algol 60 wasn't a programming language
> > .
> > FALSE. ALGOL 58, the predecessor of ALGOL 60, was designed as a
> > programming language.
> Read the Algol reort then you can see that its intention was not
> primarily to be a computer language and not a mathematical language.
..
RUBBISH.
John Backus (1959):
, "The Zurich ACM-GAMM Conference had two principal motives in proposing the IAL: (a) To provide a means of communicating numerical methods and other procedures between people, and (b) To provide a means of realizing a stated process on a variety of machines..."
..
The first ALGOL 58 compiler was running in 1958.
..
From the Revised Report:
..
"... ALGOL 60. This is a language suitable for expressing a large class of numerical processes in a form sufficiently concise for direct automatic translation into the language of programmed automatic computers."

Le jeudi 27 mai 2021 à 18:00:18 UTC+2, Paul Rubin a écrit :

> The binary of Turbo Pascal was eventually released for no cost download,
> but apparently the source code was never released. That is
> disappointing based on how cool the above articles make it sound.

Perhaps source code was not *officially* released but you find it easily on the Web (for TP 6.0) :-).

Interestingly, the HAC Ada Compiler ( https://hacadacompiler.sourceforge.io/ , https://github.com/zertovitch/hac ) is a distant descendent of Pascal-S by Wirth and identifiers are searched linearly via a linked list.
And yes, the compiler is very fast :-).

Gautier write-only address <gautier_niouzes@hotmail.com> writes:
> Perhaps source code was not *officially* released but you find it
> easily on the Web (for TP 6.0) :-).

Very interesting! I did find what I think you are referring to, though
it is much larger than the old versions. It's weird that it looks like
an official Borland release of some kind (complete with postal address
for tech support). I didn't realize they had ever let that out.
Anyway, thanks for the tip! The compiler proper seems to be about
25KLOC of almost entirely uncommented assembly code, plus Pascal
headers. I will see if I can understand any of it. I wonder if it
might be a disassembly, or otherwise obfuscated by Borland (by stripping
comments) for purpose of the release.

Sometime back I looked rather hard for the source code of TP (any
version) and I found something claiming to be TP source code, but was
actually something like a Windows wrapper. But this is different.

I think someone might have also published a disassembly of a released TP
2.0 binary, but I'm more interested in the original source as a
historical artifact, rather than something to actually use and run in
this day and age.

The comparable and amazing for the era BDS C was released as source code
here:

https://www.bdsoft.com/resources/bdsc.html

On 28/05/2021 14:28, Dmitry A. Kazakov wrote:

> Otherwise yes, it was pretty fast, much faster than MS-DOS C/C++

Apparently, they were fast because the Turbo compilers didn't do
optimisations due to the limitations of the machines.

> compilers of the time, Borland's own C++ including.
>

On 30 May 2021, Luke A. Guest wrote
(in article <s90di4$1v5f$1@gioia.aioe.org>):

> On 28/05/2021 14:28, Dmitry A. Kazakov wrote:
>
> > Otherwise yes, it was pretty fast, much faster than MS-DOS C/C++
>
> Apparently, they were fast because the Turbo compilers didn't do
> optimisations due to the limitations of the machines.
>
> > compilers of the time, Borland's own C++ including.

They were fast only by comparison with very slow compilers.
I remember, around 1987, someone telling me in astonishment
that Turbo ran at 2KSLOC/minute. I was unimpressed, as I had
worked on a compiler that ran at 20KSLOC/min a decade earlier.

--
Bill Findlay

Bill Findlay <findlaybill@blueyonder.co.uk> writes:
> They were fast only by comparison with very slow compilers.
> I remember, around 1987, someone telling me in astonishment
> that Turbo ran at 2KSLOC/minute. I was unimpressed, as I had
> worked on a compiler that ran at 20KSLOC/min a decade earlier.

Do you mean Turbo Pascal, or one of the other Turbos like Turbo C++?

Did you mean KSLOC/second rather than per minute? I think by 1987
(that would have been the 286-386 era) TP would have been compiling many
KSLOC/second. On old CP/M machines it would have been slower.

Was your 20KSLOC/??? compiler running on comparable hardware?

On 31 May 2021, Paul Rubin wrote
(in article <87k0nff07k.fsf@nightsong.com>):

> Bill Findlay<findlaybill@blueyonder.co.uk> writes:
> > They were fast only by comparison with very slow compilers.
> > I remember, around 1987, someone telling me in astonishment
> > that Turbo ran at 2KSLOC/minute. I was unimpressed, as I had
> > worked on a compiler that ran at 20KSLOC/min a decade earlier.
>
> Do you mean Turbo Pascal, or one of the other Turbos like Turbo C++?
>
> Did you mean KSLOC/second rather than per minute? I think by 1987
> (that would have been the 286-386 era) TP would have been compiling many
> KSLOC/second. On old CP/M machines it would have been slower.
>
> Was your 20KSLOC/??? compiler running on comparable hardware?

Well, I am trying to recall a passing conversation from 34 years
ago, so I may have some details wrong. I cannot swear that they
were impressed by Turbo Pascal rather than C*, but Turbo Pascal
was heavily used in the Department at the time.

The 20KSLOC compiler ran on a 1.5MIPS machine.

--
Bill Findlay

Bill Findlay <findlaybill@blueyonder.co.uk> writes:
> The 20KSLOC compiler ran on a 1.5MIPS machine.

Yes, but 1) 20KSLOC per what unit of time, 2) what language did it
compile? 1.5 mips is probably faster than a PC-XT (8088) but slower
than a PC-AT (80286). I remember being impressed with the speed of
Turbo C on the 386 that I used for a while. I never used Turbo Pascal.
CP/M and the original PC were somewhat before my time.

On 1 Jun 2021, Paul Rubin wrote
(in article <87fsy2febp.fsf@nightsong.com>):

> Bill Findlay<findlaybill@blueyonder.co.uk> writes:
> > The 20KSLOC compiler ran on a 1.5MIPS machine.
>
> Yes, but 1) 20KSLOC per what unit of time,

Per minute, as I said originally.

> 2) what language did it compile?

Pascal.
--
Bill Findlay

On Friday, May 28, 2021 at 1:22:15 PM UTC-6, Paul Rubin wrote:
> Gautier write-only address <gautier> writes:
> > Perhaps source code was not *officially* released but you find it
> > easily on the Web (for TP 6.0) :-).
> Very interesting! I did find what I think you are referring to,

I was unable to find it.
Can you provide the link?
Or search terms?

Bill Findlay <findlaybill@blueyonder.co.uk> writes:
>> > The 20KSLOC compiler ran on a 1.5MIPS machine.
>> Yes, but 1) 20KSLOC per what unit of time,

Ok, but that's maybe 5x slower than Turbo Pascal, which compiled 1000s
of LOC per second on machines of that class.