OO languages
in [Embedded]
|
Prev: AVR BASIC COMPILER source code released
Next: ATtiny10
From: Cesar Rabak on 3 Sep 2009 22:44 D Yuniskis escreveu: > cs_posting(a)hotmail.com wrote: >> What was interesting was that the other half the lab in which the >> freshmen were wearing out the () keys of a collection of apollos had >> juniors hand wiring modules into a 4 bit (or was it 8?) processor, >> that then software emulated a 32 bit one, at an effective clock rate >> of, oh, maybe a hz or two. So in a way it eventually did all tie >> together, but the lack of initial pragmatism was a little shocking to >> someone who had grown up with small micros. > > <grin> Try designing with *analog* computers (a project from > my high school days) :-/ For what reason? We have Matlab and Simulink for this today, don't we? :-D -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/
From: ArarghMail908NOSPAM on 4 Sep 2009 00:05 On Thu, 03 Sep 2009 17:53:48 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: <snip> >Yup. I can recall my first Pascal program to control a DataI/O >PROM programmer: I did that once. In a minicomputer Basic, with the I/O directed out the terminal Aux port to the Data I/O. That particular Basic had no HEX$ function, so I had to roll my own. I had to go look up just how it did it -- it's been quite a while since I wrote the program. :-) <snip> -- ArarghMail908 at [drop the 'http://www.' from ->] http://www.arargh.com BCET Basic Compiler Page: http://www.arargh.com/basic/index.html To reply by email, remove the extra stuff from the reply address.
From: Niklas Holsti on 4 Sep 2009 04:40 D Yuniskis wrote: > But, on other levels, it can bring with it all sorts > of invisible overhead that might be hard for someone not > intimately familiar with the language to pick up on. (e.g., > I am *constantly* startled by the presence of anonymous > objects that materialize in my code -- albeit of transitory > nature. As objects get "heavier" (e.g., adding debug support), > each one of these that the compiler creates starts to hammer > on memory... One of the several "restriction" pragmas that you can apply to an Ada program is No_Implicit_Heap_Allocation. This tells the compiler to complain about any code that would make the compiler allocate heap memory without an explicit "new" in the source code. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Bill Davy on 4 Sep 2009 04:51 "Niklas Holsti" <niklas.holsti(a)tidorum.invalid> wrote in message news:4aa014c1$0$24799$4f793bc4(a)news.tdc.fi... >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 > . @ . I wonder what "Ada still has 440% fewer defects" means. Or perhaps this is a defect? But if "7 times fewer" is called "700% fewer," then 440% means 4.4 times fewer. So it has 77% fewer errors. Does not sound so good. Programmers and those who would wield statistics should aim for clarity. There was someone who attended an astronomy lecture. During it, he thought he heard the lecturer say the sun would expand to engulf the world in 10M years. Afterwards he checked this with the lecturer. No, the lecturer said, it was 10B years. "Ah, that's OK then."
From: Niklas Holsti on 4 Sep 2009 05:26
D Yuniskis wrote: > Ada limits the size > of the problem that you can practically solve and the > hardware on which you can solve it. E.g., are you > going to design a control system for a microwave oven > on a little 8 (or even *4*!) bit processor in Ada? The size of the language does not exclude small target systems. You can enjoy the static compile-time strengths of the "large" language with no or minor impact on the size of the target code. Of course, you have to limit your use of features that require run-time support, but that's true of all languages -- libraries take space. I have used Ada on projects for 16-bit computers (1750) with 64 kW of memory, and the run-time overhead from the "large" language was very minor. The language also helps you with small systems. It lets you define the size of your variables and lets you pack structure components in the minimum number of bits. You can do some of that in C, but not all of it. > Are you going to find a compiler vendor who will support > "that" processor? The GNU Ada compiler is available for the 8-bit AVR. http://www.adacore.com/home/products/gnatpro/supported_platforms/. The SofCheck AdaMagic compiler emits C code, so if your processor has a good C compiler, you are OK. http://www.sofcheck.com/products/adamagic.html. > I find the bigger bang (nowadays, with larger projects) is to > put the effort into the OS. Let *it* serve as a safety net > for the developer, etc. And, let it enhance the programming > environment so the developer can call on richer subsystems > to offload some problems at run-time that he would have to > solve himself, otherwise. Well, that can be a good approach, whatever your programming language. It seems an orthogonal thing to me. >>> ... 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. > > Yes, but note that almost all of these are larger projects > [included below for context] with large development staffs > on "off the shelf hardware" (i.e., where the hardware was > chosen as a consequence of the software requirements and > not the other way around) True, except for the model railroad projects. But small projects don't generate such statistics, and I suspect that skeptics would find it even easier to dismiss small-project statistics out of hand as insignificant. > I'd be more impressed if google/nokia had claimed that they had > developed the iPhone using Ada (etc.) Yes, that would have been nice. But saying that "X cannot be good, because Y is not using X" is a vicious-circle argument, at best. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . |