>>> It may not be required, but is often worth doing it the better way
>>> even if the other way has been partly coded, particularly when the
>>> better way has much more future.
>>
>> That depends entirely on how much future the code has in the first
>> place.
>
> Sure, but only the most trivial code has no future.
IME the future of a piece of code is constrained by the life of the
system it's embedded in. Most of the code I've written in my life is no
longer in use and will never be used again.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
>>>> Sometimes I'll flowchart a small piece of code if it's
>>>> particularly tricky,
>>>
>>> I've found that it's precisely the tricky code for which flowcharts
>>> are most useless. You have to carve the bird at the joints.
>>
>> Agreed. In fact for the trickiest piece of code I have ever
>> written I only found one tool sufficiently expressive and precise to
>> describe the solution. That was of course the code - I spent two days
>> trying to write a detailed design document/diagram/something before
>> giving up and writing the code while I still had all the detail and big
>> picture in my head. After I had written the code I was able to extract
>> a reasonable description to use as documentation for the next poor sod
>> to see it. I'd be prepared to bet that that code didn't get changed at
>> all from the time I left it to the
>
> We use design documents that log the design decisions and detail
> implementation choices..
That sounds like quite a high level document. We had one of those,
but this module was internally very tricky.
> I was in the middle of a consumer product design in Asia a few years ago
> and they had an interesting approach to software design. They started
> out by developing a large overview of the application that was broken
> down into modules . They as a team then created a application resource
> budget for each module. This include ROM and RAM requirements and
> CPU cycles or response time if that was an issue. Individuals were a
> assigned to be responsible for each module and provide current status
> during development.
That's pretty much how we do large system development - fine
details vary of course - usually it's a small team per module with dev and
QA people involved and that small team is responsible for all the module
level tests too.
> This did a lot for system reliability because each module was well defined
> independent of the system organization and could be independently
> swapped out. Unit testing at the module level was a big part of the
> testing process.
Absolutely.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
>>> On Mon, 2013-01-21, Ahem A Rivet's Shot wrote:
>>>
>>>> Actually no - the first time I saw concurrency biting bad code
>>>> there were no threads, just multiple processes and a shared memory
>>>> segment.
>>>
>>> OK, but I'd argue such applications were and are not the norm.
>>
>> I wrote quite a lot of code that used shared memory before
>> threads became popular. Given my druthers I'd still do things that
>> way.
>
> Uh-huh. I finally bit the bullet on threads when I discovered
> that some Windoze APIs simply could _not_ be kept from blocking
> for minutes at a time.
I don't do Windoze code.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
> I don't think many people realize just how many answers we work out
> on the fly, not really knowing them at the time they ask a question.
> I'm often reluctant to explain this; given their mindset it might
> destroy their faith in the infallibility they need us to have.
Somewhere about the web there's a flowchart of how people like us
solve problems for people on Windows - it's quite accurate.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
>> On 21 Jan 2013 13:06:19 GMT, jmfbahciv <See.above@aol.com> wrote:
>>
>> <All gone>
>>
>>> Any software developer who needed something from the monitor would
>>> not design a system call but simply read/write what s/he needed
>>> into the running kernal. Design reviews would not have refused
>>> this flavor of implementation since it was a corporate culture
>>> thing. If there had been questions, the developer would have
>>> plenty of history to point at to get his own way. Cutler tried
>>> to establish that system call wall but nobody else in that
>>> company knew nor wanted to understand the dangers of making that
>>> wall holey. They were running PCs which were single-user, single
>>> owner and didn't need the security that multi-user systems had
>>> to have. I still see this attitude in any PC implementation
>>> even though all now have to run multi-user even if there's
>>> only one human being touching it.
>>>
>>> Think about MS' backdoors which have to be there for the update
>>> services. The progammers would not wait to go through a system
>>> call design to get into the deep dark bowels of a running system.
>>>
>>> Bottom line to your question: unending security problems and
>>> bugs which, when fixed, beget 3 new ones.
>>>
>>>
>>> /BAH
>>
>> That confirms my belief - good fences make good neighbours.
>
> YBYA.
>
>
>>
>> That if security is not built in from the ground up of a computer
>> system - managers will not allow you to "retake the ground" later.
>>
>> MS Windows leave the front door open - a REGEDIT program allows access
>> to internal configuration parameters of Windows.
>
> Several times, I've tried to get people to talk about how Multics was
> developed, especially the details of the work involved. This included
> the process of developing a new thingie such a monitor call or a
> command to a device driver. Then there is the "ensuring everything
> works" processes. Over the years, the TOPS-10 group implemented
> self-disciplinary processes so that we immediately used what we made.
> Or the procedures of having a weekly monitor meeting which reviewed
> all the MCOs written in the MCO book. (monitor change order).
> The Multics group had to have had similar experiences but (I'm
> assuming) different solutions. This all has do to with minute
> to minute and daily work each of us did. None of this ever gets
> documented becuase it's a daily living habit. Each OS developer
> had his/her little habits which affected how an OS worked and what
> actually got shipped to customers.
Trouble is that there never were enough of those involved in that
stuff in the more obscure areas like Multics for it to be at all likely
that one of those will ever show up here given how usenet has
died in the arse so comprehensively recently. Just basic statistics.
And how its done with something like Linux is completely different anyway.
> OS/360 had "threads," in the form of "tasks," almost from the beginning
(196x).
Where x > 4.
The Ferranti Orion's Management Program (OMP, its OS and predecessor of the
GEORGE systems for the ICL 1900), supported multithreaded applications as
well as multiprogramming of independent applications, ca. 1961. Threads
were called 'program branches'.
In article <kdm9kd$mg5$2@dont-email.me>,
Charles Richmond <numerist@aquaporin4.com> wrote:
> But these programmers only wanted to know enough to get their present
> function done... any extra information was unappreciated.
You know what they say, give a man a fish, and he'll be back the next
day asking for another fish.
>> But these programmers only wanted to know enough to get their
>> present function done... any extra information was unappreciated.
>
> You know what they say, give a man a fish, and he'll be back the next
> day asking for another fish.
On the other hand, if you teach him to fish he'll spend all day
sitting in a boat drinking beer.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
>>> Actually, during the Y2K boom, we had "meeting training".
>>> We got a whole bunch of rules, including one person holding a
>>> stop watch.
>>
>> During the late 80's, our meeting training was compliments of
>> John Cleese's _Meetings, Bloody Meetings_.
>>
>>
>>
>> I spent most of the 90's as an organizational representative on
>> the X/Open base standards committee, and contributed to the
>> Unix International standards as well. We were very careful to avoid
>> invention in X/Open - to be included in the standard an existence proof must
>> already have been in existence, preferably by multiple vendors. It was
>> when the behavior of a given feature varied amongst vendors that things
>> got tricky.
>>
>> UI on the other hand, was all about invention (e.g. the DWARF standard came
>> from UI, along with the Large File (> 2GB) support extensions.
>>
>> The only standards that would have been interesting to DEC in the BAH years
> would
>> have been the ANSI language standards and character set standards, I
> suspect.
>
> There was also ASCII and FORTRAN and COBOL and all the comm shite
ASCII comes from ANSI
COBOL from CODASYL (whom I meant to mention explictly - I bundled
COBOL and Fortran into the ANSI bundle).
> and our internal standards, e.g., full file specifications, documentation,
> and hardware and FS had their own, too.
Every computer system manufacturer had internal standards, which
by definition aren't standards per-se, but rather OEM documentation.
> Oh, and EBCDIC and the entities
> which we invented but got adopted by the industry and
BCD -> EBCDIC. Neither of which were standards in the currently
accepted sense, but rather de-facto standards by virtue of widespread
(albeit incompatible) usage. The EBCDIC burroughs used was slightly
different than the IBM EBCDIC, for example.
The culprit was T. Vincent Learson. The only thing for his defense is
that he had no idea of what he had done. It was when he was an IBM Vice
President, prior to tenure as Chairman of the Board, those lofty
positions where you believe that, if you order it done, it actually will
be done. I've mentioned this fiasco elsewhere.
On Wed, 2013-01-23, jmfbahciv wrote:
....
> One of the reasons I was a "bad" programmer was because I thought through
> everything, wrote the specs, then wrote the code. By the time I was
> writing code, the code was essentially writing itself.
That's not a goal in itself (unless terminal time is a limited
resource). But I assume you were also more likely to get it right
that way.
> In a production
> line environment like ours, this process took too long.
So far, I've never been under so much time pressure that I couldn't
either (a) make it right or (b) at least isolate and document the weak
areas.
I've never been impressed by "yes this code is not quite under
control, but we were in such a hurry" arguments. A lot of the
shortcuts people take start hurting immediately -- don't name a
function properly, and five minutes later you'll forget what it does
and use it incorrectly.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
On Mon, 2013-01-21, Alfred Falk wrote:
....
> The central emergency number was introduced to North America in 1959 in
> Winnipeg, following the British model as 999. It was always my
> understanding that 911 won out because it was faster on rotary dials.
But not too likely to be dialled by accident or by a child just
interested in the funny rotating thing.
Sweden used to use 90000 -- one long rotation and four short.
Perhaps it's still supported; noone wants people to die because they
panicked and fell back to the emergency number they learned as kids.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
> One of the reasons I was a "bad" programmer was because I thought
> through everything, wrote the specs, then wrote the code. By the
> time I was writing code, the code was essentially writing itself.
> In a production line environment like ours, this process took too
> long.
ObPreachingToTheChoire What sort of delays were incurred when you
skipped the careful design documentation and then had to redo the code
because you guessed wrong? There's never time to do it right but
there's always time to do it over.
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
> This newsgroup will document how and why we did the things that new
> kids will rediscover.
Yeah, well... I doubt it. If it is just some rhetorical decor to the
other things you've said, then I get your angle.
I have a 19th century book on torpedo technology. But nobody seems to
want to be rediscovering that.
But yeah, it'll be there. Just like the old Apple and IBM electronic
magazines. Looking at them now, they have some nostalgic amusement,
but there's nothing really there that would interest any kid today.
>>> I don't think many people realize just how many answers we work out
>>> on the fly, not really knowing them at the time they ask a question.
>>> I'm often reluctant to explain this; given their mindset it might
>>> destroy their faith in the infallibility they need us to have.
>>
>> Somewhere about the web there's a flowchart of how people like
>> us solve problems for people on Windows - it's quite accurate.
>
> If it's from XKCD it applies to Macintosh too.
That sounds likely - and yes it would apply to any WIMP interface.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
>>>> I came into the programming business via the hardware one. It has
>>>> always mystified me how people can write programs without at least
>>>> a basic idea of how the machine works.
>>>
>>> How do you learn to program a line of compatible computers where each
>>> model has a different implementation? Your way is fine for one-off
>>> designs in the 1950's, but breaks down for processor families.
>>>
>> SAme way you do when a new language standard is approved.
>
> Which involves reading the language definition, not understanding a
> specific compiler for it.
>
Huh? ARe talking past each other? EAch manufacturer's compiler
was different. Most had extensions to the standards. YOu scanned
each manufacturer's documentation and noted the differences, either
in your head (which I could do) or on paper. Any new aspect
is learned in this manner; at least that's how it was done in my
shop. When there is a brand new architecture, we got a two-hour
seminar. When there are slight changes to an architecture with
each new processor, we read the specs and were expected to know
it. EAch spec had a reading list of names attached the first page.
YOu read it when it came into your office, checked off your name,
and handed (or placed it on the chair) of someone who hadn't checked
it off.
Canbear wrote:
> On 23 Jan 2013 16:16:40 GMT, jmfbahciv <See.above@aol.com> wrote:
>
>> This newsgroup will document how and why we did the things that new
>> kids will rediscover.
>
> Yeah, well... I doubt it. If it is just some rhetorical decor to the
> other things you've said, then I get your angle.
>
> I have a 19th century book on torpedo technology. But nobody seems to
> want to be rediscovering that.
>
> But yeah, it'll be there. Just like the old Apple and IBM electronic
> magazines. Looking at them now, they have some nostalgic amusement,
> but there's nothing really there that would interest any kid today.
I don't make that assumption because making it is how knowledge gets
lost. Think of all the things which have been thrown away because
someone made the same assumption.
Jorgen Grahn wrote:
> On Wed, 2013-01-23, jmfbahciv wrote:
> ...
>> One of the reasons I was a "bad" programmer was because I thought through
>> everything, wrote the specs, then wrote the code. By the time I was
>> writing code, the code was essentially writing itself.
>
> That's not a goal in itself (unless terminal time is a limited
> resource). But I assume you were also more likely to get it right
> that way.
Both terminal and machine stand alone time was a scarce resource.
>
>> In a production
>> line environment like ours, this process took too long.
>
> So far, I've never been under so much time pressure that I couldn't
> either (a) make it right or (b) at least isolate and document the weak
> areas.
>
> I've never been impressed by "yes this code is not quite under
> control, but we were in such a hurry" arguments. A lot of the
> shortcuts people take start hurting immediately -- don't name a
> function properly, and five minutes later you'll forget what it does
> and use it incorrectly.
then you don't understand how OS development groups worked at DEC.
The goal was to get the hardware out the door. Period. There were
very few "software" projects other than lanugages and those were
supplied so we could sell hardware to the government.
DEC's OS people were smart and experienced enough to know when
and when not to take those "shortcuts".
>>>> Actually, during the Y2K boom, we had "meeting training".
>>>> We got a whole bunch of rules, including one person holding a
>>>> stop watch.
>>>
>>> During the late 80's, our meeting training was compliments of
>>> John Cleese's _Meetings, Bloody Meetings_.
>>>
>>>
>>>
>>> I spent most of the 90's as an organizational representative on
>>> the X/Open base standards committee, and contributed to the
>>> Unix International standards as well. We were very careful to avoid
>>> invention in X/Open - to be included in the standard an existence proof
must
>>> already have been in existence, preferably by multiple vendors. It was
>>> when the behavior of a given feature varied amongst vendors that things
>>> got tricky.
>>>
>>> UI on the other hand, was all about invention (e.g. the DWARF standard
came
>>> from UI, along with the Large File (> 2GB) support extensions.
>>>
>>> The only standards that would have been interesting to DEC in the BAH
years
>> would
>>> have been the ANSI language standards and character set standards, I
>> suspect.
>>
>> There was also ASCII and FORTRAN and COBOL and all the comm shite
>
> ASCII comes from ANSI
> COBOL from CODASYL (whom I meant to mention explictly - I bundled
> COBOL and Fortran into the ANSI bundle).
>
>> and our internal standards, e.g., full file specifications, documentation,
>> and hardware and FS had their own, too.
>
> Every computer system manufacturer had internal standards, which
> by definition aren't standards per-se, but rather OEM documentation.
>
>> Oh, and EBCDIC and the entities
>> which we invented but got adopted by the industry and
>
> BCD -> EBCDIC. Neither of which were standards in the currently
> accepted sense, but rather de-facto standards by virtue of widespread
> (albeit incompatible) usage. The EBCDIC burroughs used was slightly
> different than the IBM EBCDIC, for example.
So what? We still had to know whatever the rest of the world was
using so we could talk to those machines or read data ouptut by them
or produce data input by them.
> The EBCDIC that IBM used was slightly different than the IBM EBCDIC
> )-:
Sad but true. I once thought of calling Univac's variations
"UBCDIC", but it seems the rot was everywhere.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!