Anders Heljsberg GOAT. Turbo Pascal, Delphi, C#, TypeScript, just a phenomenal career marked with better taste than any other language designer I can think of, certainly any designer whose work is so mainstream.
Nope, J++ was on the Microsoft JVM, whereas C# was on top of a full new runtime.
However the language extensions that were the reason for the lawsuit did indeed transition from J++ into C#, with J# being J++ on top of .NET for easing code porting.
The features were events, J/Direct (later P/Invoke on .NET), COM interop (later RCW/CCW on .NET), and Windows Foundation Classes (later Windows Forms on .NET).
Given development speed is way up, I'd be interested to see what a from-basic-principles simple and efficient OS and programming system might look like. Or people trying radically different versions of efficiency and simplicity, like an OS that uses an existing battle-tested sandboxed execution environment like v8 for userspace safety/isolation.
Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore, and the cost of larger projects with clear abstraction boundaries has plummetted.
>Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
I read GP's comment differently, that we ended up where we are today (bloated languages, IDEs and runtimes) due to chasing developer productivity at all costs.
Now, developer productivity is becoming less important as developers are factored out entirely.
This was my intended meaning -- the clearest advocacy of this was from DHH about Ruby on Rails, although he's changed his mind about big questions lately and suspect he no longer endorses that set of trade-offs (I don't either, _sort of_ -- I think developer productivity means having simple ways to enable large-scale testing and oversight while minimizing context switching costs, although I think we are all figuring out what that means in practice).
This is the thing - when the cost of iterating and grinding compiler warnings drops to virtually 0, what new paradigms might we invent to exploit that? Rust gives us an inkling of an idea of what might be possible, but that still predates LLMs and thus still makes concession for human ergonomics. What are structures, guardrails, and patterns, that our OSs, frameworks, and toolchains can put in place, which would result in whole classes of problems going away completely, at the expense of massively increased (but mechanical, and easily automatable with a prompt) developer effort?
v8 is pretty complicated, and anything that depends on LLVM is going to be huge, so I think I would start smaller. You could try building around something like NuttX or an L4 + tcc or cproc and see what it takes to get to self-hosting as well as ability to do some job you care about. To me the bigger question is that last bit, you can shrink the platform code quite a lot relative to a typical Linux but what's the situation where that's a good trade vs say cross-compiling from a full C++ or Rust toolchain?
While some comparisons may look silly, the fact that the touch command's binary should exceed Turbo Pascal is insane: the command basically creates an empty file or updates the file change date if the file already exists, not more.
There's no reason (other than laziness) why that should take more than 2k.
On the other hand, a lot of boilerplace code is repeated in each and every command. When I first learned as a kid about UNIX commands being ordinary programs, I was intrigued (there is nothing "special" about them, you can also write your own!) but also shocked about the overhead compared to an architecture in which e.g. the shell contained all (at least core) commands compiled into a single binary, which could share all the error handing, startup code, command line parsing code and so on.
> the command basically creates an empty file or updates the file change date if the file already exists, not more.
GNU coreutils touch does a lot more than that. My local copy is about 95k; it allows for choosing from multiple different timestamps to update; suppressing the (default) creation of an empty file if it doesn't already exist; operating on symlinks directly rather than following them (if the system supports it); specifying a custom timestamp rather than "now" (including by parsing a date string), and of course outputting a help message and a version.
And how much of that feature-rich version touch is actual executable code?
I did a quick estimate by disassembling touch with objdump on macOS (163 kB executable), and it was approximately 6 kB (1500 instructions * 4 bytes/instruction). There is a lot more to an executable than executable code.
I was going to suggest that even that logic wouldn't account for a binary size three times the RAM of my first machine, but from the man page:
> DATE STRING
> The --date=STRING is a mostly free format human readable date string such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29 16:21:42" or even "next Thursday". A date string may contain items indicating calendar date, time of day, time zone, day of week, relative time, relative date, and numbers. An empty string indicates the beginning of the day. The date string format is more complex than is easily documented here but is fully described in the info documentation.
You'd think they'd put this bullshit inside some .so where it could be reused by all other coreutils; but no, it's re-included in every GNU tool that deals with parsing dates.
It is correct. But only 'date' and 'touch' use it, so I am not sure how much benefit there is in making it a shared library.
If size is really a concern, we have supported building a single 'coreutils' binary since 2014, which will be more effective in saving disk space. It can be done with './configure --enable-single-binary'.
> But only 'date' and 'touch' use it, so I am not sure how much benefit there is in making it a shared library.
There is also the rest of the whole "gnulib" folder inside the coreutils repo. Yes, I know that Gnulib explicitly states in the docs that it's a source code library but it doesn't bother to explain why exactly it chose to be that instead of being a .so à la glibc (beyond some rather unrelated "but supply chain attacks!" segment in the docs — if I cared about that, I'd statically link the relevant parts of glibc as well, in fact, that would be a much higher priority).
Yes, it can be. You can run `strings "$(command -v touch)"` yourself and then compare the output with the strings in parse-datetime.y [0]. Look for e.g. "FORTNIGHT", "sixth", and "error: parsing failed, stopped at '%s'", they're all inside the touch's executable.
> There's no reason (other than laziness) why that should take more than 2k.
I presume you know some of the intricacies of coreutils or the touch program. I'll probably go and donate to whomever receives donations for coreutils; it's the least I can do: Show some respect to the developers of these free and open source tools.
I'd love to have a graph of gnu [core]utils growth over time. IIRC in Unix days, these simple utils were simple.. until they had to support various flags, and various hosts ..
If you run `strace` you can get a hint at why `touch` (and any modern, compiled C binary) might be big: it is doing way more than you think it does, and you definitely _want_ a lot of that. For example, any program that uses the C standard library needs to have that code available-- since virtually every C program is going to use it, it will be loaded and mmap'ped into some region of memory. The stack needs to be set up, memory protection bits will be set, a random value is read to be used as a stack canary, etc, etc. I count on the order of 50+ system calls.
Watching `mv` do its thing is even better. About 100 system calls, including playing nice with SELinux in case it happens to be installed, just to issue a single `renameat2` system call.
Don't forget that we're running on a 64-bit machine. MS-DOS in 1986 was a 16-bit machine? The word size on a modern machine is bigger because we have a bigger address space, more registers, and more instructions.
We want speed and security and convenience and pleasant error messages. All of this is put here by the compiler to ensure that we have nice things. It sounds awesome to have such a small Pascal compiler, and it makes the modern state of binaries seem bloated, but all those extra bytes are paying for things that we want. There's probably a little bloat, but really, there is not much bloat.
Agree with everything you wrote, but if you go look for bloat on your storage device, the last thing that will be of any significance is that overhead.
Why did Pascal basically die completely? It seems like a hugely influential language and was very loved, but there are plenty of other languages which still seem to have a lot of legacy code. Where is Pascal?
In a way it didn't, the Lazarus project is the current most well-known incarnation. But that itself tells a story: it's for desktop applications, mainly. It never really had a "here's how you do a web app" story around it. There was a period 1998-2002 when Delphi was hot (and it genuinely was very good) but all the cool kids saw PHP3 and Flash and hopped aboard, and at that point, in retrospect, you can see the start of the decline of desktop applications. By the time Rails landed in (I think?) 2008 "do everything on the web" was what a lot of people were already talking about, even if the truth of that didn't really land until much later.
Really it could have been go-lang before go-lang and I'm not sure why it wasn't other than that it wouldn't have been controllable by the folks at Google.
Not in 02002. In 02002 your JS devtools were that the browser crashed when you had a bug in your JS, so you would have to binary-search your recent changes to figure out which line of JS was crashing it, and you could evaluate expressions by typing javascript:(void)alert(f()) in the URL bar. No browser console, no web inspector, and the only portable DOM was image rollovers and form field values. If you wanted to generate document content in JS the only way that was portable to Netscape Navigator 4 was document.write().
I think we didn't even have bookmarklets at that point—the browsers supported them, but we didn't know that.
Really, it was because pascal was the go of its day with very little corporate backing (by modern standards). A language designed around developer ergonomics with some safety in mind: lovely for teaching, but only because it was a jack of all trades.
Web units were included, it's just that php became dominant because it was stupidly easy. I myself was a pascal programmer that started writing php around the time of lazarus 0.9 / fpc 1.9 and I recall that php felt like bash scripting by comparison. Today, I consider the cgi model to be rudimentary and php itself a pile of shit.
Delphi / Lazarus were GUI frameworks not different languages, and regarding Lazarus itself I'm gonna be RMS here and say that it's GNU/Linux (which it was, for some time).
It didn't, despite all its management failures, several companies are still buying into Delphi (Object Pascal evolved from Turbo Pascal/Apple's Object Pascal), and there is at least an yearly conference in Germany.
It morphed into Delphi. The reason that it's not that successful anymore is that it was deeply tied to Windows (even if there were half-arsed Macintosh ports).
And then the Internet taking off happened.
And suddenly you had gigantic companies built on PHP/JavaScript/Linux (like Facebook), on open-source software (Google) and Pascal/Delphi got also attacked by actually portable stuff, like Java, which some of today's biggest companies were built on (like Amazon).
So on one hand Linux and it's myriad of open-source languages and on the other hand Java (which is what it is but it is portable) and then JavaScript in the browser.
Nowadays tens of billions of devices, including many servers powering the entire world, are running Linux. While Pascal/Delphi was that language you'd run on DOS and half-arsedly ported to Windows: not a winning proposition.
Not sure if you are being sarcastic. Pascal strings are first class citizens, so it's trivial to add null-termination. Delphi actually does this to allow typecasting.
C, for example, doesn't have strings. It has pointers to memory that might contain characters and, if you are lucky and the stars are aligned, a zero to mark the end. I'll never understand how C strings were accepted as a string representation and not the mad source of bugs and insanity that they are.
> I'll never understand how C strings were accepted as a string representation
1972 was definitely not a good year for C standardization bodies. I blame that guy Ritchie and his audacity to hack a language on a whim. Even his GitHub page is empty (or misattributed).
Free Pascal/Lazarus it's rocking nice tools such as Peazip and other stuff like Carte Du Ciel and some RAD tools in the enterprise. On the niche geeky world, there's T3X at https://t3x.org which is semi-Pascal like.
The main problem with Pascal was not having a standard at a time when having a standard was important for adoption. There were several successful implementations like Borland's, and the version used in the Macintosh, but being closed products they never talked to each other. It's similar to the situation of Basic: lots of code was created in Basic but none was compatible with a standard and was essentially lost.
It certainly had a standard, two actually, however no one cared because Turbo Pascal was more relevant, and Modula-2 was designed to fix Pascal's shortcomings, which also has a ISO standard.
Not just having a standard but being able to collectively evolve a standard.
In the absence of that, Pascal’s creators and commercializers invented follow-on languages, including the most successful thread via Hejlsberg as we’re discussing here: Object Pascal -> Delphi -> C#/.NET—with a brief detour to J++, which I don’t know enough about to understand if it belongs in this sequence.
Outside Borland and Apple, people tend to forget that already in 1976, Niklaus Wirth came up with Modula-2, exactly to fix all the shortcomings from a language originally designed for teaching, with one properly designed for systems programing from the start.
As for your sequence, from someone that was around back then, .NET and C# only exist as you know it thanks to Sun's lawsuit regarding Java language and runtime extensions introduced in J++.
Then an internal research language originally named Cool, became C#, the language extensions in J++ were made into C# features (events, J/Direct, COM interop), Windows Foundation Classes became Windows Forms, and J# was released in .NET 1.0 as transiton technology.
Had it not been for the lawsuit, Ext-VOS (.NET codename) would have been released with J++ instead.
For reference, ZX-Spectrum has 48Kb of RAM out of which 8Kb is video memory, so unusable.
Then you have to load the Pascal compiler into the remaining 40k of RAM. Allocate some RAM for stack and environment variables for the editor where you write your program, plus space for the actual program. Then compile your program into the same 40k of space. And run it, using heap and stack memory from which memory space? You guessed right, same 40k.
To recap, on 40k of RAM you had back then:
- The Pascal compiler
- The Pascal source code in text form
- The Pascal executable form in machine code
- The Pascal data/memory. Of which, recently in a "tech demo" of automated tests, one colleague said "unfortunately we only have a very limited amount of RAM to be able to do basically anything [that's why the product is a mess with no tests]. Only 32Gb per [virtual] machine".
One of my first programs was a Tetris clone, because ZX-Spectrum BASIC was slow as molasses. All on top of only having tape for storage so if I fucked up a pointer (I don't think Pascal had the concept of access violation back then but I sure discovered it on my own skin), it would take 5 minutes to load the Pascal compiler + some backup copy of my Tetris game, hopefully not from a month ago and hopefully I remember what I changed. Lots to discover and have "fun" with.
About a year later I did find a compiler for BASIC and it turned the unplayable BASIC code for Tetris I wrote in the 9th grade into a totally playable Tetris game, without the need to learn another language and paradigm (pointers!) but the damage was done. Ignoring a year of databases, in 12th grade of high school computer science class (elite class, found there basically all the Math olympics I was competing with in gymnasium), I got introduced to C and from then on, here I am, 30 years later, doing C++ in finance for an S&P 500 company.
The wall of defensive, hostile replies to this simple post is expected. Today’s programmers need to feel like they are an elite class above the rabble and programming is their identity. When someone shows them an example of what talented programming really looks like, they have to pile on and dismiss it from a thousand cuts. The guy who wrote Pascal understood the system top to bottom, and understood computer science. There are maybe a few thousand programmers alive today with that kind of skill, and it hurts the egos of the average HN typescript scrum jockey to see something they just don’t comprehend so they lash out at it.
It's always an interesting thought that I had meetings about the log aggregation dropping stack traces that would take ~3 3.5" floppies to store. Each.
Zabbix also confuses operators at this point. I recently had to increase a cache. I chose to go from a solid 4MB to a luxurious 256MB.
I know high-performance Java, so just a little jab there, but you don't size JVM parameters like that, except maybe code caches. And before Rust comes in, we also have a Rust application running without good resource control and it wouldn't like those resource constraints.
Is it such a stupid comparison? It's an absolutely trivial amount of data now, but back in the 80s, a few files of that size would fill out a floppy disk. It's also a source file - the input to a compiler.
Amusingly i also used Turbo Vision to make some agentic harness[0] :-P (though mine is meant to talk with llama-server via its OpenAI compatible endpoint since i'm using local models - the one in the shot is Gemma 4 E4B which i'm using for testing).
That said i never finished that and ended up making another one (using tvchat as a base since it had largely working communication and session management) that acts as a server/daemon inside the container is meant to run in the background and provides a web-based UI instead.
cool. can you drag & drop in files (e.g. screenshots, PDFs, video recordings, text files, etc.) for context when you work on features or bug fixes? Cursor is great at workflows like that.
no, but good idea, I am having Claude add that.
EDIT: done. if your terminal doesn't support drag-and-drop (kitty and some others do) there is also a new File | Attach file(s) menu item
Well, yeah. Back in the mid-80's, software needed to be usable on a computer with a single 360KB floppy drive. (No HD, no SSD, no USB, no network, no ...) And even a big budget for RAM - which cost many orders of magnitude more than today - would really not get you around Bill Gates' 640KB DOS memory limit.
Comparing to current-day stuff is kinda like comparing battery-powered bathtub toys to jetskis.
Those "bathtub toys" built the entire modern infrastructure, parts of which are still chugging along. If anything, I'd put the onus on software developers - like John Carmack said in 2005, "there is something deeply wrong when text editing on a 3.6 ghz processor is anything but instantaneous".
Software in the 80s showed what's possible when you really care about doing it. Software in the last 15 years feels like an exercise on what happens when you don't.
I remember Windows 98, where it crashed every few hours and took everything with it, but while it worked, it never missed a keystroke or mouse press. I could type ahead and click where I knew the button would appear in 10 seconds and it still wouldn't lose anything. Nowadays you just finish typing out a thought and then realise half of it never turned up, because something else claimed the focus or whatever.
Yet at the same time, one is a pastime for an affluent lifestyle while the other is driving the global economy. Interestingly, or ironically, the former was probably put on the shelves by means of the latter.
If there is any positive progress to be made, the rethinking necessary must go much, much deeper than the superficial flesh of the problem, but there it’s bound to hit upon the sinews and bones of vested interests.
In all, as I’m growing older and see the world trudge along the same lines it did centuries ago, I’m more and more pessimistic about the possibility of people agreeing that the sacrifices necessary will be made.
Short-term stakeholder interests seem to trump any notions of longer-term greater good.
Anders Heljsberg GOAT. Turbo Pascal, Delphi, C#, TypeScript, just a phenomenal career marked with better taste than any other language designer I can think of, certainly any designer whose work is so mainstream.
You are missing J++, several C# features were born in J++, e.g. P/Invoke was J/Direct.
Wasn't C# just a rebranding of J++ after the Sun Java trademark lawsuit?
Nope, J++ was on the Microsoft JVM, whereas C# was on top of a full new runtime.
However the language extensions that were the reason for the lawsuit did indeed transition from J++ into C#, with J# being J++ on top of .NET for easing code porting.
The features were events, J/Direct (later P/Invoke on .NET), COM interop (later RCW/CCW on .NET), and Windows Foundation Classes (later Windows Forms on .NET).
Thanks to the good work of internet archivists,
https://archive.org/details/microsoftvisualj00micr
https://download.microsoft.com/download/1/6/d/16d24ada-5317-...
https://www.microsoft.com/en-us/download/details.aspx?id=559...
The irony is that two decades later Microsoft has an OpenJDK distribution, and they were the ones that initially provided the ARM port for Windows.
https://www.microsoft.com/openjdk
https://www.zdnet.com/article/microsoft-completes-phase-one-...
Given development speed is way up, I'd be interested to see what a from-basic-principles simple and efficient OS and programming system might look like. Or people trying radically different versions of efficiency and simplicity, like an OS that uses an existing battle-tested sandboxed execution environment like v8 for userspace safety/isolation.
Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore, and the cost of larger projects with clear abstraction boundaries has plummetted.
>Fundamentally, many inefficiencies were justified for developer productivity, and I'm not sure that makes sense anymore
Having lived through this period, I would disagree, quite the opposite we tended to develop in C and assembly specifically for runtime efficiency because we had to.
For developer productivity you could opt for Lisp or SmallTalk or some such, which ran much slower until high quality compilers for these became available, and even then your target machine might only have a C compiler.
I read GP's comment differently, that we ended up where we are today (bloated languages, IDEs and runtimes) due to chasing developer productivity at all costs.
Now, developer productivity is becoming less important as developers are factored out entirely.
This was my intended meaning -- the clearest advocacy of this was from DHH about Ruby on Rails, although he's changed his mind about big questions lately and suspect he no longer endorses that set of trade-offs (I don't either, _sort of_ -- I think developer productivity means having simple ways to enable large-scale testing and oversight while minimizing context switching costs, although I think we are all figuring out what that means in practice).
Specifically, turbo pascal was entirely written in assembly according to wikipedia (I recalled only 50% but maybe that was some other pascal dialect)
I think you have that backwards.
It's the lack of clear abstraction boundaries that causes decreased developer productivity.
A code generator will not save you from Conway's law.
This is the thing - when the cost of iterating and grinding compiler warnings drops to virtually 0, what new paradigms might we invent to exploit that? Rust gives us an inkling of an idea of what might be possible, but that still predates LLMs and thus still makes concession for human ergonomics. What are structures, guardrails, and patterns, that our OSs, frameworks, and toolchains can put in place, which would result in whole classes of problems going away completely, at the expense of massively increased (but mechanical, and easily automatable with a prompt) developer effort?
The next few years are going to be fun.
This would be fine grained type systems where invalid states are inexpressible.
Both humans and LLMs struggle with slow iteration times.
v8 is pretty complicated, and anything that depends on LLVM is going to be huge, so I think I would start smaller. You could try building around something like NuttX or an L4 + tcc or cproc and see what it takes to get to self-hosting as well as ability to do some job you care about. To me the bigger question is that last bit, you can shrink the platform code quite a lot relative to a typical Linux but what's the situation where that's a good trade vs say cross-compiling from a full C++ or Rust toolchain?
While some comparisons may look silly, the fact that the touch command's binary should exceed Turbo Pascal is insane: the command basically creates an empty file or updates the file change date if the file already exists, not more.
There's no reason (other than laziness) why that should take more than 2k.
On the other hand, a lot of boilerplace code is repeated in each and every command. When I first learned as a kid about UNIX commands being ordinary programs, I was intrigued (there is nothing "special" about them, you can also write your own!) but also shocked about the overhead compared to an architecture in which e.g. the shell contained all (at least core) commands compiled into a single binary, which could share all the error handing, startup code, command line parsing code and so on.
> the command basically creates an empty file or updates the file change date if the file already exists, not more.
GNU coreutils touch does a lot more than that. My local copy is about 95k; it allows for choosing from multiple different timestamps to update; suppressing the (default) creation of an empty file if it doesn't already exist; operating on symlinks directly rather than following them (if the system supports it); specifying a custom timestamp rather than "now" (including by parsing a date string), and of course outputting a help message and a version.
And how much of that feature-rich version touch is actual executable code?
I did a quick estimate by disassembling touch with objdump on macOS (163 kB executable), and it was approximately 6 kB (1500 instructions * 4 bytes/instruction). There is a lot more to an executable than executable code.
I was going to suggest that even that logic wouldn't account for a binary size three times the RAM of my first machine, but from the man page:
> DATE STRING
> The --date=STRING is a mostly free format human readable date string such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29 16:21:42" or even "next Thursday". A date string may contain items indicating calendar date, time of day, time zone, day of week, relative time, relative date, and numbers. An empty string indicates the beginning of the day. The date string format is more complex than is easily documented here but is fully described in the info documentation.
There it is.
You'd think they'd put this bullshit inside some .so where it could be reused by all other coreutils; but no, it's re-included in every GNU tool that deals with parsing dates.
This can’t be right is it?
It is correct. But only 'date' and 'touch' use it, so I am not sure how much benefit there is in making it a shared library.
If size is really a concern, we have supported building a single 'coreutils' binary since 2014, which will be more effective in saving disk space. It can be done with './configure --enable-single-binary'.
> But only 'date' and 'touch' use it, so I am not sure how much benefit there is in making it a shared library.
There is also the rest of the whole "gnulib" folder inside the coreutils repo. Yes, I know that Gnulib explicitly states in the docs that it's a source code library but it doesn't bother to explain why exactly it chose to be that instead of being a .so à la glibc (beyond some rather unrelated "but supply chain attacks!" segment in the docs — if I cared about that, I'd statically link the relevant parts of glibc as well, in fact, that would be a much higher priority).
Yes, it can be. You can run `strings "$(command -v touch)"` yourself and then compare the output with the strings in parse-datetime.y [0]. Look for e.g. "FORTNIGHT", "sixth", and "error: parsing failed, stopped at '%s'", they're all inside the touch's executable.
[0] https://github.com/coreutils/gnulib/blob/master/lib/parse-da...
But there ought to be some reason behind this that explains why that fence is there. No?
Repeating the code is silly, but some degree of duplication in the binary makes sense. It's a basic size / latency trade-off.
> There's no reason (other than laziness) why that should take more than 2k.
I presume you know some of the intricacies of coreutils or the touch program. I'll probably go and donate to whomever receives donations for coreutils; it's the least I can do: Show some respect to the developers of these free and open source tools.
I'd love to have a graph of gnu [core]utils growth over time. IIRC in Unix days, these simple utils were simple.. until they had to support various flags, and various hosts ..
If you run `strace` you can get a hint at why `touch` (and any modern, compiled C binary) might be big: it is doing way more than you think it does, and you definitely _want_ a lot of that. For example, any program that uses the C standard library needs to have that code available-- since virtually every C program is going to use it, it will be loaded and mmap'ped into some region of memory. The stack needs to be set up, memory protection bits will be set, a random value is read to be used as a stack canary, etc, etc. I count on the order of 50+ system calls.
Watching `mv` do its thing is even better. About 100 system calls, including playing nice with SELinux in case it happens to be installed, just to issue a single `renameat2` system call.
Don't forget that we're running on a 64-bit machine. MS-DOS in 1986 was a 16-bit machine? The word size on a modern machine is bigger because we have a bigger address space, more registers, and more instructions.
We want speed and security and convenience and pleasant error messages. All of this is put here by the compiler to ensure that we have nice things. It sounds awesome to have such a small Pascal compiler, and it makes the modern state of binaries seem bloated, but all those extra bytes are paying for things that we want. There's probably a little bloat, but really, there is not much bloat.
Agree with everything you wrote, but if you go look for bloat on your storage device, the last thing that will be of any significance is that overhead.
Why did Pascal basically die completely? It seems like a hugely influential language and was very loved, but there are plenty of other languages which still seem to have a lot of legacy code. Where is Pascal?
In a way it didn't, the Lazarus project is the current most well-known incarnation. But that itself tells a story: it's for desktop applications, mainly. It never really had a "here's how you do a web app" story around it. There was a period 1998-2002 when Delphi was hot (and it genuinely was very good) but all the cool kids saw PHP3 and Flash and hopped aboard, and at that point, in retrospect, you can see the start of the decline of desktop applications. By the time Rails landed in (I think?) 2008 "do everything on the web" was what a lot of people were already talking about, even if the truth of that didn't really land until much later.
Really it could have been go-lang before go-lang and I'm not sure why it wasn't other than that it wouldn't have been controllable by the folks at Google.
Because web was cross platform, didn’t need any “installation”, and had far better devtools included than any tech that days.
Not in 02002. In 02002 your JS devtools were that the browser crashed when you had a bug in your JS, so you would have to binary-search your recent changes to figure out which line of JS was crashing it, and you could evaluate expressions by typing javascript:(void)alert(f()) in the URL bar. No browser console, no web inspector, and the only portable DOM was image rollovers and form field values. If you wanted to generate document content in JS the only way that was portable to Netscape Navigator 4 was document.write().
I think we didn't even have bookmarklets at that point—the browsers supported them, but we didn't know that.
> the Lazarus project
Hem hem,
https://www.freepascal.org/
---
Really, it was because pascal was the go of its day with very little corporate backing (by modern standards). A language designed around developer ergonomics with some safety in mind: lovely for teaching, but only because it was a jack of all trades.
Web units were included, it's just that php became dominant because it was stupidly easy. I myself was a pascal programmer that started writing php around the time of lazarus 0.9 / fpc 1.9 and I recall that php felt like bash scripting by comparison. Today, I consider the cgi model to be rudimentary and php itself a pile of shit.
Delphi / Lazarus were GUI frameworks not different languages, and regarding Lazarus itself I'm gonna be RMS here and say that it's GNU/Linux (which it was, for some time).
Florian Klämpfl deserves some credit.
It didn't, despite all its management failures, several companies are still buying into Delphi (Object Pascal evolved from Turbo Pascal/Apple's Object Pascal), and there is at least an yearly conference in Germany.
https://entwickler-konferenz.de/en
Then there is still FreePascal, Mikroe Pascal and RemObjects Pascal to chose from.
> Then there is still FreePascal, Mikroe Pascal and RemObjects Pascal to chose from.
And now also Micron, which re-added Pascal features to Oberon (https://github.com/rochus-keller/micron/).
Some of us are still using Turbo Pascal for CP/M on our Z80 systems. OK, a bit niche.
That sounds like fun. What have you written lately?
Ah, yeah, have to play with it sometime. TODO list is rather long. :)
A project like this never gets finished.
Sorry for the misunderstanding, I meant my own TODO list of stuff to check out.
The project is rather cool.
And that project (cool stuff to check out) never gets finished, because there's always more cool stuff.
Lua, Go, and Nim have some Pascal roots, according to https://en.wikipedia.org/wiki/Generational_list_of_programmi...
Though Borland had some commercial success, I remember Pascal mainly as a teaching language.
Can't believe I forgot PL/SQL, as I used that heavily for years.
Ada also was widely used in aerospace/military applications, though not sure it's still used for anything new today.
Odin borrows from Pascal as well.
Julia is also heavily influenced by Pascal syntax.
> Why did Pascal basically die completely?
It morphed into Delphi. The reason that it's not that successful anymore is that it was deeply tied to Windows (even if there were half-arsed Macintosh ports).
And then the Internet taking off happened.
And suddenly you had gigantic companies built on PHP/JavaScript/Linux (like Facebook), on open-source software (Google) and Pascal/Delphi got also attacked by actually portable stuff, like Java, which some of today's biggest companies were built on (like Amazon).
So on one hand Linux and it's myriad of open-source languages and on the other hand Java (which is what it is but it is portable) and then JavaScript in the browser.
Nowadays tens of billions of devices, including many servers powering the entire world, are running Linux. While Pascal/Delphi was that language you'd run on DOS and half-arsedly ported to Windows: not a winning proposition.
Because it didn't have nul-terminated strings.
Not sure if you are being sarcastic. Pascal strings are first class citizens, so it's trivial to add null-termination. Delphi actually does this to allow typecasting.
C, for example, doesn't have strings. It has pointers to memory that might contain characters and, if you are lucky and the stars are aligned, a zero to mark the end. I'll never understand how C strings were accepted as a string representation and not the mad source of bugs and insanity that they are.
> I'll never understand how C strings were accepted as a string representation
1972 was definitely not a good year for C standardization bodies. I blame that guy Ritchie and his audacity to hack a language on a whim. Even his GitHub page is empty (or misattributed).
Free Pascal/Lazarus it's rocking nice tools such as Peazip and other stuff like Carte Du Ciel and some RAD tools in the enterprise. On the niche geeky world, there's T3X at https://t3x.org which is semi-Pascal like.
The main problem with Pascal was not having a standard at a time when having a standard was important for adoption. There were several successful implementations like Borland's, and the version used in the Macintosh, but being closed products they never talked to each other. It's similar to the situation of Basic: lots of code was created in Basic but none was compatible with a standard and was essentially lost.
It certainly had a standard, two actually, however no one cared because Turbo Pascal was more relevant, and Modula-2 was designed to fix Pascal's shortcomings, which also has a ISO standard.
So it wasn't for lack of standard per se.
Carmack developing DOOM on a NeXT and porting it to PC was a very good advertisement for C.
The tooling was done in Objective-C.
Not just having a standard but being able to collectively evolve a standard.
In the absence of that, Pascal’s creators and commercializers invented follow-on languages, including the most successful thread via Hejlsberg as we’re discussing here: Object Pascal -> Delphi -> C#/.NET—with a brief detour to J++, which I don’t know enough about to understand if it belongs in this sequence.
Outside Borland and Apple, people tend to forget that already in 1976, Niklaus Wirth came up with Modula-2, exactly to fix all the shortcomings from a language originally designed for teaching, with one properly designed for systems programing from the start.
As for your sequence, from someone that was around back then, .NET and C# only exist as you know it thanks to Sun's lawsuit regarding Java language and runtime extensions introduced in J++.
Then an internal research language originally named Cool, became C#, the language extensions in J++ were made into C# features (events, J/Direct, COM interop), Windows Foundation Classes became Windows Forms, and J# was released in .NET 1.0 as transiton technology.
Had it not been for the lawsuit, Ext-VOS (.NET codename) would have been released with J++ instead.
https://web.archive.org/web/20190111203733/https://blogs.msd...
Follow the linked paper for Ext-VOS, aka COM+ Runtime, aka .NET.
Microsoft would revisit this COM+ Runtime a decade later with WinRT,
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
Amazing, thanks! I was also there for the commercial and legal history of J++ but was unsure how much J++ incorporated what would become “Cool” ideas.
Can’t wait to read the VOS paper.
Went the way of the dinosaurs. I learned about pointers and memory on Hi-Soft Pascal on a ZX Spectrum from this book: https://www.okazii.ro/limbajul-pascal-corina-corici-dorin-ma...
Here's a page from the book I was reading in 1993: https://imgur.com/a/7UWdGgS
For reference, ZX-Spectrum has 48Kb of RAM out of which 8Kb is video memory, so unusable.
Then you have to load the Pascal compiler into the remaining 40k of RAM. Allocate some RAM for stack and environment variables for the editor where you write your program, plus space for the actual program. Then compile your program into the same 40k of space. And run it, using heap and stack memory from which memory space? You guessed right, same 40k.
To recap, on 40k of RAM you had back then:
- The Pascal compiler
- The Pascal source code in text form
- The Pascal executable form in machine code
- The Pascal data/memory. Of which, recently in a "tech demo" of automated tests, one colleague said "unfortunately we only have a very limited amount of RAM to be able to do basically anything [that's why the product is a mess with no tests]. Only 32Gb per [virtual] machine".
One of my first programs was a Tetris clone, because ZX-Spectrum BASIC was slow as molasses. All on top of only having tape for storage so if I fucked up a pointer (I don't think Pascal had the concept of access violation back then but I sure discovered it on my own skin), it would take 5 minutes to load the Pascal compiler + some backup copy of my Tetris game, hopefully not from a month ago and hopefully I remember what I changed. Lots to discover and have "fun" with.
About a year later I did find a compiler for BASIC and it turned the unplayable BASIC code for Tetris I wrote in the 9th grade into a totally playable Tetris game, without the need to learn another language and paradigm (pointers!) but the damage was done. Ignoring a year of databases, in 12th grade of high school computer science class (elite class, found there basically all the Math olympics I was competing with in gymnasium), I got introduced to C and from then on, here I am, 30 years later, doing C++ in finance for an S&P 500 company.
Kaaaaaaaaaaaahhhnnn!!!
I’m tired of those senseless comparisons
Bytes have history, meaning, context of creation, different utilities and different cost associated with creation/transfer/storage/manipulation
We could also use those comparisons to praise how complicated our current world has become and how good we are at managing such complexity
Complexity is not something to strive for, but something to be avoided. I would also argue that we aren't good at managing that complexity at all.
I have been meaning to do an XKCD radiation/money style chart for memory for some time now.
Of course now it would be a trivial job for an AI to make the chart. Finding a authoritative source for byte counts, probably less so.
The wall of defensive, hostile replies to this simple post is expected. Today’s programmers need to feel like they are an elite class above the rabble and programming is their identity. When someone shows them an example of what talented programming really looks like, they have to pile on and dismiss it from a thousand cuts. The guy who wrote Pascal understood the system top to bottom, and understood computer science. There are maybe a few thousand programmers alive today with that kind of skill, and it hurts the egos of the average HN typescript scrum jockey to see something they just don’t comprehend so they lash out at it.
well said.
I absolutely adore the level of irony and a bit of sarcasm in each bit of the comparison represented by the referred article
It's always an interesting thought that I had meetings about the log aggregation dropping stack traces that would take ~3 3.5" floppies to store. Each.
Zabbix also confuses operators at this point. I recently had to increase a cache. I chose to go from a solid 4MB to a luxurious 256MB.
I know high-performance Java, so just a little jab there, but you don't size JVM parameters like that, except maybe code caches. And before Rust comes in, we also have a Rust application running without good resource control and it wouldn't like those resource constraints.
There is truth to this article.
"And the whole thing was lightning fast, orders of magnitude faster at building projects than Microsoft's compilers."
Sure, I mean it had a turbo whereas Microsoft only ever had quick things. A shame no one thought of swift back then.
Is it such a stupid comparison? It's an absolutely trivial amount of data now, but back in the 80s, a few files of that size would fill out a floppy disk. It's also a source file - the input to a compiler.
But literate programming is the old hotness
Way to miss the point entirely...
This is only slightly related but I just made a Turbo Vision UI for Claude Code sessions.
https://github.com/runvnc/tvclaude
Amusingly i also used Turbo Vision to make some agentic harness[0] :-P (though mine is meant to talk with llama-server via its OpenAI compatible endpoint since i'm using local models - the one in the shot is Gemma 4 E4B which i'm using for testing).
That said i never finished that and ended up making another one (using tvchat as a base since it had largely working communication and session management) that acts as a server/daemon inside the container is meant to run in the background and provides a web-based UI instead.
http://runtimeterror.com/pages/iv/images/25b1d4b43bb3467e392...
cool. can you drag & drop in files (e.g. screenshots, PDFs, video recordings, text files, etc.) for context when you work on features or bug fixes? Cursor is great at workflows like that.
no, but good idea, I am having Claude add that. EDIT: done. if your terminal doesn't support drag-and-drop (kitty and some others do) there is also a new File | Attach file(s) menu item
Well, yeah. Back in the mid-80's, software needed to be usable on a computer with a single 360KB floppy drive. (No HD, no SSD, no USB, no network, no ...) And even a big budget for RAM - which cost many orders of magnitude more than today - would really not get you around Bill Gates' 640KB DOS memory limit.
Comparing to current-day stuff is kinda like comparing battery-powered bathtub toys to jetskis.
Those "bathtub toys" built the entire modern infrastructure, parts of which are still chugging along. If anything, I'd put the onus on software developers - like John Carmack said in 2005, "there is something deeply wrong when text editing on a 3.6 ghz processor is anything but instantaneous".
Software in the 80s showed what's possible when you really care about doing it. Software in the last 15 years feels like an exercise on what happens when you don't.
Read the original John Carmack post here: https://web.archive.org/web/20050330004221/http://www.armadi...
I remember Windows 98, where it crashed every few hours and took everything with it, but while it worked, it never missed a keystroke or mouse press. I could type ahead and click where I knew the button would appear in 10 seconds and it still wouldn't lose anything. Nowadays you just finish typing out a thought and then realise half of it never turned up, because something else claimed the focus or whatever.
> Bill Gates' 640KB DOS memory limit.
IBM’s 640 KB limit, to be fair.
https://www.xtof.info/the-640k-memory-limit-of-ms-dos.html
More like comparing a racing kayak to a leaky container ship burning sulfurous bunker fuel carrying a load of short-lived consumer junk. :-)
Yet at the same time, one is a pastime for an affluent lifestyle while the other is driving the global economy. Interestingly, or ironically, the former was probably put on the shelves by means of the latter.
If there is any positive progress to be made, the rethinking necessary must go much, much deeper than the superficial flesh of the problem, but there it’s bound to hit upon the sinews and bones of vested interests.
In all, as I’m growing older and see the world trudge along the same lines it did centuries ago, I’m more and more pessimistic about the possibility of people agreeing that the sacrifices necessary will be made.
Short-term stakeholder interests seem to trump any notions of longer-term greater good.
> one is a pastime for an affluent lifestyle while the other is driving the global economy
which one is which?
The one that’s available off the shelf or by click to order and can be delivered to your porch by a reasonably sized delivery van :)