Maker Pro
Maker Pro

Per the discussions of Software Engineering

J

John Larkin

Jan 1, 1970
0

This makes no sense to me:

"The reason for that is that people who dive right into Assembly, tend
to write sub-optimal code because they don't understand well how this
code is executed by the processor and how to compile it. This is while
programmers who've learned C are better equipped to understand how
Assembly code works, because it is somewhat more convenient yet still
very close to Assembly."

Someone technically oriented could well start with assembly on a good
architecture (which qualification immediately excludes all Intel
products.) I can't see how learning C first helps. They should be
*taught* good assembly programming technique (data types, indexing on
structures, bare-metal binary math concepts, general organization,
commenting) so they don't grow their own bad habits, just like
teaching tennis or skiing.

There's a lot to be said about learning on an untyped language. C
programmers often get confused when learning assembly because they
really can't grasp the concept that most types aren't inherent to a
machine architecture, but are human constructs, or that something in
memory can be thought of as several types simultaneously; casting is
mostly in your head. This can be funny.

A modern non-GUI BASIC is a very good way to learn to program. It has
the advantage that, for engineering applications, the first language
you learn is possibly the only one you will ever need. I still do tons
of useful engineering stuff in PowerBasic, the DOS version. I use the
Console Compiler for 32-bit stuff that must run under Windows and do
TCP/IP and such, and the true Windows version for disgusting GUI
things which, luckily, are rarely needed.

John
 
A

Andrew Holme

Jan 1, 1970
0
John Larkin said:
This makes no sense to me:

"The reason for that is that people who dive right into Assembly, tend
to write sub-optimal code because they don't understand well how this
code is executed by the processor and how to compile it. This is while
programmers who've learned C are better equipped to understand how
Assembly code works, because it is somewhat more convenient yet still
very close to Assembly."

Actually, programmers who've learned assembler are better equipped to
understand how C works.
Someone technically oriented could well start with assembly on a good
architecture (which qualification immediately excludes all Intel
products.) I can't see how learning C first helps. They should be
*taught* good assembly programming technique (data types, indexing on
structures, bare-metal binary math concepts, general organization,
commenting) so they don't grow their own bad habits, just like
teaching tennis or skiing.

I started-out programming in BASIC and 6502 machine code on a Commodore PET.
By the time I went to university, I was quite an accomplished spaghetti
programmer. At college, they taught us structured programming in PASCAL.
My BASIC and machine code were much better organised after that. I just
needed a little pointer in the right direction to correct my self-taught bad
habits.
 
R

Richard Henry

Jan 1, 1970
0
I started writing horrible stuff on PDP-8's, but the PDP-11 taught me
how to think... it was designed for cleanly structured data and code.
I read the listings of the Focal-11 interpreter and the RSTS
timesharing system and the lights came on.

I still do my embedded stuff in 68K assembly, which is at least as
nice a language as C. A typical embedded product program takes a week
or two to do and never breaks. I finish programs very fast because I
hate to program. That's consistant with the quote in "Dreaming in
Code", something to the effect that the problem with programmers is
that they love to write code.

"never breaks. I finish programs very fast "

A typical programming oxymoron.
 
J

John Larkin

Jan 1, 1970
0
Actually, programmers who've learned assembler are better equipped to
understand how C works.


I started-out programming in BASIC and 6502 machine code on a Commodore PET.
By the time I went to university, I was quite an accomplished spaghetti
programmer. At college, they taught us structured programming in PASCAL.
My BASIC and machine code were much better organised after that. I just
needed a little pointer in the right direction to correct my self-taught bad
habits.

I started writing horrible stuff on PDP-8's, but the PDP-11 taught me
how to think... it was designed for cleanly structured data and code.
I read the listings of the Focal-11 interpreter and the RSTS
timesharing system and the lights came on.

I still do my embedded stuff in 68K assembly, which is at least as
nice a language as C. A typical embedded product program takes a week
or two to do and never breaks. I finish programs very fast because I
hate to program. That's consistant with the quote in "Dreaming in
Code", something to the effect that the problem with programmers is
that they love to write code.

John
 
J

John Larkin

Jan 1, 1970
0
"never breaks. I finish programs very fast "

A typical programming oxymoron.

It ain't an oxymoron if it's true. It's possible to write solid
error-free code, but most programmers aren't interested; they have
other agendas.

John
 
J

joseph2k

Jan 1, 1970
0
Richard said:
"never breaks. I finish programs very fast "

A typical programming oxymoron.
I will make you a deal; you design an embedded processor device and write
debugged code in two weeks. Until you match John's track record, don't
dis.
 
J

john jardine

Jan 1, 1970
0
Robert said:

