That rather assumes that one believes OO is always useful, or progress!
That rather assumes that one believes OO is always useful, or progress!
Indeed. OO is actually a disaster. It complicates needlessely.
And it forces a stage of design forethought that is not necessary in so many cases.
It really only has it place in huge companies employing crap coders to produce bloatware.
The OP is te sort of person who probably thinks that memeory allocation should be 'handled by the language' and then cant fix a situation where his code stops for 5 seceonds whole memory garbage collection goes on.
You can create any structure in assembler, whether you would want to is another matter. One of the fundamentals of programming is that once you have built something you can use it as a building block for the next stage of sophistication, complexity or obfuscation if you will.
I have always found it a great advantage to have started in the computing business in the age of blinken lights. You can see through a lot of nonsense if you understand the foundations.
*applause*
Isn't that true of most anything?..
None whatsoever. Because we didn't try.
Systems programming isn't like ordinary DP.
Andy
I still remember adding up instruction cycle times to make sure we weren't running too long with interrupts disabled (*). OO? WTF's that? :o)
(Rhetorical question. I know perfectly well what OO is.)
(* In device drivers under RSX11/M on a PDP11. Yes, it was a long time ago.)
Back in the days of X.25 packet switches, I wrote some carefully crafted assembly code which could switch a packet in 127 instructions. It allowed for the computer's pipeline, performing base register loads well enough in advance that there was no stall in the indirect load, generally interleaving two separate functions in alternate instructions. It was part of a project which increased the packet switching performance by over 10 times.
"You are not expected to understand this."
Why not?
Next you'll be saying you don't understand Meltdown and Spectre :P
Andy
[Whoosh]
The comment is bollocks, of course. And I assume the 127 instructions for switching a packet will still work even if the internal workings of the switch changes. E.g. if you are told to buy a more recent, cheaper model of the switch that has no pipeline and a different memory architecture.
I even had a T-shirt made with it on, years ago. Gets worn for a certain lecture.
My mother used to use that - presumably partly out of habit, since there was a big council library right opposite...
I think I should having designed the hardware and firmware for the X25 card used for billing data on SystemX.
Much more difficult to workout what the data is.
It was optimised for what was then (1980's) our top range mini- computer which had a 4-instruction pipeline. It also run on the slower/cheaper 2- and 0-instruction pipeline systems, but they were slower for many reasons besides just instruction pipeline (things like lack of multi-ported memory, and less memory, and narrower memory bus). These all ran the same 127 instructions, but only the top range system gained from specifically hand-crafting those instructions.
Ah, so Dennis Ritchie talks bollocks?
In your utterly worthless opinion.
And I take it you commented it up and documented it all for the maintenance programmer who'd be dealing with it subsequently?
Everyone talks bollocks from time to time. Even you.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.