Uncle Bob nails it again
-
Great article!
Uncle Bob said:
It's time to simply get down to work. We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes.
Exactly. I just had this discussion with someone, explaining that the Real Agile (not the one that exists differently in every single mind acquainted with it) actually works. But, I'm sure I'll get all kinds of replies to that. Do the work! :D
My book, Launch Your Android App, is available at Amazon.com.
-
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. -
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.
-
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.
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
-
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.CDP1802 wrote:
Finally someone who says it. We are not making progress, we are going in circles mighty fast.
The glass is half full...and there is a hole in the bottom. :laugh: :laugh: Here's a question-guess -- Do you work for a government somewhere? :laugh: :laugh: :laugh: It's only not funny, if you do. 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. This is NOT the problem : Creating software that doesn't work. THe problem IS:
creating software that works, but does the wrong thing.
:-D
My book, Launch Your Android App, is available at Amazon.com.
-
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.
Vark111 wrote:
Regardless if you're successful or not, the attempt is often far more important than the result.
Tell that to the surgeon who says, "Oops" while trying a new innovative procedure during your surgery. :laugh: :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
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
-
It's been true for years. 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!
-
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.
-
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
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.
My book, Launch Your Android App, is available at Amazon.com.
-
Vark111 wrote:
Regardless if you're successful or not, the attempt is often far more important than the result.
Tell that to the surgeon who says, "Oops" while trying a new innovative procedure during your surgery. :laugh: :laugh:
My book, Launch Your Android App, is available at Amazon.com.
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".
-
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.
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
-
It's been true for years. 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!
Mark_Wallace wrote:
OO? Sure, it works, but I was coding objects in COBOL more than 30 years ago, without having to change anything about the language.
This is the voice of experience speaking. I remember thinking something similar for my C projects. Took me a while to jump unto the OOP bandwagon being so awesome it cures cancer. Just like it's gonna take people a while these days to jump onto the next thing. Change is slow.
Mark_Wallace wrote:
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.
Agreed. Although, having gotten used to some newer languages (in web dev at least) it's rough to go back.
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.
To this I totally agree. Comparing it to fashion being very apropos... yay the shiny new button syndrome.
Jeremy Falcon
-
Mark_Wallace wrote:
OO? Sure, it works, but I was coding objects in COBOL more than 30 years ago, without having to change anything about the language.
This is the voice of experience speaking. I remember thinking something similar for my C projects. Took me a while to jump unto the OOP bandwagon being so awesome it cures cancer. Just like it's gonna take people a while these days to jump onto the next thing. Change is slow.
Mark_Wallace wrote:
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.
Agreed. Although, having gotten used to some newer languages (in web dev at least) it's rough to go back.
Jeremy Falcon
Jeremy Falcon wrote:
Change is slow.
There's the rub. 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.
Jeremy Falcon wrote:
having gotten :mad: used to some newer languages (in web dev at least) it's rough to go back
So use 'em! 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!
I wanna be a eunuchs developer! Pass me a bread knife!
-
CDP1802 wrote:
Finally someone who says it. We are not making progress, we are going in circles mighty fast.
The glass is half full...and there is a hole in the bottom. :laugh: :laugh: Here's a question-guess -- Do you work for a government somewhere? :laugh: :laugh: :laugh: It's only not funny, if you do. 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. This is NOT the problem : Creating software that doesn't work. THe problem IS:
creating software that works, but does the wrong thing.
:-D
My book, Launch Your Android App, is available at Amazon.com.
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. -
Jeremy Falcon wrote:
Change is slow.
There's the rub. 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.
Jeremy Falcon wrote:
having gotten :mad: used to some newer languages (in web dev at least) it's rough to go back
So use 'em! 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!
I wanna be a eunuchs developer! Pass me a bread knife!
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
-
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.
