Uncle Bob nails it again
-
raddevus wrote:
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".
Vark111 wrote:
but it doesn't seem to come across in his post
I definitely see your point of view. Great discussion. Thanks for adding to it. Your additional examples were really great.:thumbsup:
My book, Launch Your Android App, is available at Amazon.com.
-
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.
Jeremy Falcon
Great discussion and I agree with what you are saying. I really love C too and have been writing embedded AVR-C for Atmel (ATMega328) chips just recently.
Jeremy Falcon wrote:
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.
Totally agree with this too. Some people hang on to the past just because they don't want to change. Balance is key. :thumbsup:
My book, Launch Your Android App, is available at Amazon.com.
-
Great discussion and I agree with what you are saying. I really love C too and have been writing embedded AVR-C for Atmel (ATMega328) chips just recently.
Jeremy Falcon wrote:
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.
Totally agree with this too. Some people hang on to the past just because they don't want to change. Balance is key. :thumbsup:
My book, Launch Your Android App, is available at Amazon.com.
:thumbsup:
Jeremy Falcon
-
raddevus wrote:
ere's a question-guess -- Do you work for a government somewhere? :laugh: :laugh: :laugh:
Done that, but that had little to do with programming. More with Mach 3.5
raddevus wrote:
Umm...do you think we are better off than the people who read machine language zeros and ones? Maybe a bit. Are we any better off than the Assembly language programmers? Maybe another shade. I understand your meaning though.
Guess what I'm doing right at this moment? I'm writing good old assembly code. Visual Studio as code editor, antique subroutines I wrote many years ago, a simple makefile, an almost 40 year old debugger and an emulator for the elderly target computer. Much too comfortable. I should go over to the old computer and use the hex keyboard. :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"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.CDP1802 wrote:
Guess what I'm doing right at this moment? I'm writing good old assembly code
That really is very cool. I'm writing AVR-C (on the GNU C Toolchain) for embedded development myself. When it's compiled down to the hex file I often go and look at the straight hex, because I am weird. :D Im finishing my article for codeproject which uses an ATMega328, bluetooth and a relay module and it has straight C code in it for the embedded. Lots of fun. Edit The article is posted to CP: Never Buy A Garage Door Remote Again: Open Your Door With Your Android Phone (via Bluetooth)[^]
My book, Launch Your Android App, is available at Amazon.com.
-
I think that it happens mostly because it's more fun to gripe about languages and tools than it is to really understand your users and create what they need. Also, to steal a line from Battlestar Galactica: all of this has happened before, and all of it will happen again. I used to hate waiting for Maven to download half the internet when first firing up a semi-complex Java on a new machine. So I'd go and gripe about how Java sucks, Maven sucks, and JS is awesome because I can write code that just works without needing a billion dependencies. Now, if I clone a semi-complex React or Angular project and run 'npm install', I have to wait for NPM to download half the internet before I can do anything.
-
CDP1802 wrote:
Guess what I'm doing right at this moment? I'm writing good old assembly code
That really is very cool. I'm writing AVR-C (on the GNU C Toolchain) for embedded development myself. When it's compiled down to the hex file I often go and look at the straight hex, because I am weird. :D Im finishing my article for codeproject which uses an ATMega328, bluetooth and a relay module and it has straight C code in it for the embedded. Lots of fun. Edit The article is posted to CP: Never Buy A Garage Door Remote Again: Open Your Door With Your Android Phone (via Bluetooth)[^]
My book, Launch Your Android App, is available at Amazon.com.
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 R5This 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.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"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. -
Mark_Wallace wrote:
Change that doesn't really change anything, but only adds a few shortcuts, isn't real change, so why bother? If the very same shortcuts can be added to just about any language, with a Lot less effort than getting everyone to learn the p!ssballing intricacies, foibles, and shortfalls of a new one, then you've saved enough to pay for everyone's Christmas bonus.
I agree, which is what I was speaking about earlier in this thread. Not all change is warranted or justified, but there times when it is. Turning a blind eye to change is called growing old and not adapting to the current world. Living in yesterday. So, it doesn't mean it can be dismissed altogether.
Mark_Wallace wrote:
The language doesn't make a blind bit of difference to the user/customer/visitor, so twiddle with the ones and zeroes in the way that's most efficient for you!
You're preaching to the choir. I agree. My point with this though is sometimes your environment changes, and for the better. Refusing to think there is another way that may be more beneficial is just a foolish as the new shiny button chasing. It's about balance. Sometimes things need to be questioned. Sometimes not. But then sometimes so.
Jeremy Falcon
Jeremy Falcon wrote:
growing old
Hey! I just had my 17th birthday, a few days ago*! * Who the Hell wants to be an adult?
I wanna be a eunuchs developer! Pass me a bread knife!
-
Jeremy Falcon wrote:
growing old
Hey! I just had my 17th birthday, a few days ago*! * Who the Hell wants to be an adult?
I wanna be a eunuchs developer! Pass me a bread knife!
Mark_Wallace wrote:
Hey! I just had my 17th birthday, a few days ago*!
Oh wow, well happy birthday man.
Mark_Wallace wrote:
Who the Hell wants to be an adult?
It comes in handy when you want to buy alcohol, and you learn stuff. Wisdom and all that. Only downside is you die.
Jeremy Falcon
-
The problem is not we have or have not, or how much the progress is...The problem is that with far too many poorly educated 'professional' in lot of cases we sanctify the tool and not the solution...(A good solution is a good solution not matter what was the language/technology stack we used to create it) With that attitude we created a fashion-driven culture (just like with almost everything else)...We no morce choose toolkit based on knowledge only, but also how shiny it is...And when it comes to justify it (for instance to move from C to Go), we call it progress... For a most concrete example - I should take over a pro-bono project, developed using Angular as a SPA...I fill very bad about it, because that SPA contains over 200! actual pages tossed into one! file!!!
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
A good solution is a good solution not matter what was the language/technology stack we used to create it
That's true. No matter what language you used to compile a program, it's still just small voltage variations being clocked through logic circuits in the end.
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
-
Mark_Wallace wrote:
Hey! I just had my 17th birthday, a few days ago*!
Oh wow, well happy birthday man.
Mark_Wallace wrote:
Who the Hell wants to be an adult?
It comes in handy when you want to buy alcohol, and you learn stuff. Wisdom and all that. Only downside is you die.
Jeremy Falcon
Jeremy Falcon wrote:
It comes in handy when you want to buy alcohol
Luckily, I'm 17 that looks like 57, so I can get away with it. The fact that calendars say I'm actually 57 is bollocks. I don't live by Gregorian calendar rules; they're way to old to take seriously.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Jeremy Falcon wrote:
It comes in handy when you want to buy alcohol
Luckily, I'm 17 that looks like 57, so I can get away with it. The fact that calendars say I'm actually 57 is bollocks. I don't live by Gregorian calendar rules; they're way to old to take seriously.
I wanna be a eunuchs developer! Pass me a bread knife!
Ah I see, well in leap years, you're like what 14? Getting younger every day.
Jeremy Falcon
-
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.
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.
-
> Every year. though we apply massive effort, we make less progress than the year before; because every year we get closer and closer to the asymptote. No, every year we get new newbie asses. ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
I agree. He sounds old and resistant to change. I'm sure if he was coding before OOP came around he'd be saying the same thing about OOP being a waste of time.
Jeremy Falcon
LOL, I suspect Uncle Bob is one of the people who came up with the Agile Manifesto. I know he's a huge fan of Agile and all things TDD. Resistant to change...? :rolleyes: Back in the 60s and 70s when programming became a thing, there was some scientific rigour behind it. It came about at Universities, business labs and places of learning. Nowadays anyone with a computer connection can become a "programmer". Hell, I did! :laugh: But the mantra nowadays seems to be "give me a way to do it faster and without so much hassle" (i.e. so I don't have to fix so many bugs). No one makes an effort to learn to program properly anymore, so they just keep sticking language and framework bandaids over the problems. So yes, churn.
-
LOL, I suspect Uncle Bob is one of the people who came up with the Agile Manifesto. I know he's a huge fan of Agile and all things TDD. Resistant to change...? :rolleyes: Back in the 60s and 70s when programming became a thing, there was some scientific rigour behind it. It came about at Universities, business labs and places of learning. Nowadays anyone with a computer connection can become a "programmer". Hell, I did! :laugh: But the mantra nowadays seems to be "give me a way to do it faster and without so much hassle" (i.e. so I don't have to fix so many bugs). No one makes an effort to learn to program properly anymore, so they just keep sticking language and framework bandaids over the problems. So yes, churn.
He absolutely did.
-
Finally someone who says it. We are not making progress, we are going in circles mighty fast.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"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.Not only are we running in circles, but even talking about running in circles is an old story[^].
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
raddevus wrote:
ere's a question-guess -- Do you work for a government somewhere? :laugh: :laugh: :laugh:
Done that, but that had little to do with programming. More with Mach 3.5
raddevus wrote:
Umm...do you think we are better off than the people who read machine language zeros and ones? Maybe a bit. Are we any better off than the Assembly language programmers? Maybe another shade. I understand your meaning though.
Guess what I'm doing right at this moment? I'm writing good old assembly code. Visual Studio as code editor, antique subroutines I wrote many years ago, a simple makefile, an almost 40 year old debugger and an emulator for the elderly target computer. Much too comfortable. I should go over to the old computer and use the hex keyboard. :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"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.Mach 3.5? A slow Phantom? ;)
-
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.
Jeremy Falcon
Exactly this. Chimps who don't have any analytical skills rush toward the next new thing because "It's new! It will solve all our problems!" instead of actually analyzing whether it is better. At the same time, dinosaurs stick in the mud and can hack something together using an antiquated framework. I'm not sure where the line is, but we need to keep pushing forward, while at the same time, only introducing new tools when they make sense for our project, not just because.
-
Uncle Bob has become that cranky old guy who yells at kids to get off his lawn. Sorry, but we haven't actually got it all figured out yet. This is a silly rant from someone who doesn't want to adapt. He sounds like a "communist" dictator. There will be no dissention! You will not try to create a better way to solve a problem! You will use the things we have always used! Our grandparents built houses with nothing but a hammer and some handmade nails, and so shall you! Actually newer things are sometimes better. Maybe not all of them, maybe not always, but if you never try, then you'll still be building houses with nothing but a hammer and some handmade nails forever. And it's actually fun in the meantime, even if we spend a little time exploring new ideas. Every shiny new thing he derides is probably used successfully by millions of people. Frankly the only reason I am still a software developer is because of new things. Who wants to bang out the same code in exactly the same way year after year?
-
CDP1802 wrote:
Guess what I'm doing right at this moment? I'm writing good old assembly code
That really is very cool. I'm writing AVR-C (on the GNU C Toolchain) for embedded development myself. When it's compiled down to the hex file I often go and look at the straight hex, because I am weird. :D Im finishing my article for codeproject which uses an ATMega328, bluetooth and a relay module and it has straight C code in it for the embedded. Lots of fun. Edit The article is posted to CP: Never Buy A Garage Door Remote Again: Open Your Door With Your Android Phone (via Bluetooth)[^]
My book, Launch Your Android App, is available at Amazon.com.
Looking forward to reading your article! 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!!!).
