Ada featured in Doctor Dobb's Journal

Ada featured in Doctor Dobb's Journal

[Ludovic Brenta]

An opinion piece from Joachim Schüeth, the winner of the British
National Museum of Computing's Colossus Cipher Challenge.

http://www.ddj.com/architect/207800151

--
Ludovic Brenta.

Re: Ada featured in Doctor Dobb's Journal

[Mike Silva]

On May 16, 6:56 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> An opinion piece from Joachim Schüeth, the winner of the British
> National Museum of Computing's Colossus Cipher Challenge.
>
> http://www.ddj.com/architect/207800151
>
> --
> Ludovic Brenta.

Good stuff.  Another statement of what I have read here so often, that
Ada is very good at letting one model the problem space rather than
having to work backwards from the solution space.

Mike

Re: Ada featured in Doctor Dobb's Journal

[Ludovic Brenta]

Mike Silva wrote:
> Ludovic Brenta wrote:
> > An opinion piece from Joachim Schueth, the winner of the British
> > National Museum of Computing's Colossus Cipher Challenge.
> >
> > http://www.ddj.com/architect/207800151
>
> Good stuff.  Another statement of what I have read here so often, that
> Ada is very good at letting one model the problem space rather than
> having to work backwards from the solution space.

Aye. The article has been slashdotted, too, and there are surprisingly
few bad comments so far. And I'm apparently not the only one believing
in an upsurge in the use of Ada. Way to go.

--
Ludovic Brenta.

Re: Ada featured in Doctor Dobb's Journal

[Mike Silva]

On May 16, 9:04 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Mike Silva wrote:
> > Ludovic Brenta wrote:
> > > An opinion piece from Joachim Schueth, the winner of the British
> > > National Museum of Computing's Colossus Cipher Challenge.
>
> > >http://www.ddj.com/architect/207800151
>
> > Good stuff.  Another statement of what I have read here so often, that
> > Ada is very good at letting one model the problem space rather than
> > having to work backwards from the solution space.
>
> Aye. The article has been slashdotted, too, and there are surprisingly
> few bad comments so far. And I'm apparently not the only one believing
> in an upsurge in the use of Ada. Way to go.
>
> --
> Ludovic Brenta.

I picked up these links from the slashdot discussion

http://www.netbsd.org/gallery/schueth-interview.html
http://www.adacore.com/home/ada_answers/lorenz-code/

The Adacore article is essentially a rehash of the Ada-specific parts
of the Dr. Dobbs one.

Re: Ada featured in Doctor Dobb's Journal

[Randy Brukardt]

Mike Silva wrote:
> I picked up these links from the slashdot discussion
>
> http://www.netbsd.org/gallery/schueth-interview.html
> http://www.adacore.com/home/ada_answers/lorenz-code/
>
> The Adacore article is essentially a rehash of the Ada-specific parts
> of the Dr. Dobbs one.

You could have picked them up from the AdaIC page on this:
   http://www.adaic.com/news/crypto.html
where they have been linked for months (Janurary 31st, to be exact). And 
those articles were pretty old when I found them and posted them there (the 
page itself dates back to November, when the original contest came out). DDJ 
is pretty late to the party (but of course it gets wider distribution than 
the older sources).

                                    Randy.

