http://www.joelonsoftware.com/items/2009/09/23.html

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> http://www.joelonsoftware.com/items/2009/09/23.html
>=20

I don't know the author; I found the text in one of the American-Russian =

forums and translated it.

//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
Any Russian Programmer=85

After a two-minute look at a code, any Russian programmer will certainly =

jump up and say to himself: all of that should be rewritten! Then he=20
will feel some doubts about how much time it would take, and he will=20
spend the rest of the day trying to convince himself that it only seems=20
to be a lot of work. Sure, if he would work at this seriously,=20
everything could be done. Then, the code would be correct and beautiful.

Next morning, the Russian programmer looks sharp and very proud as he=20
reports to the boss that it would take no more then a day to rewrite=20
that piece of code. Yes, no more then a day. Maybe two days, in the=20
worst case, if all risks are taken into account. As a result, the boss=20
gives him a week. The process is successfully completed in half a year.=20
Until the code will be revised by some other Russian programmer.

In the meantime, four Chinese programmers keep doing their hard work in=20
four adjacent cubicles without stopping for a second. They come to work=20
much earlier and leave much later then the Russian programmer; however,=20
they somehow manage to accomplish about three times less. Those four=20
haven=92t written anything new for a while, and only support the code tha=
t=20
was created in its time by the Hindu and rewritten twice by two=20
different Russians. This code is not just infested by bugs; it is a=20
stronghold of bugs. From here, the bugs are continuously recreated by=20
the favorite Chinese technology of code reuse: Copy/Paste. The bugs are=20
spread by static variables and references to the static variables (It is =

well known that no Chinese programmer can tolerate the inconvenience of=20
not been able to access a variable directly).

When the Russian programmer remembers about these variables and=20
references, he loses the clarity of his speech. He starts swearing in=20
Russian and English at the same time. For a long time, he has been=20
dreaming of rewriting the whole piece of code on which the Chinese are=20
working, but he doesn=92t have time to do that. He is already rewriting=20
two big modules, and he just proved to the boss that the third module=20
has to be rewritten as well. Besides, the Russian programmer tries not=20
to offend the Chinese programmers. By the way, his concerns are in vain; =

the Chinese have already decided that the Russian is trying to push them =

out of work.

The Chinese are responsible for serious bugs in the code. The boss knows =

about it and he hurries them. The Chinese respect the boss; that=92s why =

they are trying to hang the bugs on each other. They know that all=20
attempts to fix the bugs will only result in the creation of new bugs.=20
That will only make the situation worse. And they are very right about=20
it. The only man in the company who knows how those static variables=20
change their values is the Hindu. But he is meditating.

That=92s why all four of the Chinese will be let go at the time of the=20
next layoff=85 But who else should be let go? The Russian is still not=20
finished rewriting his code, and the Hindu - the most valuable asset of=20
the company - rarely pays any attention to the project, but, when he=20
does, everybody understands that no one knows the software architecture=20
better then he does. So, after the Chinese are fired, their code can=20
have two different fates. The first =96 the Russians will get it, and the=
y=20
will rewrite it. The second - the local Canadian programmer will get it.

Yes, the Canadian programmer is a special character. He rushes like a=20
knight to fix the most fearsome Chinese bug. This Bug has already dwelt=20
inside the code for three years, and the Chinese have already reported=20
to the boss that the bug is fixed four times (each of the programmers=20
reported it once). But the Bug returned every time, like Batman to=20
Gotham City.

The Canadian programmer, raised on the heroic pathos of American=20
football, rushes into battle headfirst, doing what the Chinese haven=92t =

risked doing for three long years. He will find a place where the static =

variable takes a value of 1 instead of the correct value of 0, and=20
resolutely add the other variable with the correct value nearby. The Bug =

will perish in an unequal battle with the hero. However, victory will be =

achieved by a high price. Everything will quit working, including the=20
code that was just rewritten by the Russian programmer.

This will put the Russian programmer deep into thought for two days.=20
After that, he will come to the predictable conclusion that the design=20
was wrong from the very beginning, and everything has to be redone. This =

task will probably take a week. Yes, surely no more than a week.

The Canadian programmer will bravely rush to fix everything, and=20
everything will become worse, even though it seemed... This commotion=20
will bring the Hindu out of his meditation, who will come up with a=20
completely genius solution =96 branch the code out. According to his plan=
,=20
we would now support two versions of the same code =96 one working, but=20
with the Bug, the other without the Bug, but not working. The Russian=20
programmer, hearing of this plan, will break his ruler over the table=20
and call his wife an idiot, but will not dare to disagree at the meeting.=


Fortunately, this won=92t significantly affect the company=92s dealings, =

since the product is still sold. That=92s why the management is generally=
=20
satisfied, and does not tire of reminding everybody that they are picked =

as the best from the best. And that we have long ago proved our ability=20
to release the product, since we occasionally release it.

//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D


VLV

Vladimir Vassilevsky wrote:
> 
> 
> Jerry Avins wrote:
> 
>> http://www.joelonsoftware.com/items/2009/09/23.html
>>
> 
> I don't know the author; I found the text in one of the American-Russian 
> forums and translated it.
> 
> //===========================
> Any Russian Programmer�
> 
> After a two-minute look at a code, any Russian programmer will certainly 
> jump up and say to himself: all of that should be rewritten! Then he 
> will feel some doubts about how much time it would take, and he will 
> spend the rest of the day trying to convince himself that it only seems 
> to be a lot of work. Sure, if he would work at this seriously, 
> everything could be done. Then, the code would be correct and beautiful.

Maybe my Russian ancestry shows a bit!


Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:

> http://www.joelonsoftware.com/items/2009/09/23.html
> 
> Jerry

No one has ever come to me years after I released some engineering work 
and said "damn, but it's nice that you got that done so quick".  But they 
have come to me years -- decades, even -- and said "You schmuck*!  Your 
code is broken!".

Perhaps if you're working on consumer goods you can have that sort of 
attitude -- but would you want to live in a house built with that lack of 
care?  How about the software that runs the anti-lock brakes on your 
car?  Get a pacemaker whose code is written by that guy?  Know that the 
nations warplanes, ships, bombs and fighting vehicles depend on software 
written by that guy?

Think about it...

* Well, "schmuck" with four letters.

-- 
www.wescottdesign.com

Tim Wescott <tim@seemywebsite.com> wrote:
> Jerry Avins wrote:
> 
> > http://www.joelonsoftware.com/items/2009/09/23.html
> > 
> > Jerry
> 
> No one has ever come to me years after I released some engineering
> work and said "damn, but it's nice that you got that done so quick". 
> But they have come to me years -- decades, even -- and said "You
> schmuck*!  Your code is broken!".
> 
> Perhaps if you're working on consumer goods you can have that sort of 
> attitude -- but would you want to live in a house built with that lack
> of care?  How about the software that runs the anti-lock brakes on
> your car?  Get a pacemaker whose code is written by that guy?  Know
> that the nations warplanes, ships, bombs and fighting vehicles depend
> on software written by that guy?

You have a point. However, if you get something that works part of the
time then you can use it to test other things.

And if something is being done that requires a complex software project,
there's a strong chance there will be something broken elsewhere. Broken
hardware, broken specs, broken fundamental concepts, broken physics,
etc.

There's a pretty good chance that they won't find out what else is wrong
until they get working software to reveal the problems.

It isn't real good to have code that sometimes fails and it takes effort
to find out whether it's the code or something else that failed. But
that's a whole lot better than not having code to test at all.

So there's a lot to be said for starting with some sort of bare-bones
prototype that does just enough to test out the system. And then get a
proof-of-concept that shows basicly what you think can be done and how.
And a test user interface so potential users can tell you what's wrong
with it. And then an attempt at a real product that's still as much as
possible simple.

And maybe then you can start work on the product that does everything
right, while you go on maintaining and improving the existing product
that's bringing in the money to pay for the development effort. If the
really good system never gets released, at least you have something.

>On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:
>
>> http://www.joelonsoftware.com/items/2009/09/23.html
>> 
>> Jerry
>
>No one has ever come to me years after I released some engineering work 
>and said "damn, but it's nice that you got that done so quick".  But they

>have come to me years -- decades, even -- and said "You schmuck*!  Your 
>code is broken!".
>
>Perhaps if you're working on consumer goods you can have that sort of 
>attitude -- but would you want to live in a house built with that lack of

>care?  How about the software that runs the anti-lock brakes on your 
>car?  Get a pacemaker whose code is written by that guy?  Know that the 
>nations warplanes, ships, bombs and fighting vehicles depend on software

>written by that guy?
>
>Think about it...
>
>* Well, "schmuck" with four letters.

That sounds seriously naive. Of that list I've worked on warplanes, ships
and bombs. You might be horrified if you saw the standard of the software
that goes into these.

Regards,
Steve

>Tim Wescott <tim@seemywebsite.com> wrote:
>> Jerry Avins wrote:
>> 
>> > http://www.joelonsoftware.com/items/2009/09/23.html
>> > 
>> > Jerry
>> 
>> No one has ever come to me years after I released some engineering
>> work and said "damn, but it's nice that you got that done so quick". 
>> But they have come to me years -- decades, even -- and said "You
>> schmuck*!  Your code is broken!".
>> 
>> Perhaps if you're working on consumer goods you can have that sort of 
>> attitude -- but would you want to live in a house built with that lack
>> of care?  How about the software that runs the anti-lock brakes on
>> your car?  Get a pacemaker whose code is written by that guy?  Know
>> that the nations warplanes, ships, bombs and fighting vehicles depend
>> on software written by that guy?
>
>You have a point. However, if you get something that works part of the
>time then you can use it to test other things.
>
>And if something is being done that requires a complex software project,
>there's a strong chance there will be something broken elsewhere. Broken
>hardware, broken specs, broken fundamental concepts, broken physics,
>etc.
>
>There's a pretty good chance that they won't find out what else is wrong
>until they get working software to reveal the problems.
>
>It isn't real good to have code that sometimes fails and it takes effort
>to find out whether it's the code or something else that failed. But
>that's a whole lot better than not having code to test at all.
>
>So there's a lot to be said for starting with some sort of bare-bones
>prototype that does just enough to test out the system. And then get a
>proof-of-concept that shows basicly what you think can be done and how.
>And a test user interface so potential users can tell you what's wrong
>with it. And then an attempt at a real product that's still as much as
>possible simple.
>
>And maybe then you can start work on the product that does everything
>right, while you go on maintaining and improving the existing product
>that's bringing in the money to pay for the development effort. If the
>really good system never gets released, at least you have something.

Criticism of the "get something useful out the door in a reasonable time"
attitude assumes there is a superior alternative. I've never seen one. In
general, the more "rigorous" the process, the worse the outcome.

Steve

Tim Wescott wrote:
> On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:
> 
>> http://www.joelonsoftware.com/items/2009/09/23.html
>>
>> Jerry
> 
> No one has ever come to me years after I released some engineering work 
> and said "damn, but it's nice that you got that done so quick".  But they 
> have come to me years -- decades, even -- and said "You schmuck*!  Your 
> code is broken!".
> 
> Perhaps if you're working on consumer goods you can have that sort of 
> attitude -- but would you want to live in a house built with that lack of 
> care?  How about the software that runs the anti-lock brakes on your 
> car?  Get a pacemaker whose code is written by that guy?  Know that the 
> nations warplanes, ships, bombs and fighting vehicles depend on software 
> written by that guy?

I don't think you groked the kind of programmer Joel praises. I see 
myself. One of my first embedded jobe was a box to offload an Auger 
spectrometer from the minicomputer that controlled it. To wash out drift 
in the spectrometer's high-voltage supply, brief readings were taken at 
each level, the level stepped to the end, then the whole process 
repeated. The results at each level were accumulated. That way, drift 
affected only the base line, moving it up or down as a whole. Without 
that approach (or fixing the programmable supply) the baseline would 
have been tilted or even curved.

I built an interface that the mini could instruct, supplying starting 
point, step size, and number of steps. The interface box then ran the 
spectrometer, collecting 24-bit sums for the bins, and signaling the 
mini when it was ready to deliver the results. Mini usage went from 98% 
devoted to the spectrometer to less than 1%. The machine used 3Kx8 of 
data memory, 64 bytes of working RAM, and 128 bytes of program EPROM. 
(Those were early days.) I ran the 1802 on a 100KHz clock. It was plenty 
fast enough for the job and I thought it mighr increase reliability.

It ran for about 12 years without attention, when a young fellow came to 
my desk and asked for help deciphering the EPROM code. He wanted to add 
a new function. I astonished him by getting my copy of the documention 
out of my file. (The materials lab had long since lost their copy.) The 
original code occupied 127 actual bytes, and I had hedged my bets by 
wiring the ROM socket to accept up to 1K. I coded up his addition while 
he waited and sent him back with the new EPROM. It worked right off.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On Sep 24, 5:23=A0pm, Jerry Avins <j...@ieee.org> wrote:
> http://www.joelonsoftware.com/items/2009/09/23.html
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

I think there's some truth in the article, but I don't believe it's
completely accurate. Things held together with duct tape can rarely be
built upon --- add one thing and it's likely to break.

In a previous life, I did some programming for an engineer. We did
have to ship an actual product. The goal was to implement a set of
hardware control functions for a microcontroller. The engineer had a
list of the functions he needed, and the data structures defined.
Sounds like a straight forward task. But I was also familiar with an
existing higher level API, developed by another group, to encapsulate
such hardware control functions. The abstraction layer provided by the
API allowed new control functions to be added easily. The only problem
was that the code to implement the abstraction layer was written for
PC class machines, and at the outset, it was not clear whether or not
a reduced version could be made to fit into the resource-limited
microcontroller platform. When I proposed the idea of using the API to
the engineer, I could sense a roll of the eyes. But, after a little
resistance, he went along with it -- of course I had to do the
standard sales pitch painting a utopian picture of how the solid
foundation would last for centuries and would eventually grow to
encompass all things. Long story short, I got a suitable port of the
API and hardware functions working, but also took flak for doing the
project in about two weeks instead of the allotted four or five days.
I think my instincts were right in that case, though, as the code
never caused problems, at least none which I heard about in this life,
and was reportedly reused for the flexibility of the API.

I've also had a failure or two of the sort described in the article,
but of course I don't want to dredge those up!

Krishna

Tim Wescott wrote:
> On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:
> 
> 
>>http://www.joelonsoftware.com/items/2009/09/23.html
>>
>>Jerry
> 

> Perhaps if you're working on consumer goods you can have that sort of 
> attitude -- but would you want to live in a house built with that lack of 
> care?  How about the software that runs the anti-lock brakes on your 
> car?  Get a pacemaker whose code is written by that guy?  Know that the 
> nations warplanes, ships, bombs and fighting vehicles depend on software 
> written by that guy?

Do you seriously believe that somewhere in Zen there is a sinecure of 
superprogrammers who write stuff according to the carefully prepared 
technical plans? How naive of you. Those are the same clueless 
stupidents that you can see anywhere, and the code is a pitiful crap. 
The reality is that it is cheaper to take risks and pay expenses then 
get the things done as prescribed in textbooks. Especially as the 
projects are been developed by big teams, and the law of big numbers 
comes into play.

VLV

On 9/24/2009 3:23 PM, Jerry Avins wrote:
> http://www.joelonsoftware.com/items/2009/09/23.html
>
> Jerry

Nice.  Now I know why I've never embraced C++.   Never have figured out 
what it would do for me to make it worthwhile.

My observation would be that there are a lot of really crappy 
programmers who masquerade as or claim to be duct tape programmers. 
Knowing the difference is crucial.  I think a real duct tape programmer 
writes maintainable code, the other kind writes crap that functions, but 
it's still crap.  They point to the "functioning" aspect and claim 
that's where the true value lies.  Bleah.

-- 
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com

steveu wrote:

>>On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:
>>
>>
>>>http://www.joelonsoftware.com/items/2009/09/23.html
>>>
>>>Jerry
>>
>>No one has ever come to me years after I released some engineering work 
>>and said "damn, but it's nice that you got that done so quick".  But they
> 
> 
>>have come to me years -- decades, even -- and said "You schmuck*!  Your 
>>code is broken!".
>>
>>Perhaps if you're working on consumer goods you can have that sort of 
>>attitude -- but would you want to live in a house built with that lack of
> 
> 
>>care?  How about the software that runs the anti-lock brakes on your 
>>car?  Get a pacemaker whose code is written by that guy?  Know that the 
>>nations warplanes, ships, bombs and fighting vehicles depend on software
> 
> That sounds seriously naive. Of that list I've worked on warplanes, ships
> and bombs. You might be horrified if you saw the standard of the software
> that goes into these.
> 

I've seen some stuff also and I agree with you entirely. You won't drive 
your car or board an airplane if you look into the source code :-)

VLV

steveu wrote:


> Criticism of the "get something useful out the door in a reasonable time"
> attitude assumes there is a superior alternative. I've never seen one. In
> general, the more "rigorous" the process, the worse the outcome.

Agree on all points. Besides, I've never seen a project where the 
specification was not changed completely from what was in the initial plan.

VLV

On 9/24/2009 9:03 PM, Vladimir Vassilevsky wrote:
>
>
> steveu wrote:
>
>>> On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:
>>>
>>>
>>>> http://www.joelonsoftware.com/items/2009/09/23.html
>>>>
>>>> Jerry
>>>
>>> No one has ever come to me years after I released some engineering
>>> work and said "damn, but it's nice that you got that done so quick".
>>> But they
>>
>>
>>> have come to me years -- decades, even -- and said "You schmuck*!
>>> Your code is broken!".
>>>
>>> Perhaps if you're working on consumer goods you can have that sort of
>>> attitude -- but would you want to live in a house built with that
>>> lack of
>>
>>
>>> care? How about the software that runs the anti-lock brakes on your
>>> car? Get a pacemaker whose code is written by that guy? Know that the
>>> nations warplanes, ships, bombs and fighting vehicles depend on software
>>
>> That sounds seriously naive. Of that list I've worked on warplanes, ships
>> and bombs. You might be horrified if you saw the standard of the software
>> that goes into these.
>>
>
> I've seen some stuff also and I agree with you entirely. You won't drive
> your car or board an airplane if you look into the source code :-)
>
> VLV

Not sure I'd completely agree with that, at least just judging from my 
experiences of long ago working at Honeywell on airline avionics.  The 
best development processes and verification technique and procedures 
I've ever come across were in that environment.  If we used the 
standards applied to those products everywhere, though, the cost would 
go up 10x, and the release schedule likely a similar amount.  It's not 
necessarily beneficial and a good tradeoff to have the software that 
drives an iPod or a printer or a GPS road navigation computer be held to 
that standard.  A lot of engineering is knowing what's "good enough" for 
a given application.

-- 
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com

On Thu, 24 Sep 2009 21:10:10 -0500, steveu wrote:

>>Tim Wescott <tim@seemywebsite.com> wrote:
>>> Jerry Avins wrote:
>>> 
>>> > http://www.joelonsoftware.com/items/2009/09/23.html
>>> > 
>>> > Jerry
>>> 
>>> No one has ever come to me years after I released some engineering
>>> work and said "damn, but it's nice that you got that done so quick".
>>> But they have come to me years -- decades, even -- and said "You
>>> schmuck*!  Your code is broken!".
>>> 
>>> Perhaps if you're working on consumer goods you can have that sort of
>>> attitude -- but would you want to live in a house built with that lack
>>> of care?  How about the software that runs the anti-lock brakes on
>>> your car?  Get a pacemaker whose code is written by that guy?  Know
>>> that the nations warplanes, ships, bombs and fighting vehicles depend
>>> on software written by that guy?
>>
>>You have a point. However, if you get something that works part of the
>>time then you can use it to test other things.
>>
>>And if something is being done that requires a complex software project,
>>there's a strong chance there will be something broken elsewhere. Broken
>>hardware, broken specs, broken fundamental concepts, broken physics,
>>etc.
>>
>>There's a pretty good chance that they won't find out what else is wrong
>>until they get working software to reveal the problems.
>>
>>It isn't real good to have code that sometimes fails and it takes effort
>>to find out whether it's the code or something else that failed. But
>>that's a whole lot better than not having code to test at all.
>>
>>So there's a lot to be said for starting with some sort of bare-bones
>>prototype that does just enough to test out the system. And then get a
>>proof-of-concept that shows basicly what you think can be done and how.
>>And a test user interface so potential users can tell you what's wrong
>>with it. And then an attempt at a real product that's still as much as
>>possible simple.
>>
>>And maybe then you can start work on the product that does everything
>>right, while you go on maintaining and improving the existing product
>>that's bringing in the money to pay for the development effort. If the
>>really good system never gets released, at least you have something.
> 
> Criticism of the "get something useful out the door in a reasonable
> time" attitude assumes there is a superior alternative. I've never seen
> one. In general, the more "rigorous" the process, the worse the outcome.
> 
> Steve

In general, there's always a superior alternative to writing crap.

I'm not criticizing the notion of shipping product in a timely manner -- 
that's not hard to figure out.  I just got the general impression that 
the guy's attitude was "I don't like those dippy academics sticking their 
heads up their asses in a dippy academic way, so I'm going to stick _my_ 
head up _my_ ass in a manly cowboy way!".

It is humanly possible to write code that is both solid and correct.  
Slop for the sake of schedule becomes slop for the sake of kissing the 
boss's ass sooner rather than later, and then you're writing crap.

-- 
www.wescottdesign.com

Tim Wescott wrote:

   ...

> In general, there's always a superior alternative to writing crap.
> 
> I'm not criticizing the notion of shipping product in a timely manner -- 
> that's not hard to figure out.  I just got the general impression that 
> the guy's attitude was "I don't like those dippy academics sticking their 
> heads up their asses in a dippy academic way, so I'm going to stick _my_ 
> head up _my_ ass in a manly cowboy way!".
> 
> It is humanly possible to write code that is both solid and correct.  
> Slop for the sake of schedule becomes slop for the sake of kissing the 
> boss's ass sooner rather than later, and then you're writing crap.

But you seem to assume that plain and simple is crap, and that fancy and 
trendy is is the superior alternative. To particularise, code should be 
as simple as possible, but not simpler.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:

> http://www.joelonsoftware.com/items/2009/09/23.html
> 

Nice to read but quite populistic written. Seen from my
experience I state that the kind of code written by those duct
tape programmers often is a throwaway product, never to be
reused again.

And regarding higher techniques (C++, templates, ...): how often
have I heard from C programmers that using C++ would take ages
to complete the project, and it would increase the code size and
would severely reduce the execution speed.

Well, in fact quite the opposite is true when I look at my projects.
Without using C++ and inheritence and templates and policy based
design I would need much more time to complete a project, it would
be very difficult to run the code on multiple platforms including
simulators (emulating the embedded hardware), and without 
unit tests bugs would be detected by customers and not by the
regression test suite[1], and regarding execution speed I verified
by inspecting the assembler code that for example inline functions
are faster than C macros, and the multiple layered template
construction to access memory on the embedded hardware 
is identical to simple C code like '*(0xaaaabbbb) = 1'.

Maybe even very good C programmers should contemplate the fact
that they are not good C++ programmers instead of bashing the
C++ language itsself.

[1] Anybody with some sense should know that fixing bugs at 
   the customer site cost many times more than fixing in the
   development stage. Sure, writing unit tests costs initial time,
   but this time is regained many times later during the lifetime
   of the project.

bye
Andreas
-- 
Andreas H�nnebeck | email: acmh@gmx.de
----- privat ---- | www  : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc
PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc

>On Thu, 24 Sep 2009 21:10:10 -0500, steveu wrote:
>
>>>Tim Wescott <tim@seemywebsite.com> wrote:
>>>> Jerry Avins wrote:
>>>> 
>>>> > http://www.joelonsoftware.com/items/2009/09/23.html
>>>> > 
>>>> > Jerry
>>>> 
>>>> No one has ever come to me years after I released some engineering
>>>> work and said "damn, but it's nice that you got that done so quick".
>>>> But they have come to me years -- decades, even -- and said "You
>>>> schmuck*!  Your code is broken!".
>>>> 
>>>> Perhaps if you're working on consumer goods you can have that sort
of
>>>> attitude -- but would you want to live in a house built with that
lack
>>>> of care?  How about the software that runs the anti-lock brakes on
>>>> your car?  Get a pacemaker whose code is written by that guy?  Know
>>>> that the nations warplanes, ships, bombs and fighting vehicles
depend
>>>> on software written by that guy?
>>>
>>>You have a point. However, if you get something that works part of the
>>>time then you can use it to test other things.
>>>
>>>And if something is being done that requires a complex software
project,
>>>there's a strong chance there will be something broken elsewhere.
Broken
>>>hardware, broken specs, broken fundamental concepts, broken physics,
>>>etc.
>>>
>>>There's a pretty good chance that they won't find out what else is
wrong
>>>until they get working software to reveal the problems.
>>>
>>>It isn't real good to have code that sometimes fails and it takes
effort
>>>to find out whether it's the code or something else that failed. But
>>>that's a whole lot better than not having code to test at all.
>>>
>>>So there's a lot to be said for starting with some sort of bare-bones
>>>prototype that does just enough to test out the system. And then get a
>>>proof-of-concept that shows basicly what you think can be done and
how.
>>>And a test user interface so potential users can tell you what's wrong
>>>with it. And then an attempt at a real product that's still as much as
>>>possible simple.
>>>
>>>And maybe then you can start work on the product that does everything
>>>right, while you go on maintaining and improving the existing product
>>>that's bringing in the money to pay for the development effort. If the
>>>really good system never gets released, at least you have something.
>> 
>> Criticism of the "get something useful out the door in a reasonable
>> time" attitude assumes there is a superior alternative. I've never
seen
>> one. In general, the more "rigorous" the process, the worse the
outcome.
>> 
>> Steve
>
>In general, there's always a superior alternative to writing crap.

I've yet to see solid evidence to support that. The alternative to
projects going astray and producing crap has typically been a grand plan
that starts all over from scratch and produces something worse. That is a
*very* repeating theme in software development. Its de rigeur in defence
work.

>I'm not criticizing the notion of shipping product in a timely manner --

>that's not hard to figure out.  I just got the general impression that 

Shipping something people value, in a timeframe that makes them provide
good revenue, has proved to be the hardest thing to figure out in the
entire software business.

>the guy's attitude was "I don't like those dippy academics sticking their

>heads up their asses in a dippy academic way, so I'm going to stick _my_

>head up _my_ ass in a manly cowboy way!".

His attitude is something useful and shipping trumps grand plans that go
nowhere. What you said is your own invention.

>It is humanly possible to write code that is both solid and correct.  

Do you have hard evidence to support that? Most attempts to evaluate
correctness flounder badly.

>Slop for the sake of schedule becomes slop for the sake of kissing the 
>boss's ass sooner rather than later, and then you're writing crap.

Its the people with the grand plans that go nowhere who are the typical
ass kissers, promising wonderous things. People who actually ship stuff
usually have to be satisfied with smug sense of a job well done.

Regards,
Steve

On 25 Sep, 03:57, Jonah Thomas <jethom...@gmail.com> wrote:

> It isn't real good to have code that sometimes fails and it takes effort
> to find out whether it's the code or something else that failed. But
> that's a whole lot better than not having code to test at all.

If you use unit tests, you can be pretty sure whether the
code does what it is supposed to, or not. If he code does,
and the tests are relevant, then there is something else
to blame - specs, stated targets, whatever.

