Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why Did Pascal Fail?

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Ask HN: Why Did Pascal Fail?

#111

Post by cagey »

pjmlp wrote: post #96
cagey wrote: post #52

Earlier quoted context omitted.

Along those lines... on MS-DOS/x86, memory model support in (Turbo) Pascal was less flexible than in Turbo C (1.0) during the first years when those toolchains were competing and gaining critical mass: TP 3.0 generated COM files (near code, near data, far heap-allocated data). TP 4.0 generated EXE files (far code, near data, far heap-allocated data). (the above is "to the best of my recollection": I no longer have th…

Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.

> Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings.

I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform.

(Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations.

My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++).

[1] https://en.wikipedia.org/wiki/Microsoft_Pascal

Re: Ask HN: Why Did Pascal Fail?

#112

Post by bjourne »

Viliam1234 wrote: post #32

I used Turbo Pascal a lot as a teenager. Then I switched to Java and never looked back. For me the main reason was garbage collection. String size was limited to 255 (non-Unicode) characters, array size needed to be specified at compile time, everything beyond this required manually allocating and unallocating memory... okay for school projects, but too much work for anything more complicated. The standard library di…

As I remember it, you could absolutely do all that in Pascal if you put your mind to it. But raw pointer manipulation was a bit more convoluted than in C so you usually resorted to inline asm. Today all that convolutedness might have been seen as "safety features" and the language marketed as a C-replacement. :)

Re: Ask HN: Why Did Pascal Fail?

#113

Post by Koshkin »

mikewarot wrote: post #75
Koshkin wrote: post #71

Earlier quoted context omitted.

As far as I remember, Pascal admitted single-pass analysis. Such languages are especially amenable to being interpreted, i.e. immediately translated into executable actions (vs. some sort of bytecode).

I'm not familiar with "single-pass analysis", but I do know that Pascal can be compiled with a single pass recursive descent compiler, which made Turbo Pascal orders of magnitude faster than any other compiler at the time. In an era when C programmers could have coffee while waiting for things to compile, a pascal program hit enter, saw the results, and moved on.

> I'm not familiar with "single-pass analysis”

Sure, not many programmers are today, sadly. I was referring to syntax analysis, or “parsing.” Some (admittedly, relatively simple) grammars allow syntax analysis to be done in one pass, so that an intermediate representation (e.g. in the form of an AST) becomes unnecessary; the latter is only needed if the grammar is complex and thus requires two or more passes for further analysis and/or machine code generation. Writing an interpreter for a command language is straightforward - exactly because analysis of its syntax can be done in one pass. Pascal is not a command language, but its grammar is (was?) still simple enough for many students of programming having gone through this (still highly recommended) exercise when Pascal was a teaching language.

Re: Ask HN: Why Did Pascal Fail?

#114

Post by zozbot234 »

Koshkin wrote: post #113
mikewarot wrote: post #75

Earlier quoted context omitted.

I'm not familiar with "single-pass analysis", but I do know that Pascal can be compiled with a single pass recursive descent compiler, which made Turbo Pascal orders of magnitude faster than any other compiler at the time. In an era when C programmers could have coffee while waiting for things to compile, a pascal program hit enter, saw the results, and moved on.

> I'm not familiar with "single-pass analysis” Sure, not many programmers are today, sadly. I was referring to syntax analysis, or “parsing.” Some (admittedly, relatively simple) grammars allow syntax analysis to be done in one pass, so that an intermediate representation (e.g. in the form of an AST) becomes unnecessary; the latter is only needed if the grammar is complex and thus requires two or more passes for furt…

Single-pass compile was a basic requirement back when your compiler only had access to a 64KB address space for its code and data. But it forces program organization into a clunky bottom-up sequential shape that just doesn't jive with the most basic concerns for larger-scale, professional software development. There's a reason why most of us don't code in FORTH, and why more recently Rust even chose the 'crate' rather than the single program file as its compilation unit.

Re: Ask HN: Why Did Pascal Fail?

#115

Post by guenthert »

leashless wrote: post #29

C was faster. It's that simple. Computers were extremely tiny in those days.

There's no reason to believe that the language would be. Performance of the compiled code clearly depends on the quality of the compiler. Iirc, Turbo Pascal passed arguments to functions in registers when it could, C compilers back then didn't. Pascal's calling convention also used less space (hence it being an optimization option on some C compilers). On a 8 bit machine, that was important, less so on the 32 bit machines of the 90s.

In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code.

While I was fond of Turbo Pascal in its days, C was just so much more flexible.

Re: Ask HN: Why Did Pascal Fail?

#116

Post by Koshkin »

zozbot234 wrote: post #114
Koshkin wrote: post #113

Earlier quoted context omitted.

