Connect with us

Per the discussions of Software Engineering

Discussion in 'Electronic Design' started by Robert, Apr 21, 2007.

Scroll to continue with content
  1. Robert

    Robert Guest

  2. John Larkin

    John Larkin Guest

    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.

  3. Andrew Holme

    Andrew Holme Guest

    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
  4. "never breaks. I finish programs very fast "

    A typical programming oxymoron.
  5. John Larkin

    John Larkin Guest

    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.

  6. John Larkin

    John Larkin Guest

    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.

  7. joseph2k

    joseph2k Guest

    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
  8. john jardine

    john jardine Guest

    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

    "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
  9. John Larkin

    John Larkin Guest

    Dijkstra didn't program much himself, and didn't have a personal
    Yup, that's him.

  10. Joel Kolstad

    Joel Kolstad Guest

    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.
  11. Robert

    Robert Guest

    That sounds like one of the practices of the current (or just past current)
    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.

  12. Joel Kolstad

    Joel Kolstad Guest

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


    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.

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day