Per the discussions of Software Engineering

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.

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

ge/

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"

--
Posted via a free Usenet account from http://www.teranews.com

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".

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

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

Sounds good but Devil/details/etc.

Robert

Indeed.

"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