rant (Re: Ada featured in Doctor Dobb's Journal )

[jhc0033]

On May 16, 5:28 am, Mike Silva <snarflem...@yahoo.com> wrote:
> On May 16, 6:56 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > An opinion piece from Joachim Schüeth, the winner of the British
> > National Museum of Computing's Colossus Cipher Challenge.
>
> >http://www.ddj.com/architect/207800151
>
> > --
> > Ludovic Brenta.
>
> Good stuff.  Another statement of what I have read here so often, that
> Ada is very good at letting one model the problem space rather than
> having to work backwards from the solution space.
>
> Mike

People more familiar with language X than Y find that they spend less
time thinking about the language when programming in X rather than Y.

Personally, I'd find the article more interesting if the main
character was, say, a competent C++ programmer (the kind that
understands destructor semantics, etc., uses STL containers throughout
and Boost where suitable), and having switched to Ada (or the other
way around) had something interesting to say.

Right now, the article basically says: "Fortran had some cool features
C didn't have, but C had some features Fortran didn't have, and we
switched to C. But this guy uses Ada, because as we saw before, using
different languages is OK, and the safety community uses it. He solved
some discrete math problem he was trying to solve. He could have
solved it just as easily in any other language perhaps, but would we
write an article about it? The end".

Right now, I'm evaluating Ada as a language to learn and do my next
project in. I already know more diverse non-mainstream languages than
most people, so I'm not exactly closed-minded. But this article hasn't
convinced me of anything.

A few days ago, I looked at Eiffel, and I'm now convinced that I
wouldn't like it. Eiffel targets a largely similar audience of
"correctness-oriented" programmers that Ada does. However, it took
some digging around (no introductions to the language mention it) to
discover that Eiffel has a gap in its type system. Guess what, type
theory is a branch of math, and OOP is a spiritual following. I know
what takes precedence in my book. The Eiffel community's attitude is
basically: "we'll just pretend 2+2=5 because we can use it to justify
some teachings".

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Ludovic Brenta]

jhc0033@gmail.com writes:
> Right now, the article basically says: "Fortran had some cool features
> C didn't have, but C had some features Fortran didn't have, and we
> switched to C. But this guy uses Ada, because as we saw before, using
> different languages is OK, and the safety community uses it. He solved
> some discrete math problem he was trying to solve. He could have
> solved it just as easily in any other language perhaps, but would we
            ^^^^^^^^^^^^^^
> write an article about it? The end".

The whole point of the article is the "just as easily" bit.  The
author says that he solved his problem *more easily* in Ada than he
could have in C or Fortran, despite his extensive experience (11 years
as a professional) in C and little exposure (6 months as a hobbyist)
to Ada.

> Right now, I'm evaluating Ada as a language to learn and do my next
> project in. I already know more diverse non-mainstream languages
> than most people, so I'm not exactly closed-minded. But this article
> hasn't convinced me of anything.

I commend you for your open-mindedness and your sound process of
evaluating before deciding.  Few people indeed have enough common
sense to do that.  The article does not speak about C++.  If what you
want is a comparison of C++ versus Ada, look elsewhere, like
e.g. http://archive.adaic.com/docs/present/engle/comments/

> A few days ago, I looked at Eiffel, and I'm now convinced that I
> wouldn't like it. Eiffel targets a largely similar audience of
> "correctness-oriented" programmers that Ada does. However, it took
> some digging around (no introductions to the language mention it) to
> discover that Eiffel has a gap in its type system. Guess what, type
> theory is a branch of math, and OOP is a spiritual following. I know
> what takes precedence in my book. The Eiffel community's attitude is
> basically: "we'll just pretend 2+2=5 because we can use it to
> justify some teachings".

I evaluated Eiffel too when I read Bertrand Meyer's Object-Oriented
Software Construction book.  The two things I dislike the most about
Eiffel are the lack of range constraints on numeric types and the fact
that almost all contract checks are deferred to run-time.  I strongly
prefer compile-time checks over run-time checks, and a language with
no checks at all quickly disappears from my radar.

-- 
Ludovic Brenta.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Dmitry A. Kazakov]

On Sat, 17 May 2008 10:28:06 +0200, Ludovic Brenta wrote:

> I strongly prefer compile-time checks over run-time checks,

Yes, actually contract checks have to be strictly static. A check failed at
run-time has no option but to terminate the program. Otherwise, it was not
contract check. Exception propagation is a part of the contract.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Sat, 17 May 2008 10:28:06 +0200, Ludovic Brenta wrote:
> 
>> I strongly prefer compile-time checks over run-time checks,
> 
> Yes, actually contract checks have to be strictly static.

I think there is a HALTing problem here.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Dmitry A. Kazakov]

On Sat, 17 May 2008 11:56:33 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 17 May 2008 10:28:06 +0200, Ludovic Brenta wrote:
>> 
>>> I strongly prefer compile-time checks over run-time checks,
>> 
>> Yes, actually contract checks have to be strictly static.
> 
> I think there is a HALTing problem here.

You mean that checking is undecidable? Yes, this is BTW independent on when
you check. But self-correctness checks are worse that undecidable, they are
inconsistent. Consider

