comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>
Subject: Re: Text_IO for other standard types
Date: 1998/01/15
Date: 1998-01-15T00:00:00+00:00	[thread overview]
Message-ID: <98011512220569@psavax.pwfl.com> (raw)


Jean-Pierre Rosen <rosen.adalog@WANADOO.FR> writes:
>NO, NO, NO, NEVER.
>One of the most important things in Ada teaching is to train people to
>design types according to the problem domain, and forget about predefined
>types. Forcing people to forget about Integer is in my experience one of the
>most difficult things.
>OTOH, teaching a total newcomer about type definitions, and about the fact
>that you cannot add apples and oranges is easy, easier than to an
>experienced programmer.
>
>More predefined types would be a help only if you teach Ada the same way
>that you teach other languages, and (IMHO) that's the last thing to do.
>
    I afraid I would have to respectfully disagree for a couple of
    different reasons.

    1) You already have *some* predefined types which pretty much get
    used the same way that predefined types in other languages are
    used. I need to get some relatively simple job done with no great
    concern for portability, etc., so I declare something to be of
    standard type Float or Integer. So what's wrong with a predefined
    Modular type or two which correspond in size to the predefined
    Integer types?

    2) While I would agree that the concept of data types and specific
    types for specific purposes (apples & oranges, as you say) is, in
    general, A Good Idea, there is such a thing as taking something
    too far. Not all programs are million line behemoths which will be
    maintained for dozens of years. Some are quite simple or may be
    just a training exercise where the concept might be to show how to
    build code to solve some equation where having to stop to explain
    the whole business of data type definitions might only distract
    you from the problem at hand.

    3) Not all students are CS majors who need to be steeped in the
    theoretical culture because they will be designing the future. In
    my particular case here at Pratt, I was busy trying to get a bunch
    of mechanical & electrical engineers up to some passing familiarity
    with Ada so that when they saw it they would have some
    understanding of it. These engineers have had some moderate level
    of exposure to programming with FORTRAN or Basic and might need to
    occasionally hack together a few lines of code to execute some
    control module or some other light duty job that must be done in
    an Ada environment. I need to communicate to these engineers that
    anything they can do in FORTRAN is just as easy and just as simple
    in Ada. These guys are just barely accepting of the notion that
    they should have to declare a variable before they use it. Forcing
    them to define the type in the interest of theoretical purity is
    only going to frustrate them more.

    (And, P.S.: Try explaining generic instantiation to a room full of
    non-programming engineers just so you can do simple I/O exercises
    with them and see how difficult this is! They generally instantly
    hate Text_IO because it isn't as simple as what they are used to
    and they really can't cope with generic instantiations of
    Float_IO, etc. The instantaneous reaction is: "All I wanted was a
    simple little program to compute 'Y := M * X + B" and print the
    result. Why do I need all this junk getting in my way?!?!?!" You
    don't win if you turn them off from wanting to have anything to do
    with the language.)

    4) Even with someone who is going to be a CS major, there is still
    a point where they are just starting out and getting them
    comfortable with the notion of a "variable" as a simple box in
    which to keep data, predefined types are very useful. Getting them
    familiar with Modular or Decimal arithmetic without involving type
    definitions can also be helpful because you are free to talk about
    how modular math works and not confuse things with how type
    definitions work or why you need them.

    So I guess that while I can agree with your opinion about type
    definitions being a very important concept, I'd have to disagree
    that every kind of student or every kind of application should be
    forced into doing this right from the get-go. Hence, this is why I
    would like to see more predefined types and predefined
    instantiations of the I/O routines. It's not hard to implement,
    other languages provide it, it isn't inconsistent with what has
    gone before and there are legitimate uses for it.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "I filled out an application that said, 'In Case Of Emergency
    Notify'. I wrote 'Doctor'... What's my mother going to do?"
        --  Steven Wright
=============================================================================




             reply	other threads:[~1998-01-15  0:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-01-15  0:00 Marin David Condic, 561.796.8997, M/S 731-96 [this message]
1998-01-15  0:00 ` Text_IO for other standard types Robert Dewar
1998-01-15  0:00 ` Robert Dewar
1998-01-16  0:00   ` Nick Roberts
1998-01-16  0:00     ` Robert Dewar
1998-01-17  0:00       ` Geert Bosch
1998-01-17  0:00         ` Robert Dewar
1998-01-15  0:00 ` Nick Roberts
1998-01-17  0:00 ` Jean-Pierre Rosen
1998-01-17  0:00   ` Robert Dewar
1998-01-18  0:00     ` Michael F Brenner
  -- strict thread matches above, loose matches on Subject: below --
1998-01-20  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-01-21  0:00 ` Jean-Pierre Rosen
1998-01-19  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-01-12  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-01-09  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-01-10  0:00 ` Tarjei T. Jensen
1998-01-10  0:00   ` Robert Dewar
1998-01-11  0:00     ` Tarjei T. Jensen
1998-01-11  0:00       ` Robert Dewar
1998-01-11  0:00       ` Robert Dewar
1998-01-12  0:00         ` Tarjei T. Jensen
1998-01-10  0:00 ` Nick Roberts
1998-01-11  0:00 ` Jean-Pierre Rosen
1998-01-14  0:00   ` Dale Stanbrough
1998-01-14  0:00     ` Robert Dewar
1998-01-14  0:00       ` Tarjei T. Jensen
1998-01-14  0:00         ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox