comp.lang.ada
 help / color / mirror / Atom feed
From: Warren <ve3wwg@gmail.com>
Subject: Re: InformationWeek Gives Ada Black Eye
Date: Wed, 21 Apr 2010 17:12:49 +0000 (UTC)
Date: 2010-04-21T17:12:49+00:00	[thread overview]
Message-ID: <Xns9D61866AC2457WarrensBlatherings@188.40.43.245> (raw)
In-Reply-To: 60862edf-fdfb-4c68-a96c-fd6ccded599f@e7g2000yqf.googlegroups.com

Gautier write-only expounded in
news:60862edf-fdfb-4c68-a96c-fd6ccded599f@e7g2000yqf.googlegroups.com: 

> On 21 Apr., 15:35, Warren <ve3...@gmail.com> cited:
> 
>> "...
>> All this feature richness is great, but at some point it runs the
>> risk of feature bloat, bogging down resources and performance in the
>> process. Remember the Ada programming language? Oft described as
>> having everything including the kitchen sink, Ada was ahead of its
>> time with object- oriented and other capabilities. But its plethora
>> of features was more than most developers could handle, and it never
>> went mainstream. That's something the Visual Studio team should keep
>> in mind." 
> 
> Apparently the notion of bloat evolves with the time.

Certainly memory and CPU speed have changed radically
since the introduction of Ada. So leaner compilers back
then may have been more relavant to the mainstream. But
today, a compile is not a "big thing" anymore.

> A programmer who would have laughed at Ada's generics, when
> reincarnated 20 or 30 years later, will perhaps find it normal to
> swallow tons of those huge books which are designed to become obsolete
> at the next version of Visual Studio...

Ya, I don't like seeing "systems" built in MS products
because you know that it will need the necessary "upgrade" 
soon after.  And of course, it won't be fully compatible
with what you've built today.

The middle ground is perhaps open systems, where things
do change over time, but is relatively stable. A recompile
might be necessary, but usually things stay "compatible".

Then there is the mainframe, where you have COBOL/ASM
processes running forever, with only minor compatible
OS upgrades. No recompiles involved (and maybe the
source code was also long ago lost ;-)

> There are positive points in this citation: 1) he remembers Ada! 2)
> the comment "ahead of its time" is rather complimentary.

But the idea that Ada is "bloat" doesn't exactly make
ppl want to check it out.

> One might want to add "was and still is and probably will remain", if
> you consider the features, regularly added to .Net languages, which
> are borrowed from Ada.
> But that is the "zeitgeist" part. For the moment, there is some
> success at botoxing languages of the 60's.

I was reading something recently about F#(?), where they
were espousing the idea of methods with "contracts". 

I don't get this- are not these method contracts just a bunch
of "pragma Assert()" statements?  If you have to spell out
what is valid in a "contract" - how is that any different 
than assertions in C/C++ or Ada?  Syntactic sugaring.

Maybe it is just me.

"Now get off of my lawn!"

Warren



  reply	other threads:[~2010-04-21 17:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 13:35 InformationWeek Gives Ada Black Eye Warren
2010-04-21 15:13 ` Gautier write-only
2010-04-21 17:12   ` Warren [this message]
2010-04-21 20:10 ` Nasser M. Abbasi
2010-04-21 20:27   ` Warren
2010-04-21 20:57   ` 
2010-04-29  1:34 ` BrianG
replies disabled

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