Finites State Machine (OT?)

[Jeffrey C. Dege]

If you really believe this is true, then I have sympathy for your
employer, unless he's really that easy to snow. (i.e. a fool)

Every one of these is the exact opposite of good programming
practices. If I were an employer, then any idiot who calls himself
a programmer, who demonstrates this shoddy, slipshod, devil-may-
care approach to programming, wouldn't even get his foot in the
door.

That last one, isn't.

Configuration management is a sine qua non.

If you can't replicate the product you shipped, you might as well not
have written it in the first place.

 

[del cecchi]

message
snip

If you really believe this is true, then I have sympathy for your
employer, unless he's really that easy to snow. (i.e. a fool)

Every one of these is the exact opposite of good programming
practices. If I were an employer, then any idiot who calls himself
a programmer, who demonstrates this shoddy, slipshod, devil-may-
care approach to programming, wouldn't even get his foot in the
door.

Good Luck, you'll need it.
Rich

I don't know about imbedded code, but this last statement is pretty much
true for circuit design. If you want to be able to EC an circuit
design, you better have the tools from when it was done. Ever try to
work on a design that was done with Cadence 4.3 when all you've got is
Cadence 4.4 or 4.5? Or went to move a wire and add a few transistors
and now there are DRC errors all over the place? Ooops the checking deck
changed.

Del Cecchi

 

[Kelly Hall]

Every one of these is the exact opposite of good programming
practices. If I were an employer, then any idiot who calls himself
a programmer, who demonstrates this shoddy, slipshod, devil-may-
care approach to programming, wouldn't even get his foot in the
door.

A lot of the 'good programming practices' grew out of lessons learned
from managing many developers creating large software projects. For
small teams of highly talented individuals, different rules apply.

Tools like coding style and design methodology are there to help you get
the job done. Don't confuse using all the tools with being successful -
there's less correlation between the two than the "software engineers"
want you to believe.

Kelly

 

[Jeffrey C. Dege]

Tools like coding style and design methodology are there to help you get
the job done. Don't confuse using all the tools with being successful -
there's less correlation between the two than the "software engineers"
want you to believe.

Engineering is inherently a matter of choosing the proper trade-off
between conflicting demands.

The appropriate degree of structure for a 300kloc business app is not
the same as for a 3kloc embedded app.

That said - most of my experience with programmers who did not clearly
structure their code was with those who did not think clearly, rather
than those who were accepting a reasonable tradeoff between efficiency,
size, or some other meaningful engineering criteria, and maintainability.

I've written code that consisted of one massive function with thousands
of goto's - because that was the clearest and most efficient way of
implementing a state machine in that environment, and a state machine
was the most effective way of solving that particular problem.

And it wasn't even terribly difficult to understand, if you understood
what a state machine was. Because while the language let you do damned
near anything with a goto, I imposed on myself the sort of discipline
that the structured constructs gives you, in terms of how each state
was coded, labels and jumps were placed, and named, etc.

It did it for specific reasons, in a specific situation, and I think my
reasons were valid.

In fact, the product that was based on this particular piece of code
currently has a 40% market-share in its industry, so if I didn't do
something right, at least I didn't do anything obviously wrong.

But that's one specific situation. It's not my normal coding style.

Most of that product was written in a fully OO paradigm, with extensive
use of OO design patterns. Which has made it extensible in ways we'd
never conceived, when we laid out the original architecture.

--
How can you rightfully ask another human being to risk his life to protect
yours, when you will assume no responsibility yourself? Because that
is his job and we pay him to do it? Because your life is of incalculable
value, but his is only worth the $30,000 salary we pay him? If you believe
it reprehensible to possess the means and will to use lethal force to
repel a criminal assault, how can you call upon another to do so for you?
- Jeff Snyder, "Nation of Cowards"

 

[John Larkin]

I don't know about imbedded code, but this last statement is pretty much
true for circuit design. If you want to be able to EC an circuit
design, you better have the tools from when it was done. Ever try to
work on a design that was done with Cadence 4.3 when all you've got is
Cadence 4.4 or 4.5? Or went to move a wire and add a few transistors
and now there are DRC errors all over the place? Ooops the checking deck
changed.

Del Cecchi

FPGA tools seem to become obsolete in a couple of years. We have some
Actel designs that can't be maintained in any usable manner, by
anybody apparently. We'll just redesign the boards and use Xilinx
chips - it's easier than trying to resserect the old security-locked
Win3 tools - and hope we can run the Xilinx stuff in a few years.

Most of my embedded assembly programs can be archived *including a
bootable operating system* on a floppy.

John

 

[John Larkin]

These two statements are contradictory.

Why? Do you suggest that there is only one methodology that everyone
must use, regardless of how they think? Funny, hardware designers are
not so rigid, and do far better work than the average programmer.