It's in everybody's interest to point out exactly where
the problem lies: If the code passes the unit tests, the
coders are not to blame. And vice versa.

Rune

On 25 Sep, 09:31, Jerry Avins <j...@ieee.org> wrote:

> But you seem to assume that plain and simple is crap, and that fancy and
> trendy is is the superior alternative.

Are you attributing those sorts of opinions to Tim?
Based on what writings of his?

> To particularise, code should be
> as simple as possible, but not simpler.

That's not what the link you referred to said. The article said
more or less that "screw any attempts to work systematically and
professionally, and let me and the guys do as we always did."

Rune

On 25 Sep, 04:53, Jerry Avins <j...@ieee.org> wrote:
> .... It worked right off.

So you just demonstrated that you are / were the exact
oposite of the duct-tape programmer:

1) You estimated the demands of the task
2) You evaluated the available resources
3) You planned ahead for future mods
4) You documented what you did
5) You kept the documentation
6) You found the relevant docs when needed
7) The initial design was good enough that
   the mods were easily made

Great story, great feat - but don't you EVER claim again
that you used to be sloppy and just throw things together
in whatever you were up to in the past!

Rune

Rune Allnor wrote:
> It's in everybody's interest to point out exactly where
> the problem lies: If the code passes the unit tests, the
> coders are not to blame. And vice versa.

Nope.  A test can only detect the presence of bugs, never the absence.  
Also, a failing test can have two causes: either a bug in the program, or a 
bug in the test.  Unit tests are particularly weak tests, because they only 
test units, not the whole thing.  "Integration hell" is what happens when 
you put things together that worked well in isolation - but don't work 
together.

Note that many people write tests to check "if it works".  They don't write 
tests to break their program.  E.g. take the following:


: plus  or ; \ twice as fast as +

T{ 1 2 plus -> 3 }T
T{ 1 4 plus -> 5 }T
T{ 2 1 plus -> 3 }T
T{ 4 2 plus -> 6 }T

O, we passed the unit tests.  Our Russian or Chinese programmer has found a 
tuning opportunity, and the module still passes the tests.  The tests are 
obviously incomplete.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On 25 Sep, 14:39, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Rune Allnor wrote:
> > It's in everybody's interest to point out exactly where
> > the problem lies: If the code passes the unit tests, the
> > coders are not to blame. And vice versa.
>
> Nope. =A0A test can only detect the presence of bugs, never the absence. =
=A0
> Also, a failing test can have two causes: either a bug in the program, or=
 a
> bug in the test. =A0Unit tests are particularly weak tests, because they =
only
> test units, not the whole thing. =A0"Integration hell" is what happens wh=
en
> you put things together that worked well in isolation - but don't work
> together.

Agreed. But if the individual modules work as expected in
isolation one has isolated the problem the integrated system.

> Note that many people write tests to check "if it works". =A0They don't w=
rite
> tests to break their program. =A0E.g. take the following:
>
> : plus =A0or ; \ twice as fast as +
>
> T{ 1 2 plus -> 3 }T
> T{ 1 4 plus -> 5 }T
> T{ 2 1 plus -> 3 }T
> T{ 4 2 plus -> 6 }T
>
> O, we passed the unit tests. =A0Our Russian or Chinese programmer has fou=
nd a
> tuning opportunity, and the module still passes the tests. =A0The tests a=
re
> obviously incomplete.

Designing and writing tests is a skill that has to be learned.
The fact that something can not be done to perfection is no
reason to avoid doing it at all.

Rune

Rune Allnor wrote:
>> Nope.  A test can only detect the presence of bugs, never the absence.
>> Also, a failing test can have two causes: either a bug in the program, or
>> a bug in the test.  Unit tests are particularly weak tests, because they
>> only test units, not the whole thing.  "Integration hell" is what happens
>> when you put things together that worked well in isolation - but don't
>> work together.
> 
> Agreed. But if the individual modules work as expected in
> isolation one has isolated the problem the integrated system.

No, all you know is that you need to hunt down the bug.  If the modules 
connected together work as expected in isolation, you have three possible 
failure modes:

a) the expectations were wrong
b) a module gets an unexpected input that's not part of its test suite, but 
happens in the integrated system
c) the integration harness (connections between the two modules) is broken

> Designing and writing tests is a skill that has to be learned.
> The fact that something can not be done to perfection is no
> reason to avoid doing it at all.

This is the classical logical fallacy, I don't advocate that.  Your comment 
sounded like "unit tests are sufficient", whereas I say "unit tests are 
necessary (or at least useful)".  The proof of the pudding is its eating, 
the proof of a module is its integration.

This is from the design guidelines I created in the company I work for: "Use 
unit tests, i.e. test blocks in isolation first.  A unit test does not 
replace a system test, but dropping an untested block into the system is a 
waste of time."

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Jonah Thomas <jethomas5@gmail.com> wrote:

> > Maybe even very good C programmers should contemplate the fact
> > that they are not good C++ programmers instead of bashing the
> > C++ language itsself.

That's a good point. If you get really good with a language you can
figure out how to use it to its fullest extent.

That reminds me of a story. Once a long time ago, I was given the task
of maintaining a Word document. I knew very little about Word at the
time, I had used it but hadn't explored its advanced features. It was a
single document about 400 pages long, in Word for Windows. Parts of it
had been written in Word for Macintosh and in a variety of other Word
versions, on Windows 3.1 and Windows 95 and Windows NT. There were
illustrations from CorelDraw and from a couple of other programs. I was
supposed to update this document on a Windows 3.1 machine with 8
megabytes of memory. I noticed that when I did anything that took a lot
of memory, like spellcheck, occasionally Word crashed and left my
document in a state it could not recover. So I did frequent backups.

Looking back, it's not unlikely that the document or my computer had
some Word viruses, but at the time I didn't know how to check for those.

So I started to learn the details of using Word. When I used the Goto
Page function, if the number I put in was 18 or less then it went to the
opening page or one of the pages labeled i ii iii etc. But if the number
was 19 it went to the page numbered 19. To get to pages 1-18 I had to
page in one at a time. If I'd known more about Word I could have set it
to always offset by 18 or something, but I was not that skilled. I found
that Word held a whole lot of traps for the unwary. If I had written the
whole document from scratch I would have run into them one at a time,
and many of them I would have avoided completely. "If it hurts when you
do that, then don't do that." But you play the hand you're dealt. I
particularly remember that if I accidentally clicked on some of the
illustrations then Word would assume I wanted to edit them and would
switch to illustration-edit mode, and if it was an illustration that
came from the wrong source it would not know how to handle it and would
permanently turn it into garbage. And I had lots of trouble with the
styles that came from Word from Macintosh, though some of the styles
that came from other sources were nearly as bad.

I kept a list of Word flaws for awhile, but after the first few dozen I
started losing track. Some of the worst ones were due to incompatibility
between Word and other programs, and I couldn't expect Word to deal
gracefully with products written by other companies, but the large
majority were just from Word, and of course a few came from
incompatibilities between Word and itself since there were so many
versions of Word.

At one point I mentioned on a newsgroup that I was not particularly
impressed with Word, that it seemed pretty clunky to me. And somebody
responded that Word was great, it was the best, that there was nothing
whatsoever wrong with Word. He said that if I was the sort of person who
had trouble with Word that I should tell my supervisor that I was
incompetent to use Word and that I should be given some less demanding
work.

I did learn to deal with all of Word's quirks, or at least all the ones
I ran into over the course of a few big documents. I still thought Word
was definitely suboptimal. The guy on the internet was right too, if
you're going to be a professional who uses Word then it's your
responsibility to learn how to use it well.

And yet, if I could find him today and make him use that Word from all
those years ago, I'm pretty sure he'd consider it a horrible punishment
that he didn't deserve. 

So anyway, I learned barely enough C++ to write C that runs with a C++
compiler. I can't say how good C++ is for itself. Various people have
told me that C++ is an inadequate attempt to bolt OO etc on top of C,
and its big virtue is that if you already know C then it seems easier to
learn C++ than to learn a new language that does that sort of thing
well. To the extent that's true, I'd rather learn a language that's good
at what it's good for, that lets me write short routines in C when I
need to. But -- horses for courses. If I was the sort of professional
who might be expected to use C++ I'd hate to have to tell my supervisor
that I'm incompetent to use C++ and I should be given some less
demanding work. Once you choose to play the game, then you play the hand
you're dealt.

On 25 Sep, 15:46, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Rune Allnor wrote:
> >> Nope. =A0A test can only detect the presence of bugs, never the absenc=
e.
> >> Also, a failing test can have two causes: either a bug in the program,=
 or
> >> a bug in the test. =A0Unit tests are particularly weak tests, because =
they
> >> only test units, not the whole thing. =A0"Integration hell" is what ha=
ppens
> >> when you put things together that worked well in isolation - but don't
> >> work together.
>
> > Agreed. But if the individual modules work as expected in
> > isolation one has isolated the problem the integrated system.
>
> No, all you know is that you need to hunt down the bug. =A0If the modules
> connected together work as expected in isolation, you have three possible
> failure modes:
>
> a) the expectations were wrong

These things happen all too often. Some times getting
a system up and running where each component works well
in isolation, is the only way to falsify the Grand Idea.

> b) a module gets an unexpected input that's not part of its test suite, b=
ut
> happens in the integrated system

Then the code and/or tests should be refactored. Part of
the skill behind designing tests is to cover as many (all)
those awkward cases.

> c) the integration harness (connections between the two modules) is broke=
n

> > Designing and writing tests is a skill that has to be learned.
> > The fact that something can not be done to perfection is no
> > reason to avoid doing it at all.
>
> This is the classical logical fallacy, I don't advocate that. =A0Your com=
ment
> sounded like "unit tests are sufficient",

My comment was aimed at the article in Jerry's first post,
where unit tests are tagged as waste of time.

> whereas I say "unit tests are
> necessary (or at least useful)". =A0The proof of the pudding is its eatin=
g,
> the proof of a module is its integration.
>
> This is from the design guidelines I created in the company I work for: "=
Use
> unit tests, i.e. test blocks in isolation first. =A0A unit test does not
> replace a system test, but dropping an untested block into the system is =
a
> waste of time."

Agreed.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote:
> Jonah Thomas <jethom...@gmail.com> wrote:
> 
> > It isn't real good to have code that sometimes fails and it takes
> > effort to find out whether it's the code or something else that
> > failed. But that's a whole lot better than not having code to test
> > at all.
> 
> If you use unit tests, you can be pretty sure whether the
> code does what it is supposed to, or not. If he code does,
> and the tests are relevant, then there is something else
> to blame - specs, stated targets, whatever.
> 
> It's in everybody's interest to point out exactly where
> the problem lies: If the code passes the unit tests, the
> coders are not to blame. And vice versa.

That makes sense. I don't have a detailed algorithm to decide when it's
better to design your prototype code very carefully, specifying the
interfaces precisely and building test cases for all your software
including the testbed you use to run testcases, and when it's better to
get something quick that tests the rest of the system but might have
some bugs itself.

As a general rule, I think maybe if the system is not very stable you
should get stuff done quickly. You'll probably have to throw away a lot
of it anyway after things change. The slower you are to produce it, the
more likely the system will change out from under you before you're done
and then your beautiful code won't get used at all until it's revised,
and you could easily spend so much time on the revsion that the system
changes out from under you again....

Sometimes you need great code. Sometimes you need a short OODA loop. If
you an provide both then you're good. If you can only do one then you
should work inside your own niche.

>On 25 Sep, 03:57, Jonah Thomas <jethom...@gmail.com> wrote:
>
>> It isn't real good to have code that sometimes fails and it takes
effort
>> to find out whether it's the code or something else that failed. But
>> that's a whole lot better than not having code to test at all.
>
>If you use unit tests, you can be pretty sure whether the
>code does what it is supposed to, or not. If he code does,
>and the tests are relevant, then there is something else
>to blame - specs, stated targets, whatever.
>
>It's in everybody's interest to point out exactly where
>the problem lies: If the code passes the unit tests, the
>coders are not to blame. And vice versa.

Unit tests are extremely important in minimising the cost of bug fixing,
but the idea they prove anything is ridiculous. The working code only has
bugs. The unit test harness has both bugs and potential limitations in test
coverage - double the fun. :-)

In every case I can think of where a dangerous system (a plane, missile,
etc) went berzerk, and I have some insight into the root cause, it was a
failure at the unit test level.

Steve

steveu wrote:


> Unit tests are extremely important in minimising the cost of bug fixing,
> but the idea they prove anything is ridiculous. The working code only has
> bugs. The unit test harness has both bugs and potential limitations in test
> coverage - double the fun. :-)

A programer is at the firing range. He is shooting a gun, but can't hit 
the target. Then the programmer puts his finger to the end of the gun 
barrel and pulls the trigger. Bang! The finger is ripped off.
- "Aha!" - says the programmer - "Everything is OK here, the problem is 
on the target side!"

So much for the unit testing with respect to complete system.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Bernd Paysan wrote:
> Rune Allnor wrote:
>>> Nope.  A test can only detect the presence of bugs, never the absence.
>>> Also, a failing test can have two causes: either a bug in the program, or
>>> a bug in the test.  Unit tests are particularly weak tests, because they
>>> only test units, not the whole thing.  "Integration hell" is what happens
>>> when you put things together that worked well in isolation - but don't
>>> work together.
>> Agreed. But if the individual modules work as expected in
>> isolation one has isolated the problem the integrated system.
> 
> No, all you know is that you need to hunt down the bug.  If the modules 
> connected together work as expected in isolation, you have three possible 
> failure modes:
> 
> a) the expectations were wrong
> b) a module gets an unexpected input that's not part of its test suite, but 
> happens in the integrated system
> c) the integration harness (connections between the two modules) is broken
> 
>> Designing and writing tests is a skill that has to be learned.
>> The fact that something can not be done to perfection is no
>> reason to avoid doing it at all.
> 
> This is the classical logical fallacy, I don't advocate that.  Your comment 
> sounded like "unit tests are sufficient", whereas I say "unit tests are 
> necessary (or at least useful)".  The proof of the pudding is its eating, 
> the proof of a module is its integration.
> 
> This is from the design guidelines I created in the company I work for: "Use 
> unit tests, i.e. test blocks in isolation first.  A unit test does not 
> replace a system test, but dropping an untested block into the system is a 
> waste of time."

Bernd,

You and I are very likely the only participants here who write primarily 
in Forth. We agree on the importance of unit tests, but for simple 
programs -- all I write nowadays -- I just perform them without writing 
much. Forth makes that easy.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Rune Allnor wrote:
> On 25 Sep, 04:53, Jerry Avins <j...@ieee.org> wrote:
>> .... It worked right off.
> 
> So you just demonstrated that you are / were the exact
> oposite of the duct-tape programmer:
> 
> 1) You estimated the demands of the task
> 2) You evaluated the available resources
> 3) You planned ahead for future mods
> 4) You documented what you did
> 5) You kept the documentation
> 6) You found the relevant docs when needed
> 7) The initial design was good enough that
>    the mods were easily made
> 
> Great story, great feat - but don't you EVER claim again
> that you used to be sloppy and just throw things together
> in whatever you were up to in the past!

I wrote in assembler. (The original was done on a two-pass assembler 
that produced intermediate and final results on paper tape on an ASR33.) 
Nothing fancy. The approach was "Just do it." After, of course, 
carefully defining "it".

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On 25 Sep, 16:36, Jerry Avins <j...@ieee.org> wrote:
> Rune Allnor wrote:
> > On 25 Sep, 04:53, Jerry Avins <j...@ieee.org> wrote:
> >> .... It worked right off.
>
> > So you just demonstrated that you are / were the exact
> > oposite of the duct-tape programmer:
>
> > 1) You estimated the demands of the task
> > 2) You evaluated the available resources
> > 3) You planned ahead for future mods
> > 4) You documented what you did
> > 5) You kept the documentation
> > 6) You found the relevant docs when needed
> > 7) The initial design was good enough that
> > =A0 =A0the mods were easily made
>
> > Great story, great feat - but don't you EVER claim again
> > that you used to be sloppy and just throw things together
> > in whatever you were up to in the past!
>
> I wrote in assembler. (The original was done on a two-pass assembler
> that produced intermediate and final results on paper tape on an ASR33.)
> Nothing fancy. The approach was "Just do it." After, of course,
> carefully defining "it".

There's more to it than that.

Some people, by training or by attitude, just know the good
ways of working, that others can go for a lifetime without
knowing or even suspecing exist. I like to call it 'craftmanship';
that elusive 'it' apprentices learn from their masters: Those
subtle detail in their method, their approach, their attitude
towards work.

Your story has all the ingredients of craftmanship. The duct-
tape programming BS is more towards "leave me me alone and I
will just come up with *something*."

Rune

Rune Allnor wrote:
> On 25 Sep, 16:36, Jerry Avins <j...@ieee.org> wrote:
>> Rune Allnor wrote:
>>> On 25 Sep, 04:53, Jerry Avins <j...@ieee.org> wrote:
>>>> .... It worked right off.
>>> So you just demonstrated that you are / were the exact
>>> oposite of the duct-tape programmer:
>>> 1) You estimated the demands of the task
>>> 2) You evaluated the available resources
>>> 3) You planned ahead for future mods
>>> 4) You documented what you did
>>> 5) You kept the documentation
>>> 6) You found the relevant docs when needed
>>> 7) The initial design was good enough that
>>>    the mods were easily made
>>> Great story, great feat - but don't you EVER claim again
>>> that you used to be sloppy and just throw things together
>>> in whatever you were up to in the past!
>> I wrote in assembler. (The original was done on a two-pass assembler
>> that produced intermediate and final results on paper tape on an ASR33.)
>> Nothing fancy. The approach was "Just do it." After, of course,
>> carefully defining "it".
> 
> There's more to it than that.
> 
> Some people, by training or by attitude, just know the good
> ways of working, that others can go for a lifetime without
> knowing or even suspecing exist. I like to call it 'craftmanship';
> that elusive 'it' apprentices learn from their masters: Those
> subtle detail in their method, their approach, their attitude
> towards work.
> 
> Your story has all the ingredients of craftmanship. The duct-
> tape programming BS is more towards "leave me me alone and I
> will just come up with *something*."

I see it as "Let me do it my way, and it will work" said with the 
confidence that comes with experience, not from wishful thinking.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins <jya@ieee.org> writes:
> [...]

There is a good lesson to be learned/remembered here (even though
I fundamentally disagree with the article): don't overdesign stuff.

However, that doesn't mean that the "duct tape code" methodology is
always fastest.

And no matter what methodology you follow, changing the requirements
mid-project is going to be expensive. 
-- 
Randy Yates                      % "Remember the good old 1980's, when 
Digital Signal Labs              %  things were so uncomplicated?"
mailto://yates@ieee.org          % 'Ticket To The Moon' 
http://www.digitalsignallabs.com % *Time*, Electric Light Orchestra

On Fri, 25 Sep 2009 03:31:42 -0400, Jerry Avins wrote:

> Tim Wescott wrote:
> 
>    ...
> 
>> In general, there's always a superior alternative to writing crap.
>> 
>> I'm not criticizing the notion of shipping product in a timely manner
>> -- that's not hard to figure out.  I just got the general impression
>> that the guy's attitude was "I don't like those dippy academics
>> sticking their heads up their asses in a dippy academic way, so I'm
>> going to stick _my_ head up _my_ ass in a manly cowboy way!".
>> 
>> It is humanly possible to write code that is both solid and correct.
>> Slop for the sake of schedule becomes slop for the sake of kissing the
>> boss's ass sooner rather than later, and then you're writing crap.
> 
> But you seem to assume that plain and simple is crap, and that fancy and
> trendy is is the superior alternative. To particularise, code should be
> as simple as possible, but not simpler.
> 
> Jerry

It was the "I'm too manly for testing" and "shipping on schedule is more 
important than shipping something that works" threads within the 
statements that bothered me.  That, and his assumption that dead simple 
is never too simple.

-- 
www.wescottdesign.com

Rune Allnor wrote:
...
> Your story has all the ingredients of craftmanship. The duct-
> tape programming BS is more towards "leave me me alone and I
> will just come up with *something*."
> 

I have understood the "duct tape" description slightly differently. It 
is like the person who can use nylon stockings to substitute for a 
broken cam belt, or a hairpin to pick a lock. Great skill may be 
required for both, and at the time it may be life-saving; but neither 
solution is actually "better" than fitting a new cam belt or using the 
correct key - in the latter case indeed there is virtually no skill 
required at all. The problem arises when a program is developed quickly 
as a proof of concept, sort of brainstorming in code (do that myself 
lots of times); but then it is thought to be working well enough to be 
"developed" directly into a deliverable application, "leveraging" all 
the initial code, rather than designing properly from scratch. My own 
rule of thumb is that a program needs to be designed and implemented at 
least twice. If it is not, the chances of duct tape (or hairpins) being 
delivered to customers is that much greater.

Part of the problem is also the "blank slate" syndrome; all too often 
the requirements of a package are not worked out or even imagined until 
there is some prototype to criticize. At best, the working prototype 
leads to all sort of "hey, we could do this too" ideas. It is then a 
mixture of luck and judgement if the prototype is ready to support all 
that new a-posteriori input.

I seem to recall one cause of an Arianne rocket explosion was that one 
software "unit" was working in kilos and grams, while another was 
working in pounds and ounces. Each unit worked fine, and even when put 
together the numbers were plausible, and might have passed both unit and 
integration testing; but were just wrong.

Richard Dobson

On Fri, 25 Sep 2009 04:34:47 -0700, Rune Allnor wrote:

> On 25 Sep, 09:31, Jerry Avins <j...@ieee.org> wrote:
> 
>> But you seem to assume that plain and simple is crap, and that fancy
>> and trendy is is the superior alternative.
> 
> Are you attributing those sorts of opinions to Tim? Based on what
> writings of his?
> 
>> To particularise, code should be
>> as simple as possible, but not simpler.
> 
> That's not what the link you referred to said. The article said more or
> less that "screw any attempts to work systematically and professionally,
> and let me and the guys do as we always did."
> 
> Rune

That's pretty much how I read it.

A good part of my career has been to rewrite or at least fix code that 
others have written.  I've fixed code written by people whose attitude 
problem is that fancy is bad -- which means that I'm untangling spaghetti 
code, and I've fixed code written by those egghead types that feel that 
if you haven't exercised every last feature of C++ then you've missed out 
on life.

Both sets of people shared the conviction that they were up to any task, 
that reality shouldn't get in the way of getting code written quickly, 
and that thorough testing of absolutely new stuff that they'd just done 
was insulting to their intelligence and integrity.

So at the same time that this guy was bitterly complaining about people 
in the former half of the problem group, he was working hard to make it 
sound like he belongs firmly in the latter half of the problem group.

-- 
www.wescottdesign.com

On Fri, 25 Sep 2009 05:33:49 -0500, steveu wrote:

>>On Thu, 24 Sep 2009 21:10:10 -0500, steveu wrote:
>>
>>>>Tim Wescott <tim@seemywebsite.com> wrote:
>>>>> Jerry Avins wrote:
>>>>> 
>>>>> > http://www.joelonsoftware.com/items/2009/09/23.html
>>>>> > 
>>>>> > Jerry
>>>>> 
>>>>> No one has ever come to me years after I released some engineering
>>>>> work and said "damn, but it's nice that you got that done so quick".
>>>>> But they have come to me years -- decades, even -- and said "You
>>>>> schmuck*!  Your code is broken!".
>>>>> 
>>>>> Perhaps if you're working on consumer goods you can have that sort
> of
>>>>> attitude -- but would you want to live in a house built with that
> lack
>>>>> of care?  How about the software that runs the anti-lock brakes on
>>>>> your car?  Get a pacemaker whose code is written by that guy?  Know
>>>>> that the nations warplanes, ships, bombs and fighting vehicles
> depend
>>>>> on software written by that guy?
>>>>
>>>>You have a point. However, if you get something that works part of the
>>>>time then you can use it to test other things.
>>>>
>>>>And if something is being done that requires a complex software
> project,
>>>>there's a strong chance there will be something broken elsewhere.
> Broken
>>>>hardware, broken specs, broken fundamental concepts, broken physics,
>>>>etc.
>>>>
>>>>There's a pretty good chance that they won't find out what else is
> wrong
>>>>until they get working software to reveal the problems.
>>>>
>>>>It isn't real good to have code that sometimes fails and it takes
> effort
>>>>to find out whether it's the code or something else that failed. But
>>>>that's a whole lot better than not having code to test at all.
>>>>
>>>>So there's a lot to be said for starting with some sort of bare-bones
>>>>prototype that does just enough to test out the system. And then get a
>>>>proof-of-concept that shows basicly what you think can be done and
> how.
>>>>And a test user interface so potential users can tell you what's wrong
>>>>with it. And then an attempt at a real product that's still as much as
>>>>possible simple.
>>>>
>>>>And maybe then you can start work on the product that does everything
>>>>right, while you go on maintaining and improving the existing product
>>>>that's bringing in the money to pay for the development effort. If the
>>>>really good system never gets released, at least you have something.
>>> 
>>> Criticism of the "get something useful out the door in a reasonable
>>> time" attitude assumes there is a superior alternative. I've never
> seen
>>> one. In general, the more "rigorous" the process, the worse the
> outcome.
>>> 
>>> Steve
>>
>>In general, there's always a superior alternative to writing crap.
> 
> I've yet to see solid evidence to support that. The alternative to
> projects going astray and producing crap has typically been a grand plan
> that starts all over from scratch and produces something worse. That is
> a *very* repeating theme in software development. Its de rigeur in
> defence work.
> 
>>I'm not criticizing the notion of shipping product in a timely manner --
> 
>>that's not hard to figure out.  I just got the general impression that
> 
> Shipping something people value, in a timeframe that makes them provide
> good revenue, has proved to be the hardest thing to figure out in the
> entire software business.
> 
>>the guy's attitude was "I don't like those dippy academics sticking
>>their
> 
>>heads up their asses in a dippy academic way, so I'm going to stick _my_
> 
>>head up _my_ ass in a manly cowboy way!".
> 
> His attitude is something useful and shipping trumps grand plans that go
> nowhere. What you said is your own invention.
> 
>>It is humanly possible to write code that is both solid and correct.
> 
> Do you have hard evidence to support that? Most attempts to evaluate
> correctness flounder badly.
> 
>>Slop for the sake of schedule becomes slop for the sake of kissing the
>>boss's ass sooner rather than later, and then you're writing crap.
> 
> Its the people with the grand plans that go nowhere who are the typical
> ass kissers, promising wonderous things. People who actually ship stuff
> usually have to be satisfied with smug sense of a job well done.

So after you get something barely good enough to ship do you depart for 
other companies so the regular employees are left trying to keep your 
stuff working?

-- 
www.wescottdesign.com

On Fri, 25 Sep 2009 15:46:42 +0200, Bernd Paysan wrote:

