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

> >>>>> "Patrick" == Patrick Logan <[e-mail]> writes:
>
>     Patrick> In fact, I can cause the entire process to be corrupted
>     Patrick> because of this, and worse. It is a misnomer to say that
>     Patrick> C++ is *strongly* typed. It is not.
>
> Hi Patrick,
>
> Can you give an example of a language that is both strongly and
> statically typed given your definitions?

Let's quit the small talk. OF COURSE, C++ is both strongly and statically
typed. That is a good description of what C++ *is*.

The more I look into Python/Ruby, the more I like C++. To avoid a rant, skip
to the next message.

Please describe to me the practical difference between an 'interpreted
language' and C++ with hot-swappable DLL's (without resorting to lame
excuses about compile times, given Mr Moore's hueristic).

If your answer includes the term 'prototyping' you don't understand C++.

template <class Ty>
void foo(const Ty& X)
    { X.bar(); }

template <class Ty>
void foo(Ty& X)
    { X.bar(); }

Sure, it is more noisy than

class UnnecessaryScopeGivenNamespaces
    def foo(X)
        X.bar
    end
end

But who gives a care about syntax when you care about code (that is,
expressiveness and efficiency). How much do you read code compared to how
much that code is executed? Carts and horses. There is a real, practical,
absolute difference between a const-reference and a non-const-reference,
especially in distributed systems (which is why I chose such a
non-flattering example).

Syntax is a means to an end, not a means (or a justification) in an of
itself. As Bjarne says, "Syntax matters, sometimes in perverse ways".

My perspective is for practicality, not expediency. A subtle but important
difference. Note that practicality includes notions of 'ease of use' and
'prototyping' and 'efficiency' and 'readability' and 'maintainability'. It
does not *necessarily* include 'instantaneous understanding' or 'the
smallest amount of work possible for a given specific circumstance'. To para
phrase, anything that takes no time to understand is not worth
understanding.

At least in C++ I often get told about a problem before it happens.
Admittedly, it is not a permissive language. Then again, nor is any useful
language. Conversely, if it is, it can more correctly be termed 'noise'.
Yes, I exagerate to clarify.

With .NET you can have your cake and eat it too: you can write Managed C++
embedded in an XML file: it is both strongly typed and effectively
interpreted. That same C++ code can co-exist -- in the same file -- with
Python/REXX/Perl/C#/VisualBasic, to the point where you can derive from
classes defined in another language. I can write a Python class that derives
from a C++ class and conversely. The same is true for VisualBasic, C#, REXX,
etc. Where does this leave the distinction between 'compiled' and
'interpreted'?

I realise that I am now attacking the precise notion of an interpreted
language. Oops. To the mailing list of an interpreted language. Oops. But
hey, I call 'em like I see 'em. And the way I see it is that .NET and
Windows scripting (via XML) pretty much makes 'interpreted' languages like
Python and Ruby obscelete. Don't 'like' MS? Whatever. Your company is *nix
only? Sorry. My company is half Linux half Win2k. I once cared about the
difference. Now I care about practicalities.

What is the practical difference between Managed C++ embedded in XML and
Ruby?

Prototyping? Sorry, doesn't wash. Syntactic sugar is sweet, but no-one likes
the dentist.

Interpreted versus compiled? Nope: you can have 'interactive C++' with a
fast enough computer. Dont say that your computer is not fast enough. If you
insist, I'll show you 2Ghz PC's at less than $1000US within 18 months.

Ease of use? C++ has very few keywords, and yet has extreme depth. Regular
expressions as part of the language? Ever heard of a library? Sure, you can
show me Ruby code in that is 'more concise' than the same *unsupported* C++
code. But I can show you C++ code that is as consice given a library.

Do I think that C++ is the be-all-end-all? Five years ago I would have
laughed. But the more I know, the less I think that other languages are
necessary. Even to me, that sounds rich. Until you really understand C++.
It's like string theory: we got it before we understood the underlying
physical rationale.

Functional programming? C++. Generic programming? C++. Object oriented
(yuck) programming? C++.

Interpreted programming? C++. (Yes, only under .NET at the moment).

Meta-programming? C++. This is far more important than anything else.

My point? Times change. And the more things change the more things stay the
same. Thanks for reading this far.

Christian.