#ObjectOriented
7 messages in this thread
>>I suppose it is the same trade off between low level efficiency and fast
>>development that has been going on since programming began.
>
>Agreed.
This is certainly not wholeheartedly the issue.
>Not programming in assembler has cost me a few years of my life in
>solving compiler bugs.
I've never heard this before. You must have has some serious extenuating
circumstances that you are not going into.
Don't get me wrong: I've had a plethora of doozies happen to me over
the years with compilers, but I'd hardly call it man-years of punishment
or work to reconcile. Heck, I'm a compiler writer, and even bugs in my
own compilers have not cost man years to reconcile.
>This is why I returned to it. I assure you: it was a
>REAL pain in the ass being used to the comfort of high languages BUT I have
>fewer bugs now AND they are much much easier to find.
I can understand if you're writing something highly specific to some CPU,
or it is imperitive to be handled in .Xseconds, etc, but I'd hardly feel
encouraged to write a multi-million line app in assembler (I'm not even
encouraged to write it in a HLL).
But let's branch out of the personal preferences zone for a minute or two.
What were the HLL features that turned you off? (BTW, my goal is not to turn
this into a language war or anything similar and hope all participants agree).
>There is one, extremely important advantage to programming in assembler
>instead of other languages: all the bugs are YOURS!
I don't understand. That simply does not follow. For instance, you really
have not found a bug in any assembler (really, another flavor of compiler,
which you seem to hate so much!) ever? There are pros and cons and
compromises to everything. Surely, you have run into them while doing your
various assembler apps over the years, yes? Assembler is definitely not the
silver bullet you continue to imply within this context for anybody who has
experience using it and it does not mean all the bugs are yours.
BTW, and I'm not trying to be a wise guy, but as an attempt to perhaps
stroke at the heart of the matter: how come you do not program directly
in binary?
>>But I would expect OO to make programs less buggy.<<
>
>In principle, I won't disagree with this. BUT! Isn't it LOGICAL to speak the
>language of the computer instead of learning another language that is
>ultimately translated to machine language anyway?
Ah! Like I've just said then: why don't you program and write your
code in binary?
No, IMO, it's not logical or common sense to do so.
What it logical is to approach something aware of the goals and costs and
compromises.
>>>Not programming in assembler has cost me a few years of my life in >solving
compiler bugs.
I've never heard this before. You must have has some serious extenuating
circumstances that you are not going into.<<
I did, when writing “portable'' code. There were different bugs in the
different compilers and the code had to be written so that all bugs were
circumvented. In the end it was a non-useable program.
>>But let's branch out of the personal preferences zone for a minute or two.
What were the HLL features that turned you off? <<
Mainly two: IF there is a bug in the HLL it can be nearly impossible to solve,
and HLL's work slower than assembler. Since people are prepared to pay much for
a faster computer to work more efficiently it definitely makes sense writing
everything in assembler even if you have the fastest computer.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
(off the thread topic, but I can't resist):
>> .. people are prepared to pay much for a faster computer ..
That's to overcome the sluggishness of present day programs (using sloppy
compilers?) and operating systems such as Windows ..
<g>
–Jim
>> .. people are prepared to pay much for a faster computer ..
>That's to overcome the sluggishness of present day programs (using sloppy
>compilers?) and operating systems such as Windows ..
> <g>
<g> indeed! Seriously though, I get concerned about this because I seem to
see a trend (at least a sub-one) where folks have no problem adding beasts
atop of beasts. Although I think this might have its place for say a quick
access to a DOS-box, or even MS-Windows, from under UNIX w/o having to
reboot, surely native apps under Windows, it's like hey, wow, what's
happenning sometimes 🙁 I've been trying to hit home on this somewhat
when I teach lately, but the sluggishness, sloppiness, and laziness of some
_programmers_ is certainly to be condemned.
>> That's to overcome the sluggishness of present day programs (using sloppy
compilers?) and operating systems such as Windows ..
<g><<
How true…
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>Not programming in assembler has cost me a few years of my life in >solving
>compiler bugs.
>…when writing “portable'' code. There were different bugs in the
>different compilers and the code had to be written so that all bugs were
>circumvented. In the end it was a non-useable program.
I still contest that you've have some VERY extenuating circumstances.
One of this things I am extremely well known for is the vast number of
machines and operating systems that Comeau C++ is available for. Ditto for
some other products and other code I've ported "everywhere".
Such a dilemma need not be.
>Mainly two: IF there is a bug in the HLL it can be nearly impossible to solve,
Nearly impossible is quite an overstatement. I've solved many and I know
other people who have too, including optimizer bugs, which can be most
elusive.
>and HLL's work slower than assembler.
You mean compile-time-wise? Although common sense seems to implicitly imply
this would be the case (I mean, "what's so complicated about assembler
since it's compilating is a simplier mapping from the instruction to object
code"), I'm _positive_ that I could demonstrate cases where this would not be
the case.
> Since people are prepared to pay much for
>a faster computer to work more efficiently it definitely makes sense writing
>everything in assembler even if you have the fastest computer.
Sometimes. I'm more interested in a reasonable tradeoff wrt power of
expression, maintenance, readibility, manipulation, etc.
In fact, I'd be more apt to get a faster computer with a slower app
than write it in assembler. Most definitely. Also, as you mention
portability above, I'm definitely not going to rewrite my XX/YYYKLOC apps
everytime I go to a machine with a different CPU. Even on a CPU family,
what made sense with one machine, may not be optimal on the upgraded CPU
(it should still work though). And with assembler, since it is so low
level, even if I have to rip out parts of my app do to say user input,
I have to rip and throw out more in general, which seems to defeat part of
the point of it all. I can see if we're talking about jamming something
into a talking Coke Machine, or need something kick butt in say a device
driver, but you can count me out of doing say my business apps in assembler
(and yes, I know what it is like doing so).
>>You mean compile-time-wise?<<
No. I speak run-time wise. Compile-time is, in my view, not really an issue.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…