Computers and heat density
THX1138 at dakotacom.net
Sun Aug 13 20:00:11 CDT 2006
Bill Sudbrink wrote:
> Don wrote:
>> Jules Richardson wrote:
>>> Tim Shoppa wrote:
>>>> Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
>>>>> Why it's getting steadily worse, I don't know. I'm tempted to lay the
>>>>> blame at the feet of faster and more widespread communications; if
>>>>> people can communicate more quickly and further afield then there'll
>>>>> be more pressure to get a job done as quickly as possible and with an
>>>>> eye to short-term savings only.
>>>> I was tempted to think that in the 2000 era we had gotten past the hump
>>>> of "buy more hardware because it's cheap" stage.
>>> I think the problem there was that the software guys saw that people
>>> were buying lots of hardware because it was cheap, and bloated their
>>> code out to match :(
>> And, to be honest, I think "we" (developers, etc.) also take
>> advantage of the improvements in technology. Laziness creeps
>> in. E.g., I had to write a nice little search algorithm
>> to minimize a function. I didn't hesitate to pass int
>> arrays AS ARGUMENTS to the *recursive* function (e.g.,
>> it will recurse to a depth of ~50 and each invocation
>> carries 200 bytes of int arguments). Sure, I could
>> write something more elegant but it's a throw-away
>> algorithm (to verify some parameters) that I *may* use
>> twice more in my lifetime??
> The very idea that you can pass anything other than LVALUES as
> parameters is evil. Jackass language designers (Oh! I'm going to
> design the silver bullet language that it is impossible to write a
> bug in) and compiler writers are to blame. Really, everything
> should still be written in assembler. C is just a portable
> assembler. I'm not kidding here.
I don't blame languages. I blame the folks who either
don't fully understand the characteristics/consequences of
certain language features *or* the folks who don't
understand (nor appreciate) how to *test* things.
Languages should give the developer freedom to express
whatever algorithm he/she needs to without coloring it.
The developer should be able to make realistic tradeoffs
(development time, code size, data size, run-time
efficiency, reliability, maintenance, etc.) to *justify*
his/her implementation choices. Each of those tradeoffs
has a REAL *cost* associated with it -- if those aren't
visible to the developer (or whomever is making the decisions
FOR the developer!) then No Good Results.
More information about the cctalk