
C++11 and Ada 2012 - renaissance of native languages? - AndreyKarpov
http://electronicdesign.com/article/embedded/c11-ada-2012-renaissance-native-languages-74107
======
chrisaycock
Ada is "mainstream"? C++ "failed" in the 1990s? Managed languages lead to
"applications that are difficult to maintain over time"?

I found it impossible to read the rest of this article given the nonsense in
the intro. So I skipped to the conclusion and saw this gem:

    
    
      The most successful software projects are those that
      have been able to select the languages that were the
      most appropriate to their need.
    

I thought the most successful software projects were those that met the needs
of their users.

~~~
jlarocco
I'm not a big fan of TIOBE [1], but Ada is in the top 20 and ranks above Lua,
Go, Haskell, Scala, Clojure, Scheme, Ocaml, Erlang, and a bunch of others that
get more mention here. If an article called Haskell or Go "mainstream" would
you have called them out on it? Ada is still popular in a lot of fields.

I don't get the hate on Ada. It has built in tasks/threading, strong typing,
low level access when you need it, generics, native compilation, a decent
toolchain, an open standard, ...

[1]
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

~~~
Nelson69
I think it was sort of a perfect storm of a couple things. General dislike of
mandates, especially from the DoD.

It's Pascal like syntax. In the 80's there was a very real Pascal vs. C war,
literally based upon "BEGIN" and "END" being too verbose compared to "{" and
"}" argued by guys with 300bps modems and crap like that. Pascal got an unfair
bad rap. Ada looks an awful lot like it though.

Then C, especially old school C can almost be converted into assembly by YACC
without a real compiler. While it's very hard to make a good or great C
compiler, it's not hard to just make a C compiler. Ada came with a much larger
library and then, if I'm not mistaken, there was a certification process to
make sure your Ada was really "Ada" and that was fairly pricey.

It's worth a look if you're doing some kinds of green field development, the
GNU Ada compiler is pretty good. I think there was a plan for like an eclipse
plugin too.

~~~
WalterBright
Pascal's bad rap was entirely justified. You could not write a useful program
in Wirth's Pascal - a lot of language extensions were required, and of course
every Pascal vendor implemented their own such extensions.

Ada suffered for years for being an unimplementable language. It was a long
time before compiler technology caught up with it, but Ada found it hard to
shake that stigma.

C came along at the right time, did not have those problems, and so took off.
On the PC, for example, in the early days C was the only possibility other
than assembler.

~~~
mulander
> Ada suffered for years for being an unimplementable language. It was a long
> time before compiler technology caught up with it

Could you explain what features of the language made it that hard to
implement?

I would really like to see your general opinion on Ada from a language
designer standpoint. Considering you're the main mind behind D - did you draw
any inspiration from Ada while fleshing out the language?

~~~
WalterBright
I first got and read the spec for Ada in 1982, intending to write a compiler
for it. I found it to be overwhelmingly complicated, but I had little
experience with compilers at the time. I haven't paid much attention to it
since. Many other early compiler devs shared my opinion of it, and indeed it
was many years before it was successfully implemented.

I don't recall just what it was that made it hard, other than being so
complicated. I doubt I'd feel the same way looking at it now, as I have a lot
of practice implementing complex features from writing a C++ compiler :-)

What I find attractive about Ada is the emphasis on writing programs that are
checkably correct. I believe that, with the ever increasing complexity of
software, better and much more mechanically checkable encapsulation, etc., is
the way of the future, as opposed to what I call "faith based programming"
where you overly rely on the programmer not making mistakes.

A large focus of D has been and continues to be on being able to write
mechanically checkable code.

------
anuraj
C++ has always been popular. Ada has been and will remain a niche language for
niche jobs. Language selection is probably the least consquential thing in
software project success as long as the language fits the job and your
developers are comfortable with it.

------
reacweb
Concerning concurrency, Ada is 30 years in advance over C++. The concurrency
system in Ada83 was already more sophisticated than mutex and thread. Since
Ada95, the concurrency system of Ada is really marvellous.

The single problem of Ada is that there is so few Ada programmer on the
market.

------
army
What a bizarre article. Garbage collection is several orders of magnitude
slower than manual memory management? I don't think that's _ever_ been true.

~~~
berkut
Of course it is.

Programs are rarely CPU-bound from a number of instructions-per-second point-
of-view. 80% of the time I've profiled high-performance applications, it's
been memory allocations and deallocations that have been the issue.

Garbage collectors still aren't (and I doubt they ever will be for all usage
cases) smart enough to work out things like how to organise memory struct
alignment so it's aligned to L1/L2 cache boundaries, exact pre-allocation size
(for things like slab allocators for loads of small allocations), thread
contention with concurrency while allocating memory... And that's ignoring
things like even being able to allocate onto the stack which things like Java
can't even do for anything other than base primitive types.

A garbage collector might be able to pick up some of these things to a
primitive degree, but certainly not on the first run of the code, which means
the first run will be slow.

Games and embedded systems often allocate a fixed size of memory up front and
NEVER free it, re-using it instead.

~~~
loup-vaillant
Alan Kay once mentioned in passing (in Early History of Smalltalk I think)
that newer processors tend to be optimized for languages like C. Of course it
would be difficult to make a garbage collector perform well on such platforms.

Really, we have it backward. The question shouldn't be which languages run
faster on current platforms, but which languages are easier to use (depends on
the problem of course). Once you know which programming patterns humans best
deal with, you can optimize the implementation stack _all the way to the Nand
gates_. It's a pity, _a shame_ , that we currently have to stop before
touching the silicon.

~~~
rbanffy
The sad fact is that most current computers are built to run Windows, meaning,
yes, their processors are optimized to run code written in C. This is not
entirely bad, because it helps make unixes run efficiently too, but we cannot
expect anything very revolutionary at the ISA level unless we are willing too
burn a couple billions. Azul Systems July processors designed to run Java,
and, in particular, to run garbage collection efficiently, but it is so costly
to build silicon they left the hardware business.

~~~
loup-vaillant
> _Azul Systems July processors designed to run Java, and, in particular, to
> run garbage collection efficiently_

That sounds really interesting. Do we know what kind of feature made these
processors more suitable to Java byte-code and garbage collection? How did it
fare compared to then current mainstream processors? Can we speculate on how
it _would_ have fared if Intel or AMD build this kind of processor instead?

