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.
Turbo Pascal and Broland Pascal .. the memories - we used to compete in the demo scenes in Scandinavia back in the day, and even though most of our hot paths where assembly and close to illegal instructions that would crash certain cpu steppings, we would always boot the code from .pas .. and the low hanging fruit was always pascal..
All of our competitors were mostly pure asm or c combo..
Thanks for posting that comment! Made me smile and reminisce
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.
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!
The experience of editing Java in Eclipse is the fast type, and it's very cool, and I suspect it's the only modern IDE that works this way. And the only reason to use Eclipse. Or Java.
One strange feature is that a function with a syntax error in it still compiles, but compiles as throw new Error("Syntax error: ..."); - I suppose this is necessary for an interactive compiler!
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.
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.
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).
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.
> "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.
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 Turbo Pascal was one of my first languages. I wrote OWL code! Seeing that splash screen brought back memories. But 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.
Yeah, true, it probably helps to have grown up alongside the tech itself.
I'm not sure it was more accessible though. Learning programming back then was really hard. Nothing was user friendly and achieving even simple tasks like drawing a diagonal line might require you to sit down and learn Bresenham's Algorithm (from the books neither you nor your library had copies of, naturally...). So it was easy to get discouraged. You can get fun and relevant results much faster now.
I don't really think you need to understand the whole stack. Rather, you need to understand at least one level deeper than whatever you are using.
Back in the days of Turbo Pascal you had to know what you were looking at when the memory modified breakpoint went off and you got dumped to the assembly level. And you really had to understand it to deal with the 200mhz bug (there weren't convenient solutions at hand when I first hit it) or when I ended up making extensive modifications to the real mode support in the DPMI mode--never saw that mentioned anywhere. It was nasty--the library was fundamentally flawed and clearly had never actually been used as it declared real mode pointers as "pointer"--which had a very high chance of causing a segment error when the compiler emitted code that copied them by loading them into a segment:offset then storing them. And the debugger was flawed: in single step mode it was emulating, not executing. And the emulation would correctly "execute" an invalid segment register load.
Now, though, in C# I have yet to have any reason to look at assembly.
Sure, luckily nobody needs to understand the whole stack. I feel I do but that's just a mix of age + unusually varied projects, not necessity.
Have to admit I don't recall a 200Mhz bug, and all modern search results are about GPUs. As for DPMI, well back then I was just a kid and 640kb was enough for any kid ;) Then Windows came along and solved all that. I definitely knew what it was though because all the games used dos4gw...
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
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 MESA / video graphics driver, right after the first function call, that triggers OpenGL/... context initialization. Thus:
Maybe we should also ask ourselves why modern native apps need OpenGL when you used to get by with a framebuffer. You can do more things with OpenGL but are you actually doing those things?
It's almost entirely about screen resolutions. In the Turbo Pascal era the screen probably had 640x480 pixels or 307,200 pixels in total. The screen I'm looking at now is 5120x2880 = ~14.7M pixels.
If an app is maximized it has to render ~48x more pixels per frame, probably with anti-aliased text which older systems didn't use. Doing that on the CPU is not only visibly slow in many cases, but a waste of CPU time that could be better used for actual app logic. OpenGL happens to be a convenient and portable way to get the GPU to do work for you, at the cost of some memory, so GL it is.
It doesn't render them. Framebuffer native apps back then didn't have enough memory bandwidth to change every pixel every frame either. They just changed the ones that changed. You'd probably still let the compositor use the GPU to drag windows around. They had that back then too, it was called accelerated blitting.
GL based widget toolkits only render the needed pixels too. It's good for saving battery but isn't enough by itself as it only works until the app genuinely needs to repaint the entire window. Think a text editor or IDE switching to a different file.
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.
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.
I respectfully disagree. All you describe is a deeeeep reliance on who controls the models, and as the things currently trend I would say it goes more and more into a monolithic direction. Sure, you can run your local model, but hardware is so expensive that it will have many cut corners.
I also think you oversell the complexity of things to preach the superiority of a glorified text predictor
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 was told in 1969 that the Amazon was almost gone & we soon wouldn’t have enough oxygen to breathe. Humans, unlike the dinosaurs, are very resilient. Near extinction events have never occurred in human history, doubt they’d occur now. History is full of local disasters & human-created killer regimes, but only WW2 was a truly global event. And it was solved by the only country in the world with the global power to do it. If that country now needs AI to progress that’s fine with me, though I’m too old to see any of the good or bad results.
Would you not say that AI is an expression of the sum of all human knowledge? And as humans continue to generate more knowledge, it too, will be added to the AI's representation of it all?
So there's a common dichotomy in software engineering between the "big ball of mud" and "beautiful diamond" patterns. A big ball of mud is a software system that grows through accretion: it often has tangled flow control, data whales, lots of special-casing, lookup tables, and so on. It evolves, it isn't really designed. A beautiful diamond is a software system that is meticulously designed, consistent, oftentimes with tight interdependencies between how it works. Everything is efficient and easy to understand, but if you take one part out of it, it tends to fall apart. Common Lisp is a big ball of mud, Scheme is a beautiful diamond. C++ is a big ball of mud, K&R C is a beautiful diamond. Windows is a big ball of mud, BeOS is a beautiful diamond. Microsoft VSCode is a big ball of mud, Turbo Pascal is a beautiful diamond.
The big ball of mud structure is often taken to be an antipattern: at least, when I Googled this, Gemini told me it's a "haphazard, tangled anti-pattern" and gave me some advice about how to refactor such a software system into a beautiful diamond. But nearly all software systems that people actually use and maintain are big balls of mud. This is because the big ball of mud tolerates partial failure extremely well. It tolerates changing requirements very well. It tolerates parallel development very well. You can change part of it without throwing away the whole thing.
AI is a beautiful diamond. For the most part, if an AI model malfunctions, you have to blow it away and retrain it. Or I guess you can build layers to fix up the output case-by-case, but then you're really building a big ball of mud around the beautiful diamond, and obscuring it in the process.
That's a little worrisome when it comes to durability. Living, enduring systems usually end up becoming a patchwork of mud. Your ability to do this with LLMs are basically limited to LoRa patches and post-processing steps.
There's much more about humans then there is writing about them, a lot of cultures with oral histories, a lot of nuance in behavior we take for granted, can it all be digitized?
I would say your reply feels like you didn’t read beyond the first sentence of my comment.
If you did, then I apologise. But my point is about accessing that knowledge when AI isn’t available. Not about how AI discovered its corpus to begin with.
No. It’s that we shouldn’t depend on AI always being available.
Absolutely we should use all the tools at our disposal which enhances productivity. But that doesn’t mean we shouldn’t also learn how’re to do things for ourselves too.
To use a contrived example, there’s no shame in using a dishwasher. But if you cannot wash dishes by hand when the dishwasher breaks down, then you know you have problems.
> It’s that we shouldn’t depend on AI always being available.
I made the general tech-dependence statement, but it sounds like you think it is only AI tech that shouldnt' depend on. I wouldn't worry about it; humanity has proven itself to be INCREDIBLY resilient and adaptable when the things we've come to depend on go away or change materially.
We aren’t just talking about technology, we are talking about knowledge.
Like I said, I have zero issue being “AI first”. 90% of my day-to-day is using AI. But the part I objected to in the OP was “we don’t need to know things because we have AI” (to paraphrase. So I was asking the question: what if AI goes away?
I agree humans are resilient. But that’a not a good excuse for complacency.
I think open weights and local AI will distribute the knowledge across the planet, avoiding a single point of failure. All you would need is electricity and a computer. And if we have no way to access it, there will always be enough people who either have sufficient knowledge already or the hunger to rediscover things.
I think we are still a long way from that becoming an option due to the cost of hardware to run even the lower end models. But I do like this prediction of yours
I feel like having a local qwen model that could run without the internet competes with having a local searchable wikipedia. If disaster does strike, we could now recreate a lot of knowledge with a single high end pc
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.
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.
It was with Turbo Pascal that I started to code in earnest as a child. I am so grateful for the authors and for the friend from school who gave me a copy, and taught me Pascal.
A cool thing about TP was that it had simple and convenient support for inline assembly, which was the gateway drug for me learning more low level programming.
It’s really sad that Delphi didn’t take off like VB. It was a superior environment in every way. Faster programs, better UI, much better language, and I would argue easier to use (in VB you spent a lot of time working around the limitations of BASIC in my experience). Hard to compete with Microsoft though.
I didn’t realise at the time that, with the advent of web apps (and my interest in them), that chapter of my life would be the last time I would work with such a clean, integrated dev environment.
They kept jacking up the price but were many years behind on 64-bit. That said to me they were looking to extract cash, not support developers. And C# was just about as good but properly supported. And in time Microsoft closed most of the gaps.
I was using Delphi in a shop that did mixed C/C++, VB and Delphi. You'd basically rank the people based on the tool - the wizards using C++ (segfaulting all the way), boot camp folks using VB for testing and mockups, and Delphi was this weird thing also used by testers.
So here's me this Linux guy coming to a Windows shop that came from C/C++ and Turbo Pascal, loving Delphi - and I broke their brain. Naturally instead of investigating if the tool is good, they just write off the person using it. Nothing to see here!
It's one of those things that was ahead of its time (think Smalltalk / Lisp, etc). C++ obviously had (and kind of still has) its place, but Delphi could do 80% or more of that, and in radically less time, code, compile time, etc.
Check out FreePascal[1] if you want a modern compiler toolchain that's largely compatible with TP7, and Lazarus[2] if you want a modern alternative to Delphi.
The best things about TP and even VB was how fast everything was to develop. When I'm sitting there watching our CI build take 45 minutes to deploy, I still remember turning around changes and copying to release file server in just a few minutes.
Turbo Pascal and a database add-on were part of an 80s-era text-analysis-and-generation program that was devised by lit professor Hugh Kenner and CS professor Joseph O’Rourke. I implemented that, on a single-board-computer running a CP/M derivative called (IIRC) Z-System, and I had a great deal of fun playing with it.
Some years later, I worked it into a commentary on generative AI that I wrote for Fast Company. My article mentions James Joyce, because the original BYTE article did. My piece omitted to add that my experiments also included mixing Henry James with a spot of Victorian porn.
I enjoyed being reminded of all of that by the Turbo Pascal piece.
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.)
Anyone remember Turbo Pascal DiskTutor? My older brother bought that for me for my birthday and I used it to learn object oriented programming. This was DOS still.
I used Turbo Pascal in 8th grade to create a simple type of 3d wireframe CAD-like tool on the PC in my bedroom.
Then in AP Computer Science in high school we had (TUI) Turbo Pascal also.
I always remember that type/style of TUI fondly. It periodically pops up in my head out of nowhere. Like just yesterday I randomly decided to add a Borland-style menu to my Starship prompt as an experiment. I accomplished that by writing about two sentences to an AI.
My actual job at this point is feeding tasks into AI and judging whether it answered just the way I wanted.
My very first professional gig, in the mid-1980s, was extending a classified ads application that was used by telephone operators in teh days when you could call a newspaper or magazine and dictate your ad over the phone.
It was written in TurboPascal and saved its data with BTrieve. The whole thing ran under MP/M (a CP/M variant that had the concurrency support we needed) on a closely coupled network: A box with an S-100 bus where each user had their own system-on-a-card with an 8088 CPU. Our application wasn't client-server, each user had their own app and we had written our own code for network-based cooperative multitasking, as we called it in those early days.
Fifteen years later I was on a team that created a concurrency linter for Java. It inspected the behaviour of running J2EE servers and flagged runtime anti-patterns as concurrency smells to be investigated.
Everything felt so familiar, despite all of the tooling being complete different!
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.
> 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"!
For those who don't remember, the turbo button existed as a backwards compatibility hack. A lot of games in the early days did dumb stuff like implement game timing loops by spinning the CPU, because devs just didn't think ahead to "what if people play my game on hardware that doesn't exist yet". So when the first big leaps in clock speed came out, some games ran unplayably fast. The fix was a literal button on the front of the machine that controlled the clock speed.
Devs learned how to use the timer chips pretty fast after that though, so for a long time the turbo button existed but appeared to be useless. Pushing it would toggle a light but nothing appeared to change.
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.
I was about 15 when a school friend and I spent entire days writing simple video games in Turbo Pascal. That experience is what got me into programming, and it became foundational for my entire career. I still look back at those days with a big smile.
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.
> (Turbo) Pascal eventually gave way to Delphi which, despite its technical merits, never had the same impact.
Not sure I can agree with this. My time with TP7 was fledgling, Delphi was my first "professional" language. Over the years since, I still get cold-called and -emailed from recruiters who would do anything but pay for a Delphi developer.
An interesting parallel with NT: Dave Cutler was hired by MS to replicate his success with VMS and built NT.
Likewise, Anders Hejlsberg was hired by MS to replicate his success with Delphi and built C#.
Some of my first experiences with programming are being completely baffled by a TP6 book I got from my much older nephew, and using Delphi in high school for my final project.
And rich to see the Pascal guy complaining that VB made programming too accessible, the same complaint was made about Pascal in the early 80s. Just look for the article "Real programmers don't use Pascal" :).
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 missed out on Turbo Pascal for Windows — I had moved on to mostly Mac development by then, and by the time I started working on Windows again, Visual C++ was firmly entrenched, my employer was a C/C++ shop, and I was comfortable with C++ from the Mac — but I was a big fan of Turbo Pascal for DOS (and Apple's Object Pascal on the 68k Mac).
They very much were. There might have been another product, TP 7 Professional, in the middle there as well, with a bundled assembler, debugger and profiler. Not sure about that one, but that’s how they did it with some of the earlier versions, before Borland Pascal for Windows was a thing.
Maybe unfair, but at the time I had to do a project in Turbo Pascal. Up 'till then I had been using Think Pascal on the Mac. There was no comparison. I felt like I was trown back a decade. Not that the raw capability was that different, but boy, the UX. I hated it.
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.
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
Source? That's sure not the way I remember it. I don't think I ever saw OS/2 outside of in computer stores. I don't think I ever saw a single customer actually using it, either professionally or on a home computer.
I ran it at home as a teenager, as I got a free Warp cd at a store (when they cancelled the product). Ran it for a few days, then went back to windows (95 likely) and later linux....
Nah, no data. Too lazy to dig around. I vividly remember that in my bubble OS/2 was running everywhere. Literally everybody used it, me included. We considered Windows a joke. Some networking software that we used (Fidonet) was literally OS/2 only.
But then I remember how OS/2 was dying a slow death while Windows 95 rose.
Well, I asked, because I'm also too lazy to dig around for data. So, it's hard for me to complain...
[Edit: All right, I did a very superficial digging, and didn't get an apples-to-apples comparison. But it said that OS/2 sold 2.5 million desktop and 340,000 server versions in 1996. Windows 3.1 sold over 3 million copies within the first three months of its release in 1992. So by 1996, OS/2 may have been more popular than Windows 3.1, because the Windows world had moved on to Win95.]
IBM did a ton of consumer advertising for OS/2 while Windows 95 was delayed. (There even was an OS/2 Warp college bowl game.) So they moved some copies, but it probably mostly just people like me messing around.
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.
3 points by timonoko 85 days ago | parent | context | next [–] | on: Turbo Pascal on CP/M, MSX-DOS and MS-DOS
I wrote Pascal for 8080 in 1976 and Finnish Army even paid some money for it.
I was truly disappointed that Turbo Pascal did not copy my handy PORT-metavariable. You can write & read IO-ports without any extra hässle:
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.
You don’t even need to do that, there are plenty of IDEs that are lightweight and not web-based.
There’s just no reason to be mad that something is popular. Sure, VSCode is the most popular, if that person doesn’t like it they should just use something else.
I'm not mad that VScode is popular. I am mad at people that are not appalled by the resource use of vscode and clones, by the sluggish UI, by the abysmal security (with the latest example being the multi-billion bitcoin theft), by the walled garden that allowed a backdoored extension despite its very stated purpose... You know, all factors that a competent programmer would find important when making a choice of tools...
I’m not appalled by it because the resource use is “free.”
I already have 32GB of RAM plus an M2 Max in my laptop because my company issued it to me. I already have 32GB of RAM and a 9850X3D in my desktop because I play games.
What non-ideological motivation do I have to ration computing resources on my IDE? Even if I had an 8GB MacBook Neo, VSCode would run fine.
If I was coding on a raspberry pi my story would change (although I suspect VSCode would run fine on that, too), but I’m not so I don’t care. It’s fast enough to get the job done and the rich featureset is more important than raw performance.
>What non-ideological motivation do I have to ration computing resources on my IDE?
I feel gross explaining this.
If we both have the same exact machine, but I choose to use software that uses substantially less resources -- well -- then I get to run more of that software simultaneously.
if you use computers as some big single-tasked typewriter equivalent then yeah, who cares.
it's not all fucking style and ideology, sometimes behaviors have a decent concrete reasoning.
I don’t see a lot of Photoshop or Premiere Pro users giving up the complexity and functionality of their programs just to save on memory allocation. They aren’t saying “I’d rather use iMovie for iPad and MSPaint because it uses less RAM.”
Heavier IDEs like VSCode are making a very well-defined tradeoff between resource efficiency and functionality.
The fact that it is web-based makes extensions and design iterations more easy, and it allows it to run on more platforms including web browsers. In my opinion that is a very obviously intentional design decision.
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.
Fun times, and very formative to me!
Turbo Pascal and Broland Pascal .. the memories - we used to compete in the demo scenes in Scandinavia back in the day, and even though most of our hot paths where assembly and close to illegal instructions that would crash certain cpu steppings, we would always boot the code from .pas .. and the low hanging fruit was always pascal..
All of our competitors were mostly pure asm or c combo..
Thanks for posting that comment! Made me smile and reminisce
Broland! Thanks for the (unintended?) chuckle.
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.
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!
me too, with pointers in C, I would have been about 10 at the time, 1995 with DJGPP in DOS! I still remember that feeling when it clicked
Required reading, "Things Turbo Pascal is Smaller Than", https://prog21.dadgum.com/116.html
And: "A Personal History of Compilation Speed, Part 2" https://prog21.dadgum.com/47.html
I miss James Hague's posts - prog21 was really something else.
The experience of editing Java in Eclipse is the fast type, and it's very cool, and I suspect it's the only modern IDE that works this way. And the only reason to use Eclipse. Or Java.
One strange feature is that a function with a syntax error in it still compiles, but compiles as throw new Error("Syntax error: ..."); - I suppose this is necessary for an interactive compiler!
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.
--
[0]: https://web.archive.org/web/20040210055959/http://www.custod...
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.
> He offered three courses.
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.
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).
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.
> "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.
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 Turbo Pascal was one of my first languages. I wrote OWL code! Seeing that splash screen brought back memories. But 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.
Yeah, true, it probably helps to have grown up alongside the tech itself.
I'm not sure it was more accessible though. Learning programming back then was really hard. Nothing was user friendly and achieving even simple tasks like drawing a diagonal line might require you to sit down and learn Bresenham's Algorithm (from the books neither you nor your library had copies of, naturally...). So it was easy to get discouraged. You can get fun and relevant results much faster now.
I don't really think you need to understand the whole stack. Rather, you need to understand at least one level deeper than whatever you are using.
Back in the days of Turbo Pascal you had to know what you were looking at when the memory modified breakpoint went off and you got dumped to the assembly level. And you really had to understand it to deal with the 200mhz bug (there weren't convenient solutions at hand when I first hit it) or when I ended up making extensive modifications to the real mode support in the DPMI mode--never saw that mentioned anywhere. It was nasty--the library was fundamentally flawed and clearly had never actually been used as it declared real mode pointers as "pointer"--which had a very high chance of causing a segment error when the compiler emitted code that copied them by loading them into a segment:offset then storing them. And the debugger was flawed: in single step mode it was emulating, not executing. And the emulation would correctly "execute" an invalid segment register load.
Now, though, in C# I have yet to have any reason to look at assembly.
Sure, luckily nobody needs to understand the whole stack. I feel I do but that's just a mix of age + unusually varied projects, not necessity.
Have to admit I don't recall a 200Mhz bug, and all modern search results are about GPUs. As for DPMI, well back then I was just a kid and 640kb was enough for any kid ;) Then Windows came along and solved all that. I definitely knew what it was though because all the games used dos4gw...
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.
[1]https://tech-insider.org/discord-electron-rust-gpui-rebuild-...
>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
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:
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.
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
> GTK4
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 MESA / 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.Maybe we should also ask ourselves why modern native apps need OpenGL when you used to get by with a framebuffer. You can do more things with OpenGL but are you actually doing those things?
It's almost entirely about screen resolutions. In the Turbo Pascal era the screen probably had 640x480 pixels or 307,200 pixels in total. The screen I'm looking at now is 5120x2880 = ~14.7M pixels.
If an app is maximized it has to render ~48x more pixels per frame, probably with anti-aliased text which older systems didn't use. Doing that on the CPU is not only visibly slow in many cases, but a waste of CPU time that could be better used for actual app logic. OpenGL happens to be a convenient and portable way to get the GPU to do work for you, at the cost of some memory, so GL it is.
It doesn't render them. Framebuffer native apps back then didn't have enough memory bandwidth to change every pixel every frame either. They just changed the ones that changed. You'd probably still let the compositor use the GPU to drag windows around. They had that back then too, it was called accelerated blitting.
GL based widget toolkits only render the needed pixels too. It's good for saving battery but isn't enough by itself as it only works until the app genuinely needs to repaint the entire window. Think a text editor or IDE switching to a different file.
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.
3 MB RSS less with GTK4 4.22.4 on Debian Forky (testing).
We do have free pascal and it looks pretty good I think.
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.
I respectfully disagree. All you describe is a deeeeep reliance on who controls the models, and as the things currently trend I would say it goes more and more into a monolithic direction. Sure, you can run your local model, but hardware is so expensive that it will have many cut corners.
I also think you oversell the complexity of things to preach the superiority of a glorified text predictor
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 was told in 1969 that the Amazon was almost gone & we soon wouldn’t have enough oxygen to breathe. Humans, unlike the dinosaurs, are very resilient. Near extinction events have never occurred in human history, doubt they’d occur now. History is full of local disasters & human-created killer regimes, but only WW2 was a truly global event. And it was solved by the only country in the world with the global power to do it. If that country now needs AI to progress that’s fine with me, though I’m too old to see any of the good or bad results.
> There’s no substitute for human knowledge.
Would you not say that AI is an expression of the sum of all human knowledge? And as humans continue to generate more knowledge, it too, will be added to the AI's representation of it all?
So there's a common dichotomy in software engineering between the "big ball of mud" and "beautiful diamond" patterns. A big ball of mud is a software system that grows through accretion: it often has tangled flow control, data whales, lots of special-casing, lookup tables, and so on. It evolves, it isn't really designed. A beautiful diamond is a software system that is meticulously designed, consistent, oftentimes with tight interdependencies between how it works. Everything is efficient and easy to understand, but if you take one part out of it, it tends to fall apart. Common Lisp is a big ball of mud, Scheme is a beautiful diamond. C++ is a big ball of mud, K&R C is a beautiful diamond. Windows is a big ball of mud, BeOS is a beautiful diamond. Microsoft VSCode is a big ball of mud, Turbo Pascal is a beautiful diamond.
The big ball of mud structure is often taken to be an antipattern: at least, when I Googled this, Gemini told me it's a "haphazard, tangled anti-pattern" and gave me some advice about how to refactor such a software system into a beautiful diamond. But nearly all software systems that people actually use and maintain are big balls of mud. This is because the big ball of mud tolerates partial failure extremely well. It tolerates changing requirements very well. It tolerates parallel development very well. You can change part of it without throwing away the whole thing.
AI is a beautiful diamond. For the most part, if an AI model malfunctions, you have to blow it away and retrain it. Or I guess you can build layers to fix up the output case-by-case, but then you're really building a big ball of mud around the beautiful diamond, and obscuring it in the process.
That's a little worrisome when it comes to durability. Living, enduring systems usually end up becoming a patchwork of mud. Your ability to do this with LLMs are basically limited to LoRa patches and post-processing steps.
There's much more about humans then there is writing about them, a lot of cultures with oral histories, a lot of nuance in behavior we take for granted, can it all be digitized?
I would say your reply feels like you didn’t read beyond the first sentence of my comment.
If you did, then I apologise. But my point is about accessing that knowledge when AI isn’t available. Not about how AI discovered its corpus to begin with.
I re-read it. I think your thesis is that we ought not to depend on technology in case the infra to support it goes away. Does that capture it?
No. It’s that we shouldn’t depend on AI always being available.
Absolutely we should use all the tools at our disposal which enhances productivity. But that doesn’t mean we shouldn’t also learn how’re to do things for ourselves too.
To use a contrived example, there’s no shame in using a dishwasher. But if you cannot wash dishes by hand when the dishwasher breaks down, then you know you have problems.
> It’s that we shouldn’t depend on AI always being available.
I made the general tech-dependence statement, but it sounds like you think it is only AI tech that shouldnt' depend on. I wouldn't worry about it; humanity has proven itself to be INCREDIBLY resilient and adaptable when the things we've come to depend on go away or change materially.
We aren’t just talking about technology, we are talking about knowledge.
Like I said, I have zero issue being “AI first”. 90% of my day-to-day is using AI. But the part I objected to in the OP was “we don’t need to know things because we have AI” (to paraphrase. So I was asking the question: what if AI goes away?
I agree humans are resilient. But that’a not a good excuse for complacency.
I think open weights and local AI will distribute the knowledge across the planet, avoiding a single point of failure. All you would need is electricity and a computer. And if we have no way to access it, there will always be enough people who either have sufficient knowledge already or the hunger to rediscover things.
I think we are still a long way from that becoming an option due to the cost of hardware to run even the lower end models. But I do like this prediction of yours
I feel like having a local qwen model that could run without the internet competes with having a local searchable wikipedia. If disaster does strike, we could now recreate a lot of knowledge with a single high end pc
That already happened many times in history to many civilizations. Knowledge was discovered and lost, and rediscovered years later or never.
Yes, I hinted at that. And each time that civilisation fell. With the next occupiers of the land left to find it.
Do we really want to put ourselves in the same situation?
We are already in that situation and it's far too late to prepare for countermeasures. The only culture we're leaving behind is our garbage.
I disagree. However even if that were true, that’s more of a reason to learn more instead of less.
>I agree, but AI also there is hope!
It's like a religion isn't it.
My typo didn't help, but no. It is literally nothing like a religion.
You just gotta have faith.
Hail the Omnissiah! There is no strength in flesh, only weakness!
Or we could just ask them to build something less embarrassing?
[dead]
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.
Damn, the 90s, IRC and Quake were awesome!
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.
It was with Turbo Pascal that I started to code in earnest as a child. I am so grateful for the authors and for the friend from school who gave me a copy, and taught me Pascal.
A cool thing about TP was that it had simple and convenient support for inline assembly, which was the gateway drug for me learning more low level programming.
It’s really sad that Delphi didn’t take off like VB. It was a superior environment in every way. Faster programs, better UI, much better language, and I would argue easier to use (in VB you spent a lot of time working around the limitations of BASIC in my experience). Hard to compete with Microsoft though.
I didn’t realise at the time that, with the advent of web apps (and my interest in them), that chapter of my life would be the last time I would work with such a clean, integrated dev environment.
Delphi suffered from a lack of keeping up.
They kept jacking up the price but were many years behind on 64-bit. That said to me they were looking to extract cash, not support developers. And C# was just about as good but properly supported. And in time Microsoft closed most of the gaps.
I was using Delphi in a shop that did mixed C/C++, VB and Delphi. You'd basically rank the people based on the tool - the wizards using C++ (segfaulting all the way), boot camp folks using VB for testing and mockups, and Delphi was this weird thing also used by testers.
So here's me this Linux guy coming to a Windows shop that came from C/C++ and Turbo Pascal, loving Delphi - and I broke their brain. Naturally instead of investigating if the tool is good, they just write off the person using it. Nothing to see here!
It's one of those things that was ahead of its time (think Smalltalk / Lisp, etc). C++ obviously had (and kind of still has) its place, but Delphi could do 80% or more of that, and in radically less time, code, compile time, etc.
Check out FreePascal[1] if you want a modern compiler toolchain that's largely compatible with TP7, and Lazarus[2] if you want a modern alternative to Delphi.
[1]: https://www.freepascal.org/
[2]: https://www.lazarus-ide.org/
The best things about TP and even VB was how fast everything was to develop. When I'm sitting there watching our CI build take 45 minutes to deploy, I still remember turning around changes and copying to release file server in just a few minutes.
Yeah, and then we got a new generation amazed that Zig and Go compile fast, this how bad has gotten.
Turbo Pascal and a database add-on were part of an 80s-era text-analysis-and-generation program that was devised by lit professor Hugh Kenner and CS professor Joseph O’Rourke. I implemented that, on a single-board-computer running a CP/M derivative called (IIRC) Z-System, and I had a great deal of fun playing with it.
Some years later, I worked it into a commentary on generative AI that I wrote for Fast Company. My article mentions James Joyce, because the original BYTE article did. My piece omitted to add that my experiments also included mixing Henry James with a spot of Victorian porn.
I enjoyed being reminded of all of that by the Turbo Pascal piece.
Fast Company piece (from September 2022, before the release of ChatGPT): https://www.fastcompany.com/90784449/machine-writing-is-beco...
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.
According to Kahn, in this enjoyable read from a year later, at https://archive.org/details/micro-cornucopia-magazine-1984-1... .
> 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?... .
Anyone remember Turbo Pascal DiskTutor? My older brother bought that for me for my birthday and I used it to learn object oriented programming. This was DOS still.
I used Turbo Pascal in 8th grade to create a simple type of 3d wireframe CAD-like tool on the PC in my bedroom.
Then in AP Computer Science in high school we had (TUI) Turbo Pascal also.
I always remember that type/style of TUI fondly. It periodically pops up in my head out of nowhere. Like just yesterday I randomly decided to add a Borland-style menu to my Starship prompt as an experiment. I accomplished that by writing about two sentences to an AI.
My actual job at this point is feeding tasks into AI and judging whether it answered just the way I wanted.
tcc/tinycc doesn't have the IDE but is the same compiler approach applied to modern(ish) C. Tiny, fast, and fun to use.
If you ever feel like you need a palate cleanser after reading AI code, go dig into any Fabrice Bellard project.
My very first professional gig, in the mid-1980s, was extending a classified ads application that was used by telephone operators in teh days when you could call a newspaper or magazine and dictate your ad over the phone.
It was written in TurboPascal and saved its data with BTrieve. The whole thing ran under MP/M (a CP/M variant that had the concurrency support we needed) on a closely coupled network: A box with an S-100 bus where each user had their own system-on-a-card with an 8088 CPU. Our application wasn't client-server, each user had their own app and we had written our own code for network-based cooperative multitasking, as we called it in those early days.
Fifteen years later I was on a team that created a concurrency linter for Java. It inspected the behaviour of running J2EE servers and flagged runtime anti-patterns as concurrency smells to be investigated.
Everything felt so familiar, despite all of the tooling being complete different!
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.
Is Turbo Pascal 7 really the same as Turbo Pascal for Windows 1.5?
I think I used TP 7 and it was the usual blue IDE for DOS.
Not at all, Turbo Pascal for Windows 1.5 was an intermediate release between Turbo Pascal 6 and 7.
Although Turbo Pascal 7 has MS-DOS extenders support, and could target Windows 3.1 as well.
Then came Delphi.
Thanks! Seems like my memories didn't fool me.
I used Borland OWL under Windows at school. I moved to Java later on and felt the sting on the last line...
> 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"!
There was that “Turbo” button on my (self-made) 386sx, that magically doubled the CPU clock. This is what “turbo” meant in the 90s, weird.
Yeah a lot of them had that turbo button. I always thought it was kind of a Spinal Tap thing.
"Why don't you just run it at the faster speed all the time, and make that the regular speed?"
"Ours have turbo"
For those who don't remember, the turbo button existed as a backwards compatibility hack. A lot of games in the early days did dumb stuff like implement game timing loops by spinning the CPU, because devs just didn't think ahead to "what if people play my game on hardware that doesn't exist yet". So when the first big leaps in clock speed came out, some games ran unplayably fast. The fix was a literal button on the front of the machine that controlled the clock speed.
Devs learned how to use the timer chips pretty fast after that though, so for a long time the turbo button existed but appeared to be useless. Pushing it would toggle a light but nothing appeared to change.
And it was inconsistent between vendors whether light on meant fast or light on meant slow.
Turbo Boost. Intel still talks about it on their website: https://www.intel.com/content/www/us/en/gaming/resources/tur...
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.
Not sure it's fair to say they made then unergonomic in some deliberate or neglectful way. Just that Turbo Pascal was a remarkable program.
From the article:
> If there had been a ‘Turbo Pascal for Linux’ in the early 90s, then we might all be running Linux on our desktops today.
I was about 15 when a school friend and I spent entire days writing simple video games in Turbo Pascal. That experience is what got me into programming, and it became foundational for my entire career. I still look back at those days with a big smile.
> That almost nobody has the skills these days to implement something like TP is something we could eventually come to regret
Almost nobody back then had the skills to implement something like TP, that's why it was so exceptional.
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.
> (Turbo) Pascal eventually gave way to Delphi which, despite its technical merits, never had the same impact.
Not sure I can agree with this. My time with TP7 was fledgling, Delphi was my first "professional" language. Over the years since, I still get cold-called and -emailed from recruiters who would do anything but pay for a Delphi developer.
An interesting parallel with NT: Dave Cutler was hired by MS to replicate his success with VMS and built NT.
Likewise, Anders Hejlsberg was hired by MS to replicate his success with Delphi and built C#.
I think that's pretty impactful.
Some of my first experiences with programming are being completely baffled by a TP6 book I got from my much older nephew, and using Delphi in high school for my final project.
And rich to see the Pascal guy complaining that VB made programming too accessible, the same complaint was made about Pascal in the early 80s. Just look for the article "Real programmers don't use Pascal" :).
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 missed out on Turbo Pascal for Windows — I had moved on to mostly Mac development by then, and by the time I started working on Windows again, Visual C++ was firmly entrenched, my employer was a C/C++ shop, and I was comfortable with C++ from the Mac — but I was a big fan of Turbo Pascal for DOS (and Apple's Object Pascal on the 68k Mac).
Man, I have so many good memories as 9 or 10 year old kid writing Turbo Pascal 7.
The terminal IDE that it came with, if you can call it that, was ahead of its time.
> TP 7, also known as Turbo Pascal for Windows 1.5
I'm pretty sure Turbo Pascal 7 and Turbo Pascal for Windows were two different products.
They very much were. There might have been another product, TP 7 Professional, in the middle there as well, with a bundled assembler, debugger and profiler. Not sure about that one, but that’s how they did it with some of the earlier versions, before Borland Pascal for Windows was a thing.
"...it can’t produce code that runs on modern Windows systems, and few people have much interest in early Windows."
This final version for Windows 3.1 might be compatible with 32-bit Windows installations under WoW16, no?
Windows 11 was the first version to ship that was 64-bit only.
Maybe unfair, but at the time I had to do a project in Turbo Pascal. Up 'till then I had been using Think Pascal on the Mac. There was no comparison. I felt like I was trown back a decade. Not that the raw capability was that different, but boy, the UX. I hated it.
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.
> Windows 3.1 [] not that there were many alternatives at that time
OS/2 was more popular than Windows 3.1.
Update: or maybe it wasn't. Seems like different bubbles had different mainstream OS.
Oh man, the good old days. Running Windows apps in OS/2 and having OS/2 run them faster because it was true 32bit.
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
Source? That's sure not the way I remember it. I don't think I ever saw OS/2 outside of in computer stores. I don't think I ever saw a single customer actually using it, either professionally or on a home computer.
Sure, that's anecdote. Do you have data?
OS/2 was somewhat popular in corporate settings that were already "IBM shops." And I saw a bit of it in academia/scientific workplaces.
Never knew anyone who ran it at home.
I ran it at home as a teenager, as I got a free Warp cd at a store (when they cancelled the product). Ran it for a few days, then went back to windows (95 likely) and later linux....
Nah, no data. Too lazy to dig around. I vividly remember that in my bubble OS/2 was running everywhere. Literally everybody used it, me included. We considered Windows a joke. Some networking software that we used (Fidonet) was literally OS/2 only.
But then I remember how OS/2 was dying a slow death while Windows 95 rose.
So yes, an anecdote it is.
Well, I asked, because I'm also too lazy to dig around for data. So, it's hard for me to complain...
[Edit: All right, I did a very superficial digging, and didn't get an apples-to-apples comparison. But it said that OS/2 sold 2.5 million desktop and 340,000 server versions in 1996. Windows 3.1 sold over 3 million copies within the first three months of its release in 1992. So by 1996, OS/2 may have been more popular than Windows 3.1, because the Windows world had moved on to Win95.]
IBM did a ton of consumer advertising for OS/2 while Windows 95 was delayed. (There even was an OS/2 Warp college bowl game.) So they moved some copies, but it probably mostly just people like me messing around.
It certainly wasn't in Europe, plus it required more expensive hardware.
Back in 1992, it would had cost me about an extra 500 euros on today's money.
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.
Hindsight is 20/20 though
great writeup, fun reminder windows 3.1 sat on top of dos
TP 7 you say?? That's the one that made me quit - they could pry the blue ascii IDE out of my cold, dead (high schooler) hands
TPC.EXE /C
never forget
3 points by timonoko 85 days ago | parent | context | next [–] | on: Turbo Pascal on CP/M, MSX-DOS and MS-DOS
I wrote Pascal for 8080 in 1976 and Finnish Army even paid some money for it. I was truly disappointed that Turbo Pascal did not copy my handy PORT-metavariable. You can write & read IO-ports without any extra hässle:
https://photos.app.goo.gl/qeJpYb94XzLBCE139
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.
You don’t even need to do that, there are plenty of IDEs that are lightweight and not web-based.
There’s just no reason to be mad that something is popular. Sure, VSCode is the most popular, if that person doesn’t like it they should just use something else.
I'm not mad that VScode is popular. I am mad at people that are not appalled by the resource use of vscode and clones, by the sluggish UI, by the abysmal security (with the latest example being the multi-billion bitcoin theft), by the walled garden that allowed a backdoored extension despite its very stated purpose... You know, all factors that a competent programmer would find important when making a choice of tools...
I’m not appalled by it because the resource use is “free.”
I already have 32GB of RAM plus an M2 Max in my laptop because my company issued it to me. I already have 32GB of RAM and a 9850X3D in my desktop because I play games.
What non-ideological motivation do I have to ration computing resources on my IDE? Even if I had an 8GB MacBook Neo, VSCode would run fine.
If I was coding on a raspberry pi my story would change (although I suspect VSCode would run fine on that, too), but I’m not so I don’t care. It’s fast enough to get the job done and the rich featureset is more important than raw performance.
>What non-ideological motivation do I have to ration computing resources on my IDE?
I feel gross explaining this.
If we both have the same exact machine, but I choose to use software that uses substantially less resources -- well -- then I get to run more of that software simultaneously.
if you use computers as some big single-tasked typewriter equivalent then yeah, who cares.
it's not all fucking style and ideology, sometimes behaviors have a decent concrete reasoning.
I don’t see a lot of Photoshop or Premiere Pro users giving up the complexity and functionality of their programs just to save on memory allocation. They aren’t saying “I’d rather use iMovie for iPad and MSPaint because it uses less RAM.”
Heavier IDEs like VSCode are making a very well-defined tradeoff between resource efficiency and functionality.
The fact that it is web-based makes extensions and design iterations more easy, and it allows it to run on more platforms including web browsers. In my opinion that is a very obviously intentional design decision.
Two things.
One: A very many programmers have their tools selected by their jobs, not their own choices.
Two: There are very few competent programmers.
I have learned PC programming on the DOS version.
[flagged]
[dead]