No, now you are running an IDE that is badly pretending not to be a browser, while an entire second application has to work in the background eating even more RAM to provide you with access to documentation for each function at the cursor...
I mean, you could go write up an IDE that acts like that old one in a few weeks now. Could use a ton less RAM. You'll be the only person using it while everyone else uses the browser for convenience.
OS/2 more popular, not in my part of Europe, although it had its fan base. there were even OS/2 (Warp) freebie cd-roms at the time. I was quite fond of it, but Win 95 killed it
OS/2 was _incredibly_ rare UI- and UX-wise. Very frustrating to use. As if they copied Windows, but somehow copied only 80% of it with some really common bits missing.
My first real programming project was creating a pong clone on DOS using Turbo Pascal, as a 12 year old, in the mid 90s. Many years later, when I was in the penultimate year of uni, I worked as a freelance Delphi programmer. I had no idea Pascal would help me buy my first car many years later.
As someone born after the release of TP 7, this was a fascinating read!
I wouldn’t necessarily have expected for Microsoft to make development (at least the “intended” way) for early not-just-DOS Windows this unergonomic, but now in hindsight, it’s also not that surprising, really.
> "That almost nobody has the skills these days to implement something like TP is something we could eventually come to regret – or, rather, our grandchildren could. Software development is becoming a semi-skilled industry, and I doubt that the rise of AI will entirely compensate for this."
I agree, but AI also there is hope!
For many years I've worried about the ever-growing depth of abstraction in computing. There are few alive now who actually understand all of the layers on abstraction involved in modern computing, and who can debug the truly strange edge case bugs and vulnerabilities introduced by the interoperation of these many complex layers.
For a time I imagined it to be an unsolvable problem, and that there would always be only a special class of neurodivergent hyper-specialists who still mostly had to work in large teams to even come close to understanding a stack in full. We're reaching the point where a single human lifespan just isn't enough to learn it all, even for those of us with what Dilbert called "The Knack". By the time you're proficient in all of it - you're dead.
Now there is a new kind of intelligence. One that CAN fit it all in a single mind, and one that will outlive us all and continue to learn long after our meat has gone bad.
As long as the AI's stay aligned, and we find ways to build them more efficiently there's a non-zero chance that they actually make it all better instead of worse. Genuinely long-term planning and the ability to TRULY grasp the full stack COULD actually happen. At least if we use these new systems in service of the greater good, and not just to play silly games on the stock market.
There’s no substitute for human knowledge. What if the climate crisis gets to the point where we cannot justify boiling the ocean to perform tasks we’ve come to depend on?
What’s our disaster recovery strategy in the event of war and loss of internet?
Or worse yet, a near extinction event and we are forced to rebuild civilisation from memory?
Some of these might seem like extreme edge case scenarios but then history is full of disasters that people didn’t prepare for because they assumed they were too big to fail.
I’m not sure where he got that idea. All I could learn about TP was like one book sold in one bookstore in my entire city. The barriers to entry back then were astronomically higher than they are today, especially given how AI has democratized access to information, knowledge, and expertise.
AI is not trending towards small, minimal code with nice abstractions. It is faster at replicating "big team" code, but the code from a small team or a few authors still wins for elegance and simplicity.
I suppose it depends on what you mean by trending. Some of the recent rewrite news[1] for example suggest that, at minimum, it is the macro demand that is driving the software trends. In this case, issues with memory supply drive attempts at more sensible memory utilization.
The fact that we are celebrating that a chat app only uses 300MB ram at launch instead of 1GB seems absolutely ludicrous to me
The early versions of Skype used about 30MB RAM while in a video call and by the early 2000s standards it was bloatware. Before that we used WebEx in the 90s which was a browser ActiveX or Java applet and RAM use was about 6MB in a video call. In the early / mid 90s I used CU-SeeMe for video calls and its RAM footprint was just over 2MB on Mac System 7
Something has clearly gone very wrong in the software development process in the last 2-3 decades and while Im encouraged to see that some people are interested in reversing that trend I still find the resource wastage has me shaking my head sometimes
A lot of that RAM is just high resolution bitmaps. You can have apps that fit in 10MB of RAM today if you're comfortable with the UI quality of an app circa 2000 (e.g. icons are 16x16 pixels at 8 bit colour depth).
Usually thats not the case. Its mostly abstraction layers upon abstraction layers upon abstraction layers that causes this issue
Sometime in the late 90s there started a fundamental change in the software development process. We changed from optimising software for the end user (development is difficult) to optimising the software development process for the developer at the expense of user resources
That's true for Electron apps. For other kinds of desktop app, it's mostly stuff like artwork, double buffers and fonts. Go profile a desktop app heap and see for yourself.
One of the main selling points of Turbo Pascal was OWL: the Object Windows Library, which was just a big OOP abstraction over Win16. Here's some sample code:
Doesn't look radically different to how a GUI app that targets a native framework would look today. OWL added bloat to make developer lives easier. It was ever thus.
I think its true for most types of modern development for apps with a UI, not just electron
>Doesn't look radically different to how a GUI app that targets a native framework would look today
Modern "Native" frameworks are part of the problem. I cant comment on Windows current state as I havent used Windows since I moved my gaming rig from Windows 7 to Linux many, many years ago but even then Windows frameworks were a complete mess
Take Libadwaita for example. I migrated an old, very simple disk image manipulation utility app last year from GTK2 to modern gnome. No change in capabilities, a simple clone in GTK4 / Libadwaita. It went from using ~19MB to ~185MB without any additional functionality simply by switching the "Native" framework
Try GSK_RENDERER=cairo and see if it helps. I think the memory usage increase will mostly be GPU buffers. If GPU rendering isn't necessary for your app then it's pure bloat to use it, indeed. But with very large hi res screens it's often the case now that CPU rendering can't keep up anymore.
After my comment https://news.ycombinator.com/item?id=49235430 I've investigated the high RAM jump issue a bit further. It turned out, 60 MB comes from video graphics driver, right after the first function call, that triggers OpenGL/... context initialization. Thus:
AI isn't fundamentally different to us and it does benefit from abstractions. So, I don't think that's going to happen.
Besides, it's an exaggeration. I've been programming for 35 years, and in fact got started on Turbo Pascal as one of my first languages. I wrote OWL code! Seeing the screenshot of that splash screen brought back memories. But I feel I can understand and debug problems that cross almost any layer of the software stack. Anything from some ReactJS library to kernel code to UEFI. I'm now 42 so the idea nobody can understand or debug interactions across layers before they die is for the birds. The stack isn't that deep.
I think it’s easier for us to say when we grew up with the stack. In the old days you could pretty much understand everything on your computer in a relatively short period of time. So as a learner it was all so accessible. These days it’s hard to even know where to start.
Man, I haven’t seen Turbo Pascal since high school. We were lucky enough to have a CompSci class taught by our Stats teacher.
He offered three courses. CompSci 1 used Turbo Pascal and Delphi. CompSci 2 used C++ and Java. CompSci 3 used Microsoft Turbo Assembly and a language of the student’s choice.
We had to write our code and save them to floppy discs for submission since the lab systems had DeepFreeze installed on Win95, so any local storage wouldn’t persist.
> We had to write our code and save them to floppy discs for submission since the lab systems had DeepFreeze installed on Win95
Didn't realize DeepFreeze is that old. My lab used Angel Custodius[0], which was a hardware-based solution. It used a PCI-slot and the buffer was an IC on the PCI board.
It worked the same, rebooting the computer would restore the frozen state, because changes were never committed to disk.
It also was OS-agnostic, because it ran before booting anything. If you had a Linux server and got hacked, you just restarted it, though it remained vulnerable until you disabled the protection and actually patched it.
If you wanted to introduce changes you had to press a combination of keys to bypass it, by introducing the password. Mainly to apply pending Windows Updates.
I ran a small PC lab at a university for a while and we used PC-Rdist. It was magical!
You could have different templates that all built off of the same base which made switching between different specialized classes in the lab super easy.
Similar experience here, except it was Qbasic followed by Delphi. Good memories of passing our dumb little games around the compute lab. It wasn't till later in life that I connected Pascal to Wirth when reading Algorithms + Data Structures = Programs (I still think the last chapter on compilers holds amazing as an introduction to the subject).
We had two courses at my school in early post-Wende East Germany ('91 onwards, on Amstrad PC2386 386/20 MHz machines): a beginner's computer course with OS intro (MS-DOS 4.01 and Windows 3.0), office applications, and typing... and a programming course via the GW-BASIC (later QBasic) to Turbo Pascal (much later Delphi) pipeline.
Never been a big Pascal fan (though learned and used it back in the day) but i learned C and built my first Win16 and Win32 Apps for Windows 3.x and Windows 95 in Borland Turbo C(++). That was truly magical a time!
The printed documentation alone was half a meter long.
> The name ‘Turbo’ was associated with what were regarded as hobbyist products
"Turbo" was also a short-lived pop-slang term roughly meaning "cool" or "awesome." I never heard it used much but a lot of products in that era had "turbo" in the name.
The intensifier meaning of "turbo", connoting something powerful and fast, is also interesting. Its original uses are in engineering, simply denoting something that has a turbine in it. Thus turbopump, turbojet, and turbocharger, the last of which probably being the primary driver of the semantic shift.
The Latin root of "turbo" and "turbine" is turbo, meaning a whirlwind, a spinning top, or more generally any spinning motion as a noun, and "agitate, disturb" as a verb. The latter word is, of course, derived from turbo as well, as are "perturb", "turbulence", "turbid", and even "trouble"!
Oh those were the days, I remember developing my first non-trivial piece of software (an international checkers game), while still a student, with Turbo Pascal. It run to more than a thousand lines of basically the Minimax algorithm plus various optimizations (alpha beta pruning, quiescent extensions, etc)
I have fond memories of the language, the IDE, libs like TurboVision, ObjectWindows, etc... And fun times with the demos TVChess and OwlChess, which gave me inspiration.
I can definitely vouch for Turbo Pascal, having learnt it before C was definitely a good school that strongly typed languages doesn't hinder systems programming, nor higher level ergonomics.
The only real association I have with "Borland" is that I needed their $199 compiler to share my LibertyBasic programs with friends as .exe's when I was in middle school. That was a ton of money in the late 90's. It was singlehandedly the catalyst to me realizing I could pirate more than game roms on IRC.
This hits home. Turbo Pascal was the thing (although I've barely noticed at the time) where I learned actual programming, as we know now.
I had played a lot with the Spectrum (a Sinclair zx spectrum 128k) and its BASIC interpreter but that was mostly copying from magazines and changing some parameters. And BASIC is weird :)
A few years later in school in the 90s, Pascal was "the" language that most people learned the basics in, at least in my country.
Unknowingly I sort of absorbed all that and it only started making sense when a few years later I decided to get into actual programming with perl and eggdrop bots and plugins or whatever they were called.
Fun anecdote: When I was in college, my dad read an article in the Wall Street Journal about Turbo Pascal, so he bought me a copy for my birthday. That was version 1. I stuck with TP through grad school and a little bit beyond. It seemed like there wasn't anything it couldn't do. Some of my hardware hacking adventures even required inline assembly. Some of the version bumps were really timely, such as a new compiler that created stand-alone executables. I was extremely lucky that the original TP ran on my non-PC-compatible MS-DOS machine, a Sanyo MBC550.
My graduate advisor had Microsoft FORTRAN, and I tried it out. It was a monstrosity. The compiler and linker had to be on separate floppies, and took eons. My advisor admitted that he had largely switched to BASIC.
Borland-linked piece of lore I like the best is that upon release of the original Turbo Pascal, which was advertised in the Byte magazine for $49.99, they were drowned in orders so much so that the Post Office put stop on incoming checks because they suspected it was some sort of fraud.
Don't know if the last bit is true, but they did make 150K in sales in the first month ... from a single ad and in 1980s dollars, which is quite remarkable.
> The ad broke in November, and that month we took in 1100 orders. So the ad was paid for. The second month we took in 2500 orders.
It's a bit tricky to figure out the exact breakdown since it requires knowing when people got a copy of that issue of Byte, how long it took for their mail order to get to Borland, and how many copies were sold per order. Turbo Pascal wasn't even released until November 20.
Still, my eyeballing says 150K in the first month is pretty much spot-on.
The ad, by the way, cost $9,000, to be read by 400,000 people world-wide. Each physical unit cost about $4 to produce. And all the orders were filled by hand for the first couple months.
FWIW, they also did word-of-mouth (like at COMDEX) and used dealers.
I tried but failed to find the ad. Archive.org is having problems, with very slow response times, failing searches, and failing downloads. I think the Byte issue is at https://archive.org/details/byte-magazine-1983-10/ . Wow! It's 675 pages long, and a topic for that issue is "Unix on Micros", with 9 articles about different aspects of Unix.
(I assume it needed all those articles to balance out the humongous number of ads, so they could get a lower postage rate.)
Turbo Pascal was a glorious tool for my imaginative 15-year-old brain. The first programs I sold were all written in Turbo Pascal. I had the Turbo Pascal reference books near my bedside, and I wish I still had them because they were dog-eared, post-it noted, margin-scribbled, and it's kind of strange but those books guided my future almost more than any other written text.
One distinct memory stands out. I could not wrap my mind around the Object-Oriented extensions on Pascal. I read, re-read, and re-re-read the section of the book describing what polymorhpism is and how it worked, probably at least a dozen times. Somehow it seemed really important and I kept coming back to it. I worked the examples. And then one day the ah-hah moment arrived. I remember it felt like a shock, why it was useful and what I could do with it. I promptly used my knowledge to write a new game using OOP principles to guide the rudimentary "characters" of various geometric shapes at the core of the game.
Similar experience here. I'd try to understand a concept in the help file, give up, try again the next year and suddenly it clicks. Maybe that's just how the human brain develops.
I really didn’t get it either until I saw how all the good programs were organised as struct types and groups of functions that operate on those structs. Then I was like “oh so OOP just makes that more convenient.” But I couldn’t have realised that until I understood the difference between a well-written program and a bad one. If only I’d had access to as much source code then as I do now!
MacApp provided me with an crash course in Object Pascal, just in time for Apple to throw it all away in favor of C++. Fortunately I was a voracious reader of programming language books at the time, so I was already familiar with OO concepts from learning about languages like Smalltalk that I never had a chance to use at the time.
83 comments
[ 5.2 ms ] story [ 28.3 ms ] threadOS/2 was more popular than Windows 3.1.
Back in 1992, it would had cost me about an extra 500 euros on today's money.
I wouldn’t necessarily have expected for Microsoft to make development (at least the “intended” way) for early not-just-DOS Windows this unergonomic, but now in hindsight, it’s also not that surprising, really.
I agree, but AI also there is hope!
For many years I've worried about the ever-growing depth of abstraction in computing. There are few alive now who actually understand all of the layers on abstraction involved in modern computing, and who can debug the truly strange edge case bugs and vulnerabilities introduced by the interoperation of these many complex layers.
For a time I imagined it to be an unsolvable problem, and that there would always be only a special class of neurodivergent hyper-specialists who still mostly had to work in large teams to even come close to understanding a stack in full. We're reaching the point where a single human lifespan just isn't enough to learn it all, even for those of us with what Dilbert called "The Knack". By the time you're proficient in all of it - you're dead.
Now there is a new kind of intelligence. One that CAN fit it all in a single mind, and one that will outlive us all and continue to learn long after our meat has gone bad.
As long as the AI's stay aligned, and we find ways to build them more efficiently there's a non-zero chance that they actually make it all better instead of worse. Genuinely long-term planning and the ability to TRULY grasp the full stack COULD actually happen. At least if we use these new systems in service of the greater good, and not just to play silly games on the stock market.
What’s our disaster recovery strategy in the event of war and loss of internet?
Or worse yet, a near extinction event and we are forced to rebuild civilisation from memory?
Some of these might seem like extreme edge case scenarios but then history is full of disasters that people didn’t prepare for because they assumed they were too big to fail.
[1]https://tech-insider.org/discord-electron-rust-gpui-rebuild-...
The fact that we are celebrating that a chat app only uses 300MB ram at launch instead of 1GB seems absolutely ludicrous to me
The early versions of Skype used about 30MB RAM while in a video call and by the early 2000s standards it was bloatware. Before that we used WebEx in the 90s which was a browser ActiveX or Java applet and RAM use was about 6MB in a video call. In the early / mid 90s I used CU-SeeMe for video calls and its RAM footprint was just over 2MB on Mac System 7
Something has clearly gone very wrong in the software development process in the last 2-3 decades and while Im encouraged to see that some people are interested in reversing that trend I still find the resource wastage has me shaking my head sometimes
Sometime in the late 90s there started a fundamental change in the software development process. We changed from optimising software for the end user (development is difficult) to optimising the software development process for the developer at the expense of user resources
One of the main selling points of Turbo Pascal was OWL: the Object Windows Library, which was just a big OOP abstraction over Win16. Here's some sample code:
https://github.com/TeamVault/pascal-programs/blob/master/Pas...
Doesn't look radically different to how a GUI app that targets a native framework would look today. OWL added bloat to make developer lives easier. It was ever thus.
>Doesn't look radically different to how a GUI app that targets a native framework would look today
Modern "Native" frameworks are part of the problem. I cant comment on Windows current state as I havent used Windows since I moved my gaming rig from Windows 7 to Linux many, many years ago but even then Windows frameworks were a complete mess
Take Libadwaita for example. I migrated an old, very simple disk image manipulation utility app last year from GTK2 to modern gnome. No change in capabilities, a simple clone in GTK4 / Libadwaita. It went from using ~19MB to ~185MB without any additional functionality simply by switching the "Native" framework
After my comment https://news.ycombinator.com/item?id=49235430 I've investigated the high RAM jump issue a bit further. It turned out, 60 MB comes from video graphics driver, right after the first function call, that triggers OpenGL/... context initialization. Thus:
Looks a bit better. But we still need 98 MB total.Besides, it's an exaggeration. I've been programming for 35 years, and in fact got started on Turbo Pascal as one of my first languages. I wrote OWL code! Seeing the screenshot of that splash screen brought back memories. But I feel I can understand and debug problems that cross almost any layer of the software stack. Anything from some ReactJS library to kernel code to UEFI. I'm now 42 so the idea nobody can understand or debug interactions across layers before they die is for the birds. The stack isn't that deep.
He offered three courses. CompSci 1 used Turbo Pascal and Delphi. CompSci 2 used C++ and Java. CompSci 3 used Microsoft Turbo Assembly and a language of the student’s choice.
We had to write our code and save them to floppy discs for submission since the lab systems had DeepFreeze installed on Win95, so any local storage wouldn’t persist.
Didn't realize DeepFreeze is that old. My lab used Angel Custodius[0], which was a hardware-based solution. It used a PCI-slot and the buffer was an IC on the PCI board.
It worked the same, rebooting the computer would restore the frozen state, because changes were never committed to disk.
It also was OS-agnostic, because it ran before booting anything. If you had a Linux server and got hacked, you just restarted it, though it remained vulnerable until you disabled the protection and actually patched it.
If you wanted to introduce changes you had to press a combination of keys to bypass it, by introducing the password. Mainly to apply pending Windows Updates.
--
[0]: https://web.archive.org/web/20040210055959/http://www.custod...
You could have different templates that all built off of the same base which made switching between different specialized classes in the lab super easy.
We had two courses at my school in early post-Wende East Germany ('91 onwards, on Amstrad PC2386 386/20 MHz machines): a beginner's computer course with OS intro (MS-DOS 4.01 and Windows 3.0), office applications, and typing... and a programming course via the GW-BASIC (later QBasic) to Turbo Pascal (much later Delphi) pipeline.
never forget
The printed documentation alone was half a meter long.
And: "A Personal History of Compilation Speed, Part 2" https://prog21.dadgum.com/47.html
"Turbo" was also a short-lived pop-slang term roughly meaning "cool" or "awesome." I never heard it used much but a lot of products in that era had "turbo" in the name.
The Latin root of "turbo" and "turbine" is turbo, meaning a whirlwind, a spinning top, or more generally any spinning motion as a noun, and "agitate, disturb" as a verb. The latter word is, of course, derived from turbo as well, as are "perturb", "turbulence", "turbid", and even "trouble"!
I have fond memories of the language, the IDE, libs like TurboVision, ObjectWindows, etc... And fun times with the demos TVChess and OwlChess, which gave me inspiration.
The terminal IDE that it came with, if you can call it that, was ahead of its time.
I think I used TP 7 and it was the usual blue IDE for DOS.
Although Turbo Pascal 7 has MS-DOS extenders support, and could target Windows 3.1 as well.
Then came Delphi.
If you ever feel like you need a palate cleanser after reading AI code, go dig into any Fabrice Bellard project.
I had played a lot with the Spectrum (a Sinclair zx spectrum 128k) and its BASIC interpreter but that was mostly copying from magazines and changing some parameters. And BASIC is weird :)
A few years later in school in the 90s, Pascal was "the" language that most people learned the basics in, at least in my country.
Unknowingly I sort of absorbed all that and it only started making sense when a few years later I decided to get into actual programming with perl and eggdrop bots and plugins or whatever they were called.
Damn, the 90s, IRC and Quake were awesome!
My graduate advisor had Microsoft FORTRAN, and I tried it out. It was a monstrosity. The compiler and linker had to be on separate floppies, and took eons. My advisor admitted that he had largely switched to BASIC.
Don't know if the last bit is true, but they did make 150K in sales in the first month ... from a single ad and in 1980s dollars, which is quite remarkable.
> The ad broke in November, and that month we took in 1100 orders. So the ad was paid for. The second month we took in 2500 orders.
It's a bit tricky to figure out the exact breakdown since it requires knowing when people got a copy of that issue of Byte, how long it took for their mail order to get to Borland, and how many copies were sold per order. Turbo Pascal wasn't even released until November 20.
Still, my eyeballing says 150K in the first month is pretty much spot-on.
The ad, by the way, cost $9,000, to be read by 400,000 people world-wide. Each physical unit cost about $4 to produce. And all the orders were filled by hand for the first couple months.
FWIW, they also did word-of-mouth (like at COMDEX) and used dealers.
I tried but failed to find the ad. Archive.org is having problems, with very slow response times, failing searches, and failing downloads. I think the Byte issue is at https://archive.org/details/byte-magazine-1983-10/ . Wow! It's 675 pages long, and a topic for that issue is "Unix on Micros", with 9 articles about different aspects of Unix.
(I assume it needed all those articles to balance out the humongous number of ads, so they could get a lower postage rate.)
Here's Borland's ad a year later for TP 2.0 - https://archive.org/details/Computer_Language_Issue_01_1984-... and here's Dr. Dobbs' review of 1.01 in their June 1984 publication - https://archive.org/details/1984-06-dr-dobbs-journal/page/74... . Oh, and an article about it in Germany in September 1984 at https://archive.org/details/peeker-1984-01/page/50/mode/2up?... .
One distinct memory stands out. I could not wrap my mind around the Object-Oriented extensions on Pascal. I read, re-read, and re-re-read the section of the book describing what polymorhpism is and how it worked, probably at least a dozen times. Somehow it seemed really important and I kept coming back to it. I worked the examples. And then one day the ah-hah moment arrived. I remember it felt like a shock, why it was useful and what I could do with it. I promptly used my knowledge to write a new game using OOP principles to guide the rudimentary "characters" of various geometric shapes at the core of the game.
Fun times, and very formative to me!