comp.lang.ada
 help / color / mirror / Atom feed
* INFO-ADA Digest V92 #299
@ 1992-09-09 14:57 BUSHMAN
  0 siblings, 0 replies; 5+ messages in thread
From: BUSHMAN @ 1992-09-09 14:57 UTC (permalink / raw)


In response to Scott Kramer's question (V92 #299):
 
Scott,
 
    You asked what good Ada experience would get you.  First off, if you are
wanting to stay in the accounting field, but want to have the computer
knowledge as well, Unix will help.  Many large systems are using Unix.  This
will definately be of some value. However, I have worked in Ada for about
three years and the programming field for six, and I don't think that Ada
itself will do you much good as an accountant. Don't get me wrong, Ada is a
good language. What the prior advice that you quoted was probably trying to
tell you is that programming experience will help. The problem with is Ada is
that it is a very large language and so far, the main user of Ada is the U.S.
Government, especially the DOD. There are many other groups out there using
Ada, but its use is not nearly as common as other languages that you would
probably be more apt to use in your field (like COBOL, unfortunately).
 
    As far as getting some programming experience, there are litterally
hundreds of languages out there.  Ada is only a well known one.  As I stated
in the last paragraph, Ada is a very large language.  For someone wanting to
get some programming experience, as your first language to tackle, Ada would
be much harder to learn than others, such as COBOL.  When learning how to
swim, do you start by jumping in the middle of the lake and hope you survive
to the shore?  Probably not.  And the same holds true for programming.  Start
with the basics and then move on to bigger and better things (like Ada, if
you find you like programming).
 
 
Send replies to:
 
Kevin (Gonzo) Bushman
bushman@mitecmail.ccscnet.af.mil
 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: INFO-ADA Digest V92 #299
@ 1992-10-01 15:51 munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!brt.deakin.edu.au!dougcc
  0 siblings, 0 replies; 5+ messages in thread
From: munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!brt.deakin.edu.au!dougcc @ 1992-10-01 15:51 UTC (permalink / raw)


In article <2AAE10C8@ncgate.ccscnet.af.mil>,
BUSHMAN@MITECMAIL.CCSCNET.AF.MIL writes:

> As I stated
> in the last paragraph, Ada is a very large language.  For someone wanting to
> get some programming experience, as your first language to tackle, Ada would
> be much harder to learn than others, such as COBOL.  

This sounds like nonsense to me.  You are surely better off starting with
a modern language first, rather than unlearning the skills of an obsolete
one later.

This kind of objection to Ada was criticised by Jean Ichbiah who compared
it to examining the engineering blueprints for a new auditorium, and then
saying "this building is much too complex, people will never be able to
find their way into the foyer".

> When learning how to
> swim, do you start by jumping in the middle of the lake and hope you survive
> to the shore?  Probably not.  And the same holds true for programming.  Start
> with the basics and then move on to bigger and better things

This seems to be sound advice.

>  (like Ada, if you find you like programming).

If the end objective is to learn Ada, then start with Ada --- just start with
the basic features, then move on to more advanced ones later.  Learning
COBOL as an introduction to Ada would be a futile exercise.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: INFO-ADA Digest V92 #299
@ 1992-10-02  7:56 Richard A. O'Keefe
  0 siblings, 0 replies; 5+ messages in thread
From: Richard A. O'Keefe @ 1992-10-02  7:56 UTC (permalink / raw)


In article <2AAE10C8@ncgate.ccscnet.af.mil>, BUSHMAN@MITECMAIL.CCSCNET.AF.MIL w
rites:
> The problem with is Ada is that it is 
> a very large language ...  There are many other groups out there using
> Ada, but its use is not nearly as common as other languages that you would
> probably be more apt to use in your field (like COBOL, unfortunately).

>  As I stated
> in the last paragraph, Ada is a very large language.  For someone wanting to
> get some programming experience, as your first language to tackle, Ada would
> be much harder to learn than others, such as COBOL.

