Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Terje Mathisen on 13 Aug 2008 02:08 Martin Brown wrote: > Agreed. I have lost count of the number of places that have looked > awfully hurt when I ran static testing software against their production > codebase and found lots of latent bugs, unused variables and unreachable > dead wood code. I reckon some C programmers take it as a challenge to > add random casts to parameters until the code compiles. The next stage is to run a dynamic testing suite as a wrapper around the program: I used to use BoundsChecker which knows about most of the Win32 APIs, it was amazing how many bugs, errors, and just bogus api usage it would catch, even when running against very expensive, but quite simple applications like accounting packages. :-( Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen on 13 Aug 2008 02:24 Wilco Dijkstra wrote: >> It will draw fire from the C is always wonderful crowd but I expect you can live with that. And it isn't strictly the >> C language that is at fault. There is plenty of good well documented software written in C. > > Exactly. A poor programmer is going to be a poor programmer no matter > what language they use. It's always fun to see how people believe that > so called "safe" languages are really a lot "safer". The bugs just move > elsewhere. For example garbage collection solves various pointer problems > that inexperienced programmers make. However it creates a whole new > set of problems. Or the runtime system or libraries are much bigger and so > contain their own set of bugs on each platform etc. The most common serious problem I've seen with programs written in GC languages is when they try to do any kind of external communication: I.e. using Oracle database handles as if they were an infinite resource which the GC will always be able to clean up is a very good way to crash all the web front ends that share a common back-end DB. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Chris M. Thomasson on 13 Aug 2008 04:00 "Terje Mathisen" <terje.mathisen(a)hda.hydro.com> wrote in message news:UaOdncdd4Jfw5T_VnZ2dnUVZ8rGdnZ2d(a)giganews.com... > Martin Brown wrote: >> 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. > > You, my friend, have sick mind. > > OTOH, the first macro language I came up with, for a terminal > emulator/file transfer program, was only slightly more readable. :-( Ouch. [...]
From: Chris M. Thomasson on 13 Aug 2008 04:03 "Terje Mathisen" <terje.mathisen(a)hda.hydro.com> wrote in message news:GvudnWmr9--74z_V4p2dnAA(a)giganews.com... > Wilco Dijkstra wrote: >>> It will draw fire from the C is always wonderful crowd but I expect you >>> can live with that. And it isn't strictly the C language that is at >>> fault. There is plenty of good well documented software written in C. >> >> Exactly. A poor programmer is going to be a poor programmer no matter >> what language they use. It's always fun to see how people believe that >> so called "safe" languages are really a lot "safer". The bugs just move >> elsewhere. For example garbage collection solves various pointer problems >> that inexperienced programmers make. However it creates a whole new >> set of problems. Or the runtime system or libraries are much bigger and >> so >> contain their own set of bugs on each platform etc. > > The most common serious problem I've seen with programs written in GC > languages is when they try to do any kind of external communication: > > I.e. using Oracle database handles as if they were an infinite resource > which the GC will always be able to clean up is a very good way to crash > all the web front ends that share a common back-end DB. I thought GC was the silver-bullet of memory management! lol.
From: Nick Maclaren on 13 Aug 2008 04:02
In article <aqook.200536$IP7.138587(a)newsfe16.ams2>, "Wilco Dijkstra" <Wilco.removethisDijkstra(a)ntlworld.com> writes: |> |> It's certainly true the C standard is one of the worst specified. However most |> compiler writers agree about the major omissions and platforms have ABIs that |> specify everything else needed for binary compatibility (that includes features |> like volatile, bitfield details etc). So things are not as bad in reality. Er, no. I have a LOT of experience with serious code porting, and am used as an expert of last resort. Most niches have their own interpretations of C, but none of them use the same ones, and only programmers with a very wide experience can write portable code. Note that any application that relies on ghastly kludges like autoconfigure is not portable, not even remotely. And the ways in which that horror is used (and often comments in its input) shows just how bad the C 'standard' is. Very often, 75% of that is to bypass deficiencies in the C standard. A simple question: have you ever ported a significant amount of code (say, > 250,000 lines in > 10 independent programs written by people you have no contact with) to a system with a conforming C system, based on different concepts to anything the authors were familiar with? I have. Regards, Nick Maclaren. |