Hacker News

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.

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

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?

It's a full compiler and debugger. It's not at all obvious that it could be smaller than an image.

“Obviously”. Look, if you don’t really know what a development environment is, that’s okay. But a dismissive comment such as this makes it obvious to the rest of us that you don’t know, when I’m confident that isn’t your goal.

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.

More like comparing a racing kayak to a leaky container ship burning sulfurous bunker fuel carrying a load of short-lived consumer junk. :-)

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.

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

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

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.

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.

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.

Because it didn't have nul-terminated strings.

Kaaaaaaaaaaaahhhnnn!!!

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.

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.

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.

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.

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