Patrick Logan <patrickdlogan / home.com> wrote: >"Josh Stern" <jstern / foshay.citilink.com> wrote in message >news:3a615fb9$0$78691$65a95bcd / news.citilink.com... >> C++... is strongly typed for function calls. >In fact, C++ is *not* strongly typed for function calls. I can pass in >any damn thing I want to, to a function, and the language will not >prevent it. Not so. You can only pass any damm thing if you use casts or the clumsy stdarg interface to deliberately subvert the type system (or else if you have a bad point or reference to start with, in which case the problem happened somewhere else, not in the function call). In the case of casts, the type conversion happens before the functional call, and C++ has a hierarchy of casts that refelcts their relative safety. Many programmers avoid the unsafe ones altogether (which eliminates stdard), but in any case, it is flag to the programmer that something special and dangerous is going on. >In fact, I can cause the entire process to be corrupted because of >this, and worse. It is a misnomer to say that C++ is *strongly* >typed. It is not. The terminology is common. It is also common to note that C++ is not type-safe. This suggests that most people don't use 'strongly typed' as a synonym for type-safe, but I don't want to argue about a usage issue. Ruby is not type-safe either. >C++ is a statically, yet weakly, typed language. The most dangerous of >combinations, IMHO. This sentence suggests that you think static typing leads to a lack of safety, where, in fact, the reverse is true, other things being equal. >Ruby *is* strongly typed. It happens to use dynamic type checking, but >that checking is strong. It is *easy* for a Ruby programmer to accidentally pass an argument of the wrong type to a function and to have this cause a run-time error so the program stops working. Worse, in practice, would be a case where the program continues to work but has silently performed an unintended calculation. >> One of the key benefits of static typing is obviously speed. If one >> always works on little problems then speed is not an issue... > >I have worked on little problems where speed *is* the issue. And I >have worked on _many_ large problems where the speed of the language, >per se, is not the issue. So I see that claim above as a gross >oversimplification. What point do you wish to make here? >> ...many people work on problems where C, C++, Fortran, you name it, >> are all not fast enough. > >I agree, and they should choose the best tools for their problems. >However, a lot of people I have had discussions with over the last ten >years or so have held on to the notion that that set of problems is >much larger than it really seems to be from my experience of using >dynamic languages for going on 20 years. Clearly people move in different circles and any individual programmer only works on a tiny subset of all computational tasks. >> Static typing also tends to catch a lot of dumb errors. > >I have never suffered from lack of static typing. I *have* suffered >from the presence of it. Let's synchronize what we mean by static typing. Are Java, ML, and EiC all examples of statically typed languages in your lexicon? If so, then I'd be interested to hear of what you think are the biggest inconveniences of static typing. If not, then I'd suspect that you mean something like 'lacking an interpreter'. I'd agree that having an interpreted capability is important for some tasks, and a convenience for others. >> Such a feature needn't affect you if you didn't use it, but whatever. > >It would if other programmers used it and I wanted to use their code. As something of an exercise, I mentioned a possible strategy type overloading in Ruby in some earlier messages: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/8324 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/8334 Whether something like that would be a good idea overall, is not something I know the answer to. But I haven't come across any really tight arguments/examples so far of how or where it would hurt. -= Josh