Forums

Good hardware, poor software

Started by bitrex April 16, 2017
On 17/04/17 23:43, Tim Wescott wrote:
> On Mon, 17 Apr 2017 08:38:01 +0100, Tom Gardner wrote: > >> On 17/04/17 00:53, Clifford Heath wrote: >>> On 17/04/17 08:36, Tom Gardner wrote: >>>> On 16/04/17 19:36, bitrex wrote: >>>>> On 04/16/2017 01:25 PM, Don Y wrote: >>>>>> On 4/16/2017 6:13 AM, bitrex wrote: >>>>>>> The graveyard of audio production equipment is littered with the >>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>> professionals, but firmware written by nincompoops. >>>>>> >>>>>> That's true of many application domains. >>>>>> >>>>>>> It's really frustrating when you buy a blinky-light box that some >>>>>>> engineers somewhere likely spent thousands of man-hours on >>>>>>> designing the best sounding DAC structure they could for the >>>>>>> budget, but then the OS crashes when you accidentally try to load a >>>>>>> file that's the wrong format. >>>>>> >>>>>> Because most (naive) developers seem to "test" by throwing things >>>>>> that *should* work at the code and verifying that they *do*, in >>>>>> fact, work -- instead of throwing things that *don't* work (i.e., >>>>>> bad file formats, out-of-bounds parameters, etc.) and verifying >>>>>> proper handling of those conditions. >>>>> >>>>> <https://en.wikipedia.org/wiki/Test-driven_development#/media/ > File:TDD_Global_Lifecycle.png> >>>>> >>>>> >>>>> >>>> One of the major changes since I started engineering is that it is no >>>> longer deemed necessary to design software. Nowadays it is possible to >>>> "test quality into products". >>> >>> That's not what TDD does. >>> >>> A well-written specification should be written like code, and it should >>> be machine-processable (to be run as a test suite). That's what TDD >>> does. >>> >>> As you write the specification, you *test* each part by implementing >>> it. If you ever find yourself implementing anything that's not >>> specified, you're no longer doing TDD. >>> If you find yourself specifying something that cannot be tested, you're >>> no longer doing TDD. >>> >>> It's all very easy to criticize cowboy coders, but how do you write >>> design specifications? How do you know that the spec is (a) correct and >>> (b) implementable? >>> >>> Very few people are willing to accept the discipline that TDD actually >>> demands. They might say they're doing TDD, but they're often breaking >>> the rules. >> >> As you get around to implying, TDD is like fracking: safe *when done >> properly*. >> >> The relevant questions are: >> - do the people using the tool understand the >> theory behind it >> - is the specific task somewhere where the tool >> can be used safely >> - are the people given sufficient resources to >> use the tool safely >> - are the individuals capable of doing it >> properly >> >> Too many times I've seen people emphatically state "there's a green >> light so it works"! > > That applies to any formal design methodology, and not just in the > software field. > >> Too many times I've seen unit tests that aren't failable! > > Then those unit tests are broken. When I do TDD for myself, I first > write a test that tests for non-existent features, to verify that it > fails (i.e., I test the test). THEN I add the features to the code base > that I'm working on. > >> Too many times I've seen unit tests that serve *only* to test irrelevant >> implementation details, thus freezing the codebase! > > Again, broken unit tests... > >> TDD is better than some alternative testing regimes, but it is not the >> panacea claimed by some zealots. > > As with all other design methodologies, including "I just do it > inherently right because I'm a manly man!"
All true. Unfortunately it can be difficult to teach inexperienced but relatively diligent people the concepts of good tests when you are up to your neck in a swamp. Unfortunately I've seen people not care that such unit tests were completely broken. That can be traced to incompetence at programmer and managerial levels. When I left one project, I remarked that it was the only place I'd worked where I was required to produce work of which I was ashamed. I wasn't surprised to see the blank incomprehension on their faces :)
On 18/04/17 17:26, Tom Gardner wrote:
> Unfortunately I've also seen programmers use it > inappropriately, in a way that made me think of > "cargo-cult programming" and "religious dogma".
Definitely. See also: "stackoverflow-oriented programming": try { something; } catch(e) { window.location.href = "http://stackoverflow.com/search?q=[js] + " + e.message; } :) Clifford Heath.
On 18/04/17 11:44, Clifford Heath wrote:
> On 18/04/17 17:26, Tom Gardner wrote: >> Unfortunately I've also seen programmers use it >> inappropriately, in a way that made me think of >> "cargo-cult programming" and "religious dogma". > > Definitely. See also: "stackoverflow-oriented programming": > > try { > something; > } catch(e) { > window.location.href = "http://stackoverflow.com/search?q=[js] + " > + e.message; > } > > :) > > Clifford Heath.
Don't mention stackoverflow; I hate what is stands for with a vengeance. Typical topic: "which button do I push to make it turn green?" Apart from that, why did they bother to put anything in the catch clause. Despite my objections, that was SoP in one project I worked on. Stunning.
On Sun, 16 Apr 2017 09:13:39 -0400, bitrex <bitrex@de.lete.earthlink.net>
wrote:

