The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Have some random code from the listing after assembling the sources, then:
48D : EC DSP_ShiftExit: SEX RC ; store the shifted bytes in the video buffer
48E : 8B GLO RB
48F : F3 XOR
490 : 5C STR RC
491 : 1C INC RC
492 : 9B GHI RB
493 : F3 XOR
494 : 5C STR RC
495 : E2 SEX R2
496 : 8C GLO RC ; advance the video buffer pointer
497 : FC 07 ADI 07H
499 : AC PLO RC
49A : 9C GHI RC
49B : 7C 00 ADCI 00H
49D : BC PHI RC
49E : 30 6E BR DSP_ByteLoop
4A0 : 12 DSP_Exit INC R2
4A1 : D5 SEP R5
This kind of stuff never changes. Such old computers are very much like the modern microcontroller kits. Everything comes back sooner or later and it's actually quite important to learn what you can do with a few bytes of machine code, un restricted by conventions, operating systems or standards.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
Uncle Bob is definitely correct on people always look at the new 'shiny' language or framework. I remember my early days of looking for the '1' perfect language. Pascal, Forth, C, etc, etc, etc. Of course I never found it (you'll shudder but I do have a fondness for Forth!).
From my perspective now as an embedded programmer/engineer (since the 70's), C/C++ is the only real choice I have as a programming language. It's the only language that has been available on every processor I've programmed for in the last 20+ years. Every RTOS I've used has a C or C++ interface. All my personal libraries that I've built up over the years are in C and C++. I'll be programming in C/C++ for the rest of my career (only 2.5 years till retirement!!!).
I usually agree with Uncle Bob, and I understand his over-arching point here, but this article (especially the closing bit) sounds suspiciously like "let's just stop all the new stuff".
And that doesn't sit well with me. The day you give up trying to innovate is the day you become a fossil. Regardless if you're successful or not, the attempt is often far more important than the result.
The day is coming when we will write programs by attaching 2D blocks to each other, then viola, we have a program! (I think MS has already done this with scratch, MFC windows, and C# Forms/WPF. Some tools can translate a flow chart to code.)
Tell that to the surgeon who says, "Oops" while trying a new innovative procedure during your surgery.
Well, that's a good point, and maybe what Uncle Bob is railing about - if you'll permit me to extend the metaphor - is the fact that far too many of us surgeons are trying out these new innovative techniques on live patients (live projects), and not spending enough time trying them out on pigs and sheep (Test/PoC projects)?
That's a valid point of view, but it doesn't seem to come across in his post. His article seems more along the lines of "if existing tools don't support it, then don't even bother".
Uncle Bob emphasizes how much we lose by continually changing frameworks, languages, libraries, etc.
When we keep the same language, framework, and libraries for a longer period of time, we get better IDE's that handle them, better documentation that describes them, better stability and robustness (and maybe even better new libraries that work with them).
We should only change when the benefits of the change are high compared to the costs of the change. We're in a time period now when the benefits are low and the costs are high.
I'm normally in agreement with him, but he's making some strange assumptions here that are not really obvious.
1. Who says that these experiments are slowing people down? Some people are slowed down, the majority isn't.
2. If those people would be concentrating on a handful of languages, would they agree on anything? Or would you just have more different frameworks for less languages?
3. He's not taking taste into account. People work faster in frameworks/languages they like. So programmers who don't like Bob's chosen 5 are out of luck?
Also, some people (like me) like learning new languages. Why take our fun away?
While the old and seasoned side of me agrees with this, I don't think it's a waste of time to challenge the norm. It's how we evolve. I'm a slow-to-move dinosaur myself, for those very reasons he mentioned. I didn't even care about .NET for years until I had to for work... because what's the point? I could do what I needed to do already.
Libraries like React are fantastic IMO. Thinking it's the next holy grail however is immature and silly. The pros know this, which is what the article suggests as well. But, I for one am glad someone decided to give it a go and make a lib that improves upon something.
I totally understand the "shiny new button syndrome" by newbs. But, every now and again, change is warranted.
It's the information age man. Too much clutter and not enough content. But sometimes there's content. Ya know.
I think the point Uncle Bob was making is the point you are making also.
He's saying, "Dont' just throw out the old stuff because it is old."
Instead, see it as a foundation of work that allows us to build further.
We probably couldn't have gotten to a good functional programming without going through and learning OOP.
However, don't believe that OOP is just old stuff now either. It is a foundational element to software development.
I think he is also attempting to say that there is a foundation of good software development methodology (the marketized names screw it up in most people's heads though) and we should gather those and use them throughout even as new technologies are born anew.
Well to that extent I agree. Personally, I still think C is a viable language for certain projects, and I'd never want to throw it away. But, C is also one of my favorite languages with a special place in my geek heart; so I'm already biased towards it.
I have no desire to use COBOL, even though I'm sure decades ago the same thing was said of COBOL as we're saying about OOP right now. I'm sure it has its merits too and served a purpose as well an evolutionary step towards the next. Doesn't mean I'd use it today though.
Not that I'm anti-OOP, can't be in this day in age. Guess it's all about balance. Don't change for change's sake, but change for something that's genuinely better. Unfortunately, that's not always the case and some folks get caught up in the hoopla of new buzzwords and changing because it's cool - not necessarily prudent. So, I totally get it, but not to the extent we become a dinosaur and thus the next generation of COBOL guys who aren't relevant anymore.
The only places where there can be gain are in applications and in libraries/frameworks for handling new requirements (e.g. for working with 3D moving images, and the like, when the technology for displaying it becomes available).
I've hardly ever seen new languages as increments in technology. Whenever they've contained something new, it could invariably have been added to an existing language at much less cost (of time and effort in learning to use it).
OO? Sure, it works, but I was coding objects in COBOL more than 30 years ago, without having to change anything about the language. I was ordered to read Booch, so that we could migrate -- at Huge expense -- to some new language (I don't even remember which one, now, but it wasn't SmallTalk or Pascal), and the entire book got no more than a "meh" out of me.
So I knocked up a presentation to show how we'd already been doing it for years, but without having given it a mysterious aura, and showed the costs of the two learning curves involved (one curve for ripping out what we were using and learning everything from scratch, and the other for memorising a handful of different names for the structures and processes we were already using).
Linear, object, functional, kabibbifuffle -- they're all just ways to massage the ones and zeroes; they can all do it all.
An improved IDE is worth a hundred times more than any new language, as is any library/framework that reduces the level of detail that you have to delve into.
I wanna be a eunuchs developer! Pass me a bread knife!
Last Visit: 31-Dec-99 18:00 Last Update: 30-Sep-16 14:20