I recently hunted up all the programming language standards I could find and
read them (our library _still_ hasn't got the C standard I asked for).  It
was illuminating.  COBOL 85 is a very large language and the standard is
ENORMOUS.  Let's keep a sense of perspective here:
	Ada is smaller than COBOL.
	Ada is smaller than C++.
	Ada is smaller than Common Lisp (wow, the draft is _incredibly_ large)
	Ada is larger than C.
	Ada is larger than Pascal.
	Ada is larger than Scheme.
I reckon it's easier to get started with Ada than Pascal.  What counts is
not "how big is the whole language" but "how much do you have to know to
get stuff done".  If it comes to that, I am continually surprised by how
little C many of the C programmers I speak to know, and it's not large.

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: INFO-ADA Digest V92 #299
@ 1992-10-02 10:42 Dag Bruck
  0 siblings, 0 replies; 5+ messages in thread
From: Dag Bruck @ 1992-10-02 10:42 UTC (permalink / raw)


In <comp.lang.ada> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>Let's keep a sense of perspective here:
>	Ada is smaller than COBOL.
>	Ada is smaller than C++.
>	Ada is smaller than Common Lisp (wow, the draft is _incredibly_ large)
>	Ada is larger than C.
>	Ada is larger than Pascal.
>	Ada is larger than Scheme.

Excellent advice.  How do you measure size?

>....  What counts is
>not "how big is the whole language" but "how much do you have to know to
>get stuff done".

Very true.  A burden on any programmer regardless of language is to
know what feature not to use for a particular task.

>....  If it comes to that, I am continually surprised by how
>little C many of the C programmers I speak to know, and it's not large.

Do you mean that C is a good language (in some sense) because it is
small to start with and you don't even have to know much of that to
get useful work done?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: INFO-ADA Digest V92 #299
@ 1992-10-07  3:07 Richard A. O'Keefe
  0 siblings, 0 replies; 5+ messages in thread
From: Richard A. O'Keefe @ 1992-10-07  3:07 UTC (permalink / raw)


In article <1992Oct2.104250.21814@lth.se>, dag@control.lth.se (Dag Bruck) write
s:
> In <comp.lang.ada> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >Let's keep a sense of perspective here:
> >	Ada is smaller than COBOL.
	...
> >	Ada is larger than Scheme.

> Excellent advice.  How do you measure size?

Effort required to read the defining document.  The COBOL-85 standard is
physically larger than the Ada-83 LRM and I found it harder to read.  It
also appears to define more concepts.  The Scheme standard is ~50 pages,
very much in the style of the Algol 60 report, and that includes a
formal semantics which I (ahem) skipped.

> >....  If it comes to that, I am continually surprised by how
> >little C many of the C programmers I speak to know, and it's not large.
> 
> Do you mean that C is a good language (in some sense) because it is
> small to start with and you don't even have to know much of that to
> get useful work done?

I didn't mean to say anthing at all about good/bad.  I will say that very
little of ANSI C is "bloat".  However, there _are_ rough edges to watch
out for.  I have in mind things like which arguments of what built in
functions are size_t rather than int, and why; what exactly are the
differences between pointers and arrays; why it's a bad idea to put
function declarations (not definitions, that's not legal) inside blocks
even though it's legal; what NULL is and exactly when it needs a cast;
when p[-1] is legal; how to do arithmetic on times; when you need ptrdiff_t;
I could go on and on.  I've never written down a full list, but most of
the rough edges don't exist in Ada.  (How many Ada programmers would think
of multidimensional dynamically allocated arrays as _hard_?)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1992-10-07  3:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-10-02  7:56 INFO-ADA Digest V92 #299 Richard A. O'Keefe
  -- strict thread matches above, loose matches on Subject: below --
1992-10-07  3:07 Richard A. O'Keefe
1992-10-02 10:42 Dag Bruck
1992-10-01 15:51 munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!brt.deakin.edu.au!dougcc
1992-09-09 14:57 BUSHMAN

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