6 ms·

You have to be careful by what you define as "success" and "failure". Many/most languages never really fail, they just become more and more niche. So taking yo

You have to be careful by what you define as "success" and "failure". Many/most languages never really fail, they just become more and more niche. So taking your question to be, why isn't Pascal used as much as some of the other languages from antiquity, like C, sh/bash/ksh/etc, or even Lisp, my opinion is that it was a combination of it being an "old" language and an interpreted language. If you take a look at a timeline of programming language creation and usage [0], you see only a few compiled languages from before the 1980s survived and pretty much no interpreted languages did. The interpreted languages that did survive were mostly created in the late 1980s or early 1990s (Perl, Ruby, Python, Javascript). I kind of take this to mean that the programmer productivity gained from interpreted languages was overshadowed by the computational speedup from their compiled counterparts during the pre 1980s time. When computer's computational speed finally caught up so that interpreted languages made more sense, Pascal was now 20+ years old and was overshadowed by the newer interpreted languages that took advantage of newer ideas in programming language design and/or were more feature rich in the programming language fads of those eras. "sh" holds a kind of special place, as it's the workhorse of interacting with Unix-like environments, so it became pretty well entrenched. If you look at a lot of the more "modern" interpreted languages, you can see a lot of them were meant to supplant or complement tools specific to the command line or the command line itself (e.g. AWK -> Perl). I don't claim to have any deep knowledge so all this is my very biased and weak opinion. [0] https://ccrma.stanford.edu/courses/250a-fall-2005/docs/ComputerLanguagesChart.png https://ccrma.stanford.edu/courses/250a-fall-2005/docs/Compu...

einr 5y ago
Pascal is generally not an interpreted language. It is a compiled language that is suitable for systems and applications programming.
- Koshkin 5y ago
  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).
  - mikewarot 5y ago
    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.
    - wahern 5y ago
      C was also designed for single-pass compilation. Among many other things that people now dislike about C, this is why C requires forward declarations. C compilers became slow because of the optimizations they accreted. Plus, I imagine it just wasn't a priority for the vendors in the way it was for Borland Pascal. I'm curious how the Borland C compiler compared in speed to their Pascal compiler and to other C compilers.
      - cb321 5y ago
        TinyC/tcc [1] still is a single-pass compiler and can go all the way to ELF files (or directly running via tcc -run) in a few milliseconds - sometimes an order of magnitude faster than the minimal start-up time of an interpreter like Python. But yes, gcc will generate faster running object code..a long standing trade off (like -O0 vs -O3, etc.). [1] https://github.com/TinyCC/TinyCC https://github.com/TinyCC/TinyCC
    - Koshkin 5y ago
      > 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.
- abetusk 5y ago
  Whoops! You are correct! For some reason, Pascal sat in my mind as an interpreted language. Maybe my whole arguments falls apart then.
Stratoscope 5y ago
Now wait a minute. If you say that JavaScript is an interpreted language, you would also have to call Java an interpreted language. Do you agree with that? They both work in exactly the same way. Your source code is compiled to bytecode. That bytecode is then interpreted by a virtual machine. [1] That interpreter may then start a Just In Time compiler (JIT) to compile some of the bytecode down to machine code. Other than implementation details, both languages work the same way. Python also works like this, except it does not have the JIT. But it also has a compiler which generates bytecode. And even if a JIT generates what we fondly call "machine code", that code is interpreted too! What the CPU executes internally looks nothing like the machine code that we see as programmers. It's interpreters all the way down. [1] I don't mean in the sense of something like VMware; I'm talking about a software virtual machine that executes an instruction set which we call bytecode.
- nobodyandproud 5y ago
  Compilers actively translate code into a representation understandable by the machine. It just so happens that the “machine” is an abstraction of a CPU. Interpreted Javascript doesn’t fit this bill. If compiled to web assembly then it would.
  - emtel 5y ago
    V8 compiles all JavaScript it executes to machine code. There is no interpreter included in v8.
    - pjmlp 5y ago
      https://v8.dev/blog/sparkplug https://v8.dev/blog/sparkplug > As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
    - nobodyandproud 5y ago

einr 5y ago

Pascal is generally not an interpreted language. It is a compiled language that is suitable for systems and applications programming.

Koshkin 5y ago
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).
- mikewarot 5y ago
  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.
  - wahern 5y ago
    C was also designed for single-pass compilation. Among many other things that people now dislike about C, this is why C requires forward declarations. C compilers became slow because of the optimizations they accreted. Plus, I imagine it just wasn't a priority for the vendors in the way it was for Borland Pascal. I'm curious how the Borland C compiler compared in speed to their Pascal compiler and to other C compilers.
    - cb321 5y ago
      TinyC/tcc [1] still is a single-pass compiler and can go all the way to ELF files (or directly running via tcc -run) in a few milliseconds - sometimes an order of magnitude faster than the minimal start-up time of an interpreter like Python. But yes, gcc will generate faster running object code..a long standing trade off (like -O0 vs -O3, etc.). [1] https://github.com/TinyCC/TinyCC https://github.com/TinyCC/TinyCC
  - Koshkin 5y ago
    > 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.
abetusk 5y ago
Whoops! You are correct! For some reason, Pascal sat in my mind as an interpreted language. Maybe my whole arguments falls apart then.

Stratoscope 5y ago

Now wait a minute. If you say that JavaScript is an interpreted language, you would also have to call Java an interpreted language. Do you agree with that? They both work in exactly the same way. Your source code is compiled to bytecode. That bytecode is then interpreted by a virtual machine. [1] That interpreter may then start a Just In Time compiler (JIT) to compile some of the bytecode down to machine code. Other than implementation details, both languages work the same way. Python also works like this, except it does not have the JIT. But it also has a compiler which generates bytecode. And even if a JIT generates what we fondly call "machine code", that code is interpreted too! What the CPU executes internally looks nothing like the machine code that we see as programmers. It's interpreters all the way down. [1] I don't mean in the sense of something like VMware; I'm talking about a software virtual machine that executes an instruction set which we call bytecode.

nobodyandproud 5y ago
Compilers actively translate code into a representation understandable by the machine. It just so happens that the “machine” is an abstraction of a CPU. Interpreted Javascript doesn’t fit this bill. If compiled to web assembly then it would.
- emtel 5y ago
  V8 compiles all JavaScript it executes to machine code. There is no interpreter included in v8.
  - pjmlp 5y ago
    https://v8.dev/blog/sparkplug https://v8.dev/blog/sparkplug > As we turn to improving the performance of the actual initial JavaScript execution, however, we start to hit limitations when optimising our interpreter. V8’s interpreter is highly optimised and very fast, but interpreters have inherent overheads that we can’t get rid of; things like bytecode decoding overheads or dispatch overheads that are an intrinsic part of an interpreter’s functionality.
  - nobodyandproud 5y ago