Hacker News

You are missing J++, several C# features were born in J++, e.g. P/Invoke was J/Direct.

>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 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.

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?

> 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.

> 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.

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.

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.

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.

> 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.

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.

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!!!

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.

well said.

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.

Way to miss the point entirely...

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.

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.

> 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. :-)