require True;
function X return Boolean is
begin
   if Correct (X) then
      return False;
   else
      return True;
   end if;
end X;
ensure
   (return = False and Correct (X))
or
   (return = True and not Correct (X));

So

   Correct (X) =
= (require => ensure)
= ensure

But these are not equal, let result = True

   Correct (X) = not Correct (X)

So it is better to check what is possible either at compile time, or maybe
by another program at run-time. In either case, there is no way to continue
if a check fails. You continue either the source editor, or the supervising
program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[jhc0033]

On May 17, 1:28 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> If what you
> want is a comparison of C++ versus Ada, look elsewhere, like
> e.g.http://archive.adaic.com/docs/present/engle/comments/

Actually, that's terrible. Some figures without context, quoting some
judges-assigned scores using uncertain criteria, comparing to C++ from
as early as 1991! (C++ as we use it today is about 10 years old) Some
factual statements are incorrect (like C++ does have namespaces -
perhaps it didn't back then)

Still, what struck me is that the author doesn't recommend Ada for R&D
or anything that won't be "fielded". And if C++ was better for R&D in
the 90s... Is this the general consensus?

Anyway, I found this: http://www.ddj.com/184409641
which looks reasonable, but I haven't read it yet.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Ludovic Brenta]

jhc0033 writes:
> Ludovic Brenta wrote:
>> If what you want is a comparison of C++ versus Ada, look elsewhere,
>> like e.g.http://archive.adaic.com/docs/present/engle/comments/
>
> Actually, that's terrible. Some figures without context, quoting some
> judges-assigned scores using uncertain criteria, comparing to C++ from
> as early as 1991! (C++ as we use it today is about 10 years old) Some
> factual statements are incorrect (like C++ does have namespaces -
> perhaps it didn't back then)

Indeed, it didn't back then.

> Still, what struck me is that the author doesn't recommend Ada for R&D
> or anything that won't be "fielded". And if C++ was better for R&D in
> the 90s... Is this the general consensus?

Where did you see the author saying C++ was better for R&D than Ada?
Skimming through the document I only see
http://archive.adaic.com/docs/present/engle/comments/tsld032.htm where
the author basically says Ada is not for quick and dirty hacks, which
is true.  But that doesn't make C++ suitable for those either.  I
think he rather had scripting languages like Perl in mind.

Anyway, since you're evaluating languages for your next project, you
should not take anyone's word as gospel; you should experiment and
decide for yourself (only lemmings listen to "analysts" and "market
researchers", right?).  I'd be interested in learning about your
findings.

-- 
Ludovic Brenta.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[jhc0033]

On May 17, 4:49 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> jhc0033 writes:
> > Ludovic Brenta wrote:
> >> If what you want is a comparison of C++ versus Ada, look elsewhere,
> >> like e.g.http://archive.adaic.com/docs/present/engle/comments/
>
> > Actually, that's terrible. Some figures without context, quoting some
> > judges-assigned scores using uncertain criteria, comparing to C++ from
> > as early as 1991! (C++ as we use it today is about 10 years old) Some
> > factual statements are incorrect (like C++ does have namespaces -
> > perhaps it didn't back then)
>
> Indeed, it didn't back then.
>
> > Still, what struck me is that the author doesn't recommend Ada for R&D
> > or anything that won't be "fielded". And if C++ was better for R&D in
> > the 90s... Is this the general consensus?
>
> Where did you see the author saying C++ was better for R&D than Ada?
> Skimming through the document I only seehttp://archive.adaic.com/docs/present/engle/comments/tsld032.htmwhere
> the author basically says Ada is not for quick and dirty hacks, which
> is true.

Pasting the slide here:

====================================
Ada may not be appropriate

    - When some other language has lower lifecycle costs
    - For some R&D applications where the intent is for concept
development only and the system will not be fielded
    - For some prototype applications, however the prototype must not
be carried into E&D for subsequent fielding
    - When a compiler does not exist for the hardware platform
    - When timing and/or sizing constraints make Ada a technical
infeasibility
====================================

So he specifically mentions R&D with no "fielding", where "fielding"
is probably where people's lives depend on it, in the context of DoD.

> But that doesn't make C++ suitable for those either.  I
> think he rather had scripting languages like Perl in mind.

I don't think that makes sense in his context and time. The whole
comparison was C++ vs Ada. Why suddenly assume he meant some other
language on this particular slide?

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Ludovic Brenta]

jhc0033 writes:
>> But that doesn't make C++ suitable for those either.  I think he
>> rather had scripting languages like Perl in mind.
>
> I don't think that makes sense in his context and time. The whole
> comparison was C++ vs Ada.

No, you are wrong.  The presentation contains several comparisons of
Ada with several other languages besides C++ (including COBOL,
Fortran, Pascal, Eiffel and C).

> Why suddenly assume he meant some other language on this particular
> slide?

Because this is a presentation about why Ada is better than all
alternatives considered, not a presentation about C++.  Because slide
http://archive.adaic.com/docs/present/engle/comments/tsld018.htm lists
only variants of the "lemming argument" to explain why anyone would
want to use C++.  Because the last 10 slides or so are all in praise
and support of Ada.

The author does not specifically say which language he would recommend
for prototyping.  I know I would personally recommend Ada.

-- 
Ludovic Brenta.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[jhc0033]

On May 17, 4:21 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> jhc0033 writes:
> >> But that doesn't make C++ suitable for those either.  I think he
> >> rather had scripting languages like Perl in mind.
>
> > I don't think that makes sense in his context and time. The whole
> > comparison was C++ vs Ada.
>
> No, you are wrong.  The presentation contains several comparisons of
> Ada with several other languages besides C++ (including COBOL,
> Fortran, Pascal, Eiffel and C).

... very much in passing. Almost all of the presentation is about Ada
vs C++.

Anyway, it doesn't matter what better alternatives to Ada he had in
mind for R&D.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Dr. Adrian Wrigley]

On Sun, 18 May 2008 01:21:57 +0200, Ludovic Brenta wrote:

> jhc0033 writes:
>>> But that doesn't make C++ suitable for those either.  I think he
>>> rather had scripting languages like Perl in mind.
>>
>> I don't think that makes sense in his context and time. The whole
>> comparison was C++ vs Ada.
> 
> No, you are wrong.  The presentation contains several comparisons of
> Ada with several other languages besides C++ (including COBOL,
> Fortran, Pascal, Eiffel and C).
> 
>> Why suddenly assume he meant some other language on this particular
>> slide?
> 
> Because this is a presentation about why Ada is better than all
> alternatives considered, not a presentation about C++.  Because slide
> http://archive.adaic.com/docs/present/engle/comments/tsld018.htm lists
> only variants of the "lemming argument" to explain why anyone would
> want to use C++.  Because the last 10 slides or so are all in praise
> and support of Ada.
> 
> The author does not specifically say which language he would recommend
> for prototyping.  I know I would personally recommend Ada.

I think Ada is great for prototyping too.

Often, the code is in great flux when prototyping, and the Ada features
really work in your favor by ensuring consistency and catching the
mistakes early.

For very prototyping simple projects, scripting languages are fast,
but errors and inconsistencies creep in quickly.  The code tends not
to last as long because of inflexibility (poor/missing structuring tools
such as packages and generics in scripting).
--
Adrian

Prototyping with Ada (was: Ada featured in Doctor Dobb's Journal)

[Ludovic Brenta]

Dr. Adrian Wrigley writes
> I think Ada is great for prototyping too.
>
> Often, the code is in great flux when prototyping, and the Ada features
> really work in your favor by ensuring consistency and catching the
> mistakes early.
>
> For very prototyping simple projects, scripting languages are fast,
> but errors and inconsistencies creep in quickly.  The code tends not
> to last as long because of inflexibility (poor/missing structuring tools
> such as packages and generics in scripting).

I agree.  I would even go so far as to say there is no such thing as
software prototyping.  A prototype is something complex you make
before mass-producing some sort of physical good, because it is very
difficult to change the physical system after you've made it, should
you find any problems.  By definition, you know you're going to throw
the prototype away at some point.

The opposite is true for software.  If you build a prototype, you can
always fix problems in it.  And once there are no more problems, the
prototpye is the "real" software, and you don't throw anything away.
Which means the "prototype" you thought you made was not a prototype
after all; just an early and evolving version of the "real" software.

-- 
Ludovic Brenta.

Re: Prototyping with Ada (was: Ada featured in Doctor Dobb's Journal)

[John McCabe]

On Sun, 18 May 2008 10:04:17 +0200, Ludovic Brenta
<ludovic@ludovic-brenta.org> wrote:

>> For very prototyping simple projects, scripting languages are fast,
>> but errors and inconsistencies creep in quickly.  The code tends not
>> to last as long because of inflexibility (poor/missing structuring tools
>> such as packages and generics in scripting).

>I agree.  I would even go so far as to say there is no such thing as
>software prototyping.  A prototype is something complex you make
>before mass-producing some sort of physical good, because it is very
>difficult to change the physical system after you've made it, should
>you find any problems.  By definition, you know you're going to throw
>the prototype away at some point.
>
>The opposite is true for software.  If you build a prototype, you can
>always fix problems in it.  And once there are no more problems, the
>prototpye is the "real" software, and you don't throw anything away.

Ah, but this is one of the reasons there is so much poor quality
software around! If you do it right, a prototype should give you an
idea of how you are going to approach a solution, and should show up
certain features or situations that you need to handle, or avoid in
order to make that solution appropriate, reliable and acceptable.

Thus you need to plan for the prototype to be thrown away, because
then you start again taking into account the lessons you learned from
the protoyping exercise.

Of course, if there is some self-contained code that can be re-used,
e.g. a particularly complicated algorithm in its own little "space",
then it is reasonable to do so, as long as you make it more reliable
and so on in the process.

If you approach the whole thing from the point of view you describe,
then you're just taking what may be poor quality code and making it a
bit better, which doesn't necessarily make the code (or design!) good.

Re: Prototyping with Ada

[Jeffrey R. Carter]

John McCabe wrote:
> 
> Thus you need to plan for the prototype to be thrown away, because
> then you start again taking into account the lessons you learned from
> the protoyping exercise.

Brooks, 1975: Plan to throw one away. This is accepted practice in HW. The fact 
that so few developers and managers understand that this applies equally to SW 
is a big part of the reason so much SW is poor quality.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: Prototyping with Ada

[Mike Silva]

On May 20, 12:57 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> John McCabe wrote:
>
> > Thus you need to plan for the prototype to be thrown away, because
> > then you start again taking into account the lessons you learned from
> > the protoyping exercise.
>
> Brooks, 1975: Plan to throw one away. This is accepted practice in HW. The fact
> that so few developers and managers understand that this applies equally to SW
> is a big part of the reason so much SW is poor quality.

Right.  I learned this lesson the hard way (learned it more than once,
in fact).  Now I just plan for it and things go so much better.
Software is not infinitely malleable, and at some point you end up
inserting new errors for every error you are removing, or every
feature you are adding or changing.  And then, depending on your
company culture (or your personal standards), you either throw it away
or ship it.

Mike

Re: Prototyping with Ada

[Peter C. Chapin]

Jeffrey R. Carter wrote:

> Brooks, 1975: Plan to throw one away. This is accepted practice in HW.

Is this really true? I don't see the people building large office 
buildings throwing one away.

Peter

Re: Prototyping with Ada

[Mike Silva]

On May 20, 1:37 pm, "Peter C. Chapin" <pcha...@sover.net> wrote:
> Jeffrey R. Carter wrote:
> > Brooks, 1975: Plan to throw one away. This is accepted practice in HW.
>
> Is this really true? I don't see the people building large office
> buildings throwing one away.
>
Brooks uses the analogy of a new chemical process where they will
first build a pilot plant before building the full-scale plant.  Lots
of cutting edge stuff starts with a proof-of-concept unit.

Not being an expert by any means, I'd say most office buildings are,
at the engineering level, like most other office buildings.  When they
deviate too much then big problems do creep in.
http://www-tech.mit.edu/V127/N53/lawsuit.html

Re: Prototyping with Ada

[Jeffrey R. Carter]

Peter C. Chapin wrote:
> 
> Is this really true? I don't see the people building large office 
> buildings throwing one away.

Are large office buildings HW? Can I get a compiler that targets them?

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: Prototyping with Ada

[Martin Krischik]

Peter C. Chapin schrieb:
> Jeffrey R. Carter wrote:
> 
>> Brooks, 1975: Plan to throw one away. This is accepted practice in HW.
> 
> Is this really true? I don't see the people building large office 
> buildings throwing one away.

Not for office building - for example for nuclear power plants. Just 
check how many "test" reactors are out there.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Prototyping with Ada

[Stephen Leake]

John McCabe <john@nospam.assen.demon.co.uk> writes:

> On Sun, 18 May 2008 10:04:17 +0200, Ludovic Brenta
> <ludovic@ludovic-brenta.org> wrote:
>
>>> For very prototyping simple projects, scripting languages are fast,
>>> but errors and inconsistencies creep in quickly.  The code tends not
>>> to last as long because of inflexibility (poor/missing structuring tools
>>> such as packages and generics in scripting).
>
>>I agree.  I would even go so far as to say there is no such thing as
>>software prototyping.  A prototype is something complex you make
>>before mass-producing some sort of physical good, because it is very
>>difficult to change the physical system after you've made it, should
>>you find any problems.  By definition, you know you're going to throw
>>the prototype away at some point.
>>
>>The opposite is true for software.  If you build a prototype, you can
>>always fix problems in it.  And once there are no more problems, the
>>prototpye is the "real" software, and you don't throw anything away.
>
> Ah, but this is one of the reasons there is so much poor quality
> software around! If you do it right, a prototype should give you an
> idea of how you are going to approach a solution, and should show up
> certain features or situations that you need to handle, or avoid in
> order to make that solution appropriate, reliable and acceptable.
>
> Thus you need to plan for the prototype to be thrown away, because
> then you start again taking into account the lessons you learned from
> the protoyping exercise.
>
> Of course, if there is some self-contained code that can be re-used,
> e.g. a particularly complicated algorithm in its own little "space",
> then it is reasonable to do so, as long as you make it more reliable
> and so on in the process.
>
> If you approach the whole thing from the point of view you describe,
> then you're just taking what may be poor quality code and making it a
> bit better, which doesn't necessarily make the code (or design!) good.

If you do refactoring right, you can incrementally improve the quality
of code.

I think there is a spectrum here; "gross refactoring" is simply
throwing away huge chunks of code and starting over for those; "fine
refactoring" is tinkering with a few lines here and there. Anything
inbetween is possible, and can be useful.

I prefer prototyping with Ada; the compiler finds bugs for me, and
with GNAT and Emacs on current hardware, the compile/edit/run cycle is
very fast.

I have to use Matlab for part of my current job, because another part
of the project uses it. The lack of software engineering in that
language is glaring, and my productivity (in something approximating
"implemented features per day") is much lower in Matlab than in Ada.
That's partly because I can't figure out how to run Matlab from the
command line under Emacs (on Windows), and the Matlab GUI is just not
as powerful as Emacs.

-- 
-- Stephe

Re: Prototyping with Ada

[John McCabe]

On Thu, 22 May 2008 04:43:19 -0400, Stephen Leake
<Stephe.Leake@nasa.gov> wrote:

>John McCabe <john@nospam.assen.demon.co.uk> writes:
>

>> If you approach the whole thing from the point of view you describe,
>> then you're just taking what may be poor quality code and making it a
>> bit better, which doesn't necessarily make the code (or design!) good.
>
>If you do refactoring right, you can incrementally improve the quality
>of code.

Code quality, yes (but your use of the term "right" is very
important!). It is much more difficult to refactor an inadequate
design at that point.

Re: Prototyping with Ada

[Ludovic Brenta]

John McCabe wrote:
> Code quality, yes (but your use of the term "right" is very
> important!). It is much more difficult to refactor an inadequate
> design at that point.

I agree that if the design is bad, it might be better to throw the
program away (perhaps salvaging some reusable components) and start
from scratch than to refactor. But that shouldn't be what you plan
for.  If you think you need a prototype, chances are you are unsure
about the quality of your design. If that happens to me, I don't make
a "protoype"; instead, I go back to the drawing board and seek a
second opinion.

--
Ludovic Brenta.

Re: Prototyping with Ada

[tmoran]

> If you think you need a prototype, chances are you are unsure
> about the quality of your design.
  As soon as the end user says "Oh, it would actually be better if it
worked this other way" your careful design is in danger.  And these days,
when so much of "programming" consists of finding and and applying various
libraries, bindings, etc, as soon as the library module turns out to act
in a substantially different way than you were led to expect, your
careful design is again in danger.

Re: Prototyping with Ada

[John McCabe]

On Wed, 28 May 2008 05:12:12 -0700 (PDT), Ludovic Brenta
<ludovic@ludovic-brenta.org> wrote:

>John McCabe wrote:
>> Code quality, yes (but your use of the term "right" is very
>> important!). It is much more difficult to refactor an inadequate
>> design at that point.
>
>I agree that if the design is bad, it might be better to throw the
>program away (perhaps salvaging some reusable components) and start
>from scratch than to refactor. But that shouldn't be what you plan
>for.  If you think you need a prototype, chances are you are unsure
>about the quality of your design.

That all depends on what is meant by quality here. Prototyping has
many purposes, one of those is to prove a design will work. If you
don't need to prove your design will work then the chances are that
you are designing something you've done before and therefore don't
need to design again, or you are superhuman. In this paragraph I'm
referring to the structural and behavioural design you have come up
with.

In addition prototyping allows you to quickly provide a mock-up of a
system to present to a customer to validate that what you are doing is
the right thing. Once you've got a very basic design in place you can
start knocking code up to do this, but it's important to remember that
this code is only there to prove something. It's not intended to be
good quality code, it also might deviate from how your design started,
but this is all about iterating to achieve the correct design in the
end, and this needs to take into account what you've learned from
trying to produce code to do the job. In most cases you will have
cobbled together the code jsut to make it work; at the protoyping
stage refactoring the code properly isn't often something you have
time to do and, in my opinion, isn't something you should attempt.
That is the point; build a prototype, learn from it, and throw it away
because your second attempt will probably be better (that's another
Brooks thing isn't it?)

> If that happens to me, I don't make
>a "protoype"; instead, I go back to the drawing board and seek a
>second opinion.

It sounds to me like you're trying to achieve a perfect waterfall
development cycle here.

Re: Prototyping with Ada

[Stephen Leake]

John McCabe <john@nospam.assen.demon.co.uk> writes:

> On Thu, 22 May 2008 04:43:19 -0400, Stephen Leake
> <Stephe.Leake@nasa.gov> wrote:
>
>>John McCabe <john@nospam.assen.demon.co.uk> writes:
>>
>
>>> If you approach the whole thing from the point of view you describe,
>>> then you're just taking what may be poor quality code and making it a
>>> bit better, which doesn't necessarily make the code (or design!) good.
>>
>>If you do refactoring right, you can incrementally improve the quality
>>of code.
>
> Code quality, yes (but your use of the term "right" is very
> important!). It is much more difficult to refactor an inadequate
> design at that point.

I refactor to change design all the time. Since I right good code in
the first place, that's pretty much the _only_ reason I refactor :).
Some people include "change design" in the definition of "refactor".

Changing the basic architecture (say from monolithic program on one
computer to networked client/server, or from non-real-time to
real-time) is not something you can typically do via refactoring. But
changing lower-level design is possible.

Ada is a very good language for expressing design (much better than
UML!). It also happens to be executable; that's just a side benefit
:).

-- 
-- Stephe

Re: Prototyping with Ada

[Britt Snodgrass]

On May 31, 1:03 am, Stephen Leake <Stephe.Le...@nasa.gov> wrote:
>
> Ada is a very good language for expressing design (much better thanUML!). It also happens to be executable; that's just a side benefit
> :).

I generally agree. See http://developers.slashdot.org/article.pl?sid=08/05/31/1726208
for a discussion titled 'Is UML Really Dead, Or Only Cataleptic?"

However I've been using Telelogic's Rhapsody "Developer in Ada" Tool
for the last year and generally liking it as a large project design
tool.  Some aspects of UML & SysML are useful but some of the concepts
and terminology don't either map well to Ada, or are otherwise
insufficient.  Wish I had more time to write on this topic but I
don't...

- Britt

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Georg Bauhaus]

jhc0033@gmail.com wrote:

> But this guy uses Ada, because as we saw before, using
> different languages is OK, and the safety community uses it. He solved
> some discrete math problem he was trying to solve.

I think you've missed a piece that other newcomers to Ada have
reported, too, has helped them:
That the language almost automatically makes you think about how
to model objects as types even at the lowest possible level, i.e.
at the bits level; where you would be used to "machine types"
like int, float, double etc. you start using abstraction, i.e.
named numeric types, etc, without run-time overhead, but with
static type checks. Plus, you can build other types around different
named numeric types and get statically type checked operations at
a low level, e.g.

procedure News13 is

-- 4-space:

    type Enough_Precision is digits 11;  -- fpt for my algorithm
    type Index_Type is range 0 .. 3;  -- need 4-tuples
    type T4 is array(Index_Type) of Enough_Precision;
    pragma Convention(Fortran, T4);  -- can pass to Fortran

    type Count_Type is range 0 .. 1_000;  -- num of measurements
    type Fruit is (Banana, Apple, Pear);

    point_in_space: T4;
    c: Count_Type;
begin
    c := 4;
    point_in_space(c) := 1.0;  -- won't compile, c not in Index_Type
    point_in_space(4) := 1.0;  -- index constraint violation diagnosed
    point_in_space(Banana) := 1.0; -- error, Banana ∉ Index_Type

end News13;

> He could have
> solved it just as easily in any other language perhaps, but would we
> write an article about it? The end".

Perhaps, but then he says that his solution has been easier than
what he did before because he could do low level programming
yet write "wheels" abstractions.

Re: rant (Re: Ada featured in Doctor Dobb's Journal )

[Mike Silva]

On May 17, 2:30 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
> On May 16, 5:28 am, Mike Silva <snarflem...@yahoo.com> wrote:
>
> > On May 16, 6:56 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > > An opinion piece from Joachim Schüeth, the winner of the British
> > > National Museum of Computing's Colossus Cipher Challenge.
>
> > >http://www.ddj.com/architect/207800151
>
> > > --
> > > Ludovic Brenta.
>
> > Good stuff.  Another statement of what I have read here so often, that
> > Ada is very good at letting one model the problem space rather than
> > having to work backwards from the solution space.
>
> > Mike
>
> People more familiar with language X than Y find that they spend less
> time thinking about the language when programming in X rather than Y.

But if anything the article suggests that, while more familiar with
language X (16 years) than language Y (1/2 year), he spent less time
thinking about the language when programming in _Y_ rather than _X_.
I don't see how you can possibly come to the conclusion you state from
the article.
>
> Right now, the article basically says: "Fortran had some cool features
> C didn't have, but C had some features Fortran didn't have, and we
> switched to C. But this guy uses Ada, because as we saw before, using
> different languages is OK, and the safety community uses it. He solved
> some discrete math problem he was trying to solve. He could have
> solved it just as easily in any other language perhaps, but would we
> write an article about it? The end".

If he could have solved it just as easily in any other language, why
would he write about being pleasantly surprised at the features in Ada
that allowed him to write his software in two months even though he
was only a novice in the language?  There is just no way you can
represent from the text of the article that the author's key point was
"I could have solved this problem just as easily in any other
language."

Mike

re: rant (Re: Ada featured in Doctor Dobb's Journal )

[tmoran]

>People more familiar with language X than Y find that they spend less
>time thinking about the language when programming in X rather than Y.
  I find that I spend relatively little time deciding on data structures
or algorithms or how to express something in the programming language.
Most time is actually spent finding out what various devices, OS calls, or
SDK calls actually do.  Even when the documentation exists and answers the
question, it often lies, so a lot of experiment time is required.

Re: Ada featured in Doctor Dobb's Journal

[Ivan Levashew]

Ludovic Brenta пишет:
> http://www.ddj.com/architect/207800151

> I had not expected to find in Ada all the features of a modern 
> programming language.

I recently discovered talks about IoC/DI in yet-another-holywar. Wonder 
what does IoC/DI stand for? Inversion of Control / Dependency Injection. 
What a cool words indeed! Inversion, injection. After digging through 
http://martinfowler.com/articles/injection.html I realized that 
technically DI is what access discriminants (Ada 95) were designed for.

-- 
If you want to get to the top, you have to start at the bottom