From: Austin Ziegler Date: 2003-11-21T23:21:47+09:00 Subject: Re: "stereotyping" On Fri, 21 Nov 2003 17:13:36 +0900, Clifford Heath wrote: > Austin Ziegler wrote: >> Um. Sorry, but type signatures don't promise you that side >> effects are limited to compile-time. > That's true, but they help by catching some cases. I don't find that they catch *useful* cases, but rather cases where work had to be done to accommodate the static typing system in the first place. > Said cases are more likely to occur in some programs and human > environments than others. I would agree, but I think that our definitions for such programs and environments are radically different. Mine would be the "absolutely must never fail" embedded code for heart monitors and such. Typical business apps are *not* those environments. There are good reasons for thinking this, too, that I'll describe below. > Whether Ruby should be used in environments where these errors are > common and avoidable seems to be the main bone of contention. > Optional typing (whether static, dynamic, or some combination) > would increase the range of purposes for which Ruby is suitable. > You might not want that, but I do. Frankly, Ruby is already suitable to those non-"absolutely must never fail" environments. What's not happening is that people aren't feeling comfortable with their own developers' capabilities -- and, I think, are underestimating them. Question: what is the purpose of software in a business environment? Answer: serving business purposes. Question: how much C++ or Java code actually *serves* business purposes? Answer: It depends... The situation is somewhat better now in C++ than it used to be (with the STL), but I know that significant portions of the production- level C++ code that I've worked with and on that deal with memory management and other overhead details. In some cases, as much as *half* of the code was needed for wrangling with the language. In Java, it's even worse, especially if you're using J2EE. There's a book that advocates using Ruby for those environments where management has been convinced to use J2EE or .NET that covers this 50 - 75% overhead code: _Code Generation in Action_. What if your developers could write directly to the business requirements without having to worry about language overhead? With Ruby -- and other strongly-typed dynamic languages -- they can. Joel Spolsky (www.joelonsoftware.com) wrote CityDesk, a desktop-based content management system, in Visual Basic with Visual C++ performing necessary performance improvements or other things that can't be done in VB. It's easily one of the best -- and most responsive -- programs I've ever used on Windows. He did this because in VB he was able to write closer to his business requirements without having to deal with the overhead (both mental and codewise) of C++. Joel's a bright man. I think that his lesson learned in this is *generally applicable* and is applicable to Ruby's situation as well. >> Which brings you right back to the advantages of dynamic >> languages as opposed to static type signatures. > No it doesn't. It leaves you with no guarantee, but more > confidence. Often it's false confidence, Clifford. If static typing actually gave you anything of value, people wouldn't have to resort to tricks like (void *). As Bruce Eckels pointed out in the article I found earlier[1], when he tried some stuff in Python, he found that he no longer had to upcast. His class hierarchy was made simpler. Note that strongly and explicitly typed languages like Ada aren't actually as frustrating as C++, because they make you think about how your types are used, rather than sometimes doing things implicittly. > But there are no guarentees anyhow - even if the software works as > designed, nothing says it meets the user's need. Again, I think that if we consider how much code is framework code in C, C++, and Java, all of the supposed advantages of statically typed languages disappear under the productivity killing crush. > Nothing's certain in life, instead we must live within certain > confidence levels. Static typing can improve confidence levels. So > can thorough testing. Nothing about the absence of static typing > can yield these particular improvements - though individual > languages may have (mostly) unrelated other features which do, > including reduced verbosity. I'm not the only one who thinks that dynamically typed languages are at least as suitable as statically typed languages for business applications: http://www.osteele.com/archives/2003/08/test_versus_type.html As Oliver Steele points out, the productivity boost *has been shown in research*! -austin [1] http://www.mindview.net/WebLog/log-0025 -- austin ziegler * austin@halostatue.ca * Toronto, ON, Canada software designer * pragmatic programmer * 2003.11.21 * 09.21.33