> I'm not familiar with "single-pass analysis” Sure, not many programmers are today, sadly. I was referring to syntax analysis, or “parsing.” Some (admittedly, relatively simple) grammars allow syntax analysis to be done in one pass, so that an intermediate representation (e.g. in the form of an AST) becomes unnecessary; the latter is only needed if the grammar is complex and thus requires two or more passes for furt…

Single-pass compile was a basic requirement back when your compiler only had access to a 64KB address space for its code and data. But it forces program organization into a clunky bottom-up sequential shape that just doesn't jive with the most basic concerns for larger-scale, professional software development. There's a reason why most of us don't code in FORTH, and why more recently Rust even chose the 'crate' rathe…

All is true; note that “compile” is not the same as syntax analysis - because the former implies generation of code whereas the latter does not. (This is why we have two classes of language “translators”, one is compilers and the other, interpreters - although this distinction in modern practice has become somewhat blurry, because an interpreter may generate some sort of byte code which it then immediately executes.)

Re: Ask HN: Why Did Pascal Fail?

#117

Post by pjmlp »

cagey wrote: post #111
pjmlp wrote: post #96

Earlier quoted context omitted.

Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. And Turbo C 2.0 was quickly replaced by Turbo C++.

> Apparently you missed the whole TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5 offerings. I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecti…

Borland Pascal compilers that I mentioned had exactly the same memory models than their C++ counterparts, specially the Windows 3.1 versions, there was no difference between TPW 1.5 and TC++ 3.1.

Borland Pascal 7.0 introduced support for protected mode.

Re: Ask HN: Why Did Pascal Fail?

#118

Post by throwaway81523 »

pjmlp wrote: post #103
Turing_Machine wrote: post #101

Earlier quoted context omitted.

> Naturally, those variants were ignored, as Kernighan had a message to sell. Those variants were "ignored" because they largely didn't exist . Kernighan's essay was written in 1981. The first release of Turbo Pascal wasn't until 1983. The Extended Pascal standard wasn't released until 1990.

UCSD Pascal in 1977, Concurrent Pascal in 1974, DEC Pascal in 1981, and you can follow up in another dates here, http://pascal.hansotten.com/ And then there is the detail that Modula-2 was released in 1978, exactly with the goal to fix all original Pascal issues for systems programming.

Modula-2 was at best obscure at the time, while Pascal was popular. Kernighan got involved with Pascal in order to write the Pascal version of "Software Tools", called Software Tools in Pascal. He wrote "Why Pascal is not my favorite PL" as a result of that book effort. I believe that is explained in the article.

If there had been enough demand to also do a Modula version of the book, he might have written a more favorable article about Modula afterwards.

Re: Ask HN: Why Did Pascal Fail?

#119

Post by pjmlp »

AnimalMuppet wrote: post #106
pjmlp wrote: post #83

Earlier quoted context omitted.

Only if one only looks to the original Pascal language as means to sell their propaganda. All Pascal dialects, and the Extended Pascal standard that improved the original one, had the array of construct that allows you to query for the actual bounds. Type conversations were also available, again in all dialects. Naturally, those variants were ignored, as Kernighan had a message to sell.

Kernighan wrote that in 1981. As late as 1988, I was (unwillingly) using an original, non-extended Pascal. Those were still out there, still being used. And, all Pascal dialects had some construct. They had different constructs. If you wanted to be portable, you couldn't use any of them (until the Extended standard came out). Kernighan notes those extensions, but does not accept them as a solution because of their no…

So apparently ignoring that C was subject to the same dialects problems outside UNIX doesn't count.

Nor that Modula-2, designed to fix all those issues with ISO Pascal, was in use since 1978.

Yeah, whatever.

Re: Ask HN: Why Did Pascal Fail?

#120

Post by pjmlp »

throwaway81523 wrote: post #118
pjmlp wrote: post #103

Earlier quoted context omitted.

UCSD Pascal in 1977, Concurrent Pascal in 1974, DEC Pascal in 1981, and you can follow up in another dates here, http://pascal.hansotten.com/ And then there is the detail that Modula-2 was released in 1978, exactly with the goal to fix all original Pascal issues for systems programming.

Modula-2 was at best obscure at the time, while Pascal was popular. Kernighan got involved with Pascal in order to write the Pascal version of "Software Tools", called Software Tools in Pascal. He wrote "Why Pascal is not my favorite PL" as a result of that book effort. I believe that is explained in the article. If there had been enough demand to also do a Modula version of the book, he might have written a more fav…

Obscure, when the book was published three years earlier.

And based on Mesa, used at Xerox PARC.

Then again, ignoring systems languages outside Bell Labs seemed to have been a thing back in the day.

Post reply on HN