|
Wordle 1,002 4/6
⬛⬛🟨⬛⬛
🟨🟨⬛⬛⬛
⬛⬛🟩🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,002 4/6
⬛⬛⬛🟩🟩
⬛⬛⬛🟩🟩
🟩⬛🟩🟩🟩
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
Wordle 1,002 2/6*
⬛🟨🟩🟨⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
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[^]
|
|
|
|
|
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.
|
|
|
|
|
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 pencil story is apocryphal, both the US and Russia used pencils in the early days until they both realised that the tips flake and break leaving highly conductive fragments floating round the capsule to damage eyes and equipment depending on what they ran into. And that flammable wood and graphite wasn't a good idea in an area where the fire department can;t get to you easily ... 
In 1967 both the US and Russians standardised on the AG-7 "Anti-Gravity" Space Pen - the company making them gave both sides the same "bulk buy" discount selling them at $2.39 per pen.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: 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"?
Blaise Pascal.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
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)
|
|
|
|
|
Any idea how bloated/lean Devin's code is?
Is Devin's code maintainable, or does it need a Devin++ to maintain it?
modified 16-Mar-24 20:41pm.
|
|
|
|
|
Summarizing: Software is getting slower more rapidly than hardware is becoming faster. Wirth's law[^]
Mircea
|
|
|
|
|
I don't know if I'd be quite that harsh. My law is
Whatever capacity the hardware boys add, the software boys piss away. Not only in speed, but in memory, disk space, pixels...
|
|
|
|
|
Others have said: "What Andy gives, Bill takes away" 
Mircea
|
|
|
|
|
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 to run some outdated software that Win10 cannot handle. I try to avoid it; I haven't got the time. Not for digging the machine up from the basement, but waiting for it to complete its tasks.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Of course you are right (for the most part). It’s just a hyperbole, like Moore’s law stating that hardware performance grows exponentially. Nothing can grow exponentially in face of physical constraints. It’s just that these flippant statements highlight truths that we sometime forget and software is sometimes bloated.
Where you are unfair is in asking old hardware to perform today’s tasks. Compiling 20000 lines programs was not possible because there were very few 20000 lines programs and most of them were not destined to run on a PC. We had simpler tasks and we were doing those with very limited resources. Sometimes people had to expend a lot of ingenuity to meet these constraints.
A few days ago I was reminded of these “good old days” when I had to go back to TAOCP to investigate an algorithm for evaluating complex polynomials. It is very smart and it saves a few floating point operations. It is also completely insignificant these days If you want to read the details, you can find them here[^]
Mircea
|
|
|
|
|
That's totally fair, though if you were to somehow manage to graph performance of hardware vs software over time, I think you'd find ups and downs, even points of convergence, etc.
So I think it's possible that within the window of time Wirth was writing, his law held true.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I've worked for the same company for just over a third of century. I've spent most of that time building the same type/sort/class of application. Interestingly their builds have taken roughly the same amount of time: 20-45 minutes, while the disk space required for a build has jumped by three orders of magnitude: from 3x1.44MB floppies to 25GB.
The most surprising metric is this. The quantity of source code has gone up as much or more, despite the fact that the operating system and application framework now provide user interface and other infrastructure that we had to create ourselves when we first started. My original MS-DOS applications had a home-brew text-mode windowing system, parallel/serial communications, a cooperative multitasking model, and so on. The only thing MS-DOS provided was disk I/O. Our current products consist of a Windows application (C#/WPF) and multiple Windows services (C++/MFC). All of it including the UI is heavily multithreaded.
Is this software bloat? Maybe. I do know that our current products provide a level of capability and performance that would have been inconceivable in the early 1990's when I started.
Software Zen: delete this;
|
|
|
|
|
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.  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
|
|
|
|
|
Peter Adam wrote: Want to go back?
Certainly not.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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 
Welcome to my Chaos and Confusion!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
