Re: How come Ada isn't more popular?
- From: Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@xxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 31 Jan 2007 11:24:23 +0100
Maciej Sobczak <no.spam@xxxxxxxxxxx> writes:
Markus E Leypold wrote:
Sorry, but that's a misconception - I don't remember when I was theOK. I'll have to reconsider this statement. I usually couldn't trim
last time I was messing with manual memory management in a regular C++
code. I estimate that in my current programming I call delete (or free
or whatever) once in 5-10 kLOC.
down 'automatic' allocation to that extent, but that might have been
my application area. What I remember though, is the difficulty to
recover from exceptions in the presence of automatic (scope bound)
memory management. (I hope I'm making sense here, else I'd really have
to go back to my C++ mind and notes and try to retrieve the right
vocabulary and reasoning and -- well -- I don't really want to have a
C++ discussion in c.l.a. :-).
Why not having C++ discussions on the list where people claim that C++
sucks? :-)
Because of the level of detail? Because I haven't really swapped in my
C++-personality yet, I'm wary to do it and fear I'll slip up in public
claiming the wrong things about C++? :-)
Jokes aside, I feel a bit off topic with this and the fervour in this
thread seems to have diminished somewhat anyway ...
But from what I remember in
the 1997s to 1998s
Most programming languages were terrible at that time, that's true.
Not Ada 95 ... :-). Actually I think it was that time when history
branched and Ada missed to become main stream, but that is not a
historians claim only a personal impression.
(that was when there still were problems with STLs,
exceptions and the string libraries in C++ and when there was no
standard and Java was new), that this was one of the motivations that
people shifted to Java (either from C++ or from C).
Yes, I know that. And I will keep stating that this motivation
resulted from common misconceptions, further amplified by Java
marketing.
Oh yes, misconceptions perhaps. But I'v only been talking about
peoples motivations (which say a lot about their perceived problems).
I've even heard that Java is better, because it has a String class and
there is no need to use char* as in C++ (!). FUD can buy a lot.
As far as that goes I have seen people getting tripped up really bad
by string::c_str(). And I think you need it, if you don't program pure
C++, which at that time nobody did. The implementation I saw there
might have been strange/faulty though -- s.c_str() returned a pointer
into some internal data structure of s which promptly changed when s
was modified. The only "safe" way to use it was strdup(s.c_str()) and
that is not threadsafe as anybody can see. I see "the need to use
char* in C++" rumour as the result of people having been burned
by similarly quirks at that time.
The other
motivation was the "portable GUI"
Yes.
which, I think, mostly disappointed
the expectations.
Still, GUI that sucks was better than no standard GUI at all for lost
of people.
"portable" not "standard". There were always standard GUIs on Unix and
on Win32, only they where not exchangeable.
Both C++ and Ada are in the same camp in this aspect. I'm
not claiming that these languages should have standard GUI, but not
having it definitely scared many.
Let's say it the other way round: Java certainly attracted a number of
people because of the "standard GUI". And since I firmly believe that
a GUI does NOT belong into a language standard but rather in a
separate standard for a runtime environment, I wonder a bit which kind
of people those were.
Of course I might be wrong. This is just teh impression I got "from
the trenches" and I might be missing a mor global point of view. It
perhaps does not apply today where C++
Well, there is still no standard GUI for C++, but the choice with
non-standard ones is quite impressive:
I haven't been talking about the standard GUI here, but about the
memory managment issues I hinted at earlier. I see, I've been jumping
a bit here.
http://www.free-soft.org/guitool/
and the understanding of C++
has matured a bit
Yes. Sadly, too late for those who already changed their mind.
(there is even an embedded subset of C++ which will
annoy folks here no end :-).
I think that at the end of the day the embedded C++ will disappear
from the market as the "full" C++ gets wider compiler support on
embedded platforms.
That is no question of compiler support, as I understand it, but of
verifiability and safety. A bit like Ravenscar, but -- of course --
not as highly integer (ahem ... :-).
There will simply be no motivation for using subsets.
But there will -- see above.
Subsetting C++ would be beneficial in the sense similar to Ravenscar
or by extracting some core and using it with formal methods (sort of
"SPARK++"), but I doubt it will ever happen.
It already did (and perhaps died)
http://en.wikipedia.org/wiki/Embedded_C++
And certainly. Why should advances in hardware only buy more spiffyThe trend I see, is that GC is a must, clumsy pointer handling is outIndeed, looks like everybody is going in that direction.
and types are an option for those that can understand them.
GUIs and not something to ease the everyday pain for the everyday
software developer :-).
The interesting thing is that memory management is *said* to be
painful. C++ and Ada are similar in this regard - the majority of the
regular code don't need manual memory management (local objects!) or
can have it encapsulated (containers!), so there are no problems that
would need to be solved.
I disagree. The only-downward-closures style of C++ and Ada, which
allows only to mimic "upward closures" by using classes, heavily
influences the way the programmer thinks. Higher level abstractions
(as in functional languages) would require full closure -- and since
this means that memory life time cannot bound to scope any more, this
would be the point where manual memory management becomes painful.
Furthermore I've been convinced that manual memory management hinders
modularity.
Reference-oriented languages have completely
different ratio of "new per kLOC" so GC is not a feature there, it's a
must.
I wonder, if it is really possible to do OO without being
reference-oriented. I somewhat doubt it.
But then the question is not whether GC is better, but whether
reference-oriented languages are better than value-oriented ones. Many
people get seduced by GC before they even start asking such questions.
Value-oriented in my world would be functional -- languages which all
heavily rely on GC.
I also admit being one of the seduced, but that is not surprising
since my main focus is not in embedded programming and in everything
else it's sheer folly not to have GC. The arguments against GC often
read like arguments against virtual memory, against high level
languages as opposed to assembler, against filesystems (yes there was
a time when some people thought that the application would best do
allocation of disc cylinders itself since it knows its access patterns
better than the FS).
Regards -- Markus
.
- Follow-Ups:
- Re: How come Ada isn't more popular?
- From: Maciej Sobczak
- Re: How come Ada isn't more popular?
- Next by Date: Re: How come Ada isn't more popular?
- Next by thread: Re: How come Ada isn't more popular?
- Index(es):
Relevant Pages
|