>The graveyard of audio production equipment is littered with the corpses >of products that had rock-solid hardware designed by professionals, but >firmware written by nincompoops. > >It's really frustrating when you buy a blinky-light box that some >engineers somewhere likely spent thousands of man-hours on designing the >best sounding DAC structure they could for the budget, but then the OS >crashes when you accidentally try to load a file that's the wrong format.
I have PVR from Rogers Cable. Recently there was a cable outage. You'd think that we could watch the recorded programs. No such luck. -- Boris --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net>
wrote:

>On 04/17/2017 07:16 PM, Don Y wrote: >> On 4/17/2017 6:21 PM, Bill Martin wrote: >>> On 04/16/2017 07:51 AM, bitrex wrote: >>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>> >>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>> The graveyard of audio production equipment is littered with the >>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>> professionals, but firmware written by nincompoops. >>>>>> >>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>> >>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>> there with EE degrees. >>>> >>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>> patterns", "test-driven development", and "agile development." >>>> >>>> It's okay. It's really not that scary! You don't even have to be afraid >>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>> 1993 and nobody gets paid by number of classes derived from anymore. >>> >>> It's not so much "scared of", but the suspicion that the new emperor >>> has no >>> better clothes than the old emperor.. :-) >> >> The analogy *almost* fits. >> >> I think it *doesn't* fit when applied to things like OOP vs. procedural >> approaches. There's a definite distinction in how you think about >> problems (i.e., *solutions*) in the two approaches. And, while duality >> lets you (theoretically) transform an approach from one solution >> space to the other, it is impractical. >> >> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >> methodologies that try to improve quality, reliability, efficiency, etc. >> with a single idea that inevitably gets distilled to a terse mantra. Just >> like "don't run with scissors", it ignores a whole set of details that >> can (and do!) make a big difference in outcomes. > >Well, the new can be better than the old, but I still recall when Pascal >was gonna save us from ourselves...that's really the sticking point, >"save us from our selves". Doesn't work, our selves can be just as >stupid in a constrained grammar as in assembly code... :-( And damned >ingenious in finding new ways to "beat the system"!
Pascal was intended to teach block structured coding. It wasn't intended to be useful (note the crappy I/O). Of course given a screwdriver, someone will insist on making a hammer of it.
On Tue, 18 Apr 2017 08:51:09 -0400, Boris Mohar
<borism_void_@sympatico.ca> wrote:

>On Sun, 16 Apr 2017 09:13:39 -0400, bitrex <bitrex@de.lete.earthlink.net> >wrote: > >>The graveyard of audio production equipment is littered with the corpses >>of products that had rock-solid hardware designed by professionals, but >>firmware written by nincompoops. >> >>It's really frustrating when you buy a blinky-light box that some >>engineers somewhere likely spent thousands of man-hours on designing the >>best sounding DAC structure they could for the budget, but then the OS >>crashes when you accidentally try to load a file that's the wrong format. > > > I have PVR from Rogers Cable. Recently there was a cable outage. You'd >think that we could watch the recorded programs. No such luck.
That's done intentionally. Perhaps even contractually.
On Tue, 18 Apr 2017 20:50:34 -0400, krw@notreal.com wrote:

