That an app 'Fits on a Floppy' is still a useful measure in 2026 If you're old enough, you might remember using floppy disks, either of the 3.5-inch or 5.25-inch variety. They didn't hold much and often you had to have many disks to install one program. Don't be misled by Fits on a Floppy's retro-tech name: it is most definitely not about 20th century data media. It's about compactness and …
I used to use Freesco - a whole router \ firewall package on a single floppy disk aimed at scrap hardware with two NICs
https://freesco.org
I still support a client who has part of the accounts department running on an old DOS app written in 1988...
When I look at the size of some web pages as they load up data bloat has got out of hand.
Isn't there this webpage...
..
ah, yes: https://justfuckingusehtml.com/
Plus (in general) stop using bloated pictures that have no meaning and just "look nice", they add no value and create the need to scroll. And don't get me started on the "zoom in" that happens when your mouse crosses that picture. Just give me the text you wrote, thanks, informative, loved reading it.
-- stop using bloated pictures that have no meaning --
OK you just hit my RANT button. So many websites (especially the beeb) have taken on board the adage that "a picture is worth a thousand words" and ignored the point that the picture has to have some relevance otherwise you might just as well take a thousand words at random from a dictionary. Hmm that might be better since it wouldn't take as much space unless you found some very long words!
> The guy retired from editing it over a decade ago
The guy retires from a project that is useful to you? Take up the slack yourself!*
* not a coder? "Taking up slack" can include publicising the need for coders on this project. The guy even gave warning on the site that this was needed!
> Stick it in the abandonware box
How dare he be unable to support you for free forever! He has abandoned poor little you.
I still remember 8" floppies! Fixed a good few 8" floppy drives in my time too.
With every release of Windows, the computer it was installed on was twice as fast as the previous one, but no installation of Windows ever felt faster than the previous one.
Modern applications are layer upon layer upon layer of APIs, frameworks, libraries and abstractions. The theory was that all these layers let you write more reliable code more quickly. Nobody ever bothered thinking about whether this was a good idea or not. I've certainly not seen any increase in reliability over the decades. Most programmers today have zero idea about how the code they write actually runs on the computer - this leads to exactly the problems which come from treating memory and CPU cycles as an inexhaustible resource.
Also an early example of a fidget toy - held between thumb and middle finger, leaving the side of the shutter nicely within reach of my index finger, allowing it to be slid open and then let it go with a satisfying click, to be repeated as often as required during a late night coding session in front of my Amiga...
I'm convinced all the various sensory feedback (the sounds, the tactile sensations, even occasionally the smells) provided by these earlier systems is one of the reasons why we now look back on them so fondly in comparison to the rather more sterile and anonymous systems we have these days. I mean, sure, I love the performance improvements things like SSDs have brought to the table, but I also find myself sometimes missing the way my older HDD based systems would sound and feel depending on what level of drive activity was taking place, and as for the very satisfying sensation of pushing a floppy or Zip disc into the drive slot, or a cassette into a tape deck, nothing about a modern system comes even remotely close.
Upvote because every so often my underpowered Linux machine freezes for a while (fiddling with memory paging no doubt), but there's no HD light, there's no chk-chk-fvs-chk, there's nothing. I kind of miss the reassuring "I'm busy, hang on a mo" noises that Windows did far too frequently.
> Only you can decide if the (usually minimal) CPU overhead is worth the experience
Do it in hardware!
The signals* are still there, Maplins may be gone but you can harvest LEDs from Poundland lights.
* SSD in m.2 you say? Just look how small this drill bit is, now, you have a steadier hand than me...
Modern applications are layer upon layer upon layer of APIs, frameworks, libraries and abstractions. The theory was that all these layers let you write more reliable code more quickly.
All pretty much right in principle but you need to have the right abstractions and interfaces — which requires enormous effort, experience, insight, imagination and creativity to define. Of course this is where of whole ediface collapses into a pile of a confusion of mismatched interfaces, incomplete or inadequate abstractions and mindless complexity. A decent serving of premature optimisation is invariably on this dismal menu of frustration.
You beat me to the punch.
Hell, I still have an 8" Wang. It's amount of memory is close to what I have in my head. :-)
On topic: Yes, today's code is soooooo bloated. Has anyone played code golf lately? I know it's an esoteric exercise and the language can get... strange. But the point is to keep on topic, keep it simple, and keep it smart. I'm not suggesting that everyone go back to Assembly, but it seems that the languages and dev spaces have become too heavy for their own good. Am I just too old? See the Wang reference above, I suppose.
The article talks about "unnecessary complication and plain old marketing" which is undoubtedly a driving force in why we are where we are: new, shiny, misunderstood - if not outright deceptive. If it's different, it's gotta be better, right?
FWIW, I shoot a proud 120 on the green grass of 18 holes these days. IRL.
I picked the 8" floppies for my OSI computer because they could hold 275K of data compared to the 90K(?) the 5" single sided drives could do. I didn't trust the new fangled dual sided drives. They were reported to be less reliable.
I wonder if the MS basic is still readable on those 8" floppies? ;-) I have the computer, but the -9V supply had gotten flaky.
If you're old enough, you might remember using floppy disks, either of the 3.5-inch or 5.25-inch variety
I'm old enough to have used 8" floppies! Upgrading VAX/VMS using dozens of the darn things was a pain in the proverbial until they started providing us with the distribution media on mag tape.
It was surprising what you could do on a twin* floppy machine, there was a viable CAD program that would run off A: with data on B:
*Or even a single drive as DOS would simply prompt to swap between A: and B:
As a kid I coded a game for the ZX Spectrum in Assembler and won a prize from a magazine. They then put me in contact with a professional coder to help reduce my code for 16Kb as it was not even 1 Kb over it and together we made it just that bit smaller so the magazine could publish it to be played in both the 48Kb and the 16Kb models. A lesson I learned then was that efficient ways to do some things are generally (but not always) the simplest and using the least instructions :)
This was done on a Beeb game, sticking some code into a blank bit in the middle of the screen and when the screen scanning reached that part, fiddling the palette so all the colours were the same. It's kind of insane, but it's the right sort of insane that got something like seven colours in a four colour screen mode...
Exile on the Electron didn't bother to fiddle the palette to hide it, or maybe it couldn't be done.
I coded the Nokia 2210 noise reduction and echo removal functions in assembler. Every route through the filters had to take exactly the same number of cycles so there was no jitter. I managed it without a single NOP, (but some routes were optimised much more vigorously than others to achieve this hard requirement.)
"Atari ST User" magazine had a feature for readers to send in useful snippets of code in 5 lines of code. £25 paid for contributions that were published. You were required to send in a stamped self-addressed envelope for the return of the diskette. I didn't include that - they published my contribution (5 lines of ST BASIC), and NEVER paid me either. I think the cover price of the magazine was about £2 at the time - I still have a copy of it :-(
The money would have gone half way for the GFA BASIC that I bought not long after - the interpreter first, then the optional compiler.
Mark Williams Company's "Let's C" was a complete professional caliber C development environment for the IBM PC. At $179, it even came with an early IDE (a slightly hacked variation of MicroEMACS). Coded almost entirely in assembler, was it tiny ... You could fit the whole thing, including compiler, assembler, linker, libraries, IDE, etc. on a single, DOS-bootable 1.44 floppy. If you needed it, you could fit csd, their C source debugger, and a small inline help system, onto a second floppy along with your project files.
In other news, I do an annual cleaning & adjusting (if needed) of a couple of 8" floppy drives that have been in near daily use since the late 1970s. They are attached to a couple pieces of equipment at a machine shop located in SillyConValley. I've replaced the read/write heads, the motors and other parts[0] a couple times each with NOS[1] parts that I squirreled away in the '90s .... sometimes being a packrat helps pay the bills. The same company also has machines that use paper/mylar punch tape, which to date have not required any adjustment, just cleaning. The last of the Hollerith card gear was retired about a year ago.
[0] We started calling them "Theseus's Floppy Drives" nearly three decades ago.
[1] New Old Stock ... brand new original box product that's been on the shelf for a while.
Yesterday I found the zip of the Dave Moore FTL Modula2 v1.1 compiler for MSDOS that I purchased as two 360k 5¼" floppies and spiral bound manual (sold in a clipseal sandwich bag.)
One floppy was for the library and example sources (in Modula2 and assembler); the other the code editor (à la wordstar non document mode)/primitive IDE, the compiler, assembler, linker, debugger, libraries, etc.
The CP/M-80 versions are littered over the internet but I haven't seen the MSDOS version.
My first real C compiler was Walter Bright's Datalight C was just as small including the MSDOS runtime and library sources.
Once CDROMs became reasonably common the software obesity epidemic really started.
Details long since evaporated from the grey cells but a good long time ago I think it must have been this very organ the article itself and then readers came up with a single line of code to do something which I also forget. I was more than a little impressed as readers one after the other chipped away at what was already minuscule to reach a stage where you could easily count the number of characters (including punctuation marks, naturally). Those were the days, and it shows that as with any profession only experts know what they are doing. The rest muddle along and hope for the best (and then relied on Intel to speed it all up).
It was a point of pride amongst a certain class of APL programmer to get all the code for a simple-ish programme onto one line. The result, though was what came to be known as write-only code: even the author couldn't easily tell why it worked after but a few months from writing it.
I remember one instance in which I cheated - I used the line separater character (MicroAPL) to create a "function on one line" I swear the interpreter cried a bit when it reached the line. It gulped but then it ran pretty fast. The line was basically a loop so I needed it to run well otherwise I'd have been waiting a long time for the program to finish. It was something to do with either financial reporting or fleet management - can't remember at this distance in time.
Does Janet have a mother (or possibly grandmother) with the same name?
I'm pretty sure I was learning programming in school using the Janet language round about 1972. I think there was a Joint Academic NETwork in use in the UK back then. The language we were using was very like BASIC, but I thought it was called Janet.
I have occasionally looked for info about it over the years but never found anything. Maybe it was BASIC after all?
Then we progressed onto FORTRAN. No floppies involved. Hollerith Cards, paper tape and fan fold paper.
Kids today!
"if you impose an artificial limit on project size"
For those of us working in sectors where these limits are entirely real, and where failing to adhere to them means your code literally cannot run at all, so much of the sentiment here isn't just wistful longing for the good old days, it remains an utterly integral and essential part of our everyday lives.
Right now I have the relative luxury of developing code to run on an ARM core microcontroller with a positively expansive 512KB of non-volatile storage, and an equally impressive 128KB of SRAM. By the standards even of an old school PC, such figures would sound laughably small, yet this is a far from atypical level of memory/storage resource limits that modern embedded systems developers work with. And note how I've described this particular device as being quite spacious, because compared with many of the other devices also currently available, it genuinely is. Another project I'm currently involved with uses a device with 16KB storage/2KB SRAM, and even that is an order of magnitude bigger than the most constrained of devices I've worked with so far.
So yes, as someone who not only remembers how efficient old school desktop code used to be across the myriad of systems I had experience with back then, but who is constantly reminded how much can *still* be done with some efficiently written code, I'm absolutely onboard with any and all criticism of how little effort is now paid to writing stuff that takes full advantage of the hardware capabilities for the good of the end user, as opposed to taking full advantage of it for the benefit of the coder - i.e. allowing them to write underoptimised crap that only runs as adequately as it does because of how much raw power the host system is able to throw at it.
Those were the days...
They still are :)
I am tinkering with ESP32 microcontrollers where the available program size is similar to the BBC micro's 5 1/4" floppies (~340KB).
OK, the IDE takes up a lot more, but the end result is that the programs will fit on a (really old, single sided) floppy.
Drives that rattled as they started, and positively chugged in a way that power metal can only dream of. Plus all sorts of fun like "this disc has one hole but this disc has loads" or "inserting this the wrong way up is a world ending scenario" (apparently there was some sort of felt stuff inside and it wouldn't stand being rubbed the wrong way and would cause bad things to happen). Oh, and that drive that would align itself by slamming the head into the end stop with more gusto than a DeskJet 500 (that did much the same thing).
Three and a half inch was absolutely tame and civilised in comparison.
Hmm.
-rwxrwxr-x 1 cg cg 1576672 May 22 11:04 zedc*
Yep, it still fits on a floppy. Dunno how much of it is error message text. Of course you need "header" files and libraries to compile and link most stuff.
I recall the "good old days" when I was writing my "Amelon" game for my "Explore" game system. I eventually ended up having to shrink the names of many symbols, both in the Draco compiler and in my Explore driver, so that I could link the game driver with the Amelon code into something that fit in memory. Pushed things quite a ways, but it was a very satisfactory thing to do. This was on CP/M, with something like 8K of address space stolen for the graphics card.
The game display had a "grid" mode which was an overhead scrolling view of terrain, etc., along with a "maze" view, which was a line-drawn 3-D view of passages, etc. Ported it to the Amiga for better imagery, including moving water affects. No, neither version was ever publically released. And yes, the CP/M version was on 8-inch floppies - one for Draco and tools, one for the Explore system or world.
Wasn't able to get the individual issues in the UK, but *did* get hold of the first three collected volumes, from a bookshop in Brighton, just before my Acorn Atom kit arrived. Obviously nothing that could be directly copied across, but that was the point: you could see what *was* possible on a huge 12K RAM computer and have a go at something similar. Certainly a lot more fun than the Fortran had been (at least, until I could a few pennies tutoring in a Fortran course for a couple of terms).
The early volumes are still fun to read, the whole attitude towards getting the little machines to do something was different back then.
The computer I use for most stuff is a 20 year old Walmart $200 PC maxed out to 2GB running Slackware 14.1. I checked the size of the binary for some things I use all the time.
bash 921K
ls 108K
df 92K
du 106K
grep 324K
cp 125K
mv 116K
find 140K
dillo 3.5M
The only three big programs I use regularly are an old version of Firefox to view a few trusted sites, emacs and python. The emacs binary is about 40M, can't get a size for the other two without a lot of work.
Clearly the industry has come a long way in the past two decades. I'm not at all sure it has been moving in the right direction.
When you were adding all those things up, were you just `du -sk`ing the binaries or did you find and factor in the things they linked with? All of those are linked with libc at least, and on my system, /lib/x86_64-linux-gnu/libc.so.6 doesn't fit on a floppy entirely on its own. Does that count or not?
That question is relevant to most complaints about big software in my experience. Many of those complaints are about something as simple as the file size for an install file, but often that is because it includes a copy of dependencies which don't count against software given credit for efficiency where those dependencies are installed separately. I've got a nice, simple Python program, easily fits on any floppy including the smallest ones I know of (about 100 kB, a couple from the 1970s). That's mostly because this program is all code, no assets, which are a big part of most size complaints. But it won't fit on that if I have to include Python with it, and whether I have to do that depends on the system it's going to run on and the user expected to run it. If it's a Linux system, it's probably got a suitable Python on it now and if the user is competent, they can get one. If it's Windows or Mac OS and the user isn't technical, I should probably bring it with me. This makes no difference to the size of the actual program, but it allows me to brag about being small and someone to lambast me for being huge at the same time.
ls -l actually. But you're right, the Slackware 14.1 (32 bit) version of libc.so.6 looks to be 1.8M, so too big for a floppy. OTOH, one copy of libc should suffice for all. Same for lb-linux.so.2 (154K). Not being a C-programmer (I can follow C code but never had much need to do more than that) so I don't know what else might be dragged in. Not much I should think.
It depends on the program, for example here's the output of a simple script I wrote to get this information, running on /bin/mv:
/lib64/ld-linux-x86-64.so.2: 232k
/lib/x86_64-linux-gnu/libselinux.so.1: 171k
/lib/x86_64-linux-gnu/libpcre2-8.so.0: 611k
/lib/x86_64-linux-gnu/libc.so.6: 2076k
/lib/x86_64-linux-gnu/libattr.so.1: 27k
/lib/x86_64-linux-gnu/libacl.so.1: 39k
6 dependencies, total dependency size 3152k
[in addition to binary size: 136k
It's not easy to quantify what we even mean. I ran the same script against something that generates PDFs, and it had 32 MB of dependencies. I don't object to that; those dependencies had to deal with font rendering, multiple types of image compression, most of HTML, and of course the core part of properly handling all the versions of one of the least restricted format specs we have. If I was trying to properly measure the size of those programs, I'd have to add in the size of the assets they were using or could have used, and that would be a much higher number, because counting binary sizes included the font renderer but not the fonts for mathematical and traditional Chinese that the file I most recently used it on would have loaded, let alone the many others it probably has access to if I should need them.
This is one of the reasons that I don't agree with most complaints about bloated software. There are certainly exceptions, but most of the time, I understand and agree with decisions to use a bit more system resources to save development time. Sometimes that tradeoff wasn't made either and what people mean by "bloated" is "it's terrible that this software includes things I don't use just because other people do".
"I'm not at all sure it has been moving in the right direction."
Me neither. As I think I might have mentioned before, I was dismayed when Delphi 5 produced 500kb executables for even a trivial program. I'd previously been using Delphi 2, which was much smaller - around 150kb, I think, though I could be wrong - and I thought they were too big!
Free Pascal, with debugging off, is a little over 1.5Mb for a trivial application. Not hideous, by today's standards, but still unnecessarily vast for what the program does.
The trend towards layers and layers libraries/ APIs etc has not worked well. Sure, modern PCs can run the boated crap that is today's software, but imagine how much more could be done with the same hardware if the software was small and fast.
I was dismayed when Delphi 5 produced 500kb executables for even a trivial program.
Ha, that's adorable :)
As I have related previously in these parts, I experimented fairly recently with developing stuff in Microsoft's WinUI3 framework. Normally my C# stuff uses Win32/Winforms, because I am a dinosaur and cling stubbornly to the credo that software should be easily redistributable by copying its file (ok, 2 or 3 files grudgingly allowed if it has unavoidable dependencies) to portable media. I've done stuff in WPF too, mainly to show that I'm not totally fossilized.
Anyway, where was I? Oh yes. Thought I'd try WinUI3 one day so that I could develop native-looking Win11 applications (hey, don't judge).
The first problem is that Microsoft really, really wants those WinUI3 apps to be distributed via the Microsoft Store. Quite apart from the complexities of getting a developer certificate etc, the Store model just rubs me the wrong way.
Anyhoo, and sorry that this has become a shaggy dog story (I had an onion on my belt, as was the style...) there is a way to compile a WinUI3 app to discrete files, but it insists (according to the info I found at the time) on including a lot of dependencies.
Which meant that the simple "Hello World Dialog" program I wrote came out as... 130MB of files in the output directory.
I gave up on WinUI3 at that point.
Damn right. I'm an "engineer" because the employment environment has a title to fill a slot. Some of my best friends are real engineers: Industrial, civil, electrical, computer, mechanical. They earned their title through hard work and certification. They carry real risk. My title is bestowed on my business card due to contract awardednessness. I respect the people who've gotten the title on merit and effort.
All that said, a Software Engineer is a real title, earned and respected as a real engineer should be.
The lifetime of a bridge is measured in decades to centuries, with maintenance every year or so. The lifetime of a bridge building technique is measured in centuries to millennia. A bridge that requires less maintenance is considered a superior product. A building technique that works through the ages is considered fundamental. Physics don't change, ever.
The lifetime of a typical app is measured in months to years, with a patch every month or so. The lifetime of a language or major framework is measured in years to decades. An app that doesn't get frequent patches is considered dead and to be shunned, and the same goes for a framework or language that doesn't get new features. Fundamental architectures aren't stable for more than a few decades.
The people working on bridges, however, are still people, the same as the ones working on software. They can learn techniques, design products, and improve methods at roughly the same pace. You see the intrinsic problem?
Real engineering is the product of generations upon generations of accrued knowledge. You just cannot do that for software, not right now. There are a few timeless lessons, and coders would do well to learn them, but the vast majority of it is far too fluid. I can come up with a beautifully simple and functional piece of software, sometimes, but I shouldn't have to; it should be a solved problem, in hundred years old textbooks. There's very little of that in software, and not nearly enough to build a word processor out of it.
I don't have a fix for this. I hope that a few more centuries will be enough to make software engineering into a real kind of engineering.
[quote] I hope that a few more centuries will be enough to make software engineering into a real kind of engineering. [/quote]
I WAS going to say Don't hold your breath, but the time scale involved seems to make that bit irrelevant :o)
but I do like the comparison to 'basic' engineering, and the fact it has been going around for so long, yet everyone sort of expected software to just BE :o)
maybe in our next iteration on this planet, we shall arrive at a more pleasing time for us all in the IT world :o)
I don't think the difference is as much as you're claiming, partially because you've used two sentences which I think were intended to be parallel but are not. "A bridge that requires less maintenance is considered a superior product" and "An app that doesn't get frequent patches is considered dead and to be shunned" are not the same point. Using the same points on both objects is much more accurate: a piece of software which doesn't need maintenance is often seen as superior because either it doesn't need as many patches to fix bugs or it can receive more focus on adding useful functionality if there is any of that to add. A bridge that doesn't receive maintenance is considered a problem, and if I told you that a bridge was old and nobody had fixed or analyzed it in a long time, you'd be right to wonder whether it had experienced enough time and damage to need those things.
Part of the difference is a different attention to quality and I'd also like to see that fixed, but I think another part is that a bridge is a bigger project and intended to last more time (especially because of the difficulty and cost of building it), so it receives more design. I think software can be subject to those constraints but it would make it more expensive, but since it is easier to fix or improve it, people tend not to. That has good parts in addition to the many bad ones, and software is far from the only thing subject to those pressures. Electronics, designed by people that rarely get told that being called "electrical engineers" is fallacious, frequently have design problems more similar to software than bridges, and the frequency of that is directly proportional to the cost and expected lifetime of what they're building.
It is a 177kb demo by Farbrausch, (a well known German group in the demo scene). In order to crush their demos down, they used a rather novel in-house tool, Werkkzeug, (the source has been heavily forked and inspired many a clone since). It allowed artists to build procedurally generated textures and meshes using a sort of node-based editor, which it dumped out into a FORTH like bytecode.
Probably their most famous production was the 2002 .kkreiger- a 96kb, normal mapped (windows only, but probably runs in wine) first person shooter with dynamic lighting and shadows. As a game, not particularly great, but even at the time, it was several orders of magnitude smaller than anything else that could pull it off. Certainly of historical note in this context, but that unadorned zip link is only meaningful to those familiar with it, and a terrifyingly dodgy look for anyone else. Especially since demos are almost certainly UPX packed and will cause antivirus to freak the hell out.
Here's a video of what the OP wanted to show instead.
For anyone that needs to access old floppy discs which may not be accessible conventionally, check out this device and software:
"Greaseweazle is a USB device and host tools allowing versatile floppy drive control. By extracting the raw flux transitions from a drive, any disk format can be captured and analysed: PC, Amiga, Amstrad, PDP-11, musical instruments, industrial equipment, and more."
https://github.com/keirf/greaseweazle/wiki
I'm just an end-user of the device and associated software, not affiliated in anyway with it
The ones we used mostly only had one 360 kB floppy drive. Present as logical drive A & B.
Well I remember swapping floppies for apps like compilers that hoped for a data drive as well as an App drive, as well as reloading the command shell at the end. The original IBM PC had two full-height floppy drives, but I don't remember if that was standard or just a purchase option.
> The original IBM PC had two full-height floppy drives, but I don't remember....
Nominally there was a zero floppies option. Booting from cassette tape was fairly routine in games-world, cuz hundreds of bucks cheaper than even single flop.
A possibility not widely known is that a 5150 PC would boot from keyboard. Well from something to stuff bytes in the keyboard port. Say a ROM and a counter. This was used on the assembly line to run tests. (Yes ROM BIOS POST but ROM in these machines was tiny, 16K or less.) And of course it would fall-thru to ROM BASIC.
On PC -or- XT:
Switch block 1, near center of board:
Switch 1
off = Boot from floppy
ON = Don't boot from floppy (goes to Cassette BASIC in ROM)
Switch 7,8
ON,ON = 1 floppy drive
off,ON = 2 flops
ON,off = 3 flops
off,off = 4 flops
No, I do not remember how to jumper for zero flops. I suspect you jumpered for one and ignored the error.
Fits on 360K? I had DOS, an editor (NOT EDLIN!), a hypertext signboard and details of a semester's worth of events on one flop and it was not even tight.
It's all very well having small program executables but ultimately it's the data that matters. Take, for instance, your favourite small browser. It has access to the full whack of the web (give or take those sites too smart for their own good that will only work with their developers' favoured release of Chrome or whatever it may be).
If you want to house a lot of data then it's going to be a server that can handle all it. If a lot of people will need access at once it's going to need a lot of throughput. If the people are in more than one location it's going to need secure connectivity. It's starting to look awfully like a cloud. The easier question is to make damn sure you know whose computer it's on that relying on providing that yourself. This aged techy - closer to the no hair than the merely grey - has reached the point where NextCloud on a 3rd party server (no doubt a VM) run by someone I can trust is a better solution for a local charity than doing it myself.
Of course dealing with national sovereignty the issues are bigger as are the complexity of the requirements. But so are the resources available to ensure it's handled by someone who can be trusted. That's the case irrespective of whether it's done in house or not. What's really important to realising that it's necessary to have someone who can be trusted, whether you can trust those currently doing it and how urgent it it to make your mind up about it and act if you decide they aren't.
> And parenthetically, anyone who says that they can improve anything with either blockchain or AI is no more to be trusted than a schoolteacher who gives no homework.
A strange analogy. There are valid systems of education that give no or very limited homework, especially to primary school ages (Steiner, special ed) and significant evidence that homework is of limited benefit, academically or otherwise.
While I support the appeal for lean software, being a fan of the UNIX philiosophy, the following statement in the article is too general:
and go back to an older, simpler model where organizations own and store their own data on their own servers.
Do we really think it would be a good idea for small businesses to be running their own mail server, even if they were able to? Or even a file server (with external access) ?
Even if we drop the cloud moniker, there's perfectly valid technical, financial, and practical reasons why, particularly smaller, organisations would be using a 3rd party provider rather than owning and running their own servers, at least for some services.
...for the Textas Instruments TI-99/4A.
It's mostly written in machine code (TMS9900). Some of the higher level stuff is written in Forth.
The built-in code editor, compiler, REPL, and >300 "words" (aka 'functions') fit in 16 kilobytes and run off a plug in cartridge. I hand optimised every single byte (well, there's only 16384 of them!) over and over to fit it all in.
It's on the internet if you care to search for it.
It can be done.
Username checks out. Threaded interpretive languages were truly marvellous. Surprisingly Chuck Moore is still with us! He gave many a talk berating the state of software in the late 90s and early 2000s, and while perhaps his 'fat free programming' approach was lean to the point of masochism by that time, I'd say a lot of his complaints were incredibly pertinent then, and even more so today.
Seeing cooperatively multitasking, real time FORTH OSes that fit into 12k EEPROMs on a Z80 was something that sounded like science fiction then and now, but it truly was a reality to the lucky few who were exposed to them. I guess like Lisp, it was just too 'weird' a language for the majority of people to truly appreciate. It definitely fundamentally changed the way I looked at computers.
References to floppy disks these days remind me of my time working for a hardware OEM in the early 2000s. We would occasionally get overflow calls from South Africa due to the shared language and overlapping time zones. We were warned in advance that in South Africa 3.5" floppies are referred to as the much funnier and also much more accurate "stiffies" so users calling with a problem with their stiffies were not in fact just taking the piss and should not be laughed at.
Thank you for bringing up Wirth's 1995 paper. Yes, it was a self-serving promo for Oberon, but hey.
The paper gets into trouble very quickly: "Uncontrolled software growth has also been accepted because customers have trouble distinguishing between essential features and those that are just “nice to have.” Examples of the latter class: those arbitrarily overlapping windows suggested by the uncritically but widely adopted desktop metaphor; and fancy icons decorating the screen display, such as antique mailboxes and garbage cans that are further enhanced by the visible movement of selected items toward their ultimate destination. These details are cute but not essential, and they have a hidden cost."
Three points:
1. Those "details" can be very efficiently implemented in well-written code. They do not in and of themselves demand bloatware.
2. Whether they are "essential" depends on how you define the term. When is ease of use not essential? The desktop metaphor was not adopted "uncritically."
3. It was well understood, from the very beginning at Xerox PARC, that hardware and software improve together. This was never a question of software bloating to fill up hardware. The problem has always been around how well the code is written, to do what the code needs to do. Bloatware prevails when people write bad code. No particular tools will make them better programmers.
Just one voice in the wilderness, answering another ....
