Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Joerg on 12 Aug 2008 13:55 Jan Panteltje 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? By learning about mistakes that happened and about their consequences. I learn a lot when I disect a design tossed over my fence with the request to find a solution and with comments such as "we can't reliably produce this in quantities" or "we have this, that and the other problem with it in the field". [...] -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Guy Macon on 12 Aug 2008 15:28 Martin Brown wrote: >You will just love Unlambda then... >http://www.madore.org/~david/programs/unlambda/#what_is >;-) I do! Thanks! I am also rather fond of LOLPython: http://www.dalkescientific.com/writings/diary/archive/2007/06/01/lolpython.html http://lolcode.com/ http://en.wikipedia.org/wiki/LOLCODE (This sure beats talking about the Larrabee graphics chip...) -- Guy Macon <http://www.GuyMacon.com/>
From: Ken Maltby on 12 Aug 2008 16:15 "Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message news:g7sini$ja6$1(a)aioe.org... > 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. > The original thread was "crossposted" to rec.video.desktop and I took a position similar to what you have here. (So the "reversed battery" was a bad memory stick, I never saw a post from the OP of that thread as to the actual source of the problems.) > 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. > A current opportunity that may illustrate your point: "Caligari is releasing the latest version of trueSpace for free, and including all their training courses for free as well. As someone who has spent hundreds on their earlier versions and tutorial/training packages, I view this with mixed feelings, but it is a great opportunity for anyone looking for a full featured 3D Authoring package. With the training courses ( which you really need ) thrown in, it amounts to a free college semester in Graphic design or one of those "Learn how to create Games" courses." http://www.caligari.com/ It is not easy to jump right into such programs and learning to do the simplest things in such an environment will take some study (in this case there are plenty of tutorials available, though); but that doesn't make it "bad software design". Luck; Ken
From: Wilco Dijkstra on 12 Aug 2008 16:39 "Ken Hagan" <K.Hagan(a)thermoteknix.com> wrote in message news:op.ufro69ress38k4(a)khagan.ttx... >>> 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... Actually, despite this, hardware is full of bugs as well. It's just that most people don't notice them. A lot of work in the BIOS and OSes goes into making such bugs invisible to the average user. Hardware typically has a long testing cycle with many revisions and bugfixes before release. This catches most of the obvious issues, but hardware is by no means bug free. A typical CPU has 10-100 known bugs (many of which are worked around in software) and probably a similar amount of unknown ones. If things go wrong, people usually blame the software... > 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. Also hardware solves a well defined problem with a limited set of inputs and outputs that is invariably well specified and not subject to changing requirements. Given such a well specified problem it is actually easier to implement it in software with 100% correctness. Consider floating point emulation in software as an example of such a problem. The problems software solves are usually larger and more complex, often without a detailed specification and, worse, constantly changing requirements. Such problems are not even considered for hardware implementation, but it is the reality for a lot of software. Wilco
From: Nick Maclaren on 12 Aug 2008 17:56
In article <tSmok.154054$dz3.98710(a)newsfe20.ams2>, "Wilco Dijkstra" <Wilco.removethisDijkstra(a)ntlworld.com> writes: |> |> > At last something that we can agree on. Too much software is not properly designed. Modern compilers these days have a |> > fair amount of static testing built in, but nothing like enough to solve the problem of below average coders and poor |> > or no specifications or design documents. |> > |> > 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. There are at least two major classes of bug where it is false, and C does especially badly: 1) Bugs introduced by an inconsistent, ambiguous or unreasonable standard. 2) Bugs which are provably easy to detect (e.g. array bound or arithmetic overflow). Regards, Nick Maclaren. |