Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Ken Hagan on 12 Aug 2008 05:41 >> John Larkin wrote: >>> than the older ones. In products with hardware, HDL-based logic, and >>> firmware, it's nearly always the firmware that's full of bugs. If >>> engineers can write bug-free VHDL, which they usually do, why can't >>> programmers write bug-free C, which they practically never do? Whilst not disputing that hardware folks probably come to the table with a rather different attitude to bugs... Given a problem to be solved by a combination of hardware and software, the hardware is usually used *merely* (ducks for cover) to provide a set of primitives which the software will then stick together in a more complex way. The software would then be solving a more complex or less well specified problem and might reasonably be expected to have more of the bugs. A second effect is that any deficiencies in the chosen set of primitives is likely to lead to bugs that get blamed on software rather than the design. Even if the correct attribution is made, software usually *is* easier to change (and later in the development schedule) so managers decide to "fix it in software". A third effect is that *application* software has so many dependencies on code written by people you have never met and who have no interest in your welfare. If we are to compare bug rates in hard/firm/soft-ware then we'd need to direct our gaze at things like interrupt handlers and the lowest levels of device drivers. A fourth effect is that customer expectations are different (and software often *can* be changed after purchase) and so the commercially sensible decision is to be first to market and accept a non-zero level of bugs.
From: Martin Brown on 12 Aug 2008 07:00 Guy Macon wrote: > John Larkin wrote: >> Guy Macon <http://www.GuyMacon.com/> wrote: >> >>> Kim Enkovaara wrote: >>>> At least in the high-end of the embedded systems processor updates and >>>> model changes are quite frequent. The lifetimes of processors >>>> and their peripherials (especially DRAM memories) is becoming shorter >>>> all the time. The code has to be portable and easily adaptable to >>>> different platforms. >>> And at the very low end, changes to completey different processors >>> are also very common. If someone comes up with a micro that costs >>> 8.4 cents and replaces a part that costs 8.5 cents, that's a saving >>> of $16,800 per week at a production rate of 100,000 units per hour. >>> After a while you get the attitude of "ho hum, another assembly >>> language instruction set." >> Assembly? You don't program musical greeting cards and blinking >> sneakers in Python? > > Actually, I use the BEST programming language. > > BEST is a programming language that I developed > to answer the frequently asked question "Which > programming language is best?" once and for all. > > BEST is a Befunge-93[2] pseudocompiler written in > Malborge[3][6] with library calls to routines written > in Microsoft[4] Visual BogusFORTH+++[7] (!Kung edition)[9] > that invoke various trinary functions written in[5] > Reverse Polish Whitespace (for clarity).[1] You will just love Unlambda then... http://www.madore.org/~david/programs/unlambda/#what_is ;-) Simplified, Turing complete but devlishly hard to do anything in. Regards, Martin Brown ** Posted from http://www.teranews.com **
From: Jan Panteltje on 12 Aug 2008 12:43 On a sunny day (Tue, 12 Aug 2008 09:23:30 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <n3e3a496ruddt5ntdguumm2fovku6p4tlv(a)4ax.com>: >My code works fine, because I approach it as engineering, and because >I'm not a programmer, and because I hate to program. > >Read "Showstopper!" and "Dreaming in Code" to see how the real pros do >it. When I had the TV shop, some guy told me: Go look at the competition, see how they do it. And my reply was, and still is: Let the competition look at me :-) So, HOW do you think you will learn to program better by reading about how it is done wrong? You only will learn to program better by looking at great code, and: learning from those coders. This is why open source is so incredibly important. Instead of every new programmer starting to make all mistakes all over again in writing some application, you can build and improve on previous work. This is why Linux takes that incredible flight, thousands and thousands of individuals contributing, like one big brain. Now put that against those few brain washed newby ex-student programmers working in and for Redmond. You know, I am grateful if somebody takes the trouble of pointing out a flaw in my code. Sure there is that moment of 'aaarg, what was this' (old code maybe years old, you need to look it up and regain the understanding of the whole flow), but it (the code) lives on, it will outlive you, it will teach new people, they will further improve it. What a difference with the sad mouse-clickers in Redmond, who will be obsolete with the next feature limited version of their OS. R
From: John Larkin on 12 Aug 2008 13:24 On Tue, 12 Aug 2008 16:43:30 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Tue, 12 Aug 2008 09:23:30 -0700) it happened John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in ><n3e3a496ruddt5ntdguumm2fovku6p4tlv(a)4ax.com>: > >>My code works fine, because I approach it as engineering, and because >>I'm not a programmer, and because I hate to program. >> >>Read "Showstopper!" and "Dreaming in Code" to see how the real pros do >>it. > >When I had the TV shop, some guy told me: >Go look at the competition, see how they do it. >And my reply was, and still is: Let the competition look at me :-) > > >So, HOW do you think you will learn to program better by reading about how it is >done wrong? As I've said, my programs work fine. I have no immediate need to "learn to program better", any more than I need to learn to solder better. But I am fascinated by technology disasters of all kinds, and modern "computer science" has given us lots of juicy examples. And studying failure is a valuable technique for avoiding same. I recently evaluated three general-purpose drawing programs, one public-domain and two commercial. All three were horrors, undrivable or buggy as sin. Open Office Draw looks OK, if you don't mind the 127 Mbyte download. John
From: Jan Panteltje on 12 Aug 2008 13:53
On a sunny day (Tue, 12 Aug 2008 10:24:55 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <6bh3a4tlp7npnntr1nuthgdsival4akknv(a)4ax.com>: >>So, HOW do you think you will learn to program better by reading about how it is >>done wrong? > >As I've said, my programs work fine. I have no immediate need to >"learn to program better", any more than I need to learn to solder >better. But I am fascinated by technology disasters of all kinds, and >modern "computer science" has given us lots of juicy examples. > >And studying failure is a valuable technique for avoiding same. Sure. >I recently evaluated three general-purpose drawing programs, one >public-domain and two commercial. All three were horrors, undrivable >or buggy as sin. Open Office Draw looks OK, if you don't mind the 127 >Mbyte download. > >John be careful, one thing that sort of did hit me was this posting: http://groups.google.com/group/rec.video.production/browse_thread/ thread/697ce9df60d62731/8f540eb5adcef401?lnk=gst&q=wits#8f540eb5adcef401 (I have folded the URL as the server complained last time it was too long). the poor guy had a defective memory module in his PC, he found all programs sucked, all his work for nothing, anyways after somebody pointed him to a memory test program, and he finally replaced the defective memory, and then I advised him to re-install his stuff, which he did not immediately do.. anyways the problems then later disappeared. Many modern programs (like drawing programs, you are not specific so what do I know) have complex interfaces, and need considerable time to get used to, and you need time to even learn where to find the functions, etc. In the same way, one who is used to one make video-editor, may flip out completely on the user interface of one made by some other company. For some of those softwares you may need MONTH of training before you can even claim to be a user. A simple example: Blender http://www.blender.org/ , have it on my system for well, more then 8 years? from its beginning, it can do amazing things, even made leaders for VHS productions with it, it gets more complex all the time, and learning to use it takes more then a few days, not even counting your artistic capabilities. So I am not buying : 'That software sucks'. If it crashes, OK that is bad. Anyways, you jump from one issue to the other, I'd say: relax, maybe the sun even shines over there, here it is rainy, do not get all purked up by soft you do not like. In the very beginning of Linux (I started with SLS Linux (Where SLS stood for 'Soft Landing Systems') ), if I needed an application, then often it simply was not there, or was not the way I wanted, so wrote it myself. I am sure deep in your heart you _do_ like programming, I have seen your enthusiasm for your jump tables in asm, so if must be, start writing your own drawing program. I mentioned Blender, that is how Blender started, those guys at NaN (Not A Number) wanted something better, they acted. Else it all is just blah blah and does not help the world, a world of complainers is no good to anybody. |