> Rune Allnor wrote:
>>> Nope.  A test can only detect the presence of bugs, never the absence.
>>> Also, a failing test can have two causes: either a bug in the program,
>>> or a bug in the test.  Unit tests are particularly weak tests, because
>>> they only test units, not the whole thing.  "Integration hell" is what
>>> happens when you put things together that worked well in isolation -
>>> but don't work together.
>> 
>> Agreed. But if the individual modules work as expected in isolation one
>> has isolated the problem the integrated system.
> 
> No, all you know is that you need to hunt down the bug.  If the modules
> connected together work as expected in isolation, you have three
> possible failure modes:
> 
> a) the expectations were wrong
> b) a module gets an unexpected input that's not part of its test suite,
> but happens in the integrated system
> c) the integration harness (connections between the two modules) is
> broken
> 
>> Designing and writing tests is a skill that has to be learned. The fact
>> that something can not be done to perfection is no reason to avoid
>> doing it at all.
> 
> This is the classical logical fallacy, I don't advocate that.  Your
> comment sounded like "unit tests are sufficient", whereas I say "unit
> tests are necessary (or at least useful)".  The proof of the pudding is
> its eating, the proof of a module is its integration.
> 
> This is from the design guidelines I created in the company I work for:
> "Use unit tests, i.e. test blocks in isolation first.  A unit test does
> not replace a system test, but dropping an untested block into the
> system is a waste of time."

That's a good attitude.  I take that further in my own code that if I 
integrate and find a bug, I try to rewrite the unit test to find the bug 
and at least some of it's relatives before I fix the mainline code.

-- 
www.wescottdesign.com

On 25 Sep, 17:22, Richard Dobson <richarddob...@blueyonder.co.uk>
wrote:
> Rune Allnor wrote:
>
> ..
>
> > Your story has all the ingredients of craftmanship. The duct-
> > tape programming BS is more towards "leave me me alone and I
> > will just come up with *something*."
>
> I have understood the "duct tape" description slightly differently. It
> is like the person who can use nylon stockings to substitute for a
> broken cam belt, or a hairpin to pick a lock. Great skill may be
> required for both, and at the time it may be life-saving; but neither
> solution is actually "better" than fitting a new cam belt or using the
> correct key - in the latter case indeed there is virtually no skill
> required at all.

Those types of solutions might be accepted as some sort
of McGyver'ish skin-of-the-teeth save-my-day-NOW!! kind
of solution, but they are never more than an ad-hoc way
of treating an immediate problem.

If that sort of solutions is the name of the game, the
business is doomed.

> The problem arises when a program is developed quickly
> as a proof of concept, sort of brainstorming in code (do that myself
> lots of times); but then it is thought to be working well enough to be
> "developed" directly into a deliverable application, "leveraging" all
> the initial code, rather than designing properly from scratch.

This is why all projects fail: People don't understand the
difference between proof-of-concept code and production code.

> My own
> rule of thumb is that a program needs to be designed and implemented at
> least twice. If it is not, the chances of duct tape (or hairpins) being
> delivered to customers is that much greater.

Agreed.

> Part of the problem is also the "blank slate" syndrome; all too often
> the requirements of a package are not worked out or even imagined until
> there is some prototype to criticize. At best, the working prototype
> leads to all sort of "hey, we could do this too" ideas. It is then a
> mixture of luck and judgement if the prototype is ready to support all
> that new a-posteriori input.
>
> I seem to recall one cause of an Arianne rocket explosion was that one
> software "unit" was working in kilos and grams, while another was
> working in pounds and ounces. Each unit worked fine, and even when put
> together the numbers were plausible, and might have passed both unit and
> integration testing; but were just wrong.

Wasn't that the first post-Viking Mars spacecraft? The brits
have made a lot of mischief: Their stubbornness about not
driving on the correct side of the road cost hundreds if not
thousands of lives every year: People are used to driving on
one side, and react instinctively accordingly when meeting
obstacles. When they visit a country where people drive on the
other side of the road, the instinct reaction get drivers into
even greater trouble than what they try to avoid.

Rune

On 25 Sep, 16:59, Jerry Avins <j...@ieee.org> wrote:
> Rune Allnor wrote:
> > On 25 Sep, 16:36, Jerry Avins <j...@ieee.org> wrote:
> >> Rune Allnor wrote:
> >>> On 25 Sep, 04:53, Jerry Avins <j...@ieee.org> wrote:
> >>>> .... It worked right off.
> >>> So you just demonstrated that you are / were the exact
> >>> oposite of the duct-tape programmer:
> >>> 1) You estimated the demands of the task
> >>> 2) You evaluated the available resources
> >>> 3) You planned ahead for future mods
> >>> 4) You documented what you did
> >>> 5) You kept the documentation
> >>> 6) You found the relevant docs when needed
> >>> 7) The initial design was good enough that
> >>> =A0 =A0the mods were easily made
> >>> Great story, great feat - but don't you EVER claim again
> >>> that you used to be sloppy and just throw things together
> >>> in whatever you were up to in the past!
> >> I wrote in assembler. (The original was done on a two-pass assembler
> >> that produced intermediate and final results on paper tape on an ASR33=
..)
> >> Nothing fancy. The approach was "Just do it." After, of course,
> >> carefully defining "it".
>
> > There's more to it than that.
>
> > Some people, by training or by attitude, just know the good
> > ways of working, that others can go for a lifetime without
> > knowing or even suspecing exist. I like to call it 'craftmanship';
> > that elusive 'it' apprentices learn from their masters: Those
> > subtle detail in their method, their approach, their attitude
> > towards work.
>
> > Your story has all the ingredients of craftmanship. The duct-
> > tape programming BS is more towards "leave me me alone and I
> > will just come up with *something*."
>
> I see it as "Let me do it my way, and it will work" said with the
> confidence that comes with experience, not from wishful thinking.

Right. Please do everybodty a favour and don't pretend
otherwise. If you did, people without your skills and
experience might start to get ideas.

Rune

Jerry Avins wrote:

> Bernd,
> 
> You and I are very likely the only participants here who write primarily
> in Forth. We agree on the importance of unit tests, but for simple
> programs -- all I write nowadays -- I just perform them without writing
> much. Forth makes that easy.

Yes, in Forth, my unit tests aren't formalized.  I test a "module" (a few 
words or so) on the command line, and if it passes the tests, it's 
integrated.  Later changes are tested in the complete application.  For 
porting exercises such as MINOS, it's a bit of a pity that the unit tests 
aren't preserved.  Unit tests are much more important for languages where 
testing is more difficult - and that's why my design guidelines (which apply 
to Verilog, not to Forth) make formalized unit tests mandatory.

I also use "organic growth", i.e. the application starts out with a few 
working components, and growth by adding features.  That way, there's always 
an integrated system for the module to be integrated into, and only one new 
module at a time.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Rune Allnor wrote:
..
..
..
The brits
> have made a lot of mischief: Their stubbornness about not
> driving on the correct side of the road cost hundreds if not
> thousands of lives every year: People are used to driving on
> one side, and react instinctively accordingly when meeting
> obstacles. When they visit a country where people drive on the
> other side of the road, the instinct reaction get drivers into
> even greater trouble than what they try to avoid.

Hey! Who was there first? And what is the most natural side (given
that most people are right handed), if you had to decide impartially
and weren't influenced by being conquered by arbitrary Napoleonic
systems or awkward large scale wagons that needed even more skill
controlling the team from the left than attention to the road? It's
not a coincidence that the most recent country to switch went our way.

Everybody else is out of step. YOU change. P.M.Lawrence.

Tim Wescott wrote:

> A good part of my career has been to rewrite or at least fix code that 
> others have written.  I've fixed code written by people whose attitude
> problem is that fancy is bad -- which means that I'm untangling spaghetti 
> code, and I've fixed code written by those egghead types that feel that 
> if you haven't exercised every last feature of C++ then you've missed out 
> on life.

The most terrible code that I've seen was developed with the intention 
to cut costs.

> Both sets of people shared the conviction that they were up to any task, 
> that reality shouldn't get in the way of getting code written quickly, 
> and that thorough testing of absolutely new stuff that they'd just done 
> was insulting to their intelligence and integrity.
> 
> So at the same time that this guy was bitterly complaining about people 
> in the former half of the problem group, he was working hard to make it 
> sound like he belongs firmly in the latter half of the problem group.

IMO the quality is not about using or not using C++, but about the 
personality of the programmer.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Tim Wescott wrote:
> On Fri, 25 Sep 2009 03:31:42 -0400, Jerry Avins wrote:
> 
>> Tim Wescott wrote:
>>
>>    ...
>>
>>> In general, there's always a superior alternative to writing crap.
>>>
>>> I'm not criticizing the notion of shipping product in a timely manner
>>> -- that's not hard to figure out.  I just got the general impression
>>> that the guy's attitude was "I don't like those dippy academics
>>> sticking their heads up their asses in a dippy academic way, so I'm
>>> going to stick _my_ head up _my_ ass in a manly cowboy way!".
>>>
>>> It is humanly possible to write code that is both solid and correct.
>>> Slop for the sake of schedule becomes slop for the sake of kissing the
>>> boss's ass sooner rather than later, and then you're writing crap.
>> But you seem to assume that plain and simple is crap, and that fancy and
>> trendy is is the superior alternative. To particularise, code should be
>> as simple as possible, but not simpler.
>>
>> Jerry
> 
> It was the "I'm too manly for testing" and "shipping on schedule is more 
> important than shipping something that works" threads within the 
> statements that bothered me.  That, and his assumption that dead simple 
> is never too simple.

I guess we read it with different preconceptions. I'll read it again.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On 25 Sep, 17:59, Vladimir Vassilevsky <nos...@nowhere.com> wrote:

> IMO the quality is not about using or not using C++,

I could agree with that...

> but about the
> personality of the programmer.

....but this one came out of the blue. Would you care
to elaborate?

Rune

On Sep 24, 6:23=A0pm, Jerry Avins <j...@ieee.org> wrote:
> http://www.joelonsoftware.com/items/2009/09/23.html
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

cute, but like batters who swing at every pitch and batters that fight
off every pitch until the perfect down the middle pitch comes, which
method is best depends on the style of the programmer, and if you ever
worked with a team of programmers you always have a mix of both. The
issue is how to delegate which tasks to which programmers not to
change or convert them, because that isn't going to happen.

>On 25 Sep, 17:22, Richard Dobson <richarddob...@blueyonder.co.uk>
>wrote:
>> Rune Allnor wrote:
>>
>> ..
>>
>> > Your story has all the ingredients of craftmanship. The duct-
>> > tape programming BS is more towards "leave me me alone and I
>> > will just come up with *something*."
>>
>> I have understood the "duct tape" description slightly differently. It
>> is like the person who can use nylon stockings to substitute for a
>> broken cam belt, or a hairpin to pick a lock. Great skill may be
>> required for both, and at the time it may be life-saving; but neither
>> solution is actually "better" than fitting a new cam belt or using the
>> correct key - in the latter case indeed there is virtually no skill
>> required at all.
>
>Those types of solutions might be accepted as some sort
>of McGyver'ish skin-of-the-teeth save-my-day-NOW!! kind
>of solution, but they are never more than an ad-hoc way
>of treating an immediate problem.
>
>If that sort of solutions is the name of the game, the
>business is doomed.
>
>> The problem arises when a program is developed quickly
>> as a proof of concept, sort of brainstorming in code (do that myself
>> lots of times); but then it is thought to be working well enough to be
>> "developed" directly into a deliverable application, "leveraging" all
>> the initial code, rather than designing properly from scratch.
>
>This is why all projects fail: People don't understand the
>difference between proof-of-concept code and production code.
>
>> My own
>> rule of thumb is that a program needs to be designed and implemented
at
>> least twice. If it is not, the chances of duct tape (or hairpins)
being
>> delivered to customers is that much greater.
>
>Agreed.
>
>> Part of the problem is also the "blank slate" syndrome; all too often
>> the requirements of a package are not worked out or even imagined
until
>> there is some prototype to criticize. At best, the working prototype
>> leads to all sort of "hey, we could do this too" ideas. It is then a
>> mixture of luck and judgement if the prototype is ready to support all
>> that new a-posteriori input.
>>
>> I seem to recall one cause of an Arianne rocket explosion was that one
>> software "unit" was working in kilos and grams, while another was
>> working in pounds and ounces. Each unit worked fine, and even when put
>> together the numbers were plausible, and might have passed both unit
and
>> integration testing; but were just wrong.
>
>Wasn't that the first post-Viking Mars spacecraft? The brits
>have made a lot of mischief: Their stubbornness about not
>driving on the correct side of the road cost hundreds if not
>thousands of lives every year: People are used to driving on
>one side, and react instinctively accordingly when meeting
>obstacles. When they visit a country where people drive on the
>other side of the road, the instinct reaction get drivers into
>even greater trouble than what they try to avoid.

The British drive on the same side as much of the planet - Australia,
Japan, Malaysia, Singapore, Hong Kong, India, much of the middle east. Its
also the side that is more natural for a right handed person, keeping the
right hand in control of steering at all times.

Steve

>On Fri, 25 Sep 2009 05:33:49 -0500, steveu wrote:
>
>>>On Thu, 24 Sep 2009 21:10:10 -0500, steveu wrote:
>>>
>>>>>Tim Wescott <tim@seemywebsite.com> wrote:
>>>>>> Jerry Avins wrote:
>>>>>> 
>>>>>> > http://www.joelonsoftware.com/items/2009/09/23.html
>>>>>> > 
>>>>>> > Jerry
>>>>>> 
>>>>>> No one has ever come to me years after I released some engineering
>>>>>> work and said "damn, but it's nice that you got that done so
quick".
>>>>>> But they have come to me years -- decades, even -- and said "You
>>>>>> schmuck*!  Your code is broken!".
>>>>>> 
>>>>>> Perhaps if you're working on consumer goods you can have that sort
>> of
>>>>>> attitude -- but would you want to live in a house built with that
>> lack
>>>>>> of care?  How about the software that runs the anti-lock brakes on
>>>>>> your car?  Get a pacemaker whose code is written by that guy? 
Know
>>>>>> that the nations warplanes, ships, bombs and fighting vehicles
>> depend
>>>>>> on software written by that guy?
>>>>>
>>>>>You have a point. However, if you get something that works part of
the
>>>>>time then you can use it to test other things.
>>>>>
>>>>>And if something is being done that requires a complex software
>> project,
>>>>>there's a strong chance there will be something broken elsewhere.
>> Broken
>>>>>hardware, broken specs, broken fundamental concepts, broken physics,
>>>>>etc.
>>>>>
>>>>>There's a pretty good chance that they won't find out what else is
>> wrong
>>>>>until they get working software to reveal the problems.
>>>>>
>>>>>It isn't real good to have code that sometimes fails and it takes
>> effort
>>>>>to find out whether it's the code or something else that failed. But
>>>>>that's a whole lot better than not having code to test at all.
>>>>>
>>>>>So there's a lot to be said for starting with some sort of
bare-bones
>>>>>prototype that does just enough to test out the system. And then get
a
>>>>>proof-of-concept that shows basicly what you think can be done and
>> how.
>>>>>And a test user interface so potential users can tell you what's
wrong
>>>>>with it. And then an attempt at a real product that's still as much
as
>>>>>possible simple.
>>>>>
>>>>>And maybe then you can start work on the product that does
everything
>>>>>right, while you go on maintaining and improving the existing
product
>>>>>that's bringing in the money to pay for the development effort. If
the
>>>>>really good system never gets released, at least you have something.
>>>> 
>>>> Criticism of the "get something useful out the door in a reasonable
>>>> time" attitude assumes there is a superior alternative. I've never
>> seen
>>>> one. In general, the more "rigorous" the process, the worse the
>> outcome.
>>>> 
>>>> Steve
>>>
>>>In general, there's always a superior alternative to writing crap.
>> 
>> I've yet to see solid evidence to support that. The alternative to
>> projects going astray and producing crap has typically been a grand
plan
>> that starts all over from scratch and produces something worse. That
is
>> a *very* repeating theme in software development. Its de rigeur in
>> defence work.
>> 
>>>I'm not criticizing the notion of shipping product in a timely manner
--
>> 
>>>that's not hard to figure out.  I just got the general impression that
>> 
>> Shipping something people value, in a timeframe that makes them
provide
>> good revenue, has proved to be the hardest thing to figure out in the
>> entire software business.
>> 
>>>the guy's attitude was "I don't like those dippy academics sticking
>>>their
>> 
>>>heads up their asses in a dippy academic way, so I'm going to stick
_my_
>> 
>>>head up _my_ ass in a manly cowboy way!".
>> 
>> His attitude is something useful and shipping trumps grand plans that
go
>> nowhere. What you said is your own invention.
>> 
>>>It is humanly possible to write code that is both solid and correct.
>> 
>> Do you have hard evidence to support that? Most attempts to evaluate
>> correctness flounder badly.
>> 
>>>Slop for the sake of schedule becomes slop for the sake of kissing the
>>>boss's ass sooner rather than later, and then you're writing crap.
>> 
>> Its the people with the grand plans that go nowhere who are the
typical
>> ass kissers, promising wonderous things. People who actually ship
stuff
>> usually have to be satisfied with smug sense of a job well done.
>
>So after you get something barely good enough to ship do you depart for 
>other companies so the regular employees are left trying to keep your 
>stuff working?

Why are you just interjecting with random out of context comments?

Steve

>On Fri, 25 Sep 2009 04:34:47 -0700, Rune Allnor wrote:
>
>> On 25 Sep, 09:31, Jerry Avins <j...@ieee.org> wrote:
>> 
>>> But you seem to assume that plain and simple is crap, and that fancy
>>> and trendy is is the superior alternative.
>> 
>> Are you attributing those sorts of opinions to Tim? Based on what
>> writings of his?
>> 
>>> To particularise, code should be
>>> as simple as possible, but not simpler.
>> 
>> That's not what the link you referred to said. The article said more
or
>> less that "screw any attempts to work systematically and
professionally,
>> and let me and the guys do as we always did."
>> 
>> Rune
>
>That's pretty much how I read it.
>
>A good part of my career has been to rewrite or at least fix code that 
>others have written.  I've fixed code written by people whose attitude 
>problem is that fancy is bad -- which means that I'm untangling spaghetti

>code, and I've fixed code written by those egghead types that feel that 
>if you haven't exercised every last feature of C++ then you've missed out

>on life.
>
>Both sets of people shared the conviction that they were up to any task,

>that reality shouldn't get in the way of getting code written quickly, 
>and that thorough testing of absolutely new stuff that they'd just done 
>was insulting to their intelligence and integrity.
>
>So at the same time that this guy was bitterly complaining about people 
>in the former half of the problem group, he was working hard to make it 
>sound like he belongs firmly in the latter half of the problem group.

Much of the worst code I've been tasked with sorting out "had to be
written that way for performance". "That way" has taken various forms, but
it has usually been possible to improve the performance by replacing the
original with something clean and simple. The obvious exceptions have been
parallel code, which never ends up very simple when you get it to go fast.
The thing is that whatever practices they use, most people just aren't very
good at what they do. In the end, no practice will substitute for talent,
or a good attitude.

Steve
 

steveu wrote:
>> On 25 Sep, 17:22, Richard Dobson <richarddob...@blueyonder.co.uk>
>> wrote:
>>> Rune Allnor wrote:
>>>
>>> ..
>>>
>>>> Your story has all the ingredients of craftmanship. The duct-
>>>> tape programming BS is more towards "leave me me alone and I
>>>> will just come up with *something*."
>>> I have understood the "duct tape" description slightly differently. It
>>> is like the person who can use nylon stockings to substitute for a
>>> broken cam belt, or a hairpin to pick a lock. Great skill may be
>>> required for both, and at the time it may be life-saving; but neither
>>> solution is actually "better" than fitting a new cam belt or using the
>>> correct key - in the latter case indeed there is virtually no skill
>>> required at all.
>> Those types of solutions might be accepted as some sort
>> of McGyver'ish skin-of-the-teeth save-my-day-NOW!! kind
>> of solution, but they are never more than an ad-hoc way
>> of treating an immediate problem.
>>
>> If that sort of solutions is the name of the game, the
>> business is doomed.
>>
>>> The problem arises when a program is developed quickly
>>> as a proof of concept, sort of brainstorming in code (do that myself
>>> lots of times); but then it is thought to be working well enough to be
>>> "developed" directly into a deliverable application, "leveraging" all
>>> the initial code, rather than designing properly from scratch.
>> This is why all projects fail: People don't understand the
>> difference between proof-of-concept code and production code.
>>
>>> My own
>>> rule of thumb is that a program needs to be designed and implemented
> at
>>> least twice. If it is not, the chances of duct tape (or hairpins)
> being
>>> delivered to customers is that much greater.
>> Agreed.
>>
>>> Part of the problem is also the "blank slate" syndrome; all too often
>>> the requirements of a package are not worked out or even imagined
> until
>>> there is some prototype to criticize. At best, the working prototype
>>> leads to all sort of "hey, we could do this too" ideas. It is then a
>>> mixture of luck and judgement if the prototype is ready to support all
>>> that new a-posteriori input.
>>>
>>> I seem to recall one cause of an Arianne rocket explosion was that one
>>> software "unit" was working in kilos and grams, while another was
>>> working in pounds and ounces. Each unit worked fine, and even when put
>>> together the numbers were plausible, and might have passed both unit
> and
>>> integration testing; but were just wrong.
>> Wasn't that the first post-Viking Mars spacecraft? The brits
>> have made a lot of mischief: Their stubbornness about not
>> driving on the correct side of the road cost hundreds if not
>> thousands of lives every year: People are used to driving on
>> one side, and react instinctively accordingly when meeting
>> obstacles. When they visit a country where people drive on the
>> other side of the road, the instinct reaction get drivers into
>> even greater trouble than what they try to avoid.
> 
> The British drive on the same side as much of the planet - Australia,
> Japan, Malaysia, Singapore, Hong Kong, India, much of the middle east. Its
> also the side that is more natural for a right handed person, keeping the
> right hand in control of steering at all times.

Brits are as turned around as the rest of us. Originally, British (and 
American) wagons had the driver sitting on the left and driving on the 
left side of the road. That made it easy to pull up to the side of the 
road without going off it. (There were few curbs.) The very poor 
conditions on American rural roads made it advisable for wagons to pass 
driver-to-driver, so the practice became to pass to the right, and 
therefore to keep to the right on roads wide enough to allow that. The 
wisdom of this was seen in Britain as well, but they responded by moving 
the driver's seat to the other side.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

>The British drive on the same side as much of the planet - Australia,
>Japan, Malaysia, Singapore, Hong Kong, India, much of the middle east.
Its
>also the side that is more natural for a right handed person, keeping
the
>right hand in control of steering at all times.

Oh, I thought hands were for texting, and you could just enjoy both sides
of the road...been doing it wrong, I guess...

>>On Fri, 25 Sep 2009 04:34:47 -0700, Rune Allnor wrote:
>>
>>So at the same time that this guy was bitterly complaining about people

>>in the former half of the problem group, he was working hard to make it

>>sound like he belongs firmly in the latter half of the problem group.
>
>Much of the worst code I've been tasked with sorting out "had to be
>written that way for performance". "That way" has taken various forms,
but
>it has usually been possible to improve the performance by replacing the
>original with something clean and simple. The obvious exceptions have
been
>parallel code, which never ends up very simple when you get it to go
fast.
>The thing is that whatever practices they use, most people just aren't
very
>good at what they do. In the end, no practice will substitute for
talent,
>or a good attitude.
>
>Steve

An important testing step in this situation is to write a couple
implementations and compare them, both for speed and similarity of results.
 A black box approach here has often served me well, unlike with most of my
testing, because I can usually automate it such that it tests just about
every possibility.  This only works with the simplest functions, but the
ones considered for optimization usually are (but are called frequently),
so it works out nicely.

And a slight speed improvement, in exchange for much additional difficulty
of maintenance, is, of course, usually not worthwhile.  (Some exceptions in
embedded stuff, but even then...)

>Rune Allnor wrote:
>..
>> Your story has all the ingredients of craftmanship. The duct-
>> tape programming BS is more towards "leave me me alone and I
>> will just come up with *something*."
>> 
>
>I have understood the "duct tape" description slightly differently. It 
>is like the person who can use nylon stockings to substitute for a 
>broken cam belt, or a hairpin to pick a lock. Great skill may be 
>required for both, and at the time it may be life-saving; but neither 
>solution is actually "better" than fitting a new cam belt or using the 
>correct key - in the latter case indeed there is virtually no skill 
>required at all. The problem arises when a program is developed quickly 
>as a proof of concept, sort of brainstorming in code (do that myself 
>lots of times); but then it is thought to be working well enough to be 
>"developed" directly into a deliverable application, "leveraging" all 
>the initial code, rather than designing properly from scratch. My own 
>rule of thumb is that a program needs to be designed and implemented at 
>least twice. If it is not, the chances of duct tape (or hairpins) being 
>delivered to customers is that much greater.
>
>Part of the problem is also the "blank slate" syndrome; all too often 
>the requirements of a package are not worked out or even imagined until 
>there is some prototype to criticize. At best, the working prototype 
>leads to all sort of "hey, we could do this too" ideas. It is then a 
>mixture of luck and judgement if the prototype is ready to support all 
>that new a-posteriori input.

Part of the strategy I usually adopt wrt to design uncertainty when I'm
working alone on a project that will take me a long time (maybe a couple
months or more) is to unit test only functions that I'm sure belong.  Put
differently, the likelihood of my writing a unit test increases
monotonically with my certitude that the specs of that function are
appropriate.

>http://www.joelonsoftware.com/items/2009/09/23.html
>
>Jerry

The examples the author gives seem rooted in particular experiences he
doesn't describe, particularly with regard to multithreading. 
Multithreading with COM is, from what I've heard, a pain.  Heck, COM is a
pain.  But he essentially seems to be claiming threading is without merit,
which is absurd.  It's usually unwarranted, but very useful in some
situations (keeping a responsive GUI while you crunch numbers in the
background is an oft-cited example).  Having significantly more runnable
threads than cores is a bad idea, and some schedulers even deal poorly with
that.

One point I'll agree wholeheartedly with is "multiple inheritance sucks.
Stop it. Just stop." :)

The situations where OO techniques (which can be implemented in C or C++,
in spite of C not being an "OO" language...think "handle" or "context") are
most beneficial is where you have more than one person coding, or where
you're prone to come back to a large piece of code later and want to extend
it.  So for very small projects (8-bit MCU code, e.g.), the "throw
something together" approach might be appropriate, and even maintainable. 
But usually it's not.

Tim Wescott wrote:

> It was the "I'm too manly for testing" and "shipping on schedule
> is more important than shipping something that works" threads
> within the statements that bothered me.  That, and his
> assumption that dead simple is never too simple.

Some here may not be aware of it but those impressions are part of 
why Joel Spolsky is infamous in the programming-related net spaces. 
Anyway, it's just a blog.


Martin

-- 
Quidquid latine scriptum est, altum videtur.

On Sep 25, 11:22=A0am, Richard Dobson <richarddob...@blueyonder.co.uk>
wrote:
>
> I seem to recall one cause of an Arianne rocket explosion was that one
> software "unit" was working in kilos and grams, while another was
> working in pounds and ounces. Each unit worked fine, and even when put
> together the numbers were plausible, and might have passed both unit and
> integration testing; but were just wrong.
>
> Richard Dobson

I don't know how many Arianne rockets have exploded, but the one I
remember was well documented and discussed in the software community.
From

    http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html

"The Ariane 5 Accident: A Programming Problem?" by Peter B. Ladkin:

