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.
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.
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?
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.
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.
“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.
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.
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.
The next few years are going to be fun.
https://github.com/runvnc/tvclaude
Comparing to current-day stuff is kinda like comparing battery-powered bathtub toys to jetskis.
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.