They don't make 'em like that any more: Borland Turbo Pascal 7
kevinboone.me
kevinboone.me
Ah, those were the days! TP v4, v5, v6... i'd graduated to C by the time 7 came out.
> 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.
If anything, the rise (read as: shoving-down-our-throats) of AI/machine learning will hurt the collective ability to code, rather than compensate for it in the least. So many modern developers take pride in using their CoPilots and related AI/machine-learning tools to assist in coding, all the while ignoring that such usage actively keeps them from improving their own coding skills, in the same way that copying a classmate's test answers might let the copier pass the test without actually teaching them anything.
When that day comes that AI can pump out a complete, working, bug-free application based on natural-language descriptions, we will have lost the ability to code entirely, as any code such a thing generates will never be maintainable by a mere human being.
_Sigh_.
Well, it'll be fun while it lasts. The Machines can pry my makefiles and C compiler from my cold dead fingers.
PS: _GET OFF MY LAWN!_
Mee too, and it is painful to realize how much ahead of its time the IDE was. I am talking about the TUI version and yet:
- It already supported a dual monitor setup - one monitor for the IDE, one for the app - live debugging was a charm.
- The debugger had everything current debuggers have, but it was fully IDE integrated - no messin' with GDB or JDWP.
- The context sensitive help was the best, I never encountered a better one. I think a large part of it was that it really was context sensitive and it tried to solve the problem at hand, regardless if it was caused by the IDE or the language.
I've never seen C as an improvement. Macros encourage all too clever code that's impossible to parse at first glance. The string handling is horrible. The fact that there are multiple contradictory ways to express pointers.
The only thing holding Free Pascal/Lazarus back is the documentation. There's no way to work on a small part of it, Wiki style, so it's always going to be an albatross. The auto-generated descriptions of variables used in library function calls just don't work as proper documentation.
On the plus side, it's fast and has all of the linking built in. You can stuff gigabytes of binary in strings and never have to allocate anything. It does object oriented stuff, generics, is strongly typed. It can spit out code for almost any platform, including WASM, Android, etc.
You sound like Socrates lamenting that the invention of writing is hurting people's collective ability to think, since their brains no longer need to hold many things simultaneously.
There's a tremendous difference between writing and having someone else write for you.
That said the current crop of AI isn't that and is overhyped.
I may be a luddite about it but I'm also not entirely wrong. That said, I'm sure the same was said about code generators and other features introduced by IDEs, like syntax highlighting.
That's an opinion not a fact backed by any data.
In fact it feels like "you hurt your hacking skills by using an IDE rather than a simple text editor, or higher level language than assembly, or managing your memory manually rather than using GCs".
Also, maybe coding skills will become more and more irrelevant for most developers the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry.
In fact, if AI assistants will keep getting better, the best skills to have will be ability to direct those assistants and overseeing their output while meeting business and product needs.
It's a well-demonstrated fact that, for the overwhelmingly large majority of people (mainly those without eidetic memory), copying someone else's answers, rather than coming up with them by applying one's own problem-solving skills, hurts one's ability to advance their own related knowledge/skills. There's a _reason_ we're taught not to cheat in school.
This is not true. A large part of the industry just _thinks_ these things aren't relevant to them and that's why we have such terrible software everywhere.
In my industry experience software is slow because:
- time to market is overwhelmingly more important than performance so the pressure is to have something that works, not something that works smoothly. You can fix performance or bugs later (Notion is an easy example of such evolution).
- the industry keeps being largely understaffed so finding resources to allocate to performance is hard
- most of the industry is managed by people that are neither good at product nor tech, but think they understand products and tech
The fourth thing is that it lives on as Delphi:
https://www.embarcadero.com/products/delphi
And there's Free Pascal and Lazarus. One of the goals of Free Pascal is to be Turbo Pascal and Delphi compatible:
A video of their control center with English subtitles: https://www.youtube.com/watch?v=u9SGsxauu7o
Regrettably, Delphi is closer to a zombie now than to something that's alive.
In the early 1980s there was a push for “anything but BASIC” for teaching languages. Before TP, in my mind PASCAL had the stink of failure between the watching-protons-decay slowness of UCSD Pascal and the inadequacy of ISO Pascal to do anything but solve leetcode problems.
C on the other hand accomplished what PL/I had set out to do in a “worse is better” way. TP added enough of what ISO Pascal was lacking to be fine for systems and applications work like C but it was saner, didn’t have the null terminated strings which made strcpy() + a later return Turing complete in C.
TP felt just a little more disciplined than C, like a pop version of Ada.
Asked because it's gotten me a few times.
If you were actually a professional programmer in pre-internet days (as I was) I don't think you would have any nostalgia for it.
A younger self used to look forward to the latest (paper) shareware catalogue arriving by (snail) mail, posting back the order form and waiting for the floppies to arrive. True story :-)
We were definitely more productive. An order of magnitude more. As long as you picked appropriate tools. For example, I wrote a whole statistical analysis package in month (VB4). An ERP package in 6 months (access).
Code quality, which is difficult to objectively measure, was not really a problem.
Today I can barely even find a consistent UI toolkit which doesn’t fall to pieces, doesn’t require a server to run and doesn’t pull in 200 meg of untrusted JavaScript.
But there's something valuable in figuring stuff out by yourself, I wouldn't trade that experience for anything.
Again, anyone who was actually a programmer back then and is now today would never have nostalgia for those days. It was not better before.
Yeah, but figure what out? How to get wildly complicated thing A to talk to over-engineered piece of crap B, most likely.
Hit F1 on some bit of code and instantly see help on the keyword, very quickly find stuff via the index etc.
"People" here meaning Anders Hejlsberg almost single-handedly.
Honorable mention to DHH, although he didn't create a programming language. And also to Lars Bak for being the lead developer on V8.
Interesting take.
I am not even sure I agree, but in some contexts this may be true.
I think -- and indeed hope -- it's a temporary local thing and will pass.
Of course, the “heap of temporary files” is itself originally an adaptation for low main memory. The genius of Turbo Pascal is exactly that on those early PCs main memory was large enough / mass storage was small enough that for the program sizes in question the architecture of many passes communicating via disk files just wasn’t worth it. As far as I know, that was never true on minicomputers that our compiler tech was born on, and it’s very much not true on PCs now. (Consider: DOS machines had 100s of K to perhaps 4M of RAM and a couple megs to several dozen megs of floppy or disk, amounting to a proportion of perhaps 1:20. The laptop I’m typing this on has 4×10¹² bytes of mass storage and 64G bytes of RAM, a ratio of about 1:60, and I specifically made sure to get an abnormally large amount of RAM.)
More generally, though, screens and syntax trees.
First, a laptop screen that an 19th century book printer wouldn’t call an atrocity against the art (say 200ppi and above), at 32 bpp, takes ~16 MB for a single framebuffer. At 60 Hz, that means your display panel interface is already pushing 750 MB/s of useful data (and I’m ignoring all the legacy cruft like overscan and vblank). Unsurprisingly, the GPU that does all that, for multiple layers, in floating point (so 96 or 128 bpp), is heavily pipelined. Feeding that pipeline adequately and without heroics means at least a length-3 swapchain, so already you have 48 MB of screen buffers for any full-screen app that you don’t need to wait to redraw after you switch to it (remember when we needed to do that?). If said app is showing something large and scrollable, and you count on being able to see the thing you’re scrolling (remember when you couldn’t? thank touch input for killing that), that’s probably also, what, three, four screens’ worth of prerendered tiles? And now we’re already pushing a hundred megs—just for the pixels. How many browser tabs do you have open? (Personally, I get really irritated when my browser gets an attention deficit and doesn’t immediately show me the tab after I click on it.) Or thousand-page PDF specs?
(I was recently installing an old version of Windows in QEMU, and the installer showed me the installation wizard’s window—with all the text and controls—first and then spent multiple seconds blitting a purely frivolous graphic of a computer with installation disks around it onto the left pane. I didn’t remember computers used to do that! At least until you got around to installing the graphics driver, anyway, I guess.)
Second, I’ve been mulling over a Web browser’s job, and I can’t help but conclude that it’s really bloody awful.
The existence of the mutable DOM means it has to maintain a full-fat syntax tree for all the HTML—a humongous soup of pointers in a 64-bit address space (so in modern browsers they are hand-rolled 32-bit not-really-pointers). On top of that it needs to have an acceleration structure for style recomputation accessed on the critical user interaction path (because :hover), as well as a layout tree with line boxes supporting dynamic Unicode- (even BiDi-) aware line breaking and perhaps even hyphenation on resize, and none of that should fall over if you load up War and Peace in the original Russian+French with the paragraph breaks deleted.
It’s old compiler lore that no syntax tree will be as compact as the source code it was constructed from. Browsers sound like the bottommost circle of syntax tree hell even more than a general GUI has to be. The situation is probably salvageable with a flattened representation like the one Jetpack Compose uses and differential execution[1] used before it. But it’s definitely a lot of work, and to my admittedly cursory knowledge noöne’s really working on it.
(This part inspired by the urge to clutch my pearls that I felt while watching Andreas Kling’s Ladybird videos—there’s a lot of very thicc pointer soup in there, and I don’t think it’s possible to morph it into something saner in a continuous fashion. But then I thought about the problem, and yeah, the problem sucks.)
So all in all I think single-digit gigs sound about fair, I think, and that’s how much my system typically shows when I’m not deliberately running heavy stuff on it.
(For what it’s worth, I once spent weeks cramming all data required for Unicode normalization into about 20K. It’s certainly possible, but as it turns out, three iterations of fetch-shift-popcount for every character is slow. Not “why do I need to wait for my computer” slow, but definitely “why does my computer’s SSD have to wait for its CPU” slow.)
[1] https://stackoverflow.com/questions/4445656/what-is-differen...
Pascal at that time was like Ruby or something is today. Definitely widely used but a far distant to the incredibly dominant C. There's no way to explain to folks today how dominant C was back then. If you were a software engineer learning C was just a given. You may or may not have bothered with BASIC, you may or may not be comfortable getting down to Assembly, but if you were serious about coding, you knew C.
TP had little impact on Windows, I agree. TP was for a particular niche, small software shops targeting DOS. And it was a big success, it paid for a nice building in Scotts Valley, but it also fuelled the ambitions of a bunch of executives who got derailed, getting into databases, a multi-pronged bet (Paradox, dBASE, Interbase) that didn't really pay off.
And at about the same time they also tried doing a native Delphi for Linux, which was so bad they pulled out after 3 versions and never tried Linux again until recently (and even then, you can only cross-compile, you can't run Delphi 12 on Linux or macOS).
And they also tried getting into the VCS sphere with StarTeam (which somehow still received updates well into 2017... Despite it being made in 1995). I don't know why OpenText decided to buy it in 2023.
Let's not forget about Turbo Prolog and the time they almost did a Turbo Modula-2, but it was actually published by TopSpeed and now lives in Clarion. Ugh.
Borland... Err, Inprise... Err, Embarcadero... Or CodeGear? Or Idera? Who keeps count? Anyway, that switched so many hands it's sad to see. They were doing way too much. A lot of bad decisions made them less and less popular (not like their current greed is helping their case). Oh well. Long live Free Pascal.
I think this is fundamentally the same toxic thinking that is still with us today.
C offered no actual advantages over Turbo Pascal for DOS/Windows programming. I'm sure one can come up with platforms or releases that weren't supported by TP, since C was the defacto standard. Regardless, they're fundamentally equivalent.
Meanwhile, Turbo Pascal was blazingly fast compared to C. The C linker in particular used to take forever. Turbo Pascal was seen as a toy language. My AP Computer Science exam results were disregarded by colleges because it was in Pascal.
A few years later, I was a C++ snob and looked down on Visual Basic "macro hackers". Meanwhile, at least one true genius electrical engineer I worked with would rapidly prototype software in VB that would take me weeks to replicate in C++.
There's a weird disdain in software development for approachable, efficient tools that create actual business value.
For software like neovim and gdb, it could help a lot with discoverability.
The missing TurboPascal-like menus are the main thing I was trying to point out.
Fun fact: this lived on in Delphi, TP's successor. The TBitBtn component, a button with an image and one of the oldest Delphi components (probably from Delphi 1?), has a Kind property that auto-sets all sorts of glyphs; Kind := bkOk sets it to a green check.
About a year ago the glyph was updated to look a little more modern :) But it lives on. I love occasionally seeing it on apps in the wild.
As the name implies, it's indeed TURBO. I mean, to achive similar snapiness when running Eclipse or VS, you'll need pretty powerful machine.
The legacy is carried on by Free Pascal folks (there's the text based IDE). I only use this for fun/nostalgia purpose. For actual work, well there's Lazarus IDE.
I don’t think that’s true. Percentage-wise, the number may have dropped, but there are many more programmers now than there were back then.
I even am not convinced that percentage is lower today. There are plenty of people in the demo scene who, if incentivized, could write something like it.
You also have to realize that TP 7 is relatively simple compared to today’s development environments. To mention a few items:
- pascal is a lot easier for an IDE than C
- no messing with character encodings
- the editor may be fast, but does it stay fast when confronted with very large files?
- TP need not be cross-platform
Microsoft has shown MIT to be a good standard under which to license retro software from DOS to Windows file manager.
I mean we are in 2024 and should be well past the Java joke. Not only is modern Java seriously fast and could be efficient as well as natively compiled with Graal. ( Where 20 years ago GCJ was experimental at best ). The modern equivalent should really be Electron.
But back on the topic, I really miss Pascal and Delphi.
As an Android dev, I still see complaints (most likely by beginners) saying how Android Studio consumes much RAM and asking if it's possible to replace it with.. VSCode. I still remember doing Android development using Eclipse on a 2 GB PC and it was reasonably okay-ish. Of course it's practically impossible to use Android Studio on such machine. 8 GB is bare minimum.
:D
Even after installing some plugins, Eclipse ran faster, and thus become my primary IDE. I kinda miss Eclipse. On the other side, seems like most Java dev nowadays already switch to IntelliJ.
Java: bloated behemoth, destroying efficient native apps. Javscript: neat little thing for scripting web pages.
[Fast forward 30y]
Java: neat little thing, near native.
Javascript: bloated behemoth, destroying native apps.