"The problem was caused by an `Operand Error' in converting data in a
subroutine from 64-bit floating point to 16-bit signed integer.  One
value was too large to be converted, creating the Operand Error.  This
was not explicitly handled in the program (although other potential
Operand Errors were) and so the computer, the Inertial Reference
System (SRI) halted, as specified in other requirements.  There are
two SRIs, one `active', one `hot back-up' and the active one halted
just after the backup, from the same problem.  Since no inertial
guidance was now available, and the control system depends on it, we
can say that the destructive consequence was the result of `Garbage
in, garbage out' (GIGO).  The conversion error occurred in a routine
which had been reused from the Ariane 4 vehicle, whose launch
trajectory was different from that of the Ariane 5.  The variable
containing the calculation of Horizontal Bias (BH), a quantity related
to the horizontal velocity, thus went out of `planned' bounds
(`planned' for the Ariane 4) and caused the Operand Error.  Lots of
software engineering issues arise from this case history."

In short, code based on assumptions about the launch trajectory of the
Ariane 4 was reused in the Ariane 5 without changing the assumptions
in the code to handle the Ariane 5's different trajectory.  Very
interesting reading!

Alex
http://www.geonius.com/software/finc/

P.M.Lawrence wrote:
> Hey! Who was there first? And what is the most natural side (given
> that most people are right handed), if you had to decide impartially
> and weren't influenced by being conquered by arbitrary Napoleonic
> systems or awkward large scale wagons that needed even more skill
> controlling the team from the left than attention to the road? It's
> not a coincidence that the most recent country to switch went our way.

The most recent country to switch went your way, but a big majority of 
the population opposes this switch.  It's just the brother of the 
president who wants to make a fortune by importing Japanese used cars 
instead of used US cars as there are now.  Nepotism isn't a good 
argument.

I'm also not sure what "right-handed" has to do with it.  Starboard is 
on the right side of the boat because the rudder handle is a simple 
stick, and you use your right hand to operate it.  A car (and any modern 
boat) has a steering wheel, it's round, it has no preferred side.  The 
only stick to operate in a car is the gearbox stick, and that by your 
argument should be on the right side of the driver - which it is for 
right-side driving.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

In article <Mh5vm.199758$AC5.153999@newsfe06.ams2>,
Richard Dobson  <richarddobson@blueyonder.co.uk> wrote:

<SNIP>

>
>I seem to recall one cause of an Arianne rocket explosion was that one
>software "unit" was working in kilos and grams, while another was
>working in pounds and ounces. Each unit worked fine, and even when put
>together the numbers were plausible, and might have passed both unit and
>integration testing; but were just wrong.

Hasn't that one been refuted as being caused by management not
allowing enough time for testing?

>
>Richard Dobson

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Albert van der Horst wrote:
> In article <Mh5vm.199758$AC5.153999@newsfe06.ams2>,
> Richard Dobson  <richarddobson@blueyonder.co.uk> wrote:
> 
> <SNIP>
> 
>> I seem to recall one cause of an Arianne rocket explosion was that one
>> software "unit" was working in kilos and grams, while another was
>> working in pounds and ounces. Each unit worked fine, and even when put
>> together the numbers were plausible, and might have passed both unit and
>> integration testing; but were just wrong.
> 
> Hasn't that one been refuted as being caused by management not
> allowing enough time for testing?
> 

Very possibly; but hardly a refutation. By definition, a bug is (among 
other things) something that has not been caught by testing, planning, 
design, verification of assumptions, etc. Such things are most worrying 
(and tragically, sometimes fatal) when the bug (or structural fault) has 
been identified and warnings issued, but not acted on.

Richard Dobson

Alex  <c.a.measday@ieee.org> wrote:

>    http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html

>"The Ariane 5 Accident: A Programming Problem?" by Peter B. Ladkin:

>"The problem was caused by an `Operand Error' in converting data in a
>subroutine from 64-bit floating point to 16-bit signed integer.  One
>value was too large to be converted, creating the Operand Error.  This
>was not explicitly handled in the program (although other potential
>Operand Errors were) and so the computer, the Inertial Reference
>System (SRI) halted, as specified in other requirements.  There are
>two SRIs, one `active', one `hot back-up' and the active one halted
>just after the backup, from the same problem.  Since no inertial
>guidance was now available, and the control system depends on it, we
>can say that the destructive consequence was the result of `Garbage
>in, garbage out' (GIGO).  The conversion error occurred in a routine
>which had been reused from the Ariane 4 vehicle, whose launch
>trajectory was different from that of the Ariane 5.  The variable
>containing the calculation of Horizontal Bias (BH), a quantity related
>to the horizontal velocity, thus went out of `planned' bounds
>(`planned' for the Ariane 4) and caused the Operand Error.  Lots of
>software engineering issues arise from this case history."

>In short, code based on assumptions about the launch trajectory of the
>Ariane 4 was reused in the Ariane 5 without changing the assumptions
>in the code to handle the Ariane 5's different trajectory.  Very
>interesting reading!

It seems clear the code module in question was never regressed. 
This is not a "garbage-in, garbage-out" situation, nor
a problem with assumptions; this is a coding error that should have 
been caught by testing.


Steve

In article <7Dmvm.236472$Hw6.181058@newsfe22.ams2>,
Richard Dobson  <richarddobson@blueyonder.co.uk> wrote:
>Albert van der Horst wrote:
>> In article <Mh5vm.199758$AC5.153999@newsfe06.ams2>,
>> Richard Dobson  <richarddobson@blueyonder.co.uk> wrote:
>>
>> <SNIP>
>>
>>> I seem to recall one cause of an Arianne rocket explosion was that one
>>> software "unit" was working in kilos and grams, while another was
>>> working in pounds and ounces. Each unit worked fine, and even when put
>>> together the numbers were plausible, and might have passed both unit and
>>> integration testing; but were just wrong.
>>
>> Hasn't that one been refuted as being caused by management not
>> allowing enough time for testing?
>>
>
>Very possibly; but hardly a refutation. By definition, a bug is (among
>other things) something that has not been caught by testing, planning,
>design, verification of assumptions, etc. Such things are most worrying
>(and tragically, sometimes fatal) when the bug (or structural fault) has
>been identified and warnings issued, but not acted on.

Refutation is not the right word. Anyway I learned a very long time
ago to align all units in a program to standard metric.

So my NSEAF program calculated the outcome of the Brent oil fields
in cubic metre per second. (which was a reasonable unit, the right
order of magnitude!)
Then for output it was converted into thousands of barrels per day.
I introduced kilo-barrels, because I didn't like "mbarrels"
in the output, which looked like milli-barrels.

(And the whole database fitted on a box of punch cards, just
not too heavy to pay extra on the plane ...)

>
>Richard Dobson

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Bernd Paysan wrote:
> P.M.Lawrence wrote:
>> Hey! Who was there first? And what is the most natural side (given
>> that most people are right handed), if you had to decide impartially
>> and weren't influenced by being conquered by arbitrary Napoleonic
>> systems or awkward large scale wagons that needed even more skill
>> controlling the team from the left than attention to the road? It's
>> not a coincidence that the most recent country to switch went our way.
> 
> The most recent country to switch went your way, but a big majority of 
> the population opposes this switch.  It's just the brother of the 
> president who wants to make a fortune by importing Japanese used cars 
> instead of used US cars as there are now.  Nepotism isn't a good 
> argument.
> 
> I'm also not sure what "right-handed" has to do with it.  Starboard is 
> on the right side of the boat because the rudder handle is a simple 
> stick, and you use your right hand to operate it.  A car (and any modern 
> boat) has a steering wheel, it's round, it has no preferred side.  The 
> only stick to operate in a car is the gearbox stick, and that by your 
> argument should be on the right side of the driver - which it is for 
> right-side driving.

Old Semitic languages were written right to left. The only reason I can 
thing of for that is the moon's terminator advancing from right to left 
in the Northern hemisphere, so it seemed like a "natural" direction. 
Right-handed people smudge ink-based writing, so eventually the standard 
direction became left to right.

Early boats were steered with an oar (German: ruder) over the side near 
the stern. The port side of a boat is so named because that was the side 
customarily against the quay or pier. Consequently, the steering oar was 
usually mounted on the starboard side and operated with the left hand.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Bernd Paysan wrote:
> Rune Allnor wrote:
> > It's in everybody's interest to point out exactly where
> > the problem lies: If the code passes the unit tests, the
> > coders are not to blame. And vice versa.
>
> Nope.  A test can only detect the presence of bugs, never the absence.
> Also, a failing test can have two causes: either a bug in the program, or a
> bug in the test.

Three: interaction between tests.

>  Unit tests are particularly weak tests, because they only
> test units, not the whole thing.

In addition, they get outdated while the project develops.

>  "Integration hell" is what happens when
> you put things together that worked well in isolation - but don't work
> together.
>
> Note that many people write tests to check "if it works".  They don't write
> tests to break their program.  E.g. take the following:
>
>
> : plus  or ; \ twice as fast as +
>
> T{ 1 2 plus -> 3 }T
> T{ 1 4 plus -> 5 }T
> T{ 2 1 plus -> 3 }T
> T{ 4 2 plus -> 6 }T
>
> O, we passed the unit tests.  Our Russian or Chinese programmer has found a
> tuning opportunity, and the module still passes the tests.  The tests are
> obviously incomplete.

Krishna Myneni wrote:
> I think there's some truth in the article, but I don't believe it's
> completely accurate. Things held together with duct tape can rarely be
> built upon --- add one thing and it's likely to break.

Remember, what's described in the article is Netscape.  We know how the 
source code of Netscape looked like, because it was once released as 
free software.  It was horrible.  The transition from Netscape to 
Gecko/Firefox was mostly a complete rewrite, to build a solid 
foundation.  And even then, Gecko is not a very simple and clean HTML 
engine, therefore Apple took the much cleaner KHTML as base of Webkit.

KHTML is written in C++. Condemning OO for being "too complicated" is 
just silly - you can write crazy stuff in C++, where you just build 
layers on layers of complexity, but if you do it right, OO reduces 
complexity.  Using OO where it's appropriate and not using it where it 
doesn't give benefits is the right approach.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Jonah Thomas wrote:
> I did learn to deal with all of Word's quirks, or at least all the
> ones I ran into over the course of a few big documents. I still
> thought Word was definitely suboptimal. The guy on the internet was
> right too, if you're going to be a professional who uses Word then
> it's your responsibility to learn how to use it well.

Bad comparison.  If you want to professionally layout books with 400+ 
pages, you don't learn Word, you learn LaTeX.  It's like when you want 
to dig a tunnel through the alps, you don't go to the next DIY store, 
and buy a rock drill for $50, known to work somehow for the first 20cm.  
You get the proper equipment.  Word is not the proper equipment for 400+ 
pages books.  It is the proper equipment for short notes.  That's why 
it's called "Word", not "Sentence" or "Page" or even "TeX"(t).  If 
somebody writing Word also looked at 4chan, you'd see a cat popping up 
in the lower right corner telling you "I writed your a word, but I ated 
it ;-)".

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Jerry Avins <jya@ieee.org> wrote:
>[...] 
> Old Semitic languages were written right to left. The only reason I can 
> thing of for that is the moon's terminator advancing from right to left 
> in the Northern hemisphere, so it seemed like a "natural" direction. 
> Right-handed people smudge ink-based writing, so eventually the standard 
> direction became left to right.

Actually, right handed people tend to hold the hammer with the right hand
and the chisel with the left hand. This should give a more obvious reason
for the writing direction of old semitic languages.

-- 
Marc

Bernd Paysan wrote:
> Jonah Thomas wrote:
>> I did learn to deal with all of Word's quirks, or at least all the
>> ones I ran into over the course of a few big documents. I still
>> thought Word was definitely suboptimal. The guy on the internet was
>> right too, if you're going to be a professional who uses Word then
>> it's your responsibility to learn how to use it well.
> 
> Bad comparison.  If you want to professionally layout books with 400+ 
> pages, you don't learn Word, you learn LaTeX.  It's like when you want 
> to dig a tunnel through the alps, you don't go to the next DIY store, 
> and buy a rock drill for $50, known to work somehow for the first 20cm.  
> You get the proper equipment.  Word is not the proper equipment for 400+ 
> pages books.  It is the proper equipment for short notes.  That's why 
> it's called "Word", not "Sentence" or "Page" or even "TeX"(t).  If 
> somebody writing Word also looked at 4chan, you'd see a cat popping up 
> in the lower right corner telling you "I writed your a word, but I ated 
> it ;-)".

Well, the professionals I know (as well as myself, as regards the books 
I've written and edited) use FrameMaker or (more recently) InDesign. 
But I totally agree with your essential point, that Word is much better 
for smaller or more casual projects.

I'm not sure why Jonah had so much trouble, though.  I started using 
Word with Version 1.0 (about 1984),  and got along with it well until we 
started working on larger projects, at which time we looked for (and 
found) alternatives.

Prior to the advent of Word, we used a Forth-based editing and 
formatting system that was originally developed by Chuck in the 70's, 
and had a lot in common with the later development of html (text 
surrounded by tags for various purposes).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

In comp.lang.forth Bernd Paysan <bernd.paysan@gmx.de> wrote:
> P.M.Lawrence wrote:
> > Hey! Who was there first? And what is the most natural side (given
> > that most people are right handed), if you had to decide impartially
> > and weren't influenced by being conquered by arbitrary Napoleonic
> > systems or awkward large scale wagons that needed even more skill
> > controlling the team from the left than attention to the road? It's
> > not a coincidence that the most recent country to switch went our way.
> 
> The most recent country to switch went your way, but a big majority of 
> the population opposes this switch.  It's just the brother of the 
> president who wants to make a fortune by importing Japanese used cars 
> instead of used US cars as there are now.  Nepotism isn't a good 
> argument.
> 
> I'm also not sure what "right-handed" has to do with it.[...]

Right handed people find it easier to wear swords on their left
side and hence prefer mounting and demounting horses from the left.
This will then suggest a preferred direction for parking horses
at the roadside, which in turn gives a certain partition of the road.

I do not know if this is the real reason for the british preference.
But at least it looks plausible.

-- 
Marc

m_l_g3 wrote:
>> Unit tests are particularly weak tests, because they only
>> test units, not the whole thing.
> 
> In addition, they get outdated while the project develops.

Indeed, this often happens.  That's why the non-persistent Forth command 
line unit tests before integration are usually sufficient: The module is 
tested once, and then integrated.  Further tests test the whole thing, 
instead of the unit, and the outdated unit tests are never repeated, 
anyways ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Sep 26, 4:39=A0pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> > I think there's some truth in the article, but I don't believe it's
> > completely accurate. Things held together with duct tape can rarely be
> > built upon --- add one thing and it's likely to break.
>
> Remember, what's described in the article is Netscape. =A0We know how the
> source code of Netscape looked like, because it was once released as
> free software. =A0It was horrible. =A0The transition from Netscape to
> Gecko/Firefox was mostly a complete rewrite, to build a solid
> foundation. =A0...

I've had the opportunity to look at code written by engineers who "get
stuff done". Enough said.

> KHTML is written in C++. Condemning OO for being "too complicated" is
> just silly - you can write crazy stuff in C++, where you just build
> layers on layers of complexity, but if you do it right, OO reduces
> complexity. =A0Using OO where it's appropriate and not using it where it
> doesn't give benefits is the right approach.
> ..

Yep. I'll ditto that. Even the list processing approach, a la LISP,
makes sense in many cases. One great aspect of Forth is its innate
ability to cast itself into whatever model makes sense -- I can write
pure Forth code (properly factored, when pushed to do so), or get into
low-level mode and write assembly code as part of a Forth program, or
go higher level with OO or lists. For fun, it might be interesting to
find an application that benefits from all of these approaches and
demonstrate the capability to do such multi-faceted programming in
Forth.

Krishna

Marc Olschok wrote:
> Jerry Avins <jya@ieee.org> wrote:
>> [...] 
>> Old Semitic languages were written right to left. The only reason I can 
>> thing of for that is the moon's terminator advancing from right to left 
>> in the Northern hemisphere, so it seemed like a "natural" direction. 
>> Right-handed people smudge ink-based writing, so eventually the standard 
>> direction became left to right.
> 
> Actually, right handed people tend to hold the hammer with the right hand
> and the chisel with the left hand. This should give a more obvious reason
> for the writing direction of old semitic languages.

Chiseling in stone was an infrequent way to write. Marking paper and 
impressing clay were the norms.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On 26 Sep, 23:39, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> > I think there's some truth in the article, but I don't believe it's
> > completely accurate. Things held together with duct tape can rarely be
> > built upon --- add one thing and it's likely to break.
>
> Remember, what's described in the article is Netscape. =A0We know how the
> source code of Netscape looked like, because it was once released as
> free software. =A0It was horrible. =A0

I have some recollection of hearing an anecdote to the effect
that Netscape (the company, not the browser) went down because
the code in the end was so bug-infested it was all but impossible
to maintain, let alone expand upon?

Rune

Marc Olschok <nobody@nowhere.invalid> writes:
>Right handed people find it easier to wear swords on their left
>side and hence prefer mounting and demounting horses from the left.
>This will then suggest a preferred direction for parking horses
>at the roadside, which in turn gives a certain partition of the road.

The story I heard is that it gives a preferred side for passing
oncoming strangers: You pass them on the left, so they are to your
right, so they cannot obstruct your drawing the sword, and you can
more easily defend attacks from them.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

In article <rqe2p6-3od.ln1@vimes.paysan.nom>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
<SNIP>
>
>Bad comparison.  If you want to professionally layout books with 400+
>pages, you don't learn Word, you learn LaTeX.  It's like when you want
>to dig a tunnel through the alps, you don't go to the next DIY store,
>and buy a rock drill for $50, known to work somehow for the first 20cm.
>You get the proper equipment.  Word is not the proper equipment for 400+
>pages books.  It is the proper equipment for short notes.  That's why
>it's called "Word", not "Sentence" or "Page" or even "TeX"(t).  If
>somebody writing Word also looked at 4chan, you'd see a cat popping up
>in the lower right corner telling you "I writed your a word, but I ated
>it ;-)".

Indeed. While "Mark Williams" Coherent had a proud announcement
on the copyright page, stating
  This manual was written under the Coherent operating system,
  using .. MicroEMCS  ... troff ...LaserJet III

Coherent was a 286 (16 bit) unix clone. This manual is still in use
by me, because it is excellent.

In the meantime diehard Petzold's "programming Windows 3.1"
is one of the few examples of Microsoft documentation written in
MSWord that I know of.

>--
>Bernd Paysan

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Anton Ertl wrote:
> Marc Olschok <nobody@nowhere.invalid> writes:
>> Right handed people find it easier to wear swords on their left
>> side and hence prefer mounting and demounting horses from the left.
>> This will then suggest a preferred direction for parking horses
>> at the roadside, which in turn gives a certain partition of the road.
> 
> The story I heard is that it gives a preferred side for passing
> oncoming strangers: You pass them on the left, so they are to your
> right, so they cannot obstruct your drawing the sword, and you can
> more easily defend attacks from them.

Whatever the original reasons were, the common practice in the US and 
the rest of the world was the same until rural transportation realities 
made it desirable for wagons to pass driver-to-driver instead if the 
urban practice of driver-to-roadside. In the US, this was accomplished 
by the simple expedient of keeping standard wagons and adopting 
keep-right-to-pass. In the rest of the world, wagon seats were moved and 
keep-left-to-pass was retained. Didn't Napoleon turn most of the rest of 
Europe around?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Sep 25, 2:31=A0pm, "Michael Plante" <michael.pla...@gmail.com> wrote:
> >http://www.joelonsoftware.com/items/2009/09/23.html
>
> >Jerry
>
> The examples the author gives seem rooted in particular experiences he
> doesn't describe, particularly with regard to multithreading.
> Multithreading with COM is, from what I've heard, a pain. =A0Heck, COM is=
 a
> pain. =A0But he essentially seems to be claiming threading is without mer=
it,
> which is absurd. =A0It's usually unwarranted, but very useful in some
> situations (keeping a responsive GUI while you crunch numbers in the
> background is an oft-cited example). =A0Having significantly more runnabl=
e
> threads than cores is a bad idea, and some schedulers even deal poorly wi=
th
> that.

Hmm...I think you correctly point out Joel's incorrect notion that
threading is bad...

> One point I'll agree wholeheartedly with is "multiple inheritance sucks.
> Stop it. Just stop." :)

But then you do a bit of the same thing reagard multiple inheritance.
MI has created elegance and relgularity on many occasions in my code.
Here is example of templates, multiple-inheritance, synchronization,
and pointers all being used simultaneously:

struct Arrivals : Shared<Counted<Queue<Frame *> > >
{
 Arrivals ();
 Arrivals (const Arrivals &);
 Arrivals & operator =3D (const Arrivals &);

 Duration wait_limit;
 unsigned long int bad_frame_count;
 unsigned long int bad_frame_limit;

 void empty ();
 ~Arrivals ();
} arrivals;

You cannot see the MI or synchronization directly, but they are there,
twice in fact. And there is nothhing horrendously complex about this
code. I would have had to achieve the same net result in another way,
only the other way would have been distasteful.

---

This is not the first time that Joel has bashed higher-orders of
engineering. He also wrote an article about why he doesn't like
programming with exceptions:

http://www.joelonsoftware.com/items/2003/10/13.html

Of course, exceptions are a foundation of regularity in complex
software systems. Without them, the problems that warranted them do
not go away - they are simply treated more poorly. There is also the
matter of Reachability In System Space (RISS). Insisting on always
using wood means that some space ships will simply not be possible, so
it is important to keep in mind what it is you are making or trying to
make.

This whole argument is about Class Struggle and has strong parallels
in history. Even in the time of Heaviside and whether transfer
functions were good or bad, you find the same actors on the stage:

1. There would be the Self-Deluded Manager (SDM) who hires people who
really should not be called engineers, because they do not think like
engineers, but are so-called anyway, because the demand for engineers,
~any~ kind of engineer, far exceeds the demand for true competence.
This manager will be perpetually looking for silver bullet to make his
dumb engineers smart:

http://en.wikipedia.org/wiki/No_Silver_Bullet

2. There would be the Raw Ability Engineers (RAEs). These are people
were engineers right around the time that they popped out into the
world. They inadvertently move this whole mess forward, by
occasionally catching the other groups off guard. Every now and them,
one of them finds a new way of seeing or doing something, like
transfer functions, stacks in CPU's, exit velocity of gases, etc.

3. There would be the Self-Deluded Engineers (SDE's) who buy into the
notion of All-Engineers-Are-Equal, and try in vain to self-realize
this notion by buying lots of books, attending conferences, taking
courses, posting their training certifications on the wall, self-
congratulating each other in user-groups and support groups, making
sure that everyone works together as a team, *ESPECIALLY* the RAE,
whom they might silently respect, but work ardously to mitigate any
apparent gross disparity his skill level and theirs. They will work to
elevate the importance of things that require more mind than hand,
like test automation, build systems, etc. They will complain about any
company direction that places too much emphasis on mind, irrespective
of whether more mind is necessary to overcome a particular task. These
birds of a feather flock together.

4. There would be the Framework Masturbators (FM's). These are people
who are, in some ways, worse than the SDE's. Often times, these are
people gifted in spoken languages, especially grammatical structure.
They are outstanding at analysis, but hopelessly inept at synthesis.
They spend extraordinary amounts of time learning frameworks,
languages, patterns, etc, disucssing the relative merits of one over
the other. They write software that analyzes other software that they
have written to test whether they have used various language elements
of the language as they wrote the first software. They layer virtual
machine on virtual machine on vitural machine. They become excited by
introspection: the idea that code and look at it self and determine
how it is written, even though they were the ones who wrote the code
in the first place. They vigorously and contemptuously disregard and
disacknowledge the possibility that an RAE might have the foresight to
engineer what it is s/he wants, with rigor. [Joel implicitly and
correctly critizes TM's, but he makes no distinction between TM's and
RAE's, which is incorrect].

5. There would the the Astute-But-Non-Technical-Observer' (ABNTO's).
These are people who have no background in engineering, but are adept
in their own disciplines (law, medicine, etc.) Though they are not
able to create engineered artifacts themselves, they are able to
discern relative virtue of one artifact over another from the
periphery. These people, IMO, are critical for the survival of RAE's.
They are non-fanatical, either in support or subversion, but others
have no choice to heed their words when they speak.

6. There would be the Agnostic Consumers (AC'). These are people who
buy the product. If it looks like a baboon's ass, they will go to
their blog and non-chalantly write, "I like the performance of the
product, but it looks like a baboon's ass." These people are also
important for the survival of RAE's. They are the largest group, and
they provide a somewhat objective assessment of the product after all
the absudity that preceeds the deliverance of the product. They are
the one's who don't mind mentioning, in public, that exploding Space
Shuttle are a bad thing. What makes them different from ABNTO's is
that ABNTO's will go on further to insist that competent engineers
should be allowed to do their jobs to prevent said Space Shuttles from
exploding.

7. There would be the Selfish-Preserving-Encroaching-Pragmatists
(SPEP's). These are people who work in an  engineering setting but do
not like engineering any more than they would like car washing. They
faired poorly in school in mathematics and science. But a salary of
$90,000US in a company where socks are optional is very hard to let
go, so they conscientiously choose "engineering" as a career. They are
often found in singular, peripheral roles, sometimes assuming the
title of Business Analyst, a cleverly-created title that gives an
employee the slippery opportunity to disclaim technical ability in
presence of those who are truly analytical, while disclaiming business
ability in those who are truly adept at management.  Since their
fundamental motivation is self-preservation and advancement, they tend
to have the sharpest claws, and will viciously attack anyone who tries
to call them out. They strive to solidify their positions by carefully
and inrementally reducing the perceived importance of skill levels of
RAE's on quality of products. They will deliberately encourage the
hiring of SDE's over RAE's, all other things being equal.

7. There would be, IMO, the most dangerous and scariest group of them
all, the Social Equalizers (SE's). These are peole who are neither
engineers or ABNTO's or SPEP's, and might or might be AC's, but have a
very keen interest regarding the RAE's with respect to everyone else.
They believe that RAE's should not exist, or, if they do exist, should
only employ their ability for the "betterment of mankind". They abhor
the hoarding of money/fame/power by anyone, including RAE's, and will
occasionally associate with SDE's. Some SE's are so fanatical about
their principles that they will go out of their way to enter the world
of RAE's/SDM's/SDE's for the purpose of influencing the dynamics at
play. They work to trounce anything tool that allows the aggravation
of the disparity between RAE's and others. If they could have their
way, there would be far more art/history/culture in the academy, less
math, and even less science, except for "Good Science", like the kind
that would save the environment. Their goal is to turn anything they
touch into a mostly social experience. The lastest victim is
programming.

Randomly chosen link to illustrate this last point:

http://thoughtfulprogrammer.blogspot.com/2009/06/programming-language-socio=
logy.html

-Le Chaud Lapin-

Elizabeth D Rather wrote:
> Well, the professionals I know (as well as myself, as regards the
> books I've written and edited) use FrameMaker or (more recently)
> InDesign. But I totally agree with your essential point, that Word is
> much better for smaller or more casual projects.

The German TeX user community is particularly strong. I've used 
FrameMaker once, nearly 12 years ago, to edit a specification document 
with less than 100 pages, but a number of OLE components (mostly Visio 
drawings). It showed about the same symptoms as Word would: it regularly 
ate the document (or rather all OLE parts - the FrameMaker native parts 
survived all that).

Generally, FrameMaker has a good reputation - either this is just by 
comparison to Word, or this is when not using OLE ;-). Later, I had to 
contribute parts to a larger document (test cases description), and 
ended up writing that part in LaTeX, because there I could generate a 
lot of the text automatically: Extract the test description from source, 
and extract more details from the test run itself. Converting simple 
LaTeX into FrameMaker is easy to do, as is the other way round. But the 
typesetting results of LaTeX are usually better. And a number of things 
are far from easy and obvious in FrameMaker: It took me quite some time 
to figure out how to create a proper table of content, because without I 
was lost in the document, and the original author didn't even have a 
clue how to do it (FrameMaker uses a "template" approach, and the TOC 
templates were empty in that document).

In this project, there was also the (for Germany) typical rivalry 
between the FrameMaker people (who used Windows and had their tool 
officially approved), and the LaTeX people (who used mostly Solaris, and 
used their tool, despite of not being officially approved, because 
FrameMaker wasn't up to the task, like e.g. for literate programming).

About text with tags: Apart from Word (which is really weird how it 
attributes text, and by doing it so weird, it is also very fragile), 
this is common practice, and was first proposed in 1967. I would be 
surprised if Chuck would do it differently. He now even uses this 
concept for programming, it's called ColorForth ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Rune Allnor wrote:
>> Remember, what's described in the article is Netscape.  We know how
>> the source code of Netscape looked like, because it was once released
>> as free software.  It was horrible.
> 
> I have some recollection of hearing an anecdote to the effect
> that Netscape (the company, not the browser) went down because
> the code in the end was so bug-infested it was all but impossible
> to maintain, let alone expand upon?

This is no surprise.  Fortunately, there is only one browser left which 
was originally coded by Marc Andreesen: Internet Explorer.  Guess why 
they have so many troubles keeping up with the features of the 
competition (and through Microsoft's "keep it compatible" policy, they 
aren't even allowed to clean up the mess... though it's now probably 
contained in the "quirk mode").

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Bernd Paysan wrote:
> Elizabeth D Rather wrote:
>> Well, the professionals I know (as well as myself, as regards the
>> books I've written and edited) use FrameMaker or (more recently)
>> InDesign. But I totally agree with your essential point, that Word is
>> much better for smaller or more casual projects.
> 
> The German TeX user community is particularly strong. I've used 
> FrameMaker once, nearly 12 years ago, to edit a specification document 
> with less than 100 pages, but a number of OLE components (mostly Visio 
> drawings). It showed about the same symptoms as Word would: it regularly 
> ate the document (or rather all OLE parts - the FrameMaker native parts 
> survived all that).

I first met FrameMaker in the mid-90's.  I edited a couple of books with 
it, as did our official document editor, Marlin Ouverson.  I don't 
believe either of us ever suffered from an "eaten document".

> Generally, FrameMaker has a good reputation - either this is just by 
> comparison to Word, or this is when not using OLE ;-). Later, I had to 
> contribute parts to a larger document (test cases description), and 
> ended up writing that part in LaTeX, because there I could generate a 
> lot of the text automatically: Extract the test description from source, 
> and extract more details from the test run itself. Converting simple 
> LaTeX into FrameMaker is easy to do, as is the other way round. But the 
> typesetting results of LaTeX are usually better. And a number of things 
> are far from easy and obvious in FrameMaker: It took me quite some time 
> to figure out how to create a proper table of content, because without I 
> was lost in the document, and the original author didn't even have a 
> clue how to do it (FrameMaker uses a "template" approach, and the TOC 
> templates were empty in that document).

FrameMaker is a complex program.  It offers a lot of power, at a 
considerable cost in complexity.  There's a learning curve, for sure. 
But once you're reasonably well up that curve, a lot of things are 
really easy: not only TOCs, but also indexes and other special features. 
  The tables of words in the back of The Forth Programmer's Handbook, 
for example, take about 10 mins. to generate.

> In this project, there was also the (for Germany) typical rivalry 
> between the FrameMaker people (who used Windows and had their tool 
> officially approved), and the LaTeX people (who used mostly Solaris, and 
> used their tool, despite of not being officially approved, because 
> FrameMaker wasn't up to the task, like e.g. for literate programming).

I have never used LaTeX.  I think it's used a lot more in Europe than 
here.  I assume there's a learning curve with that, too.

> About text with tags: Apart from Word (which is really weird how it 
> attributes text, and by doing it so weird, it is also very fragile), 
> this is common practice, and was first proposed in 1967. I would be 
> surprised if Chuck would do it differently. He now even uses this 
> concept for programming, it's called ColorForth ;-).

Agreed!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Elizabeth D Rather <erather@forth.com> wrote:
> Bernd Paysan wrote:
> > Jonah Thomas wrote:

> >> I did learn to deal with all of Word's quirks, or at least all the
> >> ones I ran into over the course of a few big documents. I still
> >> thought Word was definitely suboptimal. The guy on the internet was
> >> right too, if you're going to be a professional who uses Word then
> >> it's your responsibility to learn how to use it well.
> > 
> > Bad comparison.  If you want to professionally layout books with
> > 400+ pages, you don't learn Word, you learn LaTeX.  It's like when
> > you want to dig a tunnel through the alps, you don't go to the next
> > DIY store, and buy a rock drill for $50, known to work somehow for
> > the first 20cm.  You get the proper equipment.  Word is not the
> > proper equipment for 400+ pages books.  

Sure, but it was the tool that was used for that project. Many documents
that size were being done with Word in those days, and the guy on the
internet who told me I was incompetent because I had some difficulty
with it claimed that he regularly created 500+ page documents in Word
with no difficulty whatsoever.

> > It is the proper equipment for short notes.  That's why 
> > it's called "Word", not "Sentence" or "Page" or even "TeX"(t).  If 
> > somebody writing Word also looked at 4chan, you'd see a cat popping
> > up in the lower right corner telling you "I writed your a word, but
> > I ated it ;-)".
> 
> Well, the professionals I know (as well as myself, as regards the
> books I've written and edited) use FrameMaker or (more recently)
> InDesign. But I totally agree with your essential point, that Word is
> much better for smaller or more casual projects.
> 
> I'm not sure why Jonah had so much trouble, though.  I started using 
> Word with Version 1.0 (about 1984),  and got along with it well until
> we started working on larger projects, at which time we looked for
> (and found) alternatives.

That might be the difference. You learned to handle the quirks in the
early Word, and then you learned to deal with the additional quirks
added on in later versions of Word, and it was easy to deal with a
little bit at a time. I ran into the whole thing all at once, with
documents that apparently had multiple authors using multiple versions
of Word on multiple operating systems. 

People can get used to anything if it changes gradually enough. 

I was able to deal with Word, but it was a steep hard learning curve and
I see no reason to pretend that Word was better than mediocre for the
task -- except that it looks unprofessional to complain about such
things.

MarkWills wrote:

> > Maybe even very good C programmers should contemplate the fact
> > that they are not good C++ programmers instead of bashing the
> > C++ language itsself.

I think this may be directly analogous. The fact was that I was not a
very good Word user, and so I want to bash Word. If I had been
sufficiently expert at Word then I could have used Word for 500 page
documents easily and professionally with no difficulties. I would have
known the Word commands that always caused Word to crash and avoided
them. I would have known the Word commands that sometimes caused Word to
crash and used them whenever it was appropriate, avoiding the crashes.
On the other hand, looking back from a long time later, it seems absurd
to develop that expertise in Word when there were better systems
available even then.

I don't know to what extent C++ is a mediocre tool or how much it
deserves the level of expertise and artistry that unlocks its full
potential. To find out, I would need to learn C++ that well, and also
learn at least one of the alternatives that well, and then I could say
whether in my experience C++ was better than that alternative for my
problem domains. I suspect there are not very many people who have
developed that paired expertise, because it's likely to take years to
reach that level for one tool, and then the years you spend developing
equivalent expertise with a second tool -- to do the same things -- are
redundant. Easier to decide that the tool you already know very well is
the best.

And if you then find out about a language that easily does the things
which are hard with your preferred language, something that doesn't take
many years to get proficient in, it's only natural to call it a "toy
language" and ignore it.

Elizabeth D Rather wrote:
> Bernd Paysan wrote:
>> Elizabeth D Rather wrote:
>>> Well, the professionals I know (as well as myself, as regards the
>>> books I've written and edited) use FrameMaker or (more recently)
>>> InDesign. But I totally agree with your essential point, that Word is
>>> much better for smaller or more casual projects.
>>
>> The German TeX user community is particularly strong. I've used 
>> FrameMaker once, nearly 12 years ago, to edit a specification document 
>> with less than 100 pages, but a number of OLE components (mostly Visio 
>> drawings). It showed about the same symptoms as Word would: it 
>> regularly ate the document (or rather all OLE parts - the FrameMaker 
>> native parts survived all that).
> 
> I first met FrameMaker in the mid-90's.  I edited a couple of books with 
> it, as did our official document editor, Marlin Ouverson.  I don't 
> believe either of us ever suffered from an "eaten document".
> 
>> Generally, FrameMaker has a good reputation - either this is just by 
>> comparison to Word, or this is when not using OLE ;-). Later, I had to 
>> contribute parts to a larger document (test cases description), and 
>> ended up writing that part in LaTeX, because there I could generate a 
>> lot of the text automatically: Extract the test description from 
>> source, and extract more details from the test run itself. Converting 
>> simple LaTeX into FrameMaker is easy to do, as is the other way round. 
>> But the typesetting results of LaTeX are usually better. And a number 
>> of things are far from easy and obvious in FrameMaker: It took me 
>> quite some time to figure out how to create a proper table of content, 
>> because without I was lost in the document, and the original author 
>> didn't even have a clue how to do it (FrameMaker uses a "template" 
>> approach, and the TOC templates were empty in that document).
> 
> FrameMaker is a complex program.  It offers a lot of power, at a 
> considerable cost in complexity.  There's a learning curve, for sure. 
> But once you're reasonably well up that curve, a lot of things are 
> really easy: not only TOCs, but also indexes and other special features. 
>  The tables of words in the back of The Forth Programmer's Handbook, for 
> example, take about 10 mins. to generate.
> 
>> In this project, there was also the (for Germany) typical rivalry 
>> between the FrameMaker people (who used Windows and had their tool 
>> officially approved), and the LaTeX people (who used mostly Solaris, 
>> and used their tool, despite of not being officially approved, because 
>> FrameMaker wasn't up to the task, like e.g. for literate programming).
> 
> I have never used LaTeX.  I think it's used a lot more in Europe than 
> here.  I assume there's a learning curve with that, too.
> 
>> About text with tags: Apart from Word (which is really weird how it 
>> attributes text, and by doing it so weird, it is also very fragile), 
>> this is common practice, and was first proposed in 1967. I would be 
>> surprised if Chuck would do it differently. He now even uses this 
>> concept for programming, it's called ColorForth ;-).

My daughter did a considerable body of freelance commercial work with 
Framemaker (on a MAC) and had no problem learning on her own. LaTeX is a 
macro extenion of TeX and is widely used in scientific circles even in 
the US. It is the required format for submissions to professional 
mathematics journals.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Elizabeth D Rather wrote:
> I have never used LaTeX.  I think it's used a lot more in Europe than
> here.  I assume there's a learning curve with that, too.

Of course there is.  For a programmer, it's not that difficult, because it's 
a markup language plus a programming language (the programming language is 
used to define the styles), and a huge set of pre-defined styles that meet 
most of your needs (e.g. on www.ctan.org, often included in the TeX 
distribution).  For non-programmers, frontends like LyX exist, which are 
easy enough to use.

For a lot of tasks that frequently come up during programming, like 
combining documentation and source code, it's definitely the way to go.

It might have something to do with Europe, because the first thing the 
editor of the Forth200x effort did was to convert the Word document into 
LaTeX ;-).  But when we reprinted Thinking Forth, LaTeX was the tool of 
choice right from start, and this didn't start in Europe.  The main LaTeX 
expert came from Europe, though ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

According to Jerry Avins  <jya@ieee.org>:
> LaTeX is a macro extenion of TeX and is widely used in scientific
> circles even in the US. It is the required format for submissions to
> professional mathematics journals.

LaTeX is _the_ standard for scientific research in mathematics and
computer science (e.g. everything published by Springer-Verlag in the
collection "Lecture Notes in Computer Science" is done in LaTeX with the
dedicated llncs LaTeX style), and is widely used in physics. In other
areas, it is in competition with Word-derived formats; for medecine and
genetics, Word dominates. In my specific area (cryptography), article
submissions to the main conferences with proceedings are required to be
in LaTeX-with-llncs since about 2000; before that, use of LaTeX was only
encouraged, but submissions in other formats (including Word) could
theoretically be salvaged (but there was a very high correlation between
"using Word" and "low scientific value": it seems that in the late 90's,
people using Word to write scientific articles on cryptography were also
people not quite in touch with the field they were writing on).

What made TeX/LaTeX very popular with mathematicians is the ease of
typesetting complex mathematical formulas. In the late 80's and early
90's, all other tools for such jobs were nightmarish. I heard that very
recent versions of Word and PowerPoint got better in that area, but I
have not checked myself.

On Unix systems, before the advent of TeX, it was customary to use
Troff, which is good enough for professional publishing (Richard Stevens
wrote his books in Troff) but requires more discipline from the writer.


	--Thomas Pornin

On Sep 28, 10:58=A0am, Thomas Pornin <por...@bolet.org> wrote:

> What made TeX/LaTeX very popular with mathematicians is the ease of
> typesetting complex mathematical formulas. In the late 80's and early
> 90's, all other tools for such jobs were nightmarish. I heard that very
> recent versions of Word and PowerPoint got better in that area, but I
> have not checked myself.

Design Science created MathType for the Macintosh in the mid/late
80's.  MathType is a simple to use yet powerful GUI based equation
creator.  It appears that MS later bought or licensed the program from
DS.  Not sure of the differences between MathType and Tex/LaTeX.  I
agree that using Word and WordPerfect for math formulas at that time
was a nightmare.

--
Doug Hoffman
http://idisk.mac.com/hoffman101-Public/?view=3Dweb

On Sep 28, 3:55=A0am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Elizabeth D Rather wrote:
> > I have never used LaTeX. =A0I think it's used a lot more in Europe than
> > here. =A0I assume there's a learning curve with that, too.
>
> Of course there is. =A0For a programmer, it's not that difficult, because=
 it's
> a markup language plus a programming language (the programming language i=
s
> used to define the styles), and a huge set of pre-defined styles that mee=
t
> most of your needs (e.g. onwww.ctan.org, often included in the TeX
> distribution). =A0For non-programmers, frontends like LyX exist, which ar=
e
> easy enough to use.
>
> For a lot of tasks that frequently come up during programming, like
> combining documentation and source code, it's definitely the way to go.
>
> It might have something to do with Europe, because the first thing the
> editor of the Forth200x effort did was to convert the Word document into
> LaTeX ;-). =A0But when we reprinted Thinking Forth, LaTeX was the tool of
> choice right from start, and this didn't start in Europe. =A0The main LaT=
eX
> expert came from Europe, though ;-).
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://www.jwdt.co=
m/~paysan/

I made the switch to LaTeX too, when it came time to document what I
was doing at IntellaSys (http://code.google.com/p/vf-plugins/).  Being
able to intermix the documentation with the source code has become a
high priority for me and creating a programmable interface was
trivial.  I certainly don't know how to do everything in it, and
setting it up can be non-trivial (like most open source tools), but
then I never knew everything about Word or OpenOffice or WordPerfect
either.  It's just another tool that makes you more useful, and having
a text backup that works with normal SCM and comparison tools is very
nice.

DaR

Jerry Avins <jya@ieee.org> wrote:
> Marc Olschok wrote:
> > Jerry Avins <jya@ieee.org> wrote:
> >> [...] 
> >> Old Semitic languages were written right to left. The only reason I can 
> >> thing of for that is the moon's terminator advancing from right to left 
> >> in the Northern hemisphere, so it seemed like a "natural" direction. 
> >> Right-handed people smudge ink-based writing, so eventually the standard 
> >> direction became left to right.
> > 
> > Actually, right handed people tend to hold the hammer with the right hand
> > and the chisel with the left hand. This should give a more obvious reason
> > for the writing direction of old semitic languages.
> 
> Chiseling in stone was an infrequent way to write. Marking paper and 
> impressing clay were the norms.

O.k., let's lay down hammer annd chisel aside and turn from stone
to clay and other softer materials, where only a stylus is needed.

But even then I would assume that the natural movement, with stylus
in right hand, would be from right to left, or sometimes from top to bottom.
(I never used a stylus, I am extrapolating from doing lino-cutting as
a child).

-- 
Marc

No discussion of software quality would be complete without a mention
of the THERAC 25 case..

http://en.wikipedia.org/wiki/Therac-25


Mark

On Sep 29, 9:55=A0am, Mark <makol...@yahoo.com> wrote:
> No discussion of software quality would be complete without a mention
> of the THERAC 25 case..
>
> http://en.wikipedia.org/wiki/Therac-25

True.

I had a far less dramatic experience with a robotic XRAY scanner a
while back. It was a machine that is supposed to automatically rotate
around a persons head and take dental X-Rays's.

The technician put me in the chair, told me to "hold still", then went
out of the room to start it. The giant arm of the machine moved the
attached photographing module that began to encircle my face. The
module got closer and closer, until it finally was touching my jaw.
Then it pushed my face, right into the wall, and proceeded to crush my
skull against the wall.

I had to yell to the technician that "This is not how this thing is
supposed to work!" before she came running into the room to pull me
out.

The position of the chair and robot were fixed, so I figured it might
be a software issue. In retrospect, I should have been more worried
about X-Ray's than getting skull-crushed.

-Le Chaud Lapin-

On Tue, 29 Sep 2009 08:05:17 -0700, Le Chaud Lapin wrote:

> On Sep 29, 9:55 am, Mark <makol...@yahoo.com> wrote:
>> No discussion of software quality would be complete without a mention
>> of the THERAC 25 case..
>>
>> http://en.wikipedia.org/wiki/Therac-25
> 
> True.
> 
> I had a far less dramatic experience with a robotic XRAY scanner a while
> back. It was a machine that is supposed to automatically rotate around a
> persons head and take dental X-Rays's.
> 
> The technician put me in the chair, told me to "hold still", then went
> out of the room to start it. The giant arm of the machine moved the
> attached photographing module that began to encircle my face. The module
> got closer and closer, until it finally was touching my jaw. Then it
> pushed my face, right into the wall, and proceeded to crush my skull
> against the wall.
> 
> I had to yell to the technician that "This is not how this thing is
> supposed to work!" before she came running into the room to pull me out.
> 
> The position of the chair and robot were fixed, so I figured it might be
> a software issue. In retrospect, I should have been more worried about
> X-Ray's than getting skull-crushed.
> 
> -Le Chaud Lapin-

Your head's radius is larger than 6.5535 inches?  Or perhaps 131.070mm?

Interesting.  I went to a software quality talk that started out with a 
picture of a big saw in a sawmill, with the operator's position crushed 
by the very first log over 65.535" diameter that the software had ever 
seen (guess what the bug was!).

-- 
www.wescottdesign.com

Le Chaud Lapin wrote:


> The technician put me in the chair, told me to "hold still", then went
> out of the room to start it. The giant arm of the machine moved the
> attached photographing module that began to encircle my face. The
> module got closer and closer, until it finally was touching my jaw.
> Then it pushed my face, right into the wall, and proceeded to crush my
> skull against the wall.
> 
> I had to yell to the technician that "This is not how this thing is
> supposed to work!" before she came running into the room to pull me
> out.
> 
> The position of the chair and robot were fixed, so I figured it might
> be a software issue. In retrospect, I should have been more worried
> about X-Ray's than getting skull-crushed.

An engineer came to the patent office:
- I have invented a machine to do haircut.
- Will you please demonstrate it.
The engineer puts his head into the machine. The blades start flying 
around his head with the hissing speed, and in a few seconds the nice 
stylish haircut is done.
- Wow! How did you accomplish that? Everybody has a different shape of 
the head...
- That's only before the first haircut!




Once long ago I did a costly mistake in the software. There was a VHF 
paging repeater located on the top of a tower. It received the paging 
broadcast from the main station to memory and then retransmitted it 
further. Everything was OK before, however, at that particular location, 
once in a while the repeater turned the transmit "on" constantly for 
about an hour, jamming the whole big area. What a mess.

It appeared that the repeater received a very weak signal from 
somewhere, and after several stages of processing, it was decoded as a 
packet of the length = 0, which equals to 65536 in the 16 bit math...


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Tue, 29 Sep 2009 11:08:54 -0500, Vladimir Vassilevsky wrote:

> Le Chaud Lapin wrote:
> 
> 
>> The technician put me in the chair, told me to "hold still", then went
>> out of the room to start it. The giant arm of the machine moved the
>> attached photographing module that began to encircle my face. The
>> module got closer and closer, until it finally was touching my jaw.
>> Then it pushed my face, right into the wall, and proceeded to crush my
>> skull against the wall.
>> 
>> I had to yell to the technician that "This is not how this thing is
>> supposed to work!" before she came running into the room to pull me
>> out.
>> 
>> The position of the chair and robot were fixed, so I figured it might
>> be a software issue. In retrospect, I should have been more worried
>> about X-Ray's than getting skull-crushed.
> 
> An engineer came to the patent office: - I have invented a machine to do
> haircut. - Will you please demonstrate it.
> The engineer puts his head into the machine. The blades start flying
> around his head with the hissing speed, and in a few seconds the nice
> stylish haircut is done.
> - Wow! How did you accomplish that? Everybody has a different shape of
> the head...
> - That's only before the first haircut!
> 
> 
> 
> 
> Once long ago I did a costly mistake in the software. There was a VHF
> paging repeater located on the top of a tower. It received the paging
> broadcast from the main station to memory and then retransmitted it
> further. Everything was OK before, however, at that particular location,
> once in a while the repeater turned the transmit "on" constantly for
> about an hour, jamming the whole big area. What a mess.
> 
> It appeared that the repeater received a very weak signal from
> somewhere, and after several stages of processing, it was decoded as a
> packet of the length = 0, which equals to 65536 in the 16 bit math...

Oops.  That's why I like it when folks want to review my code, and/or 
test the snot out of it.

Not that such things don't still slip by once in a while, you just want 
to do all you can to minimize it.

-- 
www.wescottdesign.com

On Sep 29, 11:47=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 29 Sep 2009 11:08:54 -0500, Vladimir Vassilevsky wrote:
> > An engineer came to the patent office: - I have invented a machine to d=
o
> > haircut. - Will you please demonstrate it.
> > The engineer puts his head into the machine. The blades start flying
> > around his head with the hissing speed, and in a few seconds the nice
> > stylish haircut is done.
> > - Wow! How did you accomplish that? Everybody has a different shape of
> > the head...
> > - That's only before the first haircut!

Heh...good one.

> > Once long ago I did a costly mistake in the software. There was a VHF
> > paging repeater located on the top of a tower. It received the paging
> > broadcast from the main station to memory and then retransmitted it
> > further. Everything was OK before, however, at that particular location=
,
> > once in a while the repeater turned the transmit "on" constantly for
> > about an hour, jamming the whole big area. What a mess.
>
> > It appeared that the repeater received a very weak signal from
> > somewhere, and after several stages of processing, it was decoded as a
> > packet of the length =3D 0, which equals to 65536 in the 16 bit math...

There is also the case of using signed long int for inherently
unsigned quantities.

I once saw an old ad from a magazine in the early 1980's offering
software to help "break through the 2GB file size limit". The software
was an add-on to standard (Unisys?/DEC?/IBM?) software. The add-on
cost several thousand US dollars. It would allow file sizes up to 4GB
"without significant changes to existing software". Of course we all
know where the 2GB limit came from.

Apparently it is still with us:

http://tinyurl.com/yb2xsac

I never choose a type of signed integer for an inherently unsigned
quantity.

-Le Chaud Lapin-

On Tue, 29 Sep 2009 10:57:25 -0700, Le Chaud Lapin wrote:

> On Sep 29, 11:47 am, Tim Wescott <t...@seemywebsite.com> wrote:
>> On Tue, 29 Sep 2009 11:08:54 -0500, Vladimir Vassilevsky wrote:
>> > An engineer came to the patent office: - I have invented a machine to
>> > do haircut. - Will you please demonstrate it. The engineer puts his
>> > head into the machine. The blades start flying around his head with
>> > the hissing speed, and in a few seconds the nice stylish haircut is
>> > done.
>> > - Wow! How did you accomplish that? Everybody has a different shape
>> > of the head...
>> > - That's only before the first haircut!
> 
> Heh...good one.
> 
>> > Once long ago I did a costly mistake in the software. There was a VHF
>> > paging repeater located on the top of a tower. It received the paging
>> > broadcast from the main station to memory and then retransmitted it
>> > further. Everything was OK before, however, at that particular
>> > location, once in a while the repeater turned the transmit "on"
>> > constantly for about an hour, jamming the whole big area. What a
>> > mess.
>>
>> > It appeared that the repeater received a very weak signal from
>> > somewhere, and after several stages of processing, it was decoded as
>> > a packet of the length = 0, which equals to 65536 in the 16 bit
>> > math...
> 
> There is also the case of using signed long int for inherently unsigned
> quantities.
> 
> I once saw an old ad from a magazine in the early 1980's offering
> software to help "break through the 2GB file size limit". The software
> was an add-on to standard (Unisys?/DEC?/IBM?) software. The add-on cost
> several thousand US dollars. It would allow file sizes up to 4GB
> "without significant changes to existing software". Of course we all
> know where the 2GB limit came from.
> 
> Apparently it is still with us:
> 
> http://tinyurl.com/yb2xsac
> 
> I never choose a type of signed integer for an inherently unsigned
> quantity.
> 
> -Le Chaud Lapin-

OTOH, nothing says "out of range error" like a negative value for an 
inherently unsigned quantity.

-- 
www.wescottdesign.com

On Sep 29, 10:55=A0am, Mark <makol...@yahoo.com> wrote:
> No discussion of software quality would be complete without a mention
> of the THERAC 25 case..
>
> http://en.wikipedia.org/wiki/Therac-25
>

a.k.a. "Death by Shared Variable"

i alluded to that in a presentation i did last year at the AES.
http://www.aes.org/events/125/workshops/session.cfm?code=3DW5

for me, the issue i take with the link that Jerry presented is that
the performance metric of code needs to include reusability or
portability, unit testability, readability, and maintainability.  to
do that you need to put the code into containers.  sometimes you need
to move part of it from one container into another.  you need to think
about APIs.

some people just do not include those values in their performance
metric.  the only thing they worry about is "does it work?", "how fast
is it?", "how much memory resources are required?", "how user-friendly
is the user interface?"

> Peter asked Zawinski, =93Overengineering seems to be a pet peeve of
> yours.=94
>
> =93Yeah,=94 he says, =93At the end of the day, ship the fucking thing! It=
=92s
> great to rewrite your code and make it cleaner and by the third time
> it=92ll actually be pretty. But that=92s not the point=97you=92re not her=
e to
> write code; you=92re here to ship products.=94
>
> My hero.
>
> Zawinski didn=92t do many unit tests. They =93sound great in principle.
> Given a leisurely development pace, that=92s certainly the way to go. But
> when you=92re looking at, =91We=92ve got to go from zero to done in six
> weeks,=92..."

and there is the crux of the issue.  short-term vs. long-term
interests.  compare that to the Wall Street ethic of making a fast
buck.  how well were our interests served with that?

r b-j

Le Chaud Lapin <jaibuduvin@gmail.com> wrote:
(snip)
 
< There is also the case of using signed long int for inherently
< unsigned quantities.
 
< I once saw an old ad from a magazine in the early 1980's offering
< software to help "break through the 2GB file size limit". The software
< was an add-on to standard (Unisys?/DEC?/IBM?) software. The add-on
< cost several thousand US dollars. It would allow file sizes up to 4GB
< "without significant changes to existing software". Of course we all
< know where the 2GB limit came from.
(snip)
 
< I never choose a type of signed integer for an inherently unsigned
< quantity.

Many languages don't have an unsigned type.

For OS/360 (and still in current z/OS) the usual block size limit
is 32767.  S/360 has no unsigned halfword load instruction, so it
would take an extra instruction on each reference to blocksize to
mask out the extra bits.  For machines with memory sizes in the
64K range, every byte was precious.  Disk drives couldn't write
blocks that big, and 32767 was plenty big enough for tape.

Interesting question, though, why unix didn't go to unsigned
for fseek() from the beginning.  

-- glen

On Tue, 29 Sep 2009 07:55:36 -0700 (PDT), Mark <makolber@yahoo.com>
wrote:

>No discussion of software quality would be complete without a mention
>of the THERAC 25 case..
>
>http://en.wikipedia.org/wiki/Therac-25

   There are many more examples of such things in the Risks archive
(Usenet readers will know this as comp.risks), some with frighteningly
more familiar names such as Airbus:

http://catless.ncl.ac.uk/Risks

   You can search Therac on that site and get lots of info where it
was discussed.

   I used to read it regularly a while back, but I started having
nightmares about technical problems, so I quit and only go back to it
when rememded by threads like this or technical problems in the news
(which is still much too often).

>
>
>Mark

On Sep 29, 2:09=A0pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> and there is the crux of the issue. =A0short-term vs. long-term
> interests. =A0compare that to the Wall Street ethic of making a fast
> buck. =A0how well were our interests served with that?

It should be noted that some engineers will create poorly-engineered
systems no matter how much time they are given.

If you say, "Hey...slow down...you have 6 months to get this
right...you need to THINK first, then DO", they will not slow down,
because pressure of schedule is not what drives them, but a
predisposition toward haste and sloppiness, because it is the mode in
which they are most comfortable.

Reminding these engineers that they have "6 months to get it right"
might only make them more anxious, not less, because it would draw too
much attention toward the "getting it right" metric. They would rather
be judged by something else.

-Le Chaud Lapin-

On Sep 29, 2:14=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> < I never choose a type of signed integer for an inherently unsigned
> < quantity.
>
> Many languages don't have an unsigned type.
>
> For OS/360 (and still in current z/OS) the usual block size limit
> is 32767. =A0S/360 has no unsigned halfword load instruction, so it
> would take an extra instruction on each reference to blocksize to
> mask out the extra bits. =A0For machines with memory sizes in the
> 64K range, every byte was precious. =A0Disk drives couldn't write
> blocks that big, and 32767 was plenty big enough for tape.
>
> Interesting question, though, why unix didn't go to unsigned
> for fseek() from the beginning. =A0

Microsoft followed suit with SetFilePointer():

http://msdn.microsoft.com/en-us/library/aa365541(VS.85).aspx

The specification is atrocious and reeks of an engineer who was
hellbent on keep with his "overloading return value generally works"
philosophy.

-Le Chaud Lapin-

On Sep 29, 1:07=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 29 Sep 2009 10:57:25 -0700, Le Chaud Lapin wrote:
> > I never choose a type of signed integer for an inherently unsigned
> > quantity.
>
> OTOH, nothing says "out of range error" like a negative value for an
> inherently unsigned quantity.

This is the prime rationale for always using signed int instead of
unsigned int. There is a problem with this argument, which,
unfortunately, is not acceptable to the signed people:

"We unsigned people never experience this problem."

There are essentially to modes of programming/being/thinking on this:

Philosophy 1. Quantities in my world are signed by default.
Philosophy 2. Quantities in my world are unsigned by default.

From the very early days of C, Denis Ritchie included, most
programmers have been using Philosophy #1. A small percentaage, much
less than 10% in the early days, but now increasing, stopped following
Philosophy #1 and switched to Philosopy #2.

The signed people claimed that the unsigned people switched to gain
the extra bit in the word. This is only partially true. A more
fundamentaly reason, which, ironically, cannot be fully appreciated
until after the switch has been made wholesale and experienced for a
number of months (years?), is that there is a surprising amount of
mental relief that comes with Philosophy #2.

The signed people claim that this mental relief claimed by the
unsigned people does not exist, even though we keep telling them that
it does.

Furthermore, the so-called relief cannot be experienced unless the
switch is made wholesale, as mentioned, which is what the unsigned
people have done, and which the signed people will not do, so they
remained locked in a Catch-22: They will not switch until they see the
benefit. But they will not see the benefit until they switch. So they
do something that affirms there suspicion that the mental relief does
not exist:

They try Philosophy #2, but only in incremental fashion.

Increnmental is a matter of necessity, since they are not going to
change, say, 50,000 lines of code just to check and argument, and
behold: they experience a signed/unsigned impedance mismatch that
bites them hard, just as they suspected!!! They are even more
convinced that that said mental relief does not exist.

I started in C with signed 20 years ago, and switched to unsigned
after about 7 months, and have been using it since. I did it because I
believed there was greater conceptual parity in using unsigned for
inherently unsigned quantities. As it would happen, the vast majority
of discrete quantities in generalized programming,  are unsigned, so
signed is actually the specical case. The language, however, (and
rightfully IMO), makes default constant integer signed.

In any case, this is a small example of deliberately designing a
system so that awkward problems cannot possibly manifest, but not
experiencing the benefit, until the new mode is embraced fully:

Engineer 1: "(laughing) He claims that his engine will never leak
oil..."
Engineer 2: "Who?"
Engineer 1: "Engineer 3..he says he doesn't worry about it..."
Engineer 2: "What an ass...always some new guy who thinks he knows
something that we dont.."
Engineer 2: "Let's set him straight..."
Engineer 2: "Hey, ehh Engineer 3...Engineer 1 tells me that u have a
new design that won't leak..."
Engineer 2: "I'd like to see how you accomplished that..."
Engineer 3: "Well, I am using these new seals I made..."
Engineer 1: "What an idiot...Don't you know that those types of seals
are incompatible with oil..?"
Engineer 3: "I never said that I was using oil."

-Le Chaud Lapin-

Le Chaud Lapin wrote:

> I started in C with signed 20 years ago, and switched to unsigned
> after about 7 months, and have been using it since.

There are architectures, like ADSP-21xx, for example, which have the 
native arithmetic implicitly signed. That affects rounding, saturation, 
how the flags are set,  and how the multiprecision math is working.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 29 Sep, 23:53, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 29, 2:14=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> > < I never choose a type of signed integer for an inherently unsigned
> > < quantity.
>
> > Many languages don't have an unsigned type.
>
> > For OS/360 (and still in current z/OS) the usual block size limit
> > is 32767. =A0S/360 has no unsigned halfword load instruction, so it
> > would take an extra instruction on each reference to blocksize to
> > mask out the extra bits. =A0For machines with memory sizes in the
> > 64K range, every byte was precious. =A0Disk drives couldn't write
> > blocks that big, and 32767 was plenty big enough for tape.
>
> > Interesting question, though, why unix didn't go to unsigned
> > for fseek() from the beginning. =A0
>
> Microsoft followed suit with SetFilePointer():
>
> http://msdn.microsoft.com/en-us/library/aa365541(VS.85).aspx
>
> The specification is atrocious and reeks of an engineer who was
> hellbent on keep with his "overloading return value generally works"
> philosophy.

Haven't seen that one before, but the first impression is
that it's MS-DOS all over again: It's very similar to the
way they used two 16-bit registers to address 1 MByte of RAM
through a set of 64k pages. Is it the same guy who has written
both specs?

20 years ago, my impression was that at least 90% of the
work involved in PC programming was about beating the 64 k
page size and 1 M address space of the PC architecture of
the time.

Rune

>Le Chaud Lapin <jaibuduvin@gmail.com> wrote:
>(snip)
> 
>< There is also the case of using signed long int for inherently
>< unsigned quantities.
> 
>< I once saw an old ad from a magazine in the early 1980's offering
>< software to help "break through the 2GB file size limit". The software
>< was an add-on to standard (Unisys?/DEC?/IBM?) software. The add-on
>< cost several thousand US dollars. It would allow file sizes up to 4GB
>< "without significant changes to existing software". Of course we all
>< know where the 2GB limit came from.
>(snip)
> 
>< I never choose a type of signed integer for an inherently unsigned
>< quantity.
>
>Many languages don't have an unsigned type.
>
>For OS/360 (and still in current z/OS) the usual block size limit
>is 32767.  S/360 has no unsigned halfword load instruction, so it
>would take an extra instruction on each reference to blocksize to
>mask out the extra bits.  For machines with memory sizes in the
>64K range, every byte was precious.  Disk drives couldn't write
>blocks that big, and 32767 was plenty big enough for tape.
>
>Interesting question, though, why unix didn't go to unsigned
>for fseek() from the beginning.  

In most parts of the original C library they reserved negative numbers for
some kind of error status. In several places this has proved a rather short
term decision. This, today we have size_t in the C standard, which is
unsigned. In unistd.h we have ssize_t, which is signed.

Steve

On Sep 29, 6:12=A0pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 29 Sep, 23:53, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> >http://msdn.microsoft.com/en-us/library/aa365541(VS.85).aspx
>
> > The specification is atrocious and reeks of an engineer who was
> > hellbent on keep with his "overloading return value generally works"
> > philosophy.
>
> Haven't seen that one before, but the first impression is
> that it's MS-DOS all over again: It's very similar to the
> way they used two 16-bit registers to address 1 MByte of RAM
> through a set of 64k pages. Is it the same guy who has written
> both specs?

Well, in defense of the segmentation model on the Intel 8086, the norm
was 16 bits for CPU's, but 1MB memory was reachable economically, so
there was a compromise to get 20 bits of addressability from a 16-bit
CPU while everyone else was still doing 64K addressability. The result
was a Bill-Gates-I-Cannot-Imagine-Anyone-Ever-Wanting-More-Than-640K
block of RAM, plus generous space for memory-mapped I/O.

> 20 years ago, my impression was that at least 90% of the
> work involved in PC programming was about beating the 64 k
> page size and 1 M address space of the PC architecture of
> the time.

Yes, I remember those days. Phar Lap was a big player:

http://en.wikipedia.org/wiki/Phar_Lap_(company)

Byte Magazine provided an invaluable technical foundation for young
people just getting into PC's.

-Le Chaud Lapin-

Vladimir Vassilevsky <nospam@nowhere.com> wrote:
 
> There are architectures, like ADSP-21xx, for example, which have the 
> native arithmetic implicitly signed. That affects rounding, saturation, 
> how the flags are set,  and how the multiprecision math is working.

S/360 and S/370 have support for unsigned (logical in IBM terms)
add and subtract, but not multiply and divide.  There is a paper
written in the early S/360 days on how to do unsigned divide.

I believe it hasn't been so unusual until recently to support
unsigned add/subtract but not multiply/divide.

Even though Fortran only has signed integers, early Fortran
through the Fortran 66 standard only allowed positive values
(as in greater than zero) for the DO loop start, end, and increment
values.  That may also have some history in IBM hardware.

-- glen

Rune Allnor <allnor@tele.ntnu.no> wrote:
(snip)
 
> Haven't seen that one before, but the first impression is
> that it's MS-DOS all over again: It's very similar to the
> way they used two 16-bit registers to address 1 MByte of RAM
> through a set of 64k pages. Is it the same guy who has written
> both specs?

Well, the 8086 is really just an improved 8080.  They had
a very small number of transistors available to implement it.
 
> 20 years ago, my impression was that at least 90% of the
> work involved in PC programming was about beating the 64 k
> page size and 1 M address space of the PC architecture of
> the time.

I never had so much problem with it, even for large programs.
In C, with arrays of pointers to arrays, I could do very large
calculations (in OS/2 1.0 through 1.2) with the limit of 64K
per column.  Also, by allocating my own segment selectors I got
hardware bounds check without extra software checking.

If intel did things right, we could have lasted somewhat longer
without going to 64 bit addressing using large model 32 bit code
(16 bit selector, 32 bit offset).  

-- glen

>On Sep 29, 6:12=A0pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>> On 29 Sep, 23:53, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>> >http://msdn.microsoft.com/en-us/library/aa365541(VS.85).aspx
>>
>> > The specification is atrocious and reeks of an engineer who was
>> > hellbent on keep with his "overloading return value generally works"
>> > philosophy.
>>
>> Haven't seen that one before, but the first impression is
>> that it's MS-DOS all over again: It's very similar to the
>> way they used two 16-bit registers to address 1 MByte of RAM
>> through a set of 64k pages. Is it the same guy who has written
>> both specs?
>
>Well, in defense of the segmentation model on the Intel 8086, the norm
>was 16 bits for CPU's, but 1MB memory was reachable economically, so
>there was a compromise to get 20 bits of addressability from a 16-bit
>CPU while everyone else was still doing 64K addressability. The result
>was a Bill-Gates-I-Cannot-Imagine-Anyone-Ever-Wanting-More-Than-640K
>block of RAM, 

Which is different, though.  Each memory address (well, most of it, except
for stuff near the beginning and end, along with the confusion of whether
you actually had 1MB + 64KB or not) could be accessed in multiple ways. 
The API cited above, however, specifies a straightforward composition of 2
32-bit values to obtain a 64-bit value.  And technically real mode is still
used, but only briefly when you're booting.


> plus generous space for memory-mapped I/O.

The UMBs (space above 640K, but below 1MB) were also used for expanded
memory (EMS), which was one of a couple ways of breaking that 1MB barrier.

On 30 Sep, 03:55, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote:
>
> (snip)
>
> > Haven't seen that one before, but the first impression is
> > that it's MS-DOS all over again: It's very similar to the
> > way they used two 16-bit registers to address 1 MByte of RAM
> > through a set of 64k pages. Is it the same guy who has written
> > both specs?
>
> Well, the 8086 is really just an improved 8080. =A0They had
> a very small number of transistors available to implement it.

I know. And we have been dealing with the repercussions of
some rather poor strategic technology choises, ever since.

> > 20 years ago, my impression was that at least 90% of the
> > work involved in PC programming was about beating the 64 k
> > page size and 1 M address space of the PC architecture of
> > the time.
>
> I never had so much problem with it, even for large programs.
> In C, with arrays of pointers to arrays, I could do very large
> calculations (in OS/2 1.0 through 1.2) with the limit of 64K
> per column. =A0Also, by allocating my own segment selectors I got
> hardware bounds check without extra software checking.

But you had to do all of that yourself. It's the same kind
of revelation people lek me, who used to fiddle with all the
memory details in C, gets when one discovers C++ and the STL:
All of a sudden all the drudgery has been taken care of and
you can focus on the task.

> If intel did things right, we could have lasted somewhat longer
> without going to 64 bit addressing using large model 32 bit code
> (16 bit selector, 32 bit offset). =A0

I remember what a relief it was when I first got my hands
on a UNIX terminal: At last I could focus on the problem
at hand, instad of fighting all kinds of arbitrary limits.
On the PC I had to fight the OS to get the resources I knew
wer available. Under UNIX is twas the OS' task to get me what
I asked for, and to set up disk swap space if there wasn't
enough RAM was available.

Rune

On Sep 29, 10:05=A0pm, "Michael Plante" <michael.pla...@gmail.com>
wrote:
> >On Sep 29, 6:12=3DA0pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> >> On 29 Sep, 23:53, Le Chaud Lapin <jaibudu...@gmail.com> wrote:

> >> >http://msdn.microsoft.com/en-us/library/aa365541(VS.85).aspx

> Which is different, though. =A0Each memory address (well, most of it, exc=
ept
> for stuff near the beginning and end, along with the confusion of whether
> you actually had 1MB + 64KB or not) could be accessed in multiple ways.
> The API cited above, however, specifies a straightforward composition of =
2
> 32-bit values to obtain a 64-bit value. =A0And technically real mode is s=
till
> used, but only briefly when you're booting.

"straightfoward?"  Thanks for the morning laugh. :)

Do I know how to make it do what I want, yes, but being able to get it
to do what you want and being straightforward are two different
things.

-Le Chaud Lapin-

Rune Allnor <allnor@tele.ntnu.no> wrote:
< On 30 Sep, 03:55, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
<> Rune Allnor <all...@tele.ntnu.no> wrote:
(snip)
 
<> > 20 years ago, my impression was that at least 90% of the
<> > work involved in PC programming was about beating the 64 k
<> > page size and 1 M address space of the PC architecture of
<> > the time.

<> I never had so much problem with it, even for large programs.
<> In C, with arrays of pointers to arrays, I could do very large
<> calculations (in OS/2 1.0 through 1.2) with the limit of 64K
<> per column. ?Also, by allocating my own segment selectors I got
<> hardware bounds check without extra software checking.
 
< But you had to do all of that yourself. It's the same kind
< of revelation people lek me, who used to fiddle with all the
< memory details in C, gets when one discovers C++ and the STL:
< All of a sudden all the drudgery has been taken care of and
< you can focus on the task.

Well, only to get the hardware bounds checking.  Using arrays
of pointers to arrays is standard C for dynamically sized 2D
arrays.  (and causes lots of problems in mixed languaged 
environments.)  64K allows for 8192 double variables, so
as a square matrix that would be a half gigabyte.
I only had 7MB on my OS/2 1.0 machine, at the time most people
were running DOS in 640K.  (Early 1990.)  
 
<> If intel did things right, we could have lasted somewhat longer
<> without going to 64 bit addressing using large model 32 bit code
<> (16 bit selector, 32 bit offset). ?
 
< I remember what a relief it was when I first got my hands
< on a UNIX terminal: At last I could focus on the problem
< at hand, instad of fighting all kinds of arbitrary limits.
< On the PC I had to fight the OS to get the resources I knew
< wer available. Under UNIX is twas the OS' task to get me what
< I asked for, and to set up disk swap space if there wasn't
< enough RAM was available.

I didn't have half a gigabyte of swap space in 1990 either.

-- glen

On 30 Sep, 18:37, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote:
>
> < On 30 Sep, 03:55, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> <> Rune Allnor <all...@tele.ntnu.no> wrote:
> (snip)
>
> <> > 20 years ago, my impression was that at least 90% of the
> <> > work involved in PC programming was about beating the 64 k
> <> > page size and 1 M address space of the PC architecture of
> <> > the time.
>
> <> I never had so much problem with it, even for large programs.
> <> In C, with arrays of pointers to arrays, I could do very large
> <> calculations (in OS/2 1.0 through 1.2) with the limit of 64K
> <> per column. ?Also, by allocating my own segment selectors I got
> <> hardware bounds check without extra software checking.
>
> < But you had to do all of that yourself. It's the same kind
> < of revelation people lek me, who used to fiddle with all the
> < memory details in C, gets when one discovers C++ and the STL:
> < All of a sudden all the drudgery has been taken care of and
> < you can focus on the task.
>
> Well, only to get the hardware bounds checking. =A0Using arrays
> of pointers to arrays is standard C for dynamically sized 2D
> arrays. =A0(and causes lots of problems in mixed languaged
> environments.) =A064K allows for 8192 double variables, so
> as a square matrix that would be a half gigabyte.
> I only had 7MB on my OS/2 1.0 machine, at the time most people
> were running DOS in 640K. =A0(Early 1990.) =A0

I was concerely PO'ed when I bought a PC in 1990 with a
whopping 2 MByte RAM, but with no way to actually access
that extra MByte.

> <> If intel did things right, we could have lasted somewhat longer
> <> without going to 64 bit addressing using large model 32 bit code
> <> (16 bit selector, 32 bit offset). ?
>
> < I remember what a relief it was when I first got my hands
> < on a UNIX terminal: At last I could focus on the problem
> < at hand, instad of fighting all kinds of arbitrary limits.
> < On the PC I had to fight the OS to get the resources I knew
> < wer available. Under UNIX is twas the OS' task to get me what
> < I asked for, and to set up disk swap space if there wasn't
> < enough RAM was available.
>
> I didn't have half a gigabyte of swap space in 1990 either.

No, but with UNIX, that was all you needed to watch out for:
Not to ask for more memory (RAM + swap space) than was actually
available.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote:
 
> I was concerely PO'ed when I bought a PC in 1990 with a
> whopping 2 MByte RAM, but with no way to actually access
> that extra MByte.

That is what OS/2 was for.  
 
(I wrote)
>> I didn't have half a gigabyte of swap space in 1990 either.
 
> No, but with UNIX, that was all you needed to watch out for:
> Not to ask for more memory (RAM + swap space) than was actually
> available.

The problems I was doing at the time were successive relaxation
algorithms which make many passes through a large matrix.  
If the whole matrix doesn't fit in RAM then it goes to the
swap file for each pass.  (Assuming a least recently used page
access algorithm.)  Well, it was segments for OS/2 1.x on the 80286.
It did work, though.  

I believe I was running OS/2 1.2 on a 486 for some time before
2.0 came out with 32 bit segments.  

-- glen

Rune Allnor wrote:


> I was concerely PO'ed when I bought a PC in 1990 with a
> whopping 2 MByte RAM, but with no way to actually access
> that extra MByte.

The simple way to utilize upper memory on x286 was using it as a ram 
disk. For x386, you could extend the segment limits and address the 
upper memory as flat chunk using 32 bit registers. Yes, this works in 
the real mode. Then Watcom C++ with dos4gw came in, and there was no 
problem since.

VLV

On Sep 30, 12:25=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Rune Allnor wrote:
> > I was concerely PO'ed when I bought a PC in 1990 with a
> > whopping 2 MByte RAM, but with no way to actually access
> > that extra MByte.
>
> The simple way to utilize upper memory on x286 was using it as a ram
> disk. For x386, you could extend the segment limits and address the
> upper memory as flat chunk using 32 bit registers. Yes, this works in
> the real mode. Then Watcom C++ with dos4gw came in, and there was no
> problem since.

I remember using RAM disks for C programs. I would put my entire build
tree in RAM and compile with Quick C. Extremely fast. Then when I was
satisfied with the code, I would copy it to a real hard disk.

In fairness to Intel, they did their part long before Microsoft caught
up:

The x386 was a 32-bit CPU with full-blown demand paging, translation-
lookaside-buffers, etc. The segmentation model was, in fact,
significant overkill. As is the case when Ring-1 and Ring-2, which are
typically skipped, leaving only Ring-0 and Ring-3 for kernel/user-
mode, respectively; the segmentation model, the one with selectors, is
not actually used. The memory model that uses both selectors from CS,
DS, ES, SS, FS, GS, as well as the paging (CR3/PDBT) would be
unnecesary and extremely complex. Intel's CPU manuals specifically
discourage OS writers from getting carried away over all these memory
features simply because they are avaialble. They recommend skipping CS/
DS/ES/SS/GS/FS-based segments, or rather, making the range of
addressable space using them the full 4GB limit, effectively disabling
their segmentation feature.

This is what Windows does. They ignore Ring-1/Ring-2, keep Ring-0,
Ring-3, widen all segments to 4GB, effectively "disabling" segments
[It is actually not possible to disable segmentation], and using the
remaing registers as would be expected in demand paging system.

What's remarkable is that an OS writer had all this information as
early as 1982, but Windows was still talking about "16-bit" in 1990,
and beyond. In retrospect, if someone had simply written a small
(embedded?) OS that ignored NEAR/FAR pointers and presumed the flat-32
bit model from the beginning, there might have been a market for it.
Sigh.

-Le Chaud Lapin-

Le Chaud Lapin wrote:


> The x386 was a 32-bit CPU with full-blown demand paging, translation-
> lookaside-buffers, etc. The segmentation model was, in fact,
> significant overkill.

If properly used, the segmentation would fix once forever the typical 
problems with the pointers out of range, buffer and stack overruns and 
data executed as code. Moreover, swapping and VM could be done at the 
segment level rather then at the page level. That was the concept for 
x286, however it didn't fly. Part of the reason was the associated 
overhead, the other part was the complexity. Somebody had to develop OS 
and compiler for that, but it didn't happen.


> As is the case when Ring-1 and Ring-2, which are
> typically skipped, leaving only Ring-0 and Ring-3 for kernel/user-
> mode, respectively; the segmentation model, the one with selectors, is
> not actually used. The memory model that uses both selectors from CS,
> DS, ES, SS, FS, GS, as well as the paging (CR3/PDBT) would be
> unnecesary and extremely complex. Intel's CPU manuals specifically
> discourage OS writers from getting carried away over all these memory
> features simply because they are avaialble. They recommend skipping CS/
> DS/ES/SS/GS/FS-based segments, or rather, making the range of
> addressable space using them the full 4GB limit, effectively disabling
> their segmentation feature.
> 
> This is what Windows does.

This is what Linux and other solid kernel OSes do, as well.

> What's remarkable is that an OS writer had all this information as
> early as 1982, but Windows was still talking about "16-bit" in 1990,
> and beyond.

The OS and application development is much slower then the development 
of the hardware. They also have to worry about the compatibility.

  In retrospect, if someone had simply written a small
> (embedded?) OS that ignored NEAR/FAR pointers and presumed the flat-32
> bit model from the beginning, there might have been a market for it.

I doubt it.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>The x386 was a 32-bit CPU with full-blown demand paging, translation-
>lookaside-buffers, etc. The segmentation model was, in fact,
>significant overkill. As is the case when Ring-1 and Ring-2, which are
>typically skipped

Yes, though in defense of MS, this was primarily because older NT versions
supported non-x86 processors.  Who knows what they might have come up with
if the other vendors had also gone for "overkill"...


>, leaving only Ring-0 and Ring-3 for kernel/user-
>mode, respectively; the segmentation model, the one with selectors, is
>not actually used. The memory model that uses both selectors from CS,
>DS, ES, SS, FS, GS, as well as the paging (CR3/PDBT) would be
>unnecesary and extremely complex. Intel's CPU manuals specifically
>discourage OS writers from getting carried away over all these memory
>features simply because they are avaialble. They recommend skipping CS/
>DS/ES/SS/GS/FS-based segments, or rather, making the range of
>addressable space using them the full 4GB limit, effectively disabling
>their segmentation feature.
>
>This is what Windows does. They ignore Ring-1/Ring-2, keep Ring-0,
>Ring-3, widen all segments to 4GB, effectively "disabling" segments
>[It is actually not possible to disable segmentation], and using the
>remaing registers as would be expected in demand paging system.

I'm not entirely sure this is true.  See:

http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

If you look at a listing, you will frequently see the fs: segment prefix,
even in user-mode code, particularly when you're using structured exception
handling.  Now I can't say for certain that this isn't accessible without
the segment prefix, but they're always there when I look.  Note that fs
does not point to the bottom of the virtual address space, since that area
is reserved for catching pointer mistakes, so I would have to infer the fs
selector is set up differently than cs,ds,ss.

On Sep 30, 7:18=A0pm, "Michael Plante" <michael.pla...@gmail.com> wrote:
> >This is what Windows does. They ignore Ring-1/Ring-2, keep Ring-0,
> >Ring-3, widen all segments to 4GB, effectively "disabling" segments
> >[It is actually not possible to disable segmentation], and using the
> >remaing registers as would be expected in demand paging system.
>
> I'm not entirely sure this is true. =A0See:
>
> http://en.wikipedia.org/wiki/Win32_Thread_Information_Block
>
> If you look at a listing, you will frequently see the fs: segment prefix,
> even in user-mode code, particularly when you're using structured excepti=
on
> handling. =A0Now I can't say for certain that this isn't accessible witho=
ut
> the segment prefix, but they're always there when I look. =A0Note that fs
> does not point to the bottom of the virtual address space, since that are=
a
> is reserved for catching pointer mistakes, so I would have to infer the f=
s
> selector is set up differently than cs,ds,ss.

Yes, CS, ES, DS, SS, FS, GS are all used. One of them, I forget which
one, is used to keep track of thread-local storage, where a global C
variable can be declared "thread-local", and each thread will have its
own copy of the pseudo-global variable.

But Microsoft uses them in "wimpy" mode, as Vladimir points out. Intel
engineered in the iAPX family the possibility of trapping out-of-range
memory acess at resolution of 1-byte. If the limit fields for segment
registers were used, this would be possible. But Microsoft, per
Intel's not-so-subtle hinting, decided not to use it, so the limits of
each register are all maxed-out at 4GB.

If the out-of-range feature is desired under Windows, it is achieved
using page guards.

-Le Chaud Lapin-

On Sep 29, 5:46=A0pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Sep 29, 2:09=A0pm, robert bristow-johnson <r...@audioimagination.com>
> wrote:
>
> > and there is the crux of the issue. =A0short-term vs. long-term
> > interests. =A0compare that to the Wall Street ethic of making a fast
> > buck. =A0how well were our interests served with that?
>
> It should be noted that some engineers will create poorly-engineered
> systems no matter how much time they are given.

and it's these guys who are promoted to management.  i could give you
specific examples, but they're too current and i don't (yet) want to
name names.  (we don't know who is reading this.)

> If you say, "Hey...slow down...you have 6 months to get this
> right...you need to THINK first, then DO", they will not slow down,
> because pressure of schedule is not what drives them, but a
> predisposition toward haste and sloppiness, because it is the mode in
> which they are most comfortable.
>
> Reminding these engineers that they have "6 months to get it right"
> might only make them more anxious, not less, because it would draw too
> much attention toward the "getting it right" metric. They would rather
> be judged by something else.
>

well, it doesn't change the fact that behavior that is rewarded
becomes more prevalent and behavior that is not rewarded becomes less
prevalent.

wise management would have enough technical chops to be able to know
what is clean, reusable, and maintainable code, and when engineers
don't do it (for whatever reason), tell them that it's a condition of
employment.  wise management would do that for the future of the
project.  by overlooking sloppiness because of schedule, they are
doing harm to the project's future.  that's why sloppy code is less
valuable than clear code, even if the functionality seems to be the
same.

r b-j

On 2 Okt, 07:14, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Sep 29, 5:46=A0pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:

> > It should be noted that some engineers will create poorly-engineered
> > systems no matter how much time they are given.
>
> and it's these guys who are promoted to management.
....
> wise management would have enough technical chops to be able to know ...

But as the circle of evil perpetuates, present managers
tend to promote and reward employees that do things the
same way the present managers used to do, when they were
mere tech-staff employees.

Rune

Rune Allnor wrote:
> On 2 Okt, 07:14, robert bristow-johnson <r...@audioimagination.com>
> wrote:
> 
>>On Sep 29, 5:46 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> 
> 
>>>It should be noted that some engineers will create poorly-engineered
>>>systems no matter how much time they are given.
>>
>>and it's these guys who are promoted to management.
> 
>>wise management would have enough technical chops to be able to know ...
> 
> But as the circle of evil perpetuates, present managers
> tend to promote and reward employees that do things the
> same way the present managers used to do, when they were
> mere tech-staff employees.

Those who blame managers and don't like how the things are done, are 
free to go and start companies of their own. It is very enlightening 
experience. You will see the things in the entirely different perspective.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 2 Okt, 16:02, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Rune Allnor wrote:
> > On 2 Okt, 07:14, robert bristow-johnson <r...@audioimagination.com>
> > wrote:
>
> >>On Sep 29, 5:46 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
> >>>It should be noted that some engineers will create poorly-engineered
> >>>systems no matter how much time they are given.
>
> >>and it's these guys who are promoted to management.
>
> >>wise management would have enough technical chops to be able to know ...
>
> > But as the circle of evil perpetuates, present managers
> > tend to promote and reward employees that do things the
> > same way the present managers used to do, when they were
> > mere tech-staff employees.
>
> Those who blame managers and don't like how the things are done, are
> free to go and start companies of their own. It is very enlightening
> experience. You will see the things in the entirely different perspective.

I am sure such a change of perspective would be enlightening,
but I don't see why it would change any opinions about promoting
the members of staff who have the least chance to perform well in
higher positions?

Rune

Rune Allnor wrote:

> On 2 Okt, 16:02, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> 
>>Rune Allnor wrote:
>>
>>>On 2 Okt, 07:14, robert bristow-johnson <r...@audioimagination.com>
>>>wrote:
>>
>>>>On Sep 29, 5:46 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>>
>>>>>It should be noted that some engineers will create poorly-engineered
>>>>>systems no matter how much time they are given.
>>
>>>>and it's these guys who are promoted to management.
>>
>>>>wise management would have enough technical chops to be able to know ...
>>
>>>But as the circle of evil perpetuates, present managers
>>>tend to promote and reward employees that do things the
>>>same way the present managers used to do, when they were
>>>mere tech-staff employees.
>>
>>Those who blame managers and don't like how the things are done, are
>>free to go and start companies of their own. It is very enlightening
>>experience. You will see the things in the entirely different perspective.
> 
> 
> I am sure such a change of perspective would be enlightening,
> but I don't see why it would change any opinions about promoting
> the members of staff who have the least chance to perform well in
> higher positions?

There could be many different reasons for promotion ranging from 
avoiding clashes between employees to satisfying your personal 
preferences. Those things are no more and no less important then the 
performance of the candidate.

VLV

On 2 Okt, 17:24, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Rune Allnor wrote:
> > On 2 Okt, 16:02, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> >>Rune Allnor wrote:
>
> >>>On 2 Okt, 07:14, robert bristow-johnson <r...@audioimagination.com>
> >>>wrote:
>
> >>>>On Sep 29, 5:46 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
> >>>>>It should be noted that some engineers will create poorly-engineered
> >>>>>systems no matter how much time they are given.
>
> >>>>and it's these guys who are promoted to management.
>
> >>>>wise management would have enough technical chops to be able to know ...
>
> >>>But as the circle of evil perpetuates, present managers
> >>>tend to promote and reward employees that do things the
> >>>same way the present managers used to do, when they were
> >>>mere tech-staff employees.
>
> >>Those who blame managers and don't like how the things are done, are
> >>free to go and start companies of their own. It is very enlightening
> >>experience. You will see the things in the entirely different perspective.
>
> > I am sure such a change of perspective would be enlightening,
> > but I don't see why it would change any opinions about promoting
> > the members of staff who have the least chance to perform well in
> > higher positions?
>
> There could be many different reasons for promotion ranging from
> avoiding clashes between employees to satisfying your personal
> preferences. Those things are no more and no less important then the
> performance of the candidate.

I have to disagree. If the skills and competence of the
candidate are ruled out of the decision, you end up with
the worst choises of people in the positions with the
most influence on the company.

Once that happens, you as CEO has stepped down from running
a business to playing a lottery. With no higher chances
of obtaining a profit than you would in the lottery.

Rune

Rune Allnor wrote:

> On 2 Okt, 17:24, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> 
>>Rune Allnor wrote:
>>
>>>>>But as the circle of evil perpetuates, present managers
>>>>>tend to promote and reward employees that do things the
>>>>>same way the present managers used to do, when they were
>>>>>mere tech-staff employees.
>>
>>>>Those who blame managers and don't like how the things are done, are
>>>>free to go and start companies of their own. It is very enlightening
>>>>experience. You will see the things in the entirely different perspective.
>>
>>>I am sure such a change of perspective would be enlightening,
>>>but I don't see why it would change any opinions about promoting
>>>the members of staff who have the least chance to perform well in
>>>higher positions?
>>
>>There could be many different reasons for promotion ranging from
>>avoiding clashes between employees to satisfying your personal
>>preferences. Those things are no more and no less important then the
>>performance of the candidate.
> 
> 
> I have to disagree. If the skills and competence of the
> candidate are ruled out of the decision, you end up with
> the worst choises of people in the positions with the
> most influence on the company.

A subordinate is no more then a tool, just like oscilloscope or power 
screwdriver. When choosing a tool, you certainly look at the 
performance, however you also look at the price, convenience, 
compatibility, etc; and the choice is limited to what is available.
Good thing about the real power tools is that they don't have the habit 
to express their invaluable opinition.

> Once that happens, you as CEO has stepped down from running
> a business to playing a lottery. With no higher chances
> of obtaining a profit than you would in the lottery.

Business is never a goal. The goal is having a good life; i.e. doing the 
things you like in the way you like. Business is a suitable way to 
approach that for some people; other people may have different ways.

VLV

On 2 Okt, 18:35, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Rune Allnor wrote:
> > On 2 Okt, 17:24, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
....
> >>There could be many different reasons for promotion ranging from
> >>avoiding clashes between employees to satisfying your personal
> >>preferences. Those things are no more and no less important then the
> >>performance of the candidate.
>
> > I have to disagree. If the skills and competence of the
> > candidate are ruled out of the decision, you end up with
> > the worst choises of people in the positions with the
> > most influence on the company.
>
> A subordinate is no more then a tool, ...

> Business is never a goal. ...

....so your interest is merely to play chess with live pieces?

Rune

Rune Allnor wrote:

> On 2 Okt, 18:35, Vladimir Vassilevsky <nos...@nowhere.com> wrote:

>>
>>A subordinate is no more then a tool, ...
>>Business is never a goal. ...
> 
> ...so your interest is merely to play chess with live pieces?

I like freedom of research and design; what I do as a job is probably as 
close as it could be to that ultimate goal. I also like meeting the 
interesting people (most self-made business owners are quite out of 
common).
If you thought of something like saving the world, greed, or proving 
anything to anybody, that never interested me.

Could you tell more about your philosophy?

VLV

On 2 Okt, 19:10, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Rune Allnor wrote:

> > ...so your interest is merely to play chess with live pieces?

> Could you tell more about your philosophy?

Try and stimulate people to learn as much as possible about
their crafts. Assemble collections of people who, when they
work together, acieve more than they would have been able to,
on their own. Prepare processes and provide tools such that
people are able to reach stated production goals at the same
time they come out at the other end as functional human beings,
not wrecks.

Heck, it's *me* who is the chess player here...!

Rune

On Oct 2, 12:35 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> Business is never a goal. The goal is having a good life; i.e. doing the
> things you like in the way you like.

Vladimir, in fact we have a profound agreement about that.

> Business is a suitable way to
> approach that for some people; other people may have different ways.

withing ethical bounds (which we might have a slugfest arguing), i
agree with that, too.


On Oct 2, 1:10=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> I like freedom of research and design; what I do as a job is probably as
> close as it could be to that ultimate goal.

this does not conflict at all with the preference of some aesthetic
value in the structure of code.  now one thing that Greg Berchin noted
to me recently that i really agree with (lessee if i remember it
accurately): there is little value in a modern structured language in
writing code that abstracts a function just for the sake of
abstracting it.  my spin on it is that we do this to put our
intellectual property into containers.  it's like having your tools
hanging at the right place on the pegboard in your shop.  it's like
cleaning up your workspace and putting things in the right drawer.  if
you do that regularly, your work is more efficient.  modular,
structured programming is s'pose to be that.  OOPs is s'posed to do
more (i like operator overloading), but it makes no sense to me to
write bunch of spaghetti C++ code and claim it gets the OOPs point if
things ain't put into containers.

i dunno C++ very well, but i think i can recognize ugly C++ code that
could have had some principles of modular design applied to it and
does not aspire to that value at all.  and i know i've seen some
really good C++ code (if you were an industrial spy with access to
source, you would know instantly what the "secret sauce" is made of
from reading the code).  and i'm not naming any names either way.

> I also like meeting the interesting people (most self-made
> business owners are quite out of common).

some of these guys are cool (esp. in the audio sub-group), and some of
these guys are assholes.  no better nor worse than a random sampling
of the population, though.

> If you thought of something like saving the world, greed, or proving
> anything to anybody, that never interested me.

oh, c'mon Vlad.  you have an agenda to push.  (i know i do.)

On Oct 2, 11:00=A0am, Rune Allnor <all...@tele.ntnu.no> wrote:
> > There could be many different reasons for promotion ranging from
> > avoiding clashes between employees to satisfying your personal
> > preferences. Those things are no more and no less important then the
> > performance of the candidate.
>
> I have to disagree. If the skills and competence of the
> candidate are ruled out of the decision, you end up with
> the worst choises of people in the positions with the
> most influence on the company.
>
> Once that happens, you as CEO has stepped down from running
> a business to playing a lottery. With no higher chances
> of obtaining a profit than you would in the lottery.

It is true that idealism might degrade somewhat when you become boss.
Occasionally you might have to yell at people to get them to do what
you want, when you want it (right now), without challenging you (which
they cannot see any harm in doing), even though it is not in your
nature to yell, because if you have 15 subordinates, and each of them,
on average, argues with you once every three weeks, then that means,
on average, one argument per day, which for a busy CEO is far too
much.

However, I agree with Rune.

Companies are like organisms. They start small with great vitality.
They grow, mature it, then start to fester in their own waste. The
waste is people who, ideally, should not be part of the company, but
managed to become so due to the imperfect nature of hiring, and all it
takes is a single "wrong person" to enter the company, and that
person, through an extraordinary effort to self-preserve, will begin
to hire others like himself/herself, and start the process of decay.
The organism gradually becomes infected by parasites on the payroll.

This is why companies max out at some annual revenue and cannot seem
to grow any more or as fast as they did, even with profits that are,
in absolute terms, absolutely huge. They might earn several billion
dollars in profit, and not be able to start a single Google-like spin-
off with those billions, because the organism is rife with parasites
whose interests lie in throttling back any movement away from the
moribund.

I attended an MIT/Havard/Austin Venture's conference last year, and
one of the Top 5 pieces of advice given by the speaker, Ken Morse,
was:

"Whatver you do, always hire A people, because A people hire A people,
B people hire C people, and C people hire dogs!"

This is the most consistent and recurring piece of advice I have
received over the years from leaders in innovation.

-Le Chaud Lapin-

On 10/2/2009 2:21 PM, robert bristow-johnson wrote:
> On Oct 2, 12:35 pm, Vladimir Vassilevsky<nos...@nowhere.com>  wrote:

>> I also like meeting the interesting people (most self-made
>> business owners are quite out of common).
>
> some of these guys are cool (esp. in the audio sub-group), and some of
> these guys are assholes.  no better nor worse than a random sampling
> of the population, though.

It's been my experience that generally people in the "upper" ranks 
(whatever that means) tend to be generally more focused and intense than 
a sampling of the general populace.  But other than that, as far as the 
likability of the individual goes, I agree completely that the 
cool/asshole ratio is about the same as it is anywhere.

>> If you thought of something like saving the world, greed, or proving
>> anything to anybody, that never interested me.
>
> oh, c'mon Vlad.  you have an agenda to push.  (i know i do.)

My quest for the ultimate beer continues, and likely will until I die. 
I only hope that a few years before I transform to a different existence 
space that I'm able to imbue the passion of this quest into a suitable 
apprentice.

-- 
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com

On Oct 2, 4:21=A0pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> this does not conflict at all with the preference of some aesthetic
> value in the structure of code. =A0now one thing that Greg Berchin noted
> to me recently that i really agree with (lessee if i remember it
> accurately): there is little value in a modern structured language in
> writing code that abstracts a function just for the sake of
> abstracting it. =A0my spin on it is that we do this to put our
> intellectual property into containers. =A0it's like having your tools
> hanging at the right place on the pegboard in your shop. =A0it's like
> cleaning up your workspace and putting things in the right drawer. =A0if
> you do that regularly, your work is more efficient. =A0modular,
> structured programming is s'pose to be that. =A0OOPs is s'posed to do
> more (i like operator overloading), but it makes no sense to me to
> write bunch of spaghetti C++ code and claim it gets the OOPs point if
> things ain't put into containers.

Beautifully said.

Some programmers have built-in OOP meters.

Their compiler says "C++" on it. The book says C++. The spec says
write it in C++. But they do not feel C++. So they start doing
artificial things that a C++ programmer is expected to do. They wrap
everything as a class with the letter 'C' affixed. They use some
virtual functions. They replace printf with cout. The use new() and
delete(). They go buy Gang of Four and throw in some design patterns,
maybe a singleton, some scary templates, whatever, anything, to be
able to say they are doing C++.

After making huge mess, they go find the resident C jock to get them
out of it. ;)

-Le Chaud Lapin-

On 2 Okt, 23:21, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Oct 2, 12:35 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:

> > I like freedom of research and design; what I do as a job is probably a=
s
> > close as it could be to that ultimate goal.
>
> this does not conflict at all with the preference of some aesthetic
> value in the structure of code. =A0

This 'aesthetic value' of the result is caused by what I like
to call 'craftmanship.' Where I come from, people until recently
(about a century ago) used to make themselves a lot of the tools
and devices they needed to make a livelihood as farmers and
fishermen. They also marked their work with their insignia, mostly
to indicate who owned the tool. But for home-made tools these
ownership marks also became maker's mark.

At the end, everybody did their best to make good-looking tools,
since their pride was at stake as everybody would see the marks
on the tools, and thus be able to attribute maker's skills to
a particular person. And of course, the tools had to be functional.
Or there would be no point in making them in the first place.

Sadly, this kind of vocational pride seems to have been lost.

Rune

Rune Allnor wrote:
> On 2 Okt, 23:21, robert bristow-johnson <r...@audioimagination.com>
> wrote:
>> On Oct 2, 12:35 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> 
>>> I like freedom of research and design; what I do as a job is probably as
>>> close as it could be to that ultimate goal.
>> this does not conflict at all with the preference of some aesthetic
>> value in the structure of code.  
> 
> This 'aesthetic value' of the result is caused by what I like
> to call 'craftmanship.' Where I come from, people until recently
> (about a century ago) used to make themselves a lot of the tools
> and devices they needed to make a livelihood as farmers and
> fishermen. They also marked their work with their insignia, mostly
> to indicate who owned the tool. But for home-made tools these
> ownership marks also became maker's mark.
> 
> At the end, everybody did their best to make good-looking tools,
> since their pride was at stake as everybody would see the marks
> on the tools, and thus be able to attribute maker's skills to
> a particular person. And of course, the tools had to be functional.
> Or there would be no point in making them in the first place.
> 
> Sadly, this kind of vocational pride seems to have been lost.

I make many of my tools, including the steel stamp I mark them with. 
That's mostly because I'm too cheap to buy them.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On 3 Okt, 15:28, Jerry Avins <j...@ieee.org> wrote:
> Rune Allnor wrote:

> > This 'aesthetic value' of the result is caused by what I like
> > to call 'craftmanship.'
....
> > Sadly, this kind of vocational pride seems to have been lost.
>
> I make many of my tools, including the steel stamp I mark them with.
> That's mostly because I'm too cheap to buy them.

You are into silversmithing, right?

Do you show or sell every piece you make? Or do you want
the stuff that makes it out from your smithy(?) to have
that elusive /je ne sais quoi/ that tells the connoiseur
that 'yep, Jerry Avins made this piece!' ?

That's the kind of pride I was talking about. I remember
when I was about 15, when a couple of friends of my parents
(the husband was a professional carpenter) helped my father
with some carpentry work. The wife gave the husband a very
clear message: "Remember, this is not paid work so you'd
better get it right!"

I never quite knew if she was joking...

Rune

>On 2 Okt, 23:21, robert bristow-johnson <r...@audioimagination.com>
>wrote:
>> On Oct 2, 12:35 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
>> > I like freedom of research and design; what I do as a job is probably
a=
>s
>> > close as it could be to that ultimate goal.
>>
>> this does not conflict at all with the preference of some aesthetic
>> value in the structure of code. =A0
>
>This 'aesthetic value' of the result is caused by what I like
>to call 'craftmanship.' Where I come from, people until recently
>(about a century ago) used to make themselves a lot of the tools
>and devices they needed to make a livelihood as farmers and
>fishermen. They also marked their work with their insignia, mostly
>to indicate who owned the tool. But for home-made tools these
>ownership marks also became maker's mark.
>
>At the end, everybody did their best to make good-looking tools,
>since their pride was at stake as everybody would see the marks
>on the tools, and thus be able to attribute maker's skills to
>a particular person. And of course, the tools had to be functional.
>Or there would be no point in making them in the first place.
>
>Sadly, this kind of vocational pride seems to have been lost.

This is nonsense. Only small percentage of people ever cared, and a small
percentage still do. The only difference between the past and the present
is the growth of large corporations. They tend to make people who start out
caring give up. You can never suppress caring completely, though, however
much many corporations try.

Steve

Le Chaud Lapin wrote:


> It is true that idealism might degrade somewhat when you become boss.

I woudn't call the narrow minded Dilbert's way of thinking an idealism.

> Companies are like organisms. They start small with great vitality.
> They grow, mature it, then start to fester in their own waste. The
> waste is people who, ideally, should not be part of the company, but
> managed to become so due to the imperfect nature of hiring, and all it
> takes is a single "wrong person" to enter the company, and that
> person, through an extraordinary effort to self-preserve, will begin
> to hire others like himself/herself, and start the process of decay.
> The organism gradually becomes infected by parasites on the payroll.
> This is why companies max out at some annual revenue and cannot seem
> to grow any more or as fast as they did, even with profits that are,
> in absolute terms, absolutely huge. They might earn several billion
> dollars in profit, and not be able to start a single Google-like spin-
> off with those billions, because the organism is rife with parasites
> whose interests lie in throttling back any movement away from the
> moribund.

Who should be happy? The investors. If the investors are happy, then the 
company is healthy. Those who don't like how the things are done, can 
either change the things or quit. Where is the problem?

> I attended an MIT/Havard/Austin Venture's conference last year, and
> one of the Top 5 pieces of advice given by the speaker, Ken Morse,
> was:
> 
> "Whatver you do, always hire A people, because A people hire A people,
> B people hire C people, and C people hire dogs!"
> 
> This is the most consistent and recurring piece of advice I have
> received over the years from leaders in innovation.

I think I can give an advice about same as useful: Ferrari is an 
excellent car. Everybody should drive Ferrari. And, of course, the 
employment practices of WalMart, Microsoft, etc. are completely and 
unconditionally wrong.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Oct 4, 5:33=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> Who should be happy? The investors. If the investors are happy, then the
> company is healthy. Those who don't like how the things are done, can
> either change the things or quit. Where is the problem?

The investors can be happy and the company can be unhealthy. Just ask
Michael Dell. Or Charles Schwab. Or any other CEO/Founder whose wife
got tired of the long hours and missed Little-League baseball games
and asked him to "take a break".

Each of these CEO's made the same mistake - they looked to their #2,
and asked that #2 to "watch the company while I make good with wife
and kids." The #2 takes over. Sales improve dramatically. Profit
margin is up. For the first year, the Founder is relieved. Then 3
years pass, and sales drop 30%. Lawsuits mount. Customer satisfaction
ratings plumment. A net lost is posted for first time in company's
history.

What happened?

It's simple:

The #2, after asking to be #1 while Founder is away, seduces the
Founder into establishing metrics that, while ostensibly virtuous, can
be achieved by raping the integrity of the organization. These metrics
are things like: increased sales, increased profits, etc. The Founder
unwittingly agrees. Then the #2 proceeds to pillage silently. He does
this quietly and quickly, since his goal is to nab and run.

For example, in the case of Dell, the packaging was changed so that
the prices of each system stayed the same - but now _without_ the
monitor! Dell customers, like me, who have been buying from Dell for
almost 20 years, go to site, see a price for a system, and say, "Hmm...
$20 lower than I expected..". We might buy. Of course, it says in
small print "monitor not inlcluded", but for 20 years, we have have
known that, at Dell, the _monitor_ has *always* been included. What do
we do now? Do we try to figure out cost with monitor? Do we throw away
the  30 minutes picking system we wanted?

Maybe the #2 sends customer support to India. Maybe #2 starts using
batteriess with programmed obsolescence exactly one 1 month after
expiration of warranty on battery. Maybe the #2 decides that, if
customer gets good deal, customer should be hounded to death by calls
from India to "up-sale" for three weeks straight, each day, every day.
Maybe #2 decides to increase length of call queue and fire 50 customer
support reps. Maybe #2 tells the CFO to register future (questionable)
sales as present revenue, to boost the numbers.

There are all kinds of things that a #2 (or his subordinate), can do
to increase short-term gain at the expense of the health of the
organization, *including* hiring cheap-but-incompetent labor as
mentioned previously.

What is remarkable is is how many Founder/CEO's are seduced into this
mess.

Machiavelli alluded to this when he said that a Prince is judged by
whom he chooses as lieutenants. The Founder/CEO should know, more than
anyone, that what they possess makes the company what it is, and is
not likely to be possessed by a #2. This is only wishful thinking.

> > I attended an MIT/Havard/Austin Venture's conference last year, and
> > one of the Top 5 pieces of advice given by the speaker, Ken Morse,
> > was:
>
> > "Whatver you do, always hire A people, because A people hire A people,
> > B people hire C people, and C people hire dogs!"
>
> > This is the most consistent and recurring piece of advice I have
> > received over the years from leaders in innovation.
>
> I think I can give an advice about same as useful: Ferrari is an
> excellent car. Everybody should drive Ferrari. And, of course, the
> employment practices of WalMart, Microsoft, etc. are completely and
> unconditionally wrong.

If I could get a Ferrari for 20% premium over a Honda Accord, I would
buy it.

You, of all people, should know that 20 "engineers" whose mathematical
ability stops at trigonometry will not be able to achieve what could 1
engineer who understands the intricacies of recursive stochastic
filters.  But if those 10 engineers earn $50,000/year each...the
company will not pay the 1 engineer 20x, or $1 million/year, if he
replaces the 20. That's not how it works. Perhaps his salary will be
double, or triple, but not 20x.

So since the money is going to have to be spent anyway, it makes sense
to spend it wisely, and hire competence.

-Le Chaud Lapin-

On Oct 4, 6:33=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> Who should be happy? The investors. If the investors are happy, then the
> company is healthy. Those who don't like how the things are done, can
> either change the things or quit. Where is the problem?
>
> > I attended an MIT/Havard/Austin Venture's conference last year, and
> > one of the Top 5 pieces of advice given by the speaker, Ken Morse,
> > was:
>
> > "Whatver you do, always hire A people, because A people hire A people,
> > B people hire C people, and C people hire dogs!"
>
> > This is the most consistent and recurring piece of advice I have
> > received over the years from leaders in innovation.
>
> I think I can give an advice about same as useful: Ferrari is an
> excellent car. Everybody should drive Ferrari. And, of course, the
> employment practices of WalMart, Microsoft, etc. are completely and
> unconditionally wrong.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

Rune Allnor wrote:
> On 3 Okt, 15:28, Jerry Avins <j...@ieee.org> wrote:
>> Rune Allnor wrote:
> 
>>> This 'aesthetic value' of the result is caused by what I like
>>> to call 'craftmanship.'
> ...
>>> Sadly, this kind of vocational pride seems to have been lost.
>> I make many of my tools, including the steel stamp I mark them with.
>> That's mostly because I'm too cheap to buy them.
> 
> You are into silversmithing, right?
> 
> Do you show or sell every piece you make? Or do you want
> the stuff that makes it out from your smithy(?) to have
> that elusive /je ne sais quoi/ that tells the connoiseur
> that 'yep, Jerry Avins made this piece!' ?

I make many kinds of things. When I wanted a boat, I hung around a boat 
yard to augment what I had learned in the library. The questions I asked 
inspired answers from kindly workmen, especially the master shipwright. 
eventually, he offered me an paarenticeship. (He was a Norwegian, with 
wooden tools, and he was impressed that I knew how to use and maintain 
them.) If we get to visit, I'll show you some of the model steam engines 
I've made.

> That's the kind of pride I was talking about. I remember
> when I was about 15, when a couple of friends of my parents
> (the husband was a professional carpenter) helped my father
> with some carpentry work. The wife gave the husband a very
> clear message: "Remember, this is not paid work so you'd
> better get it right!"
> 
> I never quite knew if she was joking...

She was expressing her pride in him.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Oct 4, 6:33=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>
> Who should be happy? The investors. If the investors are happy, then the
> company is healthy.

hmmm.  do you really believe that, Vlad?  during the 80s and 90s,
investors in the American "big 3" (GM, Chrysler, Ford) were pretty
happy but the infection of those companies was festering even at that
time.  now the companies (less so, Ford) are in trouble (the second or
third time for Chrysler). they're obviously sick now.  but what i
question is if you understand that they were sick back then when the
investors were happy.  complacency is not the same as evidence of
health.

> Those who don't like how the things are done, can
> either change the things or quit. Where is the problem?

what you say is a reality, Vlad, but some of us have come to a
conclusion in social and economic values that the unenlightened self-
interest (a.k.a. "greed", i am a proponent of "enlightened self-
interest") of unregulated American capitalizm doesn't necessarily
serve the common good.  just because micro$hit and $prawl-mart are
doing well doesn't mean that they got there by compatible events that
serve our common good.  certainly there are banks and investment
houses that made zillions, distributed those zillions to their
investors and as bonuses to their execs, by dumping shit upon other
people.  they got rich (by either deception or sloppiness) and
everyone else pays for it.

good code is more honest than that.  good code clearly spells out what
it is doing.  good code isn't "tricky" simply for the sake of being
tricky.  (and tricks that save a cycle or two, or a machine or data
word or two, become less valuable as Moore's Law advances.  at some
point, a trick that obscures the purpose and flow of code becomes less
valuable than its absence and the clean and reusable code it leaves
behind.  that's why i continue to spout that a metric for evaluating
code is not based only on execution speed and memory compactness.)
good code treat tricks as bits of intellectual property, like special
tools (like the little moto-router in your shop).  it strives to be
transparent and puts this intellectual property into containers so you
always know what it is, where it is, and how to hook it up.

r b-j

Ben Bradley <ben_u_bradley@etcmail.com> writes:

> On Tue, 29 Sep 2009 07:55:36 -0700 (PDT), Mark <makolber@yahoo.com>
> wrote:
>
>>No discussion of software quality would be complete without a mention
>>of the THERAC 25 case..
>>
>>http://en.wikipedia.org/wiki/Therac-25
>
>    There are many more examples of such things in the Risks archive
> (Usenet readers will know this as comp.risks), some with frighteningly
> more familiar names such as Airbus:
>
> http://catless.ncl.ac.uk/Risks
>
>    You can search Therac on that site and get lots of info where it
> was discussed.
>
>    I used to read it regularly a while back, but I started having
> nightmares about technical problems, so I quit and only go back to it
> when rememded by threads like this or technical problems in the news
> (which is still much too often).
>
>>
>>
>>Mark

No matter what the other problems were in this case (and there were
several), it was absolutely unthinkable that the the company "had never
tested the Therac-25 with the combination of software and hardware until
it was assembled at the hospital" for such a device. 
-- 
Randy Yates                      % "Maybe one day I'll feel her cold embrace,
Digital Signal Labs              %                    and kiss her interface, 
mailto://yates@ieee.org          %            til then, I'll leave her alone."
http://www.digitalsignallabs.com %        'Yours Truly, 2095', *Time*, ELO   

On Oct 4, 11:11=A0pm, Randy Yates <ya...@ieee.org> wrote:
> No matter what the other problems were in this case (and there were
> several), it was absolutely unthinkable that the the company "had never
> tested the Therac-25 with the combination of software and hardware until
> it was assembled at the hospital" for such a device.

Of course, we must must not forget Roger Boisjoly and the Challenger
"Accident".

http://www.calbaptist.edu/dskubik/nasa.htm

http://en.wikipedia.org/wiki/Roger_Boisjoly

NASA and Morton Thiokol earned the Dilbert award of the century with
this one.

Imagine, you're an engineer, trained to do what you do. You have
intimate knowledge of your design space. You've studied for years,
worked long hours, nights, weekends, read countless papers, attended
conferences, even did a little extra just to be sure.

Then you discover a flaw in the company's product. It's not something
that will cause a few RMA's, or increase in support calls, or slaps on
the wrist by consumer protection agencies. The monetary cost will be
in excess of $1 billion. National Honor will be lost. Credibility will
be lost. Millions of children all over the world will witness a
horrific event. Precious lives will be lost. And the families of those
lost, already having sacrificed so much, will be tortured until their
own deaths, with the knowledge that those who were lost were lost
unnecessarily.

You are this engineer. You see it coming. And you are 95% certain.

Then some Dilbert-head comes in and says, "Whatever. We're launching."

Inexcusable!

I hope every sould involved with that explosion wakes up everyday
thinking about what they did. Because when you have someone ready to
lay it all out for you, showing cause and effect, etc., the process,
the precedure, with discipline and reason, and has already told you
what is at stake, and you have essentially unlimited resources to
determine the veracity of their claims, it's not an "accident"
anymore. It's stupidity of the worst kind.

-Le Chaud Lapin-

Le Chaud Lapin <jaibuduvin@gmail.com> wrote:
(snip)
 
< Of course, we must must not forget Roger Boisjoly and the Challenger
< "Accident".
(snip)
 
< Imagine, you're an engineer, trained to do what you do. You have
< intimate knowledge of your design space. You've studied for years,
< worked long hours, nights, weekends, read countless papers, attended
< conferences, even did a little extra just to be sure.
 
< Then you discover a flaw in the company's product. It's not something
< that will cause a few RMA's, or increase in support calls, or slaps on
< the wrist by consumer protection agencies. The monetary cost will be
< in excess of $1 billion. National Honor will be lost. Credibility will
< be lost. Millions of children all over the world will witness a
< horrific event. Precious lives will be lost. And the families of those
< lost, already having sacrificed so much, will be tortured until their
< own deaths, with the knowledge that those who were lost were lost
< unnecessarily.
 
< You are this engineer. You see it coming. And you are 95% certain.
 
< Then some Dilbert-head comes in and says, "Whatever. We're launching."

OK, so you are 95% certain leaving 5%.

Now, suppose you know that there is a 100% chance you lose your
job and won't be hired by anyone else.  (Your boss will tell them
how much trouble you caused.)

100% against 95%?

(We know on average the number is about 4%.  At some temperature
it is, presumably, 95% but they didn't know in advance what that
temperature was.

-- glen

>On Oct 4, 11:11=A0pm, Randy Yates <ya...@ieee.org> wrote:
>> No matter what the other problems were in this case (and there were
>> several), it was absolutely unthinkable that the the company "had
never
>> tested the Therac-25 with the combination of software and hardware
until
>> it was assembled at the hospital" for such a device.
>
>Of course, we must must not forget Roger Boisjoly and the Challenger
>"Accident".
>
>http://www.calbaptist.edu/dskubik/nasa.htm
>
>http://en.wikipedia.org/wiki/Roger_Boisjoly
>
>NASA and Morton Thiokol earned the Dilbert award of the century with
>this one.
>
>Imagine, you're an engineer, trained to do what you do. You have
>intimate knowledge of your design space. You've studied for years,
>worked long hours, nights, weekends, read countless papers, attended
>conferences, even did a little extra just to be sure.
>
>Then you discover a flaw in the company's product. It's not something
>that will cause a few RMA's, or increase in support calls, or slaps on
>the wrist by consumer protection agencies. The monetary cost will be
>in excess of $1 billion. National Honor will be lost. Credibility will
>be lost. Millions of children all over the world will witness a
>horrific event. Precious lives will be lost. And the families of those
>lost, already having sacrificed so much, will be tortured until their
>own deaths, with the knowledge that those who were lost were lost
>unnecessarily.
>
>You are this engineer. You see it coming. And you are 95% certain.
>
>Then some Dilbert-head comes in and says, "Whatever. We're launching."
>
>Inexcusable!
>
>I hope every sould involved with that explosion wakes up everyday
>thinking about what they did. Because when you have someone ready to
>lay it all out for you, showing cause and effect, etc., the process,
>the precedure, with discipline and reason, and has already told you
>what is at stake, and you have essentially unlimited resources to
>determine the veracity of their claims, it's not an "accident"
>anymore. It's stupidity of the worst kind.

No. Its just business. Most business startups fail completely at a fairly
early stage. The chances of a serious product liability issue are
relatively small compared to all the other hazards a new activity faces.

Steve

On Oct 5, 12:03=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> (snip)
>
> < Of course, we must must not forget Roger Boisjoly and the Challenger
> < "Accident".
> (snip)
>
> < Imagine, you're an engineer, trained to do what you do. You have
> < intimate knowledge of your design space. You've studied for years,
> < worked long hours, nights, weekends, read countless papers, attended
> < conferences, even did a little extra just to be sure.
>
> < Then you discover a flaw in the company's product. It's not something
> < that will cause a few RMA's, or increase in support calls, or slaps on
> < the wrist by consumer protection agencies. The monetary cost will be
> < in excess of $1 billion. National Honor will be lost. Credibility will
> < be lost. Millions of children all over the world will witness a
> < horrific event. Precious lives will be lost. And the families of those
> < lost, already having sacrificed so much, will be tortured until their
> < own deaths, with the knowledge that those who were lost were lost
> < unnecessarily.
>
> < You are this engineer. You see it coming. And you are 95% certain.
>
> < Then some Dilbert-head comes in and says, "Whatever. We're launching."
>
> OK, so you are 95% certain leaving 5%.
>
> Now, suppose you know that there is a 100% chance you lose your
> job and won't be hired by anyone else. =A0(Your boss will tell them
> how much trouble you caused.)
>
> 100% against 95%?
>
> (We know on average the number is about 4%. =A0At some temperature
> it is, presumably, 95% but they didn't know in advance what that
> temperature was.

I just read large tracts of the transcript of the Rogers Report:

http://history.nasa.gov/rogersrep/v1ch5.htm

....and it is quite clear that Roger Boisjoly (and his colleague
Thompson) were 100% certain that there was a problem, and a few other
engineering colleagues agreed with him. In the meeting the management
asked the engineers about launch, and every single engineer in the
room said 'no'.

It was management.

What is disgusting is the subsequent lack of responsibility and honor.
It is clearly evident from the report that none of the management want
to take responsibility. They want to be responsible to calling the
shots on go/no-go without listening to engineers, but when things blow
up..."Oh...no...not my fault..I was unware."

I have had very similar experiences. Of course, not with anything
remotely as critical as a Space Shuttle, but the behavioral patterns
with respect to management are identical:

I once worked for a certain software company as senior engineer for
writing anti-virus software. For months, I warned them that their
trick for patching the Windows kernel would fail because the new
PatchGuard feature from Microsoft would block it in 64-bit Windows and
beyond. They never listened. We were acquired by a top-4 software
company..and we had no 64-bit solution. I'd been quietly working on an
alternative in months that my idiot boss ignored me [ad nauseum],
until one day _his_ boss, the CEO, comes flying into my office and
says.."So wait minute...yada..." I said, "Yes! That's what I've been
trying to tell you for FOUR friggin' months!" He called an impromptu
meeting where I presented my work, and I was attacked vigorously...the
other managers would not let me speak more than 2 seconds until the
CEO says, "This sh*t needs to stop. Let him speak!"

Anyhow, the point is that there are typically two types of people in
meetings whose goal is to make a technical decision:

Those who belong, and those who don't.

-Le Chaud Lapin-

Randy Yates wrote:
> Ben Bradley <ben_u_bradley@etcmail.com> writes:
> 
>> On Tue, 29 Sep 2009 07:55:36 -0700 (PDT), Mark <makolber@yahoo.com>
>> wrote:
>>
>>> No discussion of software quality would be complete without a mention
>>> of the THERAC 25 case..
>>>
>>> http://en.wikipedia.org/wiki/Therac-25
>>    There are many more examples of such things in the Risks archive
>> (Usenet readers will know this as comp.risks), some with frighteningly
>> more familiar names such as Airbus:
>>
>> http://catless.ncl.ac.uk/Risks
>>
>>    You can search Therac on that site and get lots of info where it
>> was discussed.
>>
>>    I used to read it regularly a while back, but I started having
>> nightmares about technical problems, so I quit and only go back to it
>> when rememded by threads like this or technical problems in the news
>> (which is still much too often).
>>
>>>
>>> Mark
> 
> No matter what the other problems were in this case (and there were
> several), it was absolutely unthinkable that the the company "had never
> tested the Therac-25 with the combination of software and hardware until
> it was assembled at the hospital" for such a device. 

The problem as I remember it was a bug in the editing software that 
allowed the display and the internal register to differ in rare cases.

When I later built a machine that allowed keypad entry of co-ordinates, 
I edited the display as Therac did, but instead of coding to 
simultaneously edit the co-ordinate registers, I read the display into 
the co-ordinate registers when the "Go" button was pressed. It's harder 
to hide a bug that way.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On 5 Okt, 07:03, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Now, suppose you know that there is a 100% chance you lose your
> job and won't be hired by anyone else. =A0(Your boss will tell them
> how much trouble you caused.)
>
> 100% against 95%?

The Challenger story was, what, 25 years ago?

There has been some progress in the mean time: These days the
major companies don't hire potential would-be 'troublemakers' like
Boisjoly in the first place. The emphasis when screening potential
employees is not on comepetence and skills, but on 'team playership'
- that people don't voice their own opinions but do as they are told.

I was a bit scared a few weeks ago when I visited a friend who
teach at the local College of Engineering. He tries to stimulate
his students to actually think on their feet - and he seemed to
be well on his way to reach his goal.

As one understand right away, the guy has only worked in academic
institutions, where he always had the last word on his professional
priorities and choises. He has never worked anywhere where somebody
else, incompetent at their (and his) craft, had the professional
responsibility and last word on what he should do and how he should
do his job.

So he just have no idea what hellhole his students will meet
when they eventually migrate into the Real World, where nepotism,
sex, ethnical background, geographical location, political and
religious sympathies, and anything else one can think of, by
default beats professional skills and competence what carreer
oportunties are concerned.

Rune

On Oct 5, 12:10=A0pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> So he just have no idea what hellhole his students will meet
> when they eventually migrate into the Real World, where nepotism,
> sex, ethnical background, geographical location, political and
> religious sympathies, and anything else one can think of, by
> default beats professional skills and competence what career
> oportunties are concerned.
>

just to be clear.  the (unnamed) examples of mediocrity migrating to
management and imposing such mediocrity downward in search of the
quick buck (and quick release date) was, as far as i could tell,
decoupled from all of that.  no ethnic nor gender nor political
discrimination nor nepotism.  it's just the case of a bias toward
uncreativity that, in the mind of the mediocre engineer that becomes
mediocre manager, is more quickly and securely turned into a quick
(but problematic) product.  essentially, they will trust their own
mediocre judgment over something more creative if they cannot
understand the something more creative or what the promise of that
something more creative has for the future of the project or company.

r b-j

On Oct 5, 2:05=A0pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> just to be clear. =A0the (unnamed) examples of mediocrity migrating to
> management and imposing such mediocrity downward in search of the
> quick buck (and quick release date) was, as far as i could tell,
> decoupled from all of that. =A0no ethnic nor gender nor political
> discrimination nor nepotism. =A0it's just the case of a bias toward
> uncreativity that, in the mind of the mediocre engineer that becomes
> mediocre manager, is more quickly and securely turned into a quick
> (but problematic) product. =A0essentially, they will trust their own
> mediocre judgment over something more creative if they cannot
> understand the something more creative or what the promise of that
> something more creative has for the future of the project or company.

I agree, Rune and Robert.

What is ironic is that, in general, on scale of intelligence, mediocre
managers tend to be close to center of Guassian than creative
engineers. For 1000's of years, it has been this way - people of
questionable scruples ruling over the intelligentsia.

Why?

Why do we tolerate this? Sure, there are counter examples, like Bill
Gates [you have to admit that he has vision], but in general, the
model persists as it has been since the early days of organization.

Some might argue that there are "different kinds of intelligence", and
scheming/greedy CEO's simply exercise the kind they possess. I would
disagree with this argument. Machiavelli's teachings notwithstanding,
I think the ascension to power is more likely a result of indifference
about engaging in manipulative, self-serving, predatory, and
occasionally, brutish acts.

I do not think it has to be EITHER/OR: I see nothing inherently
mutually-exclusive about being able to do a Laplace Transform and
knocking a few heads together when people get out of line.

Top business schools in the USA have courses on Ethics, presumably to
make business leaders more ethical [less rapacious], resulting a
better society.

Why not teach students in technical schools Assertive-Management? They
could be reminded that being naive or acting naively on the job can be
detrimental to one's career. They can be taught to observe
manipulative behavior.

They can be taught that it is OK to bite! [those who deserve to be
bitten].

Think of the transformation of our society that would result if this
new mode of thinking/being by the intelligentsia were somehow
realized. For one things, few Space Shuttles would blow up, DARPA
would not be wasting billions of dollars a year on non-sense,
alternative energy might become a reality, health care costs might
actually recede, etc.

-Le Chaud Lapin-

On 5 Okt, 21:05, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Oct 5, 12:10=A0pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
>
>
> > So he just have no idea what hellhole his students will meet
> > when they eventually migrate into the Real World, where nepotism,
> > sex, ethnical background, geographical location, political and
> > religious sympathies, and anything else one can think of, by
> > default beats professional skills and competence what career
> > oportunties are concerned.
>
> just to be clear. =A0the (unnamed) examples of mediocrity migrating to
> management and imposing such mediocrity downward in search of the
> quick buck (and quick release date) was, as far as i could tell,
> decoupled from all of that. =A0no ethnic nor gender nor political
> discrimination nor nepotism.

The US might be shielded form such tendencies, but the
above list is what we have to contend with where I am.
A few years ago, a law was introduced to the effect that
share-holder's boards of all companies of a certain
organization type were obliged to have no more than 60%
members of either sex: At least 40% females on the board,
no more than 60% men.

Totally irrespective of quailifications or skills.

The particular organization form targeted by this, was
particularly popular for the companies where the Norwegian
governement was in heavy as shareholder.

Of course this blew up: Last spring, one of these
company conglomerates was reorganized, to cut dead weight,
reduce risk, or whatever. The government's appointee to
the board - female, no relevant business experience - did
not underatnd what was going on.

The short story is that the Government - represented by
this woman - accepted a deal where the other main shareholders
sold the dead weight to the Government for a few hundred $
more than the company was worth. Ignoring competent analyst's
warnings about what the deal really meant.

This is the only English link I could find:

http://newsinenglish.no/News/brustadhearing.html

It gives the big picture but none of the details that was
all over the local media, about who said and knew what, when
and where.

This would probably have toppled the Government in residence,
had there not been an election coming up: The opposition
in parliament decided against kicking out the Government
mere months before an election.

So if incompetent engineers is all you have to worry about,
you might count yourself lucky.

Rune

On Oct 5, 11:41 am, Jerry Avins <j...@ieee.org> wrote:
> Randy Yates wrote:
> > Ben Bradley <ben_u_brad...@etcmail.com> writes:
>
> >> On Tue, 29 Sep 2009 07:55:36 -0700 (PDT), Mark <makol...@yahoo.com>
> >> wrote:
>
> >>> No discussion of software quality would be complete without a mention
> >>> of the THERAC 25 case..
>
> >>>http://en.wikipedia.org/wiki/Therac-25
> >>    There are many more examples of such things in the Risks archive
> >> (Usenet readers will know this as comp.risks), some with frighteningly
> >> more familiar names such as Airbus:
>
> >>http://catless.ncl.ac.uk/Risks
>
> >>    You can search Therac on that site and get lots of info where it
> >> was discussed.
>
> >>    I used to read it regularly a while back, but I started having
> >> nightmares about technical problems, so I quit and only go back to it
> >> when rememded by threads like this or technical problems in the news
> >> (which is still much too often).
>
> >>> Mark
>
> > No matter what the other problems were in this case (and there were
> > several), it was absolutely unthinkable that the the company "had never
> > tested the Therac-25 with the combination of software and hardware until
> > it was assembled at the hospital" for such a device.
>
> The problem as I remember it was a bug in the editing software that
> allowed the display and the internal register to differ in rare cases.
>
> When I later built a machine that allowed keypad entry of co-ordinates,
> I edited the display as Therac did, but instead of coding to
> simultaneously edit the co-ordinate registers, I read the display into
> the co-ordinate registers when the "Go" button was pressed. It's harder
> to hide a bug that way.

maybe the least buggy way to do it is base the displayed value
entirely on the value that machine is using.  that might mean "un-
cooking" coefficients.  like a while ago, i posted a way to plot the
dB gain in a biquad based directly on the 5 Direct 1 form
coefficients.

like this:

if ( get_keypad(my_parameter_index, &my_parameter) )
    {
    change_parameter(my_parameter_index, my_parameter);

    get_parameter(my_parameter_index, &my_displayed_parameter);

    display_parameter(my_parameter_index, my_displayed_parameter);

    if (abs(my_displayed_parameter-my_parameter) > my_tolerance)
        {
        ooops(void);
        }
    }

i dunno why, particularly for a critical device why not just anal-
retentively display the parameters only from the effective source.  it
has the annoying property that the number that comes back to you
sometimes is not the number you punched in.  that's a reflection of
reality that is more accurate than the number you punched in.  and if
that is a problem to the practitioner controlling the device, maybe
that person should reconsider their intention to press the "Execute"
button.

r b-j

robert bristow-johnson wrote:
> On Oct 5, 11:41 am, Jerry Avins <j...@ieee.org> wrote:
>> Randy Yates wrote:
>>> Ben Bradley <ben_u_brad...@etcmail.com> writes:
>>>> On Tue, 29 Sep 2009 07:55:36 -0700 (PDT), Mark <makol...@yahoo.com>
>>>> wrote:
>>>>> No discussion of software quality would be complete without a mention
>>>>> of the THERAC 25 case..
>>>>> http://en.wikipedia.org/wiki/Therac-25
>>>>    There are many more examples of such things in the Risks archive
>>>> (Usenet readers will know this as comp.risks), some with frighteningly
>>>> more familiar names such as Airbus:
>>>> http://catless.ncl.ac.uk/Risks
>>>>    You can search Therac on that site and get lots of info where it
>>>> was discussed.
>>>>    I used to read it regularly a while back, but I started having
>>>> nightmares about technical problems, so I quit and only go back to it
>>>> when rememded by threads like this or technical problems in the news
>>>> (which is still much too often).
>>>>> Mark
>>> No matter what the other problems were in this case (and there were
>>> several), it was absolutely unthinkable that the the company "had never
>>> tested the Therac-25 with the combination of software and hardware until
>>> it was assembled at the hospital" for such a device.
>> The problem as I remember it was a bug in the editing software that
>> allowed the display and the internal register to differ in rare cases.
>>
>> When I later built a machine that allowed keypad entry of co-ordinates,
>> I edited the display as Therac did, but instead of coding to
>> simultaneously edit the co-ordinate registers, I read the display into
>> the co-ordinate registers when the "Go" button was pressed. It's harder
>> to hide a bug that way.
> 
> maybe the least buggy way to do it is base the displayed value
> entirely on the value that machine is using.  that might mean "un-
> cooking" coefficients.  like a while ago, i posted a way to plot the
> dB gain in a biquad based directly on the 5 Direct 1 form
> coefficients.
> 
> like this:
> 
> if ( get_keypad(my_parameter_index, &my_parameter) )
>     {
>     change_parameter(my_parameter_index, my_parameter);
> 
>     get_parameter(my_parameter_index, &my_displayed_parameter);
> 
>     display_parameter(my_parameter_index, my_displayed_parameter);
> 
>     if (abs(my_displayed_parameter-my_parameter) > my_tolerance)
>         {
>         ooops(void);
>         }
>     }
> 
> i dunno why, particularly for a critical device why not just anal-
> retentively display the parameters only from the effective source.  it
> has the annoying property that the number that comes back to you
> sometimes is not the number you punched in.  that's a reflection of
> reality that is more accurate than the number you punched in.  and if
> that is a problem to the practitioner controlling the device, maybe
> that person should reconsider their intention to press the "Execute"
> button.

That's another implementation of the principal I acted on: the numbers 
should be kept in one place, and used for all the processes that need 
them. Individual processes should not maintain their own copies.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Oct 5, 5:43=A0pm, Jerry Avins <j...@ieee.org> wrote:
>
> That's another implementation of the principal I acted on: the numbers
> should be kept in one place, and used for all the processes that need
> them. Individual processes should not maintain their own copies.

this is the same issue as "Death by Shared Variable".

because separate copies of the same variable are written to by their
separate processes that "own" those copies.  that is effectively the
same danger as having a shared variable that different processes are
allowed to write to.  there are circumstances where not all processes
agree to what the value of that shared variable is and bad shit can
happen when different processes believe that some common physical
quantity has different values.

variables are owned by processes (or instantiations of a process).
only the single process that owns a variable may write to it.  there
may be variables in which only the top executive may own (those are
like globals).  the top executive first questions all of the processes
underneath (or one layer underneath) and finds them all to be in an
unfrozen state; their internal states *may* change if something
changes.  they may or may not be "ready" and each have their own "not
ready" flag.  then the executive issues a freeze order to each
process, after which no subservient processes may update their states
or "owned" variables (which may be read by the exec or other
processes).  then the exec confirms that each process is frozen by
reading their "frozen" flag.  only when all of the processes are
frozen does the exec proceed and asks each process if they're ready or
not.  if they are all ready and no variables are shared (only one
process is allowed to write to variables they own and none are jointly
owned), then the exec can say "go" with confidence that everyone is on
the same page.

i am not sure if this is canonized in some textbook about robust real-
time processes, but i imagine something like this is.

r b-j