Per the discussions of Software Engineering

The best Programming Language to start with:

http://www.shlomifish.org/philosophy/computers/education/introductory-language/

Robert

 

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

 

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.

 

"never breaks. I finish programs very fast "

A typical programming oxymoron.

 

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

 

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

 

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.

 

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"

 

Dijkstra didn't program much himself, and didn't have a personal
computer.

Yup, that's him.

John

 

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

 

"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