From: Christian Date: 2001-01-16T00:33:33+09:00 Subject: [ruby-talk:9338] Re: 101 Misconceptions About Dynamic Languages > >>>>> "Patrick" == Patrick Logan 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 void foo(const Ty& X) { X.bar(); } template 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.