|
 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Two things:
1. From the point of view of the end user the same look and feel is good, so Bootstrap has it place...
2. We use Bootstrap - as idea - in our new project, but you can not tell, just by looking at it. So even with Bootstrap, you can create different sites - if you are really a designer and not a 'so called'...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The Churn[^] - why the shiny and new isn't always better than the established and battle hardened.
|
|
|
|
|
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! 
|
|
|
|
|
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 f***ing 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.
|
|
|
|
|
|
raddevus wrote: ere's a question-guess -- Do you work for a government somewhere?
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 f***ing 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.
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)[^]
modified 28-Jul-16 11:07am.
|
|
|
|
|
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.
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 f***ing 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.
|
|
|
|
|
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!!!).
|
|
|
|
|
Mach 3.5? A slow Phantom? 
|
|
|
|
|
Not only are we running in circles, but even talking about running in circles is an old story[^].
| Ravings en masse^ |
|---|
| "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 |
|
|
|
|
|
Maybe I am old fashioned, but I still like the King James version best....
|
|
|
|
|
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
|
|
|
|
|
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...? 
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!
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.
|
|
|
|
|
|
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.)
|
|
|
|
|
Heheh you go do that, and enjoy. I'll be developing the IDEs that give you the 2D blocks to build your software with 
|
|
|
|
|
No offense intended (but probably unavoidable), but you sound young and too cocky and naive to consider the experienced perspective of older folks who've been there and seen a bit more than you.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Yes. This.
I'm normally in agreement with him, but he's making some strange assumptions here that are not really obvious.
For example:
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