If you really believe this is true, then I have sympathy for your
employer, unless he's really that easy to snow. (i.e. a fool)

Every one of these is the exact opposite of good programming
practices. If I were an employer, then any idiot who calls himself
a programmer, who demonstrates this shoddy, slipshod, devil-may-
care approach to programming, wouldn't even get his foot in the
door.

There's nothing slipshod about any of these preferences... they're
just not what you're used to.

What do you have against comments? Or being able to run the same
compiler and linker scripts a couple of years from now? Or being able
to read a program in the same sequence that it executes?

And I can't be fired, as I own the company. 90% of the deep UV lasers
that make ICs use my code; we got an award (laser engraved!) for that
one. NIF, the world's biggest laser, uses my products; Los Alamos and
Lockheed and Pratt&Whitney buy my stuff. Joint Strike Fighter is being
developed with my gear. Because it works.

You can't claim that orthodox C-programming rules are effective,
because they aren't. Bad code costs lots of lives and trillions of
dollars. Programming is in the dark ages, where engineering was 200
years ago.

Good Luck, you'll need it.

Thanks. It's been good so far.

John

 

[John Larkin]

Engineering is inherently a matter of choosing the proper trade-off
between conflicting demands.

The appropriate degree of structure for a 300kloc business app is not
the same as for a 3kloc embedded app.

That said - most of my experience with programmers who did not clearly
structure their code was with those who did not think clearly, rather
than those who were accepting a reasonable tradeoff between efficiency,
size, or some other meaningful engineering criteria, and maintainability.

I've written code that consisted of one massive function with thousands
of goto's - because that was the clearest and most efficient way of
implementing a state machine in that environment, and a state machine
was the most effective way of solving that particular problem.

Exactly. "Programming" can range from coding a musical Christmas card
to a credit-card transaction system. No orthodoxy can span that range.

Except of course: comment!

John

 

[Richard Henry]

Program in assembly. C rots your mind.

I see your problem.

 

[Richard Henry]

These two statements are contradictory.


If you really believe this is true, then I have sympathy for your
employer, unless he's really that easy to snow. (i.e. a fool)

Every one of these is the exact opposite of good programming
practices.

Not entirely. I like the last one (...archive the entire tool chain...)

 

[Richard Henry]

A lot of the 'good programming practices' grew out of lessons learned
from managing many developers creating large software projects. For
small teams of highly talented individuals, different rules apply.

The first objective is to get the product working. To meet that, almost any
bad habits cna be tolerated..

The second objective is to keep it working. After all your "highly talented
individuals" have been promoted to management, someone else will appreciate
the time and effort spent on proper design and documentation, not just cute
coding.

 

[Stephen Sprunk]

Why? Do you suggest that there is only one methodology that everyone
must use, regardless of how they think? Funny, hardware designers are
not so rigid, and do far better work than the average programmer.

In my experience, hardware engineers have the mindset that everything must
be perfect before shipment, whereas software engineers have the mindset any
problems can be fixed later on with little to no cost. While hopefully this
isn't widespread, I've seen it at three different employers (each with
majority marketshare in different areas) and it has a significant impact on
product quality (to the benefit of time to market).

S

 

[Ketil Malde]

What do you have against comments?

Funny, I used to argue with some (mostly hardware) people about
this. I tried to point out that comments are not always a good
thing. I was using some random code as an example of clear, neat and
self explanatory code that didn't need any comments, and it turned out
one of them wrote it

If it is a natural entity that does something useful, it should have a
descriptive name.

I agree, at least for some programs where this model fits well. I
don't much care for object orientation, partly for this reason.

The best control structure is recursion, preferably structured as
folds and maps.

