[ruby-talk:9624] Re: 101 Misconceptions About Dynamic Languages

In article <001401c082b3$8a39e220$2e03280a@puma>, "Christian"
<[e-mail]> wrote:

> "Larry J. Elmore" <[e-mail]> wrote:
> 
>> > Christian> But I do know that Mr Stepanov chose to move from Ada95
>> > to C++ to implement his STL. Why?
>>
>> Larry> Actually, he didn't. From an interview in DDJ in March, 1995
>> (http://www.sgi.com/Technology/STL/drdobbs-interview.html):
>>
>> This particular [C++ template] technique became crucial for my work
>> because I discovered that it allowed me to do many things that were
>> not possible in Ada. I view this particular design by Bjarne as a
>> marvelous piece of work and I'm very happy that he didn't follow my
>> advice."
>>
>> Of course, the Ada being referred to here is Ada83. The differences
>> between Ada83 and Ada95 aren't as great as between C and C++, but
>> Ada95 is a considerably nicer language.
> 
> I was thinking of that article when I claimed that Mr Stepanov moved
> from Ada95 to C++. I should have re-read it and referenced it.
> However, the spirit of the claim holds: C++'s templates are more
> suitable to use to implement a STL than Ada95's generics. He even
> claims that C++ allows him to
> "do many things that were not possible in Ada". Of coure, he was
> refering to Ada83, not Ada95, but it is not clear if the situation has
> changed.

It has, so I fail to see how the "spirit of the claim" still holds.

>> Even with a standard and the STL, writing portable C++ seems to be
>> somewhat problematic, as this page relates:
>> http://www.mozilla.org/hacking/portable-cpp.html
> 
> If you want C++ code to work on a wide variety of compilers, with
> radically different language support, of course you will become very
> limited in what features and techniques are available. That is
> obvious, and says nothing about C++ itself. Is it true that if I write
> a bad C++ compiler that does not support virtual functions properly,
> then you must not use virtual functions? Yes, if you want your code to
> work with my compiler.

With validated Ada compilers, that's not a problem. Don't use an
unvalidated compiler. IIRC, _most_ C++ compilers do not _yet_ adhere to
the standard in all particulars. Perhaps that's changed in the last
year?

>> True, but do have a look at
>> http://www.adaic.com/docs/flyers/95cplus.shtml
> 
> The author is very eloquent, and careful, at least at first, to limit
> his language bias (which is wholly acceptable in this context).
> However, the article is dated. It claims that C++ has no standard,
> which was true at the time of writing (1992). Because of this, many of
> his arguments are now false, or at least much weaker. It bemoans the
> lack of features in C++ that were later introduced in the standard:
> "C++ classes are the only encapsulation mechanism in the language".
> Hello, namespaces.

True, but they do look like tacky glued-on additions to an already
complicated beast. I'm not trying to claim that Ada is the be-all and
end-all of languages as you were doing with C++ (and IMHO it would take
more than just an "increment by one" to make C a truly good high-level
language), I'm just pointing out some areas where I do feel Ada is
indeed better. C/C++ has some features I like, but to claim that C++ is
the epitome of programming languages is ridiculous.
 
> That said, some valid points are made convincingly. The fact that
> proficiency in C++ implies proficiency in the environment in which it
> is being used is true. Although it could be claimed that this is both
> obvious and good, the point is taken that it can result in assumptions
> that fail in a different environment. But there are ways and means,
> and POSIX is a good start (most *nix's and Win2k are POSIX compliant,
> although again YMMV). It could be claimed that POSIX is then "a part
> of C++". True enough, from that perspective.
> 
> It is well and good that Bjarne refused the temptation to add threads
> or tasks to C++. These are necessarily application space issues. This
> point could be argued, but it is true that models change from platform
> to platform and even from year to year. How can one buil-in,
> 'standardized' model for threading work in all cases for all purposes
> for all time? The notion of a microthread is different to that of a
> thread. By refusing to lock C++ to any model, Bjarne gave us the
> flexibility to change and adapt. Yes, this means a less strict
> environment. It also means that we can solve problems quickly and
> efficiently, and be adaptable to changes.

I don't understand why you think that's a benefit. IIUC, Ada doesn't
specify the tasking model(s) to be used, it does specify the interface
between units of code. 

>> If it's execution which truly matters, then wouldn't a modern OO
>> assembler be the way to go? :)
> 
> Although you mention it sarcastically, the notion of a modern OO
> assembler is a profound and relevant one.

It wasn't mentioned sarcastically. It was a good question.


>> Larry> Seriously, though, maintenance is an important part of much
>> software engineering.
> 
> Yes, but less so over time. The situation where a company has millions
> of lines of code to maintain over many years is happily going away.

BOGGLE

> Of course, there will be the need for legacy. But as hardware and
> deployment environment evolves ever faster, maintenance can often be a
> poorer choice than a re-write. Yes this is a weak point, but is it not
> true that given that the number of programmers increases non-linearly,
> the amount of software increases non-linearly, thereby reducing the
> importance of 'legacy code'?

BOGGLE

> I do not mean to argue that maintenance is not important because C++
> doesnt support it well (it does).

In comparison to assembler and languages like BLISS, perhaps. But not so
well as other alternatives.

> I argue that, more generally, the sheer amount of new code that will
> be written in the future will make that legacy code far less important
> than it was when there were fewer programmers and a relatively stable
> deployment environment.

That's an interesting viewpoint, to say the least.
 
> Case in point: my profession. I am a game developer. Each new title, I
> re-write the systems from scratch. Very little is used from one game
> to the next. It just isn't meaningful anymore. Yes this is an extreme
> case, but it demonstrates the importance of expressibility and
> practicality over maintainability. I fear that I am in dangerous water
> here and that I am not expressing myself well, so I'll move on :).

I'll tell you one thing -- games are far, far different than the vast
majority of programming that's going on out there. The company I work
for is only 11 years old and still has to support a lot of the original
equipment it first shipped. That means updates to the software so that
it can decode newer telecom protocols. Some of these protocols get
updated almost yearly, if not by the ITU or ANSI, then by the customers
themselves. I would dearly love to rewrite most of our code base (just
decode has well over 2 million _files_, I've no idea what the other
depts have), but business (and the company) is growing fast and it's all
we can do just to keep up. Legacy code is just a fact of life, and it's
no more going away than sewage treatment plants will be.

> How would the use of fibers in Ada95 contend with the built-in task
> model? Oops.

I can't see any problems, but I'm not (yet) a compiler writer, either.
Ada can use threads in Windows quite well, so why not fibres? My main
point is that C++ is not the greatest thing to have ever happened to
computer science. It has some real good points and it has some very bad
ones, too. To get this back to Ruby, I can't imagine using C++ or Ada95
or even Lisp for most of what I now use Ruby for. That'd be like using a
piledriver for crushing tin cans, and driving nails for hanging
pictures. It can be done, but _why_?

Larry