Software Bloat.
-
That is a common myth, but it is just a myth. If you have got, say, a 25 MHz 386 sitting on your basement shelf, or maybe something slightly newer, that will still boot, try booting it up and run some of the applications. The boot up time alone is insufferable. The applications take ages to start up, and response is like cold molasses. There were format wars in the image department (as well as in most other departments), with people rejecting JPEG because it took too long to render the images on the screen; GIF did the display much faster, so it was a better format. In my student days, I remember one student exercise spending half an hour compiling on a VAX 750. I was a TA in the elementary programming course; we were running 20 terminals on each of three fridge-sized computers, accepting a new set of students ever hour. We told them to log out after 45 minutes - yet it sometimes happened that the 20 logouts were not completed 15 minutes later, so the new group of students had to wait. Do you remember OLE 1.0? You had to wait for ten seconds, twenty seconds, half a minute to get, say, a spreadsheet embedded in a Word document to display. We learned to avoid scrolling through the document: If you scrolled into an OLE object, you might as well take a walk to the coffee machine for a refill while waiting. If you claim to have a 20, 30 or 40 year old PC with original software, and seriously claim that it runs common tasks (such as compiling a 20,000 lines program system, displaying a high-resolution image, reformat a document to a different layout, do a complete spell check of your text, or similar tasks) significantly faster than today's software and today's machines, then I would most certainly like to see a description of that hardware, software, and actual timings of running the various tasks. If you make a timing test, please make sure to include in the description the vintage of your equipment! Comparing a 1995 fastest-on-the-market machine stuffed with RAM and all sorts of speed-improving hardware to a 2024 bargain PC with the very minimum of RAM, the cheapest CPU around, a spinning magnetic disk etc. is an unfair competition. Like the Norwegian emigrant farmer to the USA who was on a visit back to his home country, telling "Over there, the farms are so large that it takes a day to drive around them!" His old friend, who had remained in Norway, nodded: "Yes, we've got some cars like that here in old country as well, you know". Every now and then I boot up one of my old machines t
Want to go back? Just replace your SSD to a plain simple HDD under your Windows 10/11. More retro feeling can be achieved using a HDD with SMR technology.
-
Was that Mark Twain who ended a long letter to a friend: "I should have written you a shorter letter, but I didn't have the time for that"? I think that comes in here. There is so much "nice" libraries and free source code, ready to past into your application; you can make something with lots of functionality in a short time. Maybe it would take you three times as much time, maybe ten times, to shave those libraries end source code repositories down to what you really need. My impression is that very few developers write their own bloated code. They make a simple call here, a simple call there. Their own source code grow by half a dozen lines that pulls in megabytes by megabytes of code written by others. Maybe the developers are still to blame. I heard (sorry, no URL) that when US and Russians met up in the space station, the Americans proudly showed this ballpoint pen that was developed for the project: You could use it in a weightless environment. It would write under waster. It would work in vacuum outside the space ship. I had cost millions of dollars to develop ... The Russians solved their tasks using a wooden pencil with a traditional graphite core. I think this story bears some resemblance to Wirth's lament.
Religious freedom is the freedom to say that two plus two make five.
-
Was that Mark Twain who ended a long letter to a friend: "I should have written you a shorter letter, but I didn't have the time for that"? I think that comes in here. There is so much "nice" libraries and free source code, ready to past into your application; you can make something with lots of functionality in a short time. Maybe it would take you three times as much time, maybe ten times, to shave those libraries end source code repositories down to what you really need. My impression is that very few developers write their own bloated code. They make a simple call here, a simple call there. Their own source code grow by half a dozen lines that pulls in megabytes by megabytes of code written by others. Maybe the developers are still to blame. I heard (sorry, no URL) that when US and Russians met up in the space station, the Americans proudly showed this ballpoint pen that was developed for the project: You could use it in a weightless environment. It would write under waster. It would work in vacuum outside the space ship. I had cost millions of dollars to develop ... The Russians solved their tasks using a wooden pencil with a traditional graphite core. I think this story bears some resemblance to Wirth's lament.
Religious freedom is the freedom to say that two plus two make five.
The space pen story is urban legend, sadly - pencils were risky in space with the graphite shavings posing a shorting hazard if they drifted into the wrong bit of circuitry Both the US and USSR started using pencils in space, but both ended up developing a space pen (or in the US's case, buying them from a private developer at $2.95 per pen)
-
Came across this article written by Niklaus Wirth in 1995 that is quite applicable to the state of software today in 2024. Thought I would share it. "A Plea for Lean Software" https://cr.yp.to/bib/1995/wirth.pdf[^]
It should be product owners, business owners, business analysts that should get that message. I think 95% of devs are already agreeing with what was written there :)
-
See, I appreciate this. When I learned to code, half of the job was cramming as much functionality into as little space as you could manage. Bloat was a luxury that few applications could afford. I also was firmly instilled with the notion that software should be as simple as it can be, and no simpler. It may seem like a competing goal, but this actually facilitates making all that functionality work in the first place. If any piece got too big and complicated, the whole thing would fall apart, so simplify simplify simplify. A lot of times a feature is just a matter of exposing existing functionality in the right way. Since I grew up coding within the constraints of modest time and space requirements of the software that could run on the machines I worked with, I learned to code without lots of frameworks, dependencies and mega-abstractions. I still code that way, whether I like it or not. It's just baked in now. I'm much more comfortable working with small streamlined codebases than I am in codebases where you you have a class, 6 different interfaces, and dependency injection for every task. I'm not judging. I'm just saying what I'm most comfortable with. I guess that's why I took to embedded for my second act in development. Software got too big maybe? I stopped enjoying it. Embedded on the other hand keeps me solving problems efficiently, and that's what I like to do. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I totally agree. I'm on my Second Stream now (it's well over 40 years since I left school). After decades as a hands on CTO at startups I decided to go into embedded systems; which is really what my degree was in. I've maintained this as a hobby, so I'm up to date-ish. However the jobs available weren't fully remote (understandable with some hardware) and were a three hour commute away (on a good day) and paid considerably less than the architecture job I took. I'm happy enough; I'm in a company way larger than startups so I don't have to do literally everything; but small enough that I can do interesting work, explore new ideas and manage my team with a light touch.
-
Want to go back? Just replace your SSD to a plain simple HDD under your Windows 10/11. More retro feeling can be achieved using a HDD with SMR technology.
I still use HDD! I have two Hatachi DeskStar drives I use on my Dell Optiplex desktop running Windows 10. Yep! It is that old. Windows 11 is not an option for a machine this old. Performance is not that bad, unless I try to compile something. :zzz: My biggest slow-down is the speed of the Internet out here in the boondocks - I have two choices: DSL over copper loop or HughsNet. Neither is very fast by todays fiber standards.
__________________ Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now. © 2009, Rex Hammock
-
Want to go back? Just replace your SSD to a plain simple HDD under your Windows 10/11. More retro feeling can be achieved using a HDD with SMR technology.
-
That is a common myth, but it is just a myth. If you have got, say, a 25 MHz 386 sitting on your basement shelf, or maybe something slightly newer, that will still boot, try booting it up and run some of the applications. The boot up time alone is insufferable. The applications take ages to start up, and response is like cold molasses. There were format wars in the image department (as well as in most other departments), with people rejecting JPEG because it took too long to render the images on the screen; GIF did the display much faster, so it was a better format. In my student days, I remember one student exercise spending half an hour compiling on a VAX 750. I was a TA in the elementary programming course; we were running 20 terminals on each of three fridge-sized computers, accepting a new set of students ever hour. We told them to log out after 45 minutes - yet it sometimes happened that the 20 logouts were not completed 15 minutes later, so the new group of students had to wait. Do you remember OLE 1.0? You had to wait for ten seconds, twenty seconds, half a minute to get, say, a spreadsheet embedded in a Word document to display. We learned to avoid scrolling through the document: If you scrolled into an OLE object, you might as well take a walk to the coffee machine for a refill while waiting. If you claim to have a 20, 30 or 40 year old PC with original software, and seriously claim that it runs common tasks (such as compiling a 20,000 lines program system, displaying a high-resolution image, reformat a document to a different layout, do a complete spell check of your text, or similar tasks) significantly faster than today's software and today's machines, then I would most certainly like to see a description of that hardware, software, and actual timings of running the various tasks. If you make a timing test, please make sure to include in the description the vintage of your equipment! Comparing a 1995 fastest-on-the-market machine stuffed with RAM and all sorts of speed-improving hardware to a 2024 bargain PC with the very minimum of RAM, the cheapest CPU around, a spinning magnetic disk etc. is an unfair competition. Like the Norwegian emigrant farmer to the USA who was on a visit back to his home country, telling "Over there, the farms are so large that it takes a day to drive around them!" His old friend, who had remained in Norway, nodded: "Yes, we've got some cars like that here in old country as well, you know". Every now and then I boot up one of my old machines t
In the Delphi 4 era I have written a few tools with the included Delphi 1 compiler - compiled and ran faster as it did not participate in drag and drop and did not use the new chrome. Later there was a Russian library called KOL for newer Delphis which was without a few rarely used feature from the VCL (and without RTTI) but largely compatible which was similar.
-
Came across this article written by Niklaus Wirth in 1995 that is quite applicable to the state of software today in 2024. Thought I would share it. "A Plea for Lean Software" https://cr.yp.to/bib/1995/wirth.pdf[^]
Gary Stachelski 2021 wrote:
"A Plea for Lean Software"
Written of course by someone who spent his entire life in academia. Idealism is wonderful but loses its luster when the paychecks stops coming. I suspect clean and elegant code probably is more possible when a company is making money and the CTO owns enough equity that he is on the board. And of course the CTO actually cares about the code as well. Vast majority of software doesn't work like that though. Last two companies I have been at have 20 years of legacy code. Both companies have been through mergers and one with more than 10 mergers. Naturally this means numerous rounds of people applying 'fixes' to make the code 'better'. Which changes with the next round of new employees while the previous ones are long gone. I have worked on systems that I designed from scratch. Sometimes I have even had the opportunity to make up my own business rules as I went along. Of course in those systems there is no need to worry about breaking existing functionality. Those solutions certainly seemed elegant. To me of course. These days chatter of elegant code from a developer impresses not at all. While the ability to deliver working code that works with the enterprise (not just adhoc tests carried out on a developer box) again and again impresses me quite a bit.
-
Gary Stachelski 2021 wrote:
"A Plea for Lean Software"
Written of course by someone who spent his entire life in academia. Idealism is wonderful but loses its luster when the paychecks stops coming. I suspect clean and elegant code probably is more possible when a company is making money and the CTO owns enough equity that he is on the board. And of course the CTO actually cares about the code as well. Vast majority of software doesn't work like that though. Last two companies I have been at have 20 years of legacy code. Both companies have been through mergers and one with more than 10 mergers. Naturally this means numerous rounds of people applying 'fixes' to make the code 'better'. Which changes with the next round of new employees while the previous ones are long gone. I have worked on systems that I designed from scratch. Sometimes I have even had the opportunity to make up my own business rules as I went along. Of course in those systems there is no need to worry about breaking existing functionality. Those solutions certainly seemed elegant. To me of course. These days chatter of elegant code from a developer impresses not at all. While the ability to deliver working code that works with the enterprise (not just adhoc tests carried out on a developer box) again and again impresses me quite a bit.
Hi, Having worked on the "Big Iron" for a number of years....I would meet with various members of the IBM organization from time to time. Was in a meeting once (Virtual) and this comment was made by a higher level IBM VP (who hadn't remembered/ realized there were non-IBMer's present. " Slow software sells fast hardware " There were a number of chuckles etc from the meeting invitee's. And that IBM VP moved on from there.
Cegarman document code? If it's not intuitive, you're in the wrong field :D Welcome to my Chaos and Confusion!