OO languages
in [Embedded]
|
Prev: AVR BASIC COMPILER source code released
Next: ATtiny10
From: Grant Edwards on 3 Sep 2009 10:38 On 2009-09-03, Phil O. Sopher <invalid(a)invalid.invalid> wrote: > "Boudewijn Dijkstra" <boudewijn(a)indes.com> wrote in message > news:op.uzoduu0oy6p7a2(a)azrael.lan... >> >> People who are not comfortable with pointers haven't done enough assembly >> language programming. >> > > It is a mystery to me as to how recent graduates of Computer Science > are vaunted as experts on computers, yet haven't a clue about the actual > operation of a computer at the assembly language (or even machine code) > level. It's been that way for at least 25 years. I remembeber dealing with CS grads back in the mid 80s who had no clue about low-level stuff. They didn't know what a "register" was nor were they aware of how many CPUs used stacks for call/return linkage. -- Grant Edwards grante Yow! Am I in Milwaukee? at visi.com
From: Niklas Holsti on 3 Sep 2009 15:10 D Yuniskis wrote: > Hi Niklas, > > Niklas Holsti wrote: >> D Yuniskis wrote: >>> Andrew Reilly wrote: >>> ... >>>> When a similar discussion came up on Comp.arch last week, there was >>>> quite a bit of vocal support for both contemporary Ada and D, both >>>> of which are >>> >>> <groan> Stay away from Ada. It *really* doesn't seem worth the >>> effort! :< >> >> If that groan and warning are based on actual experience, rather than >> hearsay, it would be interesting to hear more about your reasons for >> saying so. > > Personal experience. The language is just too "big" and > clumsy. So you don't like it, and of course you have that right. (By the way, was your experience with the original Ada, the 1983 form that is, or the updates from 1995 or 2005? Quite a lot of flexibility and power have been added in the newer forms of the language.) > With good discipline, I think you can produce > applications that are as reliable as anything developed > under Ada *without* that burden. No doubt. But I like the help I get from Ada to observe that discipline. I'm fallible -- sometimes more, sometimes less, but rarely zero. Doing it in C feels like harder work. In addition, Ada gives me tools that C just doesn't have: modularity and encapsulation with packages, strong separation of interface and implementation for operations *and* data structures, run-time error checking (if I want it). > But, its a heavy price to pay for "everything" (and, > apparently, Industry seems to concur with that). Well, some industries use Ada, others don't. What was that saying about a billion flies :-) > [I wonder how long it would take to develop the iPhone if > it had been written in Ada? :-/ ] We will never know. But see below for some indications... > ... I.e., its just > an inconvenience that gets in your way. It may feel like that sometimes, but there are several reports that indicate that in the end Ada helps programmers, in several contexts. For example, John McCormick reports dramatically better results from students in a real-time programming course when they implemented a model-railroad system in Ada than in C. See http://www.sigada.org/conf/sigada99/proceedings/p111-mccormick.pdf. Pratt-Whitney compared its production of software for military jet engines (initially mandated to use Ada) and for commercial engines (initially using whatever they wanted). The Ada side had twice the productivity and one-fourth the number of errors. See http://www.adaic.com/atwork/pw.html. Ok, the commercial side used lots of assembly code. But according to this report, the government side of Pratt-Whitney is staying with Ada, although the "Ada mandate" has been lifted, so they could switch if they wanted to. Stephen Zeigler compared the effectiveness of C and Ada programming at Rational, a compiler and SW tool business (now part of IBM), as Rational was gradually switching from C to Ada. See http://archive.adaic.com/docs/present/ajpo/pll-cost/html/tsld058.htm. Some quotes: "Ada cost almost half of what the C code cost, and contained significantly fewer defects per 1000 SLOC by 7x the C code (700%). Even on the new C++ code, Ada still has 440% fewer defects." In fairness, there are also studies that suggest that the languages are about equally effective. See http://www.stsc.hill.af.mil/crosstalk/1996/07/quantify.asp. YMMV, sure. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Nobody on 3 Sep 2009 15:16 On Thu, 03 Sep 2009 11:28:23 +0100, Phil O. Sopher wrote: > It is a mystery to me as to how recent graduates of Computer Science > are vaunted as experts on computers, By whom? > yet haven't a clue about the actual > operation of a computer at the assembly language (or even machine code) > level. Academic CS seems quite happy to accept Dijkstra's maxim: "computer science is no more the study of computers than astronomy is the study of telescopes". Beyond that, there is a common view that a focus on low-level details can be harmful. In my experience, there is some justification for that view; e.g. I've seen experienced assembly-language programmers spend hours shaving clock cycles off the inner loop of an O(n^2) algorithm when a naive implementation of an O(n.log(n)) algorithm turned out to be significantly faster. I've seen the same programmers struggle as the industry has moved from a small number of large projects employing many programmers for years to millions of projects taking a single programmer a week. Once upon a time, embedded development wasn't all that much different to developing for larger systems. These days, they're completely different fields. The skills required for embedded development are more likely to be taught on an electronic engineering course than computer science. If you read the electronics groups, you'll find EEs complaining about current EE graduates understanding FPGAs and microcontrollers but not understanding the operation of a simple amplifier.
From: Niklas Holsti on 3 Sep 2009 15:30 I'll start by correcting a false impression I may have given: I definitely agree that a knowledge of assembly language and an insight into the machine level of computing are very useful and should be taught. I just wanted to point out that they are not *enough*, that some programming languages and computing tools use concepts that are so different from assembly language that there is no comparison. Phil O. Sopher wrote: > "Niklas Holsti" <niklas.holsti(a)tidorum.invalid> wrote in message > news:4a9fa556$0$6282$4f793bc4(a)news.tdc.fi... >> Phil O. Sopher wrote: >>> "Boudewijn Dijkstra" <boudewijn(a)indes.com> wrote in message >>> news:op.uzoduu0oy6p7a2(a)azrael.lan... >>>> People who are not comfortable with pointers haven't done enough >>>> assembly language programming. >>> Those of us who cut our teeth on assembly language find no difficulty >>> in understanding the concepts inherent in any high level language, even >>> those as arcane as LISP ("Lots of Infernal Stupid Parentheses") >> Hmm... I'll grant you Lisp, which in its basics has a close correspondence >> to machine-level structures and algorithms, > > No it doesn't, Does too :-) Even the basic functions "car" and "cdr" are named after, and originally depended on, the structure of a word or machine instruction in the computer on which the first Lisp was implemented ("car" = "choose address register", "cdr" = "choose data register", if I remember correctly). > but that's not relevant to my point which is that by > understanding > the fundamental operations of a machine it is but a small step to see how > those > fundamental operations are used to synthesize other machines. I agree that this understanding is important and helpful; even necessary if one wants to fully understand that there is nothing mysterious in the working of the higher-level machines such as the virtual or logical machines that define the semantics of imperative programming languages, even of high level languages. But... >> but what about Prolog? > > As for Lisp, above. No. The way a Prolog program works is so distant from the way assembly language works that the concepts of one are of no help in understanding the concepts of the other. Of course, in the end a Prolog program is executed by an assembly language (machine) program, but the connection between a given Prolog statement (rule) and the assembly instructions that implement such rules is very distant and not at all as simple as for an imperative language like C/C++/Ada/Lisp. For example, there are no assembly-level conceptc that correspond to a "free logical variable" or "matching of logical clauses", not even roughly. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Grant Edwards on 3 Sep 2009 16:07
On 2009-09-03, Niklas Holsti <niklas.holsti(a)tidorum.invalid> wrote: > Some quotes: "Ada cost almost half of what the C code cost, > and contained significantly fewer defects per 1000 SLOC by 7x > the C code (700%). Even on the new C++ code, Ada still has > 440% fewer defects." Huh? 440% fewer defects? Doesn't "100% fewer defects" mean zero defects? What does 440% fewer mean? -- Grant Edwards grante Yow! I want to read my new at poem about pork brains and visi.com outer space ... |