All programming essays are duty bound to contain at least 3 fawning
references to Dijkstra. I see none in the above link.
In lieu of this glaring omission, I offer 3 from the Confuscious-jardi
rubaiyat ...

"The disciple who is versed in the way of machine code is free and
bountiful."

"Do not be concerned about others not appreciating you, be concerned about
your not appreciating others"

"To learn without thinking is labour in vain. To think without learning is
desolation"
 
J

John Larkin

Jan 1, 1970
0
All programming essays are duty bound to contain at least 3 fawning
references to Dijkstra. I see none in the above link.

Dijkstra didn't program much himself, and didn't have a personal
computer.
"To learn without thinking is labour in vain. To think without learning is
desolation"

Yup, that's him.

John
 
J

Joel Kolstad

Jan 1, 1970
0
John Larkin said:
It ain't an oxymoron if it's true. It's possible to write solid
error-free code, but most programmers aren't interested; they have
other agendas.

One of the contracts we currently have is with a Big Name company (hundreds
of milliions in capitalization, many multi-million dollar government
contracts, that sort of thing), and what does this big company want us to
provide them with on a regular basis?

How many "lines of code" we've written.

Given how utterly meaningless such a metric is these days, with GUI builders
and other code "wizards" "writing" thousands of lines of code for you,
better programmers typically using sibstantially fewer lines of code to
accomplish the same task as beginning programmers -- and more readably and
reliably to boot --, etc., it's not even worth pointing this out to come and
debating it. We just comply and accept their payments...

Said big company uses "pair programming" internally, where two folks sit
side by side and co-author/critique/debug code as it's being written. I'd
tend to agree that, yeah, the result probably is reasonably bug-free, but I
think this result comes at the price of rather low productivity -- IMO a
better solution is to just hire better programmers in the first place.
 
R

Robert

Jan 1, 1970
0
Joel Kolstad said:
One of the contracts we currently have is with a Big Name company
(hundreds of milliions in capitalization, many multi-million dollar
government contracts, that sort of thing), and what does this big company
want us to provide them with on a regular basis?

How many "lines of code" we've written.

Given how utterly meaningless such a metric is these days, with GUI
builders and other code "wizards" "writing" thousands of lines of code for
you, better programmers typically using sibstantially fewer lines of code
to accomplish the same task as beginning programmers -- and more readably
and reliably to boot --, etc., it's not even worth pointing this out to
come and debating it. We just comply and accept their payments...

Said big company uses "pair programming" internally, where two folks sit
side by side and co-author/critique/debug code as it's being written. I'd
tend to agree that, yeah, the result probably is reasonably bug-free, but
I think this result comes at the price of rather low productivity -- IMO a
better solution is to just hire better programmers in the first place.

That sounds like one of the practices of the current (or just past current)
fad
of "Extreme Programming".

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

They define 12 practices from Extreme Programming at the end, one of which
is "Pair Programming":

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

All of flavor of the main fad currently in Programming of "Agile Methods":

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

<shrug>

Sounds good but Devil/details/etc.

Robert
 
J

Joel Kolstad

Jan 1, 1970
0
Robert said:
That sounds like one of the practices of the current (or just past
current) fad
of "Extreme Programming".
Indeed.

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

"Extreme Programming was created by Kent Beck, Ward Cunningham, and Ron
Jeffries during their work on the Chrysler Comprehensive Compensation System
(C3) payroll project. ... Chrysler cancelled the essentially unsuccessful C3
project in February 2000, but the methodology had caught on in the software
engineering field."

Nice!

Then again, if I somehow ended up working on a payroll project, I'd probably
want some guy sitting right next to me just to keep me awake. :)

"A larger recent study (Arisholm et al. 2007) had 48% increase in
correctness for complex systems, but no signficant difference in time,
whilst simple systems had 20% decrease in time, but no significant
difference in correctness. Overall there was no general reduction in time or
increase in correctness, but an overall 84% increase in effort."

That sounds reasonable enough, and for certain mission-critical systems
perhaps it makes sense.

That sounds much more level-headed to me. I can't tell you the number of
times I've seen programmers sit around and maintain/tweak/"improve" code
that's clearly *rotten at the core* rather than just starting it out and
start anew.

---

A real problem, IMO, is that far too few engineers, programmers, etc. are
particularly *passionate* about what they do. They'll do what they're asked
to the best of their abilities, but if those managing them don't make it
clearly that buggy design isn't acceptable, that more sophisticated
techniques could be used to produce better results in less time, etc.,
relatively few people will gravitate towards such goals on their own. Hence
I tend to blame buggy and/or "uninspired" software and hardware more on
management than individual programmers... at least in companies big enough
that, e.g., staff funding is not the problem.

---Joel
 
Top