>On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net> >wrote: > >>On 04/17/2017 07:16 PM, Don Y wrote: >>> On 4/17/2017 6:21 PM, Bill Martin wrote: >>>> On 04/16/2017 07:51 AM, bitrex wrote: >>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>> >>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>> professionals, but firmware written by nincompoops. >>>>>>> >>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>> >>>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>>> there with EE degrees. >>>>> >>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>> patterns", "test-driven development", and "agile development." >>>>> >>>>> It's okay. It's really not that scary! You don't even have to be afraid >>>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>>> 1993 and nobody gets paid by number of classes derived from anymore. >>>> >>>> It's not so much "scared of", but the suspicion that the new emperor >>>> has no >>>> better clothes than the old emperor.. :-) >>> >>> The analogy *almost* fits. >>> >>> I think it *doesn't* fit when applied to things like OOP vs. procedural >>> approaches. There's a definite distinction in how you think about >>> problems (i.e., *solutions*) in the two approaches. And, while duality >>> lets you (theoretically) transform an approach from one solution >>> space to the other, it is impractical. >>> >>> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >>> methodologies that try to improve quality, reliability, efficiency, etc. >>> with a single idea that inevitably gets distilled to a terse mantra. Just >>> like "don't run with scissors", it ignores a whole set of details that >>> can (and do!) make a big difference in outcomes. >> >>Well, the new can be better than the old, but I still recall when Pascal >>was gonna save us from ourselves...that's really the sticking point, >>"save us from our selves". Doesn't work, our selves can be just as >>stupid in a constrained grammar as in assembly code... :-( And damned >>ingenious in finding new ways to "beat the system"! > >Pascal was intended to teach block structured coding. It wasn't >intended to be useful (note the crappy I/O). Of course given a >screwdriver, someone will insist on making a hammer of it.
In the days Pascal was created, the mainstream programming languages (COBOL and FORTRAN) did not have any block IF statements and the loop control was very limited. The same applied of course to all assembly languages. Thus, the only tool to affect the program flow was the GOTO statements. One had to invent target labels for the GOTO targets. At least in one FORTRAN dialect, it was possible to use the label number of a FORMAT statement as a target GOTO statement or to terminate the DO-loop :-). Lack of proper control structures made it hard to write easy to read programs. In Fortran IV I used GOTOs only for jumping forwards and DO-loops to return backwards. Unfortunately, the anti-GOTO lobby (Wirth, Dijkstra etc.) declared war against GOTOs, while IMHO a better approach would have been to state that the better control structures would reduce the need for inventing labels and branching over the "else" parts. The anti-COTO lobby claimed that programs using GOTOs create "spagetti-code". In my career, I have only seen one bad spagetti-code in an old COBOL programs, in all other cases, people tried to keep the program flow more or less simple, even if the only control structure was th GOTO statement.
On 4/17/2017 4:22 PM, bitrex wrote:
> On 04/17/2017 08:47 AM, Tom Gardner wrote: >> On 17/04/17 11:56, bitrex wrote: >>> On 04/16/2017 07:00 PM, Lasse Langwadt Christensen wrote: >>>> Den s&oslash;ndag den 16. april 2017 kl. 16.51.46 UTC+2 skrev bitrex: >>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>> >>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>> professionals, but firmware written by nincompoops. >>>>>>> >>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>> >>>>>> HEY! There's a lot of profoundly good embedded software engineers >>>>>> out >>>>>> there with EE degrees. >>>>>> >>>>> >>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>> patterns", "test-driven development", and "agile development." >>>> >>>> there is also the opposite, where using the latest greatest half done >>>> pre-alpha languages, libraries, tools and buzz word development models >>>> they only understand half of gets priority over making stuff that >>>> actually works >>>> >>> >>> There are probably four or five languages that came out in the past >>> decade that >>> have as their "mission statement" something like "To develop a >>> language which >>> has the ease of use, expressiveness, and safety of an interpreted >>> language, and >>> the execution speed of a compiled language." >>> >>> People still use C++ a lot... >> >> There is a fad cycle. >> >> People don't like strongly typed languages because >> they are "too constraining" and "too verbose". So >> they invent yet another more-or-less untyped language. >> >> They then find that they've lost the ability to: >> - inspect and draw solid conclusions about other >> people's codebase >> - use code-completion to speed typing and avoid >> mistakes >> - detect errors at compile time; they have to hope >> they can detect them at run time before their >> customers detect them >> So then they realise the benefits of strongly typed >> languages, and swap to the latest variant thereof. > > the "auto" automatic type deduction keyword available in C++11 onwards > helps cut down on the verbosity a lot; I use it wherever possible, in > C++14 it's even available for use to automatically deduce function > return types.
What people don't get about strong typing is that it isn't as much to tell the compiler what the type is as to clarify it for the programmer. Or maybe I should say it is to make the programmer consider the type so they don't make typing mistakes. -- Rick C
On 04/19/2017 09:19 AM, upsidedown@downunder.com wrote:
> On Tue, 18 Apr 2017 20:50:34 -0400, krw@notreal.com wrote: > >> On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net> >> wrote: >> >>> On 04/17/2017 07:16 PM, Don Y wrote: >>>> On 4/17/2017 6:21 PM, Bill Martin wrote: >>>>> On 04/16/2017 07:51 AM, bitrex wrote: >>>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>>> >>>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>>> professionals, but firmware written by nincompoops. >>>>>>>> >>>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>>> >>>>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>>>> there with EE degrees. >>>>>> >>>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>>> patterns", "test-driven development", and "agile development." >>>>>> >>>>>> It's okay. It's really not that scary! You don't even have to be afraid >>>>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>>>> 1993 and nobody gets paid by number of classes derived from anymore. >>>>> >>>>> It's not so much "scared of", but the suspicion that the new emperor >>>>> has no >>>>> better clothes than the old emperor.. :-) >>>> >>>> The analogy *almost* fits. >>>> >>>> I think it *doesn't* fit when applied to things like OOP vs. procedural >>>> approaches. There's a definite distinction in how you think about >>>> problems (i.e., *solutions*) in the two approaches. And, while duality >>>> lets you (theoretically) transform an approach from one solution >>>> space to the other, it is impractical. >>>> >>>> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >>>> methodologies that try to improve quality, reliability, efficiency, etc. >>>> with a single idea that inevitably gets distilled to a terse mantra. Just >>>> like "don't run with scissors", it ignores a whole set of details that >>>> can (and do!) make a big difference in outcomes. >>> >>> Well, the new can be better than the old, but I still recall when Pascal >>> was gonna save us from ourselves...that's really the sticking point, >>> "save us from our selves". Doesn't work, our selves can be just as >>> stupid in a constrained grammar as in assembly code... :-( And damned >>> ingenious in finding new ways to "beat the system"! >> >> Pascal was intended to teach block structured coding. It wasn't >> intended to be useful (note the crappy I/O). Of course given a >> screwdriver, someone will insist on making a hammer of it. > > In the days Pascal was created, the mainstream programming languages > (COBOL and FORTRAN) did not have any block IF statements and the loop > control was very limited. The same applied of course to all assembly > languages. > > Thus, the only tool to affect the program flow was the GOTO > statements. One had to invent target labels for the GOTO targets. At > least in one FORTRAN dialect, it was possible to use the label number > of a FORMAT statement as a target GOTO statement or to terminate the > DO-loop :-). Lack of proper control structures made it hard to write > easy to read programs. In Fortran IV I used GOTOs only for jumping > forwards and DO-loops to return backwards. > > Unfortunately, the anti-GOTO lobby (Wirth, Dijkstra etc.) declared war > against GOTOs, while IMHO a better approach would have been to state > that the better control structures would reduce the need for inventing > labels and branching over the "else" parts. > > The anti-COTO lobby claimed that programs using GOTOs create > "spagetti-code". In my career, I have only seen one bad spagetti-code > in an old COBOL programs, in all other cases, people tried to keep the > program flow more or less simple, even if the only control structure > was th GOTO statement. > >
There are other reasons not to like GOTOs much. They confuse optimizers, for one thing, and can make code harder to read. It isn't so much the GOTO that's bad as the named label. Reading some random chunk of code, my heart always hits my boots when I come across a named label in some gigantic function--usually but not always there's a goto three screen-fulls away that I have to go find. Sometimes the coder is a sportsman and deletes the goto but leaves the label. There are still good uses for GOTO, e.g. some versions of Duff's Device for loop unrolling, or bailing out of nested loops on some error condition. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
On 04/19/2017 11:38 AM, rickman wrote:

>> the "auto" automatic type deduction keyword available in C++11 onwards >> helps cut down on the verbosity a lot; I use it wherever possible, in >> C++14 it's even available for use to automatically deduce function >> return types. > > What people don't get about strong typing is that it isn't as much to > tell the compiler what the type is as to clarify it for the programmer. > Or maybe I should say it is to make the programmer consider the type so > they don't make typing mistakes. >
It can't stop active malice (or extreme stupidity.) With C++ if you're determined you can often find a way to cast things to get something to take a value or type that it shouldn't. Even with "auto" scattered everywhere instead of a function that returns const std::vector<MyClass<std::string..... etc> it's still all strongly-typed. You might not be able to tell immediately what type the function is returning; you might not even know precisely at compile-time if the return signature depends on a template parameter. But the compiler will definitely let you know and fail with an error if you try to stick the output of that function to the input of something where it doesn't belong. The Volt locks the gearshift whenever it senses that it's plugged in and prevents you from shifting out of park. That's saved me from "everyday stupidity" several times!