Re: prevalence of C++ in embedded linux?

[Bernd Petrovitsch <bernd@firmix.at>]

On Wed, 2008-07-30 at 14:07 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > If "GOLD" is as old and flexible (and portable?) as binutils,
> 
> The author says it will only work with ELF, and he does not
> intend to add support for all the other things binutils does.

Well, supporting 80% of the deployed systems requires probably only 20%
of the code;-)
But then it won't really replace binutils. And if, some quirky
hardware/systems have a problem .....

> > gcc and/or other huge software maintained to death, it is probably
> > similar complex and odd.  If people take a > 10 year old tool and
> > rewrite it from scratch, I would assume that design is better.
> 
> Only true if the cruft is no longer relevant.  If the cruft is
> intrinsic to the problem, e.g. supporting umpteen quirky architectures
> implies umpteen quirks of cruft, then it'll be in the new design.

Yes, but one can make a better design in always knowing/planning to have
hooks here and there and everywhere.

> Btw, gcc and binutils are more like 30 years old :-)

That doesn't make it better;-)
I was too lazy to search for more exact numbers.

> > And I can't see any direct dependence on the used programming
> > language(s) if one compares running code and what is left of "design"
> > after years of design extensions, changes, enhancements, etc. to a new
> > design from scratch from the lessons learned (hopefully) from the former
> > one.
> 
> Some programming languages allow you to express a problem concisely
> and clearly, and some don't.  That clarity then affects whether an

And if C is too low-level, one abstracts with functions etc. I call that
"design" - independent if the design existed before the source or if the
design evolved over years with the software
And yes, at first it is enough to add a parameter and/or function here
and there without breaking implicit or explicit assumptions.
But at one point from a larger view, the "design problems" will be
obvious and one can either solve them (investing time/money for
effectively no real gain in features and/or functionality, just only
cleanups or refactoring of parts or whatever one wants to call it) or
lives on with patching/maintaining the software to death.

> evolving design becomes loaded with implementation cruft or not - and
> you can't always tell the difference.

Yes.
And over the years and decades, the implementation evolves with the
problems - new and existing ones. If the design doesn't involve - which
IMHO implies refactoring of existing, tested and working code(!)
possible breaking it - you have at some point such a mess that each
"trivial" enhancement takes age (and breaks again somewhere else
something).

> Most languages are well-matched to different problem domains.

Maybe. IMHO these differences are almost nothing compared to the below
point:

> Binutils and bfd look very crufty, but I think it's hard to tell how
> much of that is due to the implementation language and implementation,
> or the design and requirements, and how much would exist in any
> implementation on any language.

IMHO it's (mostly) independent of the implementation language:

If changes in design are not completed (including removal of old
deprecated stuff or at least push it in peripheral places where nobody
cares;-) in the implementation (for whatever reason - no one does it, no
one wants to pay it, one wants to support every API indefinitely, ....),
it will lead more sooner than later to unmaintanable crufty software.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services