(We're on different abstraction levels here, I guess

Yes.

Explain why, and perhaps when and what, but not how. The code should
be clear enough, and redundancy unavoidably leads to divergence (look
at any genome if you don't believe me

Use abstraction, but not at all cost.

Program in Haskell. C rots your mind.

Program with standardized tools, preferably with mulitple and/or open
source implementations. Use good configuration management/version
control.

-kzm

 

[Nick Maclaren]

|> |> > |> > > "Real Programmers are not afraid of five-page-long do loops ..."
|> >
|> > Maybe not, but it sounds more like bravado to me. An _effective_
|> > programmer keeps both ends of his loops on the same page.
|>
|> An experienced professional (in any discipline) knows that while rules of
|> thumb are generally applicable, sometimes the most effective solution
|> requires a different approach _and documents the heck out of it, including
|> rationale_.

Quite.

I have several times had to 'de-structure' code in order to
make head or tail of it. If you have a complex loop structure,
splitting it into 10 routines just to keep every loop short
can make it unintelligible.

The structure of your code should reflect the structure of your
algorithm. Beyond that, follow Kipling.

There are nine and sixty ways of constructing tribal lays,
And every single one of them is right!


Regards,
Nick Maclaren.

 

[Jan Vorbrüggen]

- it's easier than trying to resserect the old security-locked Win3 tools

VMware might be your friend in such cases. In this case, "tools" includes
an image copy of the OS disk.

Jan

 

[Jeffrey C. Dege]

What do you have against comments?

They're a waste of time and energy, if all they do is describe what the
code is doing. The code describes what the code is doing. The comments
should focus on why.

I'm not much of one for in-line comments.

I document what each function does, what each variable is used for,
how the algorithm works if it's non-obvious, places where a change in
one place will have to be reflected in a change someplace else, etc.

But this "x = x + 1; // Add one to x" kind of comments are worse than
useless.

--
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
- R. A. Heinlein

 

[John Larkin]

The best control structure is recursion, preferably structured as
folds and maps.

Oh, that brings up another rule: if, at any point in your code, you
can't pretty-closely estimate your stack usage, find another line of
work.

John

 

[John Larkin]

Well, when you're right, you're right. I'm torn, because I want to argue
both sides of this simultaneously. The only graceful retreat I can manage
is to say that the folks who perpetrate the undisciplined messes aren't
what I'd call programmers. Let me elaborate:

In companies that live or die by their software, star programmers are pretty
much at the top of the social pecking order, as determined by respect
they've earned by their peers.

In corporations for which IT is just a means to an end, programmers are,
regrettably, pretty much the lowest form of IT life. They are generally
managed by folks who were politically -- as opposed to technically -- savvy
enough to have risen out of the programmer ranks. So is it any surprise
that corporate code is generally a couple of notches below "mediocre"?
Companies that deal with programmers in that way (compensation, management)
are reaping what they have sown.

I feel very fortunate to have worked (before retirement) in a Fortune 50
consumer goods company that paid their programming employees as much as
$130,000, and gave them a voice. It was certainly the exception for
non-technology companies.

You have expressed something that I've noticed for a while now. If a
company is in the software business, the programmers are the
superstars, and they tend to be not only talented, but work in a
reward/scorn system that encourages good work. But if the superstars
of an organization are physicists or insurance execs or MDs, the
programmers are (often) just more staff, so aren't as talented or as
rewarded for excellence. EEs are subject to some of the same forces,
but seem to hold up a little better.

Software is now the heart of any technology or information-critical
company, which leaves almost no enterprise out. Management ignores its
programmers at great peril.

One of my customers, a big-science outfit, is "spinning out of
control" because their technical programming staff is so sloppy and
isolated. Another customer, a *big* aerospace conglomerate, has
Corporate Fellows who are programmers. The difference in results is
startling.


So: how do we explain the crap that Microsoft cranks out?

John

 

[John Larkin]

I once turned down a job because they were use Paradox to run their
payroll system.

One of my customers, a couple of years ago, installed a huge Oracle
system to run everything. Their annual report says that they have
"almost completely recovered" from the conversion.

When they release an engineering document or some code, the Oracle
record is unintelligible nonsense; it reads like the fine print on a
cell phone contract. So the *real* history and status of system
configurations is actually in peoples' heads and in emails and in
folklore.

John

 

[John Larkin]

In my experience, hardware engineers have the mindset that everything must
be perfect before shipment, whereas software engineers have the mindset any
problems can be fixed later on with little to no cost. While hopefully this
isn't widespread, I've seen it at three different employers (each with
majority marketshare in different areas) and it has a significant impact on
product quality (to the benefit of time to market).

S

The amount of care that goes into a design is in proportion to the
cost of fixing mistakes. A big CMOS IC may have a mask/prototype/test
loop cost in the tens of millions of dollars, so lots of verification
gets done, and first-pass yields - with tens of millions of gates! -
are very high. Electronic hardware design is intermediate. Software is
quick and cheap to patch, so lots of people just type the code then
run it to see if it works. If it seems OK, it's done til the bugs
start popping up. I find most of my bugs by reading the code before
it's ever run.

The Space Shuttle blasted off with a full fuel load and a full crew,
to orbit, on its first powered flight.

John

 

[krw]

The amount of care that goes into a design is in proportion to the
cost of fixing mistakes. A big CMOS IC may have a mask/prototype/test
loop cost in the tens of millions of dollars, so lots of verification
gets done, and first-pass yields - with tens of millions of gates! -
are very high. Electronic hardware design is intermediate. Software is
quick and cheap to patch, so lots of people just type the code then
run it to see if it works. If it seems OK, it's done til the bugs
start popping up. I find most of my bugs by reading the code before
it's ever run.

The Space Shuttle blasted off with a full fuel load and a full crew,
to orbit, on its first powered flight.

....and the Shuttle OBS wasn't designed by hackers who thought they
could patch bugs after the pieces were swept up. It had to be right
the first time. Of course STS-1 had the "bug heard around the world"
too.