Strongly Typed Languages Considered Dangerous 75
Have you ever heard of covariance? Method parameters or returns are said to be covariant if, as you work your way down an inheritance hierarchy, the types of the formal parameters or return type in an overridden method can be sub-types of the formal parameters and return types in the superclass’ version of the method.
Oh, and contravariance is just the opposite.
What?! Why should you care? Answer, you shouldn’t. Yes C++ and Java both support covariant return types, but so what? Have you ever used them? OK, I have, but then I also used and liked C++ for about 7 years, over 10 years ago. We all learn to move on.
You ever notice how something meant to help often (typically?) turns out to do exactly the opposite? Even worse, it directly supports or enables another unfortunate behavior. This is just Weinberg’s first rule of problem solving:
Every solution introduces new problems
Here’s an example I’m guilty of. Several years ago I was working on a project where we had written many unit tests. We had not followed the FIRST principles, specifically R-Reliability. Our tests were hugely affected by the environment. We had copies of real databases that would get overridden without warning. We’d have problems with MQ timeouts at certain times of the day or sometimes for days. And our tests would fail.
We wold generally have “events” that would cause tests to fail for some time. We were using continuous integration and so to “fix” the problem, I created a class we called “TimeBomb” – turns out it was the right name for the wrong reason.
You’d put a TimeBomb in a test and then comment out the test. The TimeBomb would be given a date. Until that date, the test would “pass” – or rater be ignored. At some point in the future, the TimeBomb would expire and tests would start failing again.
I was so proud of it, I even took the time to write something up about it here. I had nothing but the best intentions. I wanted an active mechanism to remind us of work that needed to be done. We had so many todo’s and warnings that anything short of an active reminder would simply be missed. I also wanted CI to “work.” But what eventually happened was that as our tests kept failing, we’d simply keep moving the TimeBomb date out.
I wrote something that enabled our project to collect more design debt. As I said, my intentions were noble. But the road to Hell is paved with good intentions. Luckily I got the name right. The thing that was really blowing up, however, was the project itself.
What has all of this got to do with “strongly typed languages”?
If you’re working with a strongly typed language, you will have discussions about covariance (well I do anyway). You’ll discuss the merits of multiple inheritance (it really is a necessary feature – let the flames rise, I’m already in Hell from my good intentions). You’ll also discuss templates/generics. The list goes on and on.
If you’re working with a dynamically typed language (the first one I used professionally was Smalltalk but I also used Self, Objective-C, which lets you choose, and several other languages whose names I do not recall).
Covariance is not even an issue. The same can be said of generics/templates and yes, even multiple inheritance is less of an issue. In a strongly-typed languages, things like Multiple Inheritance are necessary if you want your type system to be complete. (If you don’t believe me, read a copy of Object Oriented Software Construction, 2nd ed. by Bertrand Meyer – an excellent read.)
Ever created a mock object in a typed language? You either need an interface or at least a non-final class. What about Ruby or Smalltalk? Nope. Neither language cares about a class’ interface until it executes. And neither language cares how a class is able respond to a particular message, just that it does. It’s even possible in both languages to NOT have a method and still work if you mess with the meta-language protocol.
OK, but still, does this make typed languages bad?
Lets go back to that issue of enabling bad things.
Virtual Machines, like the JVM and CLR, have made amazing strides in the past few years. Reflection keeps getting faster. Just in time compilers keep getting smarter. The time required for intrinsic locks has improved and now a Java 5 compiler will support non-blocking, safe, multi-threaded updates. Modern processors support such operations using an optimistic approach. Heck, Java 6 even does some cool stuff with local object references to significantly improve Java’s memory usage. Java runs pretty fast.
Dynamic languages, generally, are not there yet. I hope they get there, but they simply are not there. But so what?! If your system runs “fast enough” then it’s fast enough. People used Smalltalk for real applications years ago – and still do to some extent. Ruby is certainly fast enough for a large class of problems.
How is that? These languages force you to write well. If you do not, then you will write code that is not “fast enough.” I’ve see very poor performing Smalltalk solutions. But it was never because of Smalltalk, it was because of poor programming practices. Are there things that won’t currently perform fast enough in dynamically typed languages? Yes. Are most applications like that? Probably not.
You can’t get away with as much in a dynamically typed language. That sounds ironic. On the one hand you have amazing power with dynamically typed languages. Of course Peter Parker learned that “With great power comes great responsibility.” This is just as true with Ruby and other dynamically typed languages.
You do not have as much to guide you in a dynamically typed language. Badly written, poorly organized code in a typed language is hard to follow but it’s possible. In a language like Ruby or Smalltalk it’s still possible but it’s a lot harder. Such poor approaches will typically fail sooner. And thats GOOD! You’ve wasted less money because you failed sooner. If you’ve got crappy design, you’re going to fail. The issue is how much time/money will you spend to get there.
Another thing that strongly typed languages offer is a false sense of security because of compiler errors. I have heard many people deride the need for unit tests because the compiler “will catch it.”
This misses a significant point that unit tests can serve as a specification of behavior rather than just a validation of as-written code.
You cannot get away with as much in a dynamically typed language. Or put another way, a dynamically typed language does not enable you to be as sloppy. It’s just a fact. In fact you can typically get away with a lot in a dynamically typed language, you just have to do it well.
Does this mean that dynamically typed languages are harder to work in? Maybe. But if you follow TDD, then the language is less important.
Do we need fast, typed languages? Clearly we do. There are applications where having such languages is necessary. Device drivers are not written in Ruby (maybe they are, I’m just trying to be more balanced).
However, how many of you were around when games were written in assembly? C was not fast enough. Then C was fast enough but C++ was still a question mark. C++ and C became mainstream but Java was just too slow. Some games are getting written in Java now. Not many, but it’s certainly possible. It is also possible to use multiple languages and put the time-critical stuff, which is generally a small part of your system, in one language and use another language for the rest of the system.
Back in the very early 90’s I worked just a little bit with Self. At that time, their Just In Time compiler would create machine code from byte code for methods that got executed. They went one step further, however. Not only did they JIT compile a method for an object, they would actually do it for combinations of receivers and type parameters.
There’s a name for this. In general it is called multi-dispatch (some languages support double-dispatch, the visitor pattern is a mechanism to turn standard polymorphism into a weak form of double dispatch, Smalltalk used a similar approach for handling numerical calculations).
Self was doing this not to support multi-dispatch but to improve performance. That means that a given method could have multiple compiled forms to handle commonly used methods on a receiver with commonly-used parameters. Yes it used more memory. But given what modern compilers do with code optimization, it just seems that this kind of technique could have huge benefits in the performance of dynamically typed languages. This is just one way a dynamic language can speed things up. There are others and they are happening NOW.
I’m hoping that in the next few years dynamic languages will get more credit for what they have to offer. I believe they are the future. I still primarily develop in Java but that’s just because I’m waiting for the dust to settle a little bit and for a clear dynamic language to start to assert itself. I like Ruby (though its support for block closures is, IMO, weak). I’m not convinced Ruby is the next big thing. I’m working with it a little bit just in case, however.
What are you currently doing that enables yourself or your co-workers to maintain the status quo?
I wouldn’t say those languages are “dangerous”, but in my experience they do take more mental energy to use effectively. C# and Java have much more cruft you have to deal with compared to Ruby, especially once you start applying XP/agile methods.
But don’t you mean that statically typed languages are considered dangerous? Some dynamic languages such as Ruby are strongly typed, where others like Perl are weakly typed. And where both Ruby and Java are strongly typed, Ruby is dynamically typed while Java is statically typed.
http://onestepback.org/articles/10things/typesummary.html
Haskell is an example of a language which is both strongly typed and yet often considered to be a dynamic language, due entirely to the expressivity of its type system.
I speak from experience when I say that strong typing is MANDATORY for working in large development teams. It’s the only way you can keep developers in check with each other when it comes time to integrate the pieces into a single product. I’ve never once heard of anyone writing a medical or aerospace application, where real lives are at stake, in a dynamic language. Please prove me wrong.
> If you’re working with a strongly typed language, you will > have discussions about covariance (well I do anyway).
I have worked for many organizations, all using strongly typed languages. I use a strongly typed language for my own programming at home.
I have NEVER heard anyone discuss co- or contravariance except in the context of comparing a language to Eiffel. No, really, I’m being honest. It NEVER COMES UP.
> things like Multiple Inheritance are necessary if you want > your type system to be complete.
Yes, this is true; a more formal model of this (and a vastly superior implementation of the concept) appears in Haskell, in the form of “type classes.”
> What about Ruby or Smalltalk? Nope.
Yes. The interface of the mock mirrors the object it’s mocking. Just because you don’t have to manually re-implement the interface yourself doesn’t mean the interface doesn’t exist.
Mock objects are proxy objects, by definition.
> It’s even possible in both languages to NOT have a method > and still work if you mess with the meta-language protocol.
Full agreement, but as with all tricks available to a dynamically typed language coder, you INVARIABLY end up writing code that is obnoxiously hard to maintain, and nigh impossible to debug when something goes horribly wrong.
Case in point: I currently work for a company that invests a lot of effort into Java. To facility a more automated approach towards discovering hooks made available for test software to attach to (e.g., collecting performance metrics, etc.), extensive use of Java’s reflection API is employed.
Well, as it happened, something went horribly wrong, where I spent a week (literally) trying to track down the cause of a bug, because an object was being instantiated through the reflection interface, NOT through your local, friendly, debugger-friendly method of instantiating an object. After a week of hairpulling to discover that, I then find out it’s instantiating the wrong kind of object to begin with.
All because it used reflection instead of type-safe methods.
> These [dynamically typed] languages force you to write > well.
Sorry, the opposite is true. These languages, being dynamically typed, freely allow the programmer to mix and match constructs that make no sense going together. What is the sum of two social security numbers? Both are numbers, but clearly, the addition operator just plain isn’t defined for them. This is something that can, and should, be caught at compile-time.
The way I see things, dynamically typed languages encourage artistry and exploration. Their promiscuity with data types and program constructs allows the programmer to freely explore a wide variety of “what if?” or “what does this do?” type situations. There is definitely great value in this.
Statically typed languages, however, encourage design. It takes longer to get a program running with good-quality, static typing, because you first have to resolve compiler errors, then resolve run-time errors that come up. What you’re really doing when doing this is clarifying the program’s design to the compiler. You’ll find that the better the static typing the language provides, the fewer the runtime errors you’ll have, because the design of the program will have been proven to be self-consistent. it will not, however, eliminate ALL the runtime errors you can have; you CAN still implement a design to solve a problem that is not well understood. A customer might ask for a racecar, but you might still deliver a car-boat.
Dynamic languages offer faster time to market, but statically typed languages offer a higher quality product. It’s that simple.
> If you do not, then you will write code that is not “fast > enough.â€
Absolutely non sequitor. ML is a strongly-typed programming language intended to be a SCRIPTING language for a larger program, designed to prove theorems.
> Peter Parker learned that “With great power comes great > responsibility.â€
You have much greater responsibility with a statically typed language, because you must deliver a product that actually compiles.
With a dynamically typed language, if your module is designed for re-use with other modules, you must invest extensive amounts of time documenting the interfaces to your types and modules.
Unit tests do not serve as a specification of the product. They serve as documentation of the product’s API. Unit tests cannot test everything under the sun about a product. You just don’t have enough time to write that many tests. They cover a large amount of ground, but the existence of bugs in unit tested code clearly attests to their incompleteness.
If you’re going to spend time documenting modules, you might as well make said documentation machine-readable and checkable. Kill two birds with one stone. Remember, automation is good. Unit testing proves that admirably. So why not do the same for type-checking? To do otherwise is nonsense.
> Another thing that strongly typed languages offer is a false > sense of security because of compiler errors. I have heard > many people deride the need for unit tests because the > compiler “will catch it.â€
You’re taking this out of context, and totally misrepresenting the truth.
The compiler can only verify consistency of the design. It cannot verify that you have a correct design. This is something pro-dynamically typed language entheusiasts always seem to overlook.
Unit testing, similarly, does not verify correct design either. Remember, it’s not the user who is writing these unit tests, but rather, the programmer. Consequently, the unit tests represent the programmer’s interpretation of the program’s behavior. As if to add insult to injury, unit tests are unit tests precisely because they test one unit of code at a time, in isolation. They do not replace integration tests, which are more accurate descriptions of the end-user’s specifications. But, even these aren’t a full encoding of the specifications.
> Badly written, poorly organized code in a typed language is > hard to follow but it’s possible. In a language like Ruby or > Smalltalk it’s still possible but it’s a lot harder.
I must now question whether you have had any real experience maintaining a large-scale project in any dynamically typed language, coded by amateurs. With all due respect, I call “bull**” on the above statement.
Dynamically typed languages tend to be “programmer amplifiers.” Great programmers do wonderous things in them. Poor programmers tend to write code that give languages like BASIC a good name.
Perhaps one need look no further than Forth to illustrate this point. (Lisp is similar.) Forth isn’t just dynamically typed - it’s totally typeless. So, by your logic, it ought to be the world’s best language, right? And, many argue that it IS. I know I* enjoy it very much. But, yet, you find code from *seasoned Forth professionals which are so obnoxiously hard to read and maintain that Forth today now has a reputation as being a dead language. Nobody wants to code in it. For the same reasons nobody wants to code in Lisp - the languages are “backwards” (read, “I don’t know how to read/maintain the code in it), and new programmers don’t understand them as well (read, “they’re not taught in college.”).
These languages are the ultimate in programmer amplifiers, though. Good coders tend to LOVE Forth and Lisp. Bad coders tend to HATE them with a passion. And, it reflects in their code.
I am not only responsible for maintaining Java code where I work, but also Python code. Generally, the code is very clean and maintainable. But this is not because of the programmers—the company has a VERY strict coding conventions document. To be able to submit code to the repository in Python (or any language, Java and C++ included), the coder must first acquire a “readability” certification for that language. If this isn’t possible, then they need to find someone who does have said certification.
Everything is reviewed, from basic design decisions to minutia like indentation, brace placement, and commenting style. Micro-management is too nice a description for the process. But we’ve found that this is the ONLY way to ensure a universally readable and maintainable code base.
It is no coincidence, then, that the readability guidelines for dynamically typed languages here tend to be bigger than their static language counterparts, which TOTALLY invalidates . . .
> a dynamically typed language does not enable you to be > as sloppy. It’s just a fact.
. . . because it is patently false. This is not a fact, and there are volumes of papers to back it up. Citeseer is your friend.
> However, how many of you were around when games were > written in assembly?
Unfortunately for you, I was.
> C was not fast enough.
No, because the overhead of pushing and popping procedure activation frames consumed a significant amount of processing time, when individual CPU instructions took up to FIVE MICROSECONDS EACH. Invoking a C procedure with 5 parameters (a common thing in most C programs today) would have consumed 30 to 50 microseconds. This compares with the horizontal scanline sweep of an NTSC display (63.5 microseconds). Note that this doesn’t consider, at all, the time taken to actually invoke the subroutine. CALL/Return overhead on a 65816 is 12 clock cycles. On an 80286 and 80386, it’s closer to 24. On an 8088/8086, it’s even more. Do the math.
> Then C was fast enough
But, only when CPU clock speeds reached 5MHz or faster.
> but C++ was still a question mark.
Because CPUs then didn’t have good support for dereferencing pointers indirectly. CPUs were designed for Modula-2 at the most back then.
Once CPU vendors realized that object orientation was here to stay, they optimized their instruction sets and even added new addressing modes to facilitate C++.
> C++ and C became mainstream but Java was just too slow.
Again, back when CPUs were running sub-200MHz in speed. On average, to emulate any arbitrary CPU (including one which cannot be realized in hardware, like the JVM), you’re looking to invest close to 30 clock cycles per virtual instruction. This is about 6 times slower than the old-school CPUs, which consumed 5 clock cycles on average.
> Some games are getting written in Java now.
Keyword - SOME. Not all. I have an 800MHz Athlon - 800x faster than a Commodore 64. Yet, a Java-written Pacman clone takes 100% of my CPU. The VICE C64 emulator (x64) takes only 50%. I note that a Pacman clone plays better in VICE than in Java.
And even so, supposing I get myself a 2.5GHz or faster machine to play Java Pacman, note that modern CPU architectures:
To summarize, it is true that dynamically typed languages are finally coming into their own in the performance field. But, I openly challenge anyone, ANYONE, to get Self running on an Apple IIgs, with all its polymorphic inline caching goodness enabled, and compare it to C running on the same platform.
It is said that Self runs, best-case, 2 to 3 times slower than optimized C. This isn’t bad (note: Forth also claims these kinds of speeds too). You’d expect, and you’ll find, that this 2x to 3x performance gap exists on the 65816 as well. But, here’s the deal—3x difference at 2.8MHz is markedly more observable than 3x difference at 2.8GHz. Trust me.
> They went one step further, however. Not only did they JIT > compile a method for an object, they would actually do it > for combinations of receivers and type parameters. > > There’s a name for this. In general it is called > multi-dispatch
No, sorry, this is called Polymorphic Inline Caching.
Self is a single-dispatch object system. If you want multi-dispatch, look at CLOS.
> I’m hoping that in the next few years dynamic languages > will get more credit for what they have to offer.
I TRUELY don’t understand what your beef is here. Dynamically typed languages are becoming overwhelmingly more popular, and yet, you’re still championing them as if they were being raped by dogs.
What credit do they need? If anything, here’s what they need credit for:
It’s not a long list, but it’s got devastating amounts of punch to each bullet. You simply cannot under-estimate the importance of each of these. And, I strongly encourage the use of dynamically-typed languages for precisely these purposes.
But, neither of these items eliminates the need for static typing in a large-scale development project. To re-use your own words, that is simply a fact.
Thank you for reading.
It seems like you’re talking about statically-typed languages, not strongly typed languages. Python, Ruby, and Smalltalk are strongly typed, but they’re strongly typed at runtime not compile time. The checking still happens, it’s just delayed.
It’s like the space of typing is two dimensional. On one axis you have weak versus strong (weak means that invalid accesses can corrupt the program) and the other axis is dynamic versus static.
Clearly, a controversial topic ;)
I’ve moved into the dyno camp (and yes, Carlos is right that we’re really talking about dynamic vs. static typing, not string vs. weak. Correct me if I’m wrong, Brett!). I’ll just offer a few opinions and observations.
First, we need unit, integration, and acceptance tests. These really are executable specifications when done right. You can’t test documentation. That’s a fact! ;) (Okay, you can manually test it, in some sense.) Someone, maybe even Uncle Bob, said that automated tests are even more essential for dynamic-language projects to succeed than they are for static-language projects.
I think of a static language compiler as the syntax checker, whereas the proper use of the software is more like semantics, which only tests can validate. With dynamic languages, your tests have to cover more ground. The design is tested by practices like Quick Design Sessions, Pair Programming, and automated “torture testing” (e.g., for performance and concurrency flaws). Sure, in really big projects, there’s more ceremony than that.
So, why give up at least the “syntax checking”? Because you can be so much more productive with a dynamic language that you finish sooner, even if you’re writing more tests! I recently finished the first release of an <shameless-plug>AOP toolkit for Ruby called Aquarium </shameless-plug>. It’s amazing to me how much one guy can accomplish in Ruby compared to what I would have to do in Java. In fact, in Java they had to invent a new language to do the same things, AspectJ, although you could hack byte code, if you dare…
For a better example, consider Rail’s ActiveRecord, one which illustrates brilliantly how metaprogramming should be used to provide “missing methods”. AR provides all possible query methods for a “model” object in MVC, plus attribute getters and setters, using metaprogramming. The productivity savings are vast and the issues you raise, Samuel, are avoided by a good design and well-understood conventions.
I understand Samuel’s concerns about large teams and production quality, but I believe those problems reflect team and individual deficiencies, more than language choices. Some of the Java and C++ shops I’ve seen aren’t being helped by static typing! Also, let me be candid; I’d rather fire (or reassign) any developer who isn’t good enough to be effective with Ruby or Java. I’d be better off in the long run, anyway.
Where are the big dynamic-language projects? I’m not sure, but Paul Graham got rich writing an ecommerce system in Lisp that he eventually sold to Yahoo! There are some reasonably large Rails- and Django-based web sites. Anyone know of some good examples??
Finally, Brett mentioned using multiple languages, e.g., where most of the app is written in a language like Ruby and the “hot spots” are written in C. Let me emphasize just how valuable mixed-language programming can be to give us great productivity and acceptable performance. Ruby makes this easy and people are writing number-crunching applications this way, for example. I think we’ll see polyglot programming increase, too.
So, yes, there are tradeoffs, but I believe automated testing + polyglot programming + faster computers will finally make dynamic languages more globally accepted.
Paul Graham also used Lisp’s optional static typing, if I recall, especially when it came to optimize parts of the code for performance.
I want to make it clear that I’m neither anti-dynamic typing nor pro-static typing. I use, and enjoy, both types of languages daily. (I am even a large fan of Forth, a completely typeless language!)
But, unfortunately, as development teams get large, you cannot just fire one guy, because his replacement is likely to be no better. Static type checking becomes an important factor towards minimizing mistakes that could make its way, unit testing or not, into the customer’s hands.
Remember, we’re all humans, and humans have a nasty propensity for making mistakes. :) Type checkers exist to help mitigate the consequences of type-related mistakes. I just don’t see static typing as harmful. I do, however, see “angry apologists” as being sorely counter-productive.
BTW, languages like Java and those in the C family are not particularly good expressions of statically-typed languages. They’re mandatory type annotations are holdovers from the 60s. If you want to explore highly productive, yet statically type checked languages, I encourage you to research OCaml and Haskell, where type inferencing makes a huge, huge difference.
It’s a common misbelieve that inheritance has someting to do with typing. It has not! It’s true that languages like Java misuse the one for the other but that’s just accidental. Take ML: Totally strong typed, no inheritance whatsoever.
Samuel, I agree with the spirit of your reply but I really feel that once you get into a situation where you “can’t fire one guy because his replacement is likely to be no better,” nothing is going to save you right now. Static typing in today’s popular languages can be a great tool, but it’s definitely not a prophylactic against the inadequately skilled.
That said, the ML derived languages may be. From a maintenance point of view, the cool thing about them is that you can’t even edit them unless you some base knowledge Hindley-Milner typing. So, I bet you end up with better code, not because of the typing checking itself, but because those languages raise the bar.
People passing through a neighborhood hate speed bumps. People who live there accept them as a necessary evil. Likewise, researchers and consultants hate static typing because they spend their time writing software, not living with it.
The average large project developer spends very little of their time writing software. A number of studies have shown this, most recently a presentation I saw from Microsoft Research.
The majority of their time is spent coordinating with other developers and reading other people’s software and trying to understand it—not only at a mechanical level but also the underlying intentions. “This condition is odd, is it a bug or is it a bug fix?” They don’t complain about missing covariance or contravariance because those only add ambiguity. The more bland, simple, and blunt the language, the better.
Static typing adds a layer of design enforcement to software. It helps to convey your thoughts and intentions and just as importantly, to slow down those who may be tempted to drive through a little too fast.
This isn’t necessary on small or disposable projects but it becomes critical with a larger team. The few experiences I have had or heard about with large, dynamically typed systems always end in the project being replaced with a statically typed language or being scrapped altogether.
Scott, I’d differ just on one point. As a consultant, I spend less time writing software than I do trying to help people change it (refactor). Design enforcement is great, if you have a design you want to enforce. On balance, I’d rather enforce behavior (with tests) and let design vary more easily.
There’s been some interesting discussion recently about pluggable type systems. A similar thing that occurred to me a while ago is that type systems may be a bit too coupled to program structure: http://www.artima.com/weblogs/viewpost.jsp?thread=155960
It’s a direction that might be worth pursuing.
Dean Wampler wrote: “Where are the big dynamic-language projects?”
Some have been done Erlang. The AXD301 (ATM switch) contains over 2 million lines of Erlang code (http://www.pragmaticprogrammer.com/articles/erlang.html). I have heard of another project that has over 0.5 million lines, but I don’t have any references.
Kind regards
@Peter, thanks for the Erlang information. Surfing the pragprog page and links, I found a press release that Jabber.org now uses an Erlang server
I really believe you that dynamic languages are better, more productive and everything, but it is also a fact the the average developer is well just average. A great developer can be very productive and write great software in any language. When you say “You can’t get away with as much in a dynamically typed language.” I believe it but I’m not at all sure the average coder has the skills to keep himself out of trouble. It seems really disingenuous to dismiss the developer competency and apathy problems that most of us working for large companies fight on a daily basis.
When I learn Ruby, which I’ve been trying to get to for a while, can I ask you guys for a job? :-)
Yep, sure enough as soon as I posed this, Tim O. was kind enough to let me know I dropped the ball. I really did mean statically typed languages, not strongly-typed languages.
Pretty big difference, I know. I’ll have more to say regarding Samuel post! I just have to work through it.
@Richard, this is a legitimate concern, but I think there is hope ;)
Rails provides a good example. The internals of Rails utilize some sophisticated metaprogramming and other constructs, the sort of stuff that only the best developers can write successfully, but the external API is simple and elegant. As a result, there are a lot of web developers with limited programming skills who are successfully writing Rails apps.
This works, in part, because Rails exposes several of it’s APIs as intuitive Domain Specific Languages. I think the average development team can be successful with dynamic languages if they design them to encapsulate the “hairy” stuff that the best developers work on, while providing intuitive APIs that the rest of the team uses. Of course, this along won’t guarantee success, but I think it will help a lot.
Brett:
Man, you just had to go and do it. You just had to kick the hornets nest. And not just a little kick, no… you had to go with the most inflammatory title you could, and then a bunch of generalizations so broad they can’t possibly be true.
I move back and forth between a dynamically-typed language (Matlab) and a statically-typed language (C/C++) at work. Each has its advantages.
The advantage I’ve experienced with statically-typed languages is that they reduce the burden of developer testing at the expense of flexibility. Dynamically-typed languages do the opposite—they increase the burden of testing, and in return, you get some flexibility.
I’ve really enjoyed working with Objective-C, where I can choose—after all, I don’t always need the flexibility of dynamic typing, and it’s nice not to have it when I don’t need it.
Which is better? I don’t know… I do know it’s going to take more than “isn’t flexibility GRRRREAT!?” posts to make up my mind. How many errors are really type errors? How much does dynamic typing increase the testing burden? How does that increased test burden scale with the size of the program? linearly? exponentially? What sorts, and how much flexibility do we lose with static typing? Examples?
These are the sorts of questions you need to answer before you enter this war. Otherwise, I think you’re just adding to the mayhem and name calling.
Finally, I really think you should retract your statement about the “compiler offering a false sense of security”. Your anecdotal experience is just that, anecdotal. Automated testing is very much alive in the statically-typed world. Sure, you can find people who don’t understand or believe in its value, and MAYBE you can even find people who think the compiler can completely substitute for automated tests (I haven’t met them), but that’s a straw man.
To Nathan:
Whenever I see the word “anecdotal” my mind insists on translating it to “I can’t prove my strongly held opinion, so I’m going to try to invalidate your strongly held opinion by calling it ‘anecdotal’.”
I agree with Bret in saying that static typing gives (most) developers a false sense of security. There’s a reason for that: compiler type checking is totally useless if you don’t have distinct types to check.
When I look at a program that uses strings, integers and library types to mean multiple different things I see a program where the compiler can’t detect a large fraction of the possible misuses of the underlying conceptual types. Then when I hear the responsible developer claim that static typing finds errors I’m kind of baffled: he clearly doesn’t know what he’s talking about, but is utterly convinced he does.
John Roth
You’re brushing a major question under the rug here: how much do you have to test? How much unit code test do you have to generate for each behavior?
The weaker the type system, the more you’re going to have to test.
Consider, for instance, the case of nulls. If a method is not supposed to take nulls, the dynamic typed language is going to have to check each argument to make sure it does some kind of error handling. Either that, or you can leave a big gaping whole which will come back to bite you. And when it does bite you, it will bite you through displaced explosions: the error will be at one place, but the ultimate explosion will not be until much later. I’ve got an example of this on my blog: http://enfranchisedmind.com/blog/archive/2007/06/13/255
If, on the other hand, your system has compile-time null type checking, then I don’t have to write a single line of code to check that: if it’s not supposed to be nil, but it could be, it’s a compile-time error.
So, in short—yes, you are right. Given sufficient unit tests which are being run regularly, static typing is a redundancy. But from a practical point of view, the compiler is a significant time-saving tool.
To the first commentor, who is looking for a large system written in a language without strong types, look no further than the US Courts’ case docket system, which is written entirely in Perl.
Reddit has been written in both Lisp and Python. The Bazaar Version Control System is written in Python and is over 100 KSLOC. These are just a couple of examples that jump to mind.
John,
You need to rethink the way you analyze arguments, and develop a more critical approach. When a claim is made about “how things of type A behave under circumstance B”, and no statistical evidence is given, such a claim should be assumed to be anecdotal until it is proven otherwise. The burden of proof is his, not mine, therefore my objection that it is anecdotal stands until refuted.
Also, you’re wrong about my trying to “prove a strongly held opinion”. I was not trying to prove some claim like “people who use statically typed languages are TOO just as careful”. Rather, I was criticizing his argument for the claim that they are not. I don’t believe a critical reader could read my post and say “aha, Brett is certainly wrong about statically typed languages”, but rather, hopefully “Brett’s argument about statically typed languages and developers who use them is invalid”
This reminds me of an article written about Stephen Wolfram and his “automations”. The author used “automation” in the title and throughout the document.
In this case, however, you’ve confused several different phrases and made some extrapolations that are simply incorrect. I suggest reading up on type inference, pattern matching in ML, polymorphic variants in OCaml and type classes in Haskell.
To the first commentor, who is looking for a large system written in a language without strong types, look no further than the US Courts’ case docket system, which is written entirely in Perl.
Some language definitely require more energy, but i guess it’s part of the game. If one was perfect, we would all be using it. I think it’s a great article and i loved reading the discussion that followed, strongly typed languages (well C/C++ for me), sure can be a lot of work some time, we have to play along i guess :)
Thankfully there is strong type checking in C++ whereas in Python, a single object referencing scheme can be use. A strong type checking in C++ is very important for C++, but “compile-time” checking in Python would be much less valuable.
I agree that Ruby sintax is quite nice, and can save a lot of time during development (Not so during maintenance). Anyway, there is a feature that is a great time saver in statically-typed languages such as java, that I don’t think is even possible in pure dynamic languages such as Ruby. And that is autocompletion. Well, you need a nice IDE, but nowadays there are dozens of them (Eclipse is my favorite). I just write the label, a dot, and I get a contextual list with all the available methods for that object. Is that even possible in Ruby? First, is that classes are dynamic, so you can’t be sure which methods are available at write time (You may know at runtime, but I normally don’t write code at runtime) Even more. It is impossible for the editor to know the type of the objects, so autocompletion is by definition impossible. You have to find the class definition, search in the code and figure out the kind of parameters it expects (Or read documentation if you are lucky and there is documentation). This luck of write-time helpers may not be a big problem with your own code, but may be much worse in a big work team, and a complete nightmare with third party libraries.
we all drop the ball here and their the trick is to keep picking it up , than magically after a while automation truly sets in
great share about,.. it “Strongly Typed Languages Considered Dangerous”,,.
great share about,.. it “Strongly Typed Languages Considered Dangerous”,,.
n an inheritance hierarchy, the types of the formal parameters or return type in
think it, do it. finish it.
Thanks for your share. If you have any news about iphone 4 white plz tell us, i will be really appreciate.
This is just one way a dynamic language can speed things up. There are others and they are happening NOW.
GHD australia have fairly very rated for rather a few of elements just like pattern durability and ease of use.
GHD australia have fairly very rated for rather a few of elements just like pattern durability and ease of use.
glad to see you!
glad
i’m glad you presented this topic. thanks for sharing!
Thanks for shareing! I agree with you. The artical improve me so much! I will come here frequently. Would you like to banckup iphone SMS to mac, macBook, macbookPro as .txt files? Now a software iphone SMS to Mac Backup can help you to realize it.
I really like this essay. Thank you for writing it so seriously.
FREE SHIPPING
To be, or not to be- that is a question.Whether ipad bag tis nobler in the mind to suffer The slings and Game Controllers arrows of outrageous fortune Or to take arms against a sea of troubles, And USB Gadgets by opposing end them.33333333
Our company is engaged in the professional manufacturer of damper, air cylinder, oil cylinder, and hydraulic station. The company has many year’s production experience and strong technical power.
thanks a lot.
?nternette görüntülü olarak okey oyunu oyna, gerçek kisilerle tan?s, turnuva heyecan?n? ya?a.
Good writing, this article bring me a lot. Your blog is great, thanks for sharing.
Good writing, this article bring me a lot. Your blog is great, thanks for sharing.
Good writing, this article bring me a lot. Your blog is great, thanks for sharing.
Online UK costume and fashion jewellery shop with, Online UK costume and fashion jewellery shop with, Online UK costume and fashion jewellery shop with, Online UK costume and fashion jewellery shop with,
Good writing, this article bring me a lot. Your blog is great, thanks for sharing.
hmm ,i’m not sure if this is what i’m looking for but anyway this is interresting and could be useful some day,thanks for taking time to write such cool stuff
hmm ,i’m not sure if this is what i’m looking for but anyway this is interresting and could be useful some day,thanks for taking time to write such cool stuff
Great post! Nice and informative, I really enjoyed reading it and will certainly share this post with my friends . Read everything about the gold history and its complex and interesting facts.
useful some day,thanks for taking time to write such cool stuffhigh quality headphones new design headphones
useful some day,thanks for taking time to write such cool stuffhigh quality headphones new design headphones
I am very happy for visiting the nice services in this blog that to very happy for the great services in this blog. This is really admired for this info in this blog and the nice technology in this website
When I at first left a comment I clicked the “Notify me when new comments are added” checkbox and now each time a comment is added I get three notification emails with the same comment. Is there any way you can take away people from that service? Thanks a lot!
No, there’s not much competition between puppeteers in general because everybody’s working their own style.
Thanks CASINO FANS a lot for providing the CASINO ONLINE TALK great info is visible in this blog poker slots just and using the great technology.
With 50 DuoNian history of the French “old” Moncler, http://www.monclerstyle2011.com absolutely is manufacturing and design down jacket of experts, had become France and Italy were HuaXueDui country of necessary costume. Step into the 21 century, Moncler not only to reignite hot, also successfully down by sport jump into fashion, all by brand in for breakthrough revolution,== http://www.monclerstyle2011.com == Haute Couture fashion series launched down, bold innovation design, completely beyond the previous established sports image; Then trigger DuoGe fashion brand with the palace down to partner with cross, successful model a MONCLER today bright, sexy inviting, independent and subtle rebel brand style.
The professional design make you foot more comfortable. Even more tantalizing,this pattern make your legs look as long as you can,it will make you looked more attractive.Moveover,it has reasonable price.If you are a popular woman,do not miss it.
No, there’s not much competition between puppeteers in general because everybody’s working their own style.
Christian Louboutin Rolando Hidden-Platform Pumps Golden is a fashion statement – that’s sexy, it makes you look longer highlight, and it highlights the curves in the woman body and makes the body look more elegant and thinner without any diet.
?Brand: Christian Louboutin ?Material: Golden leather ?Specialty: Signature red sole ?Color: Golden ?Heel height: Approximately 130mm/ 5.2 inches high and a concealed 20mm/ 1 inch platform ?Condition: Brand New in box with dust bags & Original Box
Fashion, delicate, luxurious Christian louboutins shoes on sale, one of its series is Christian Louboutin Rolando Pumps, is urbanism collocation. This Christian louboutins shoes design makes people new and refreshing. Red soles shoes is personality, your charm will be wonderful performance.
Wow, this was a really quality post. In theory I’d like to write like this too – taking time and real effort to make a good article
Hello dude ! I must say, it is one of the most interesting and informative blog I have ever read. Thanks for sharing
Very good to read your most informative article. Its very informative and well written also.
Nicely explained. It’s indeed an art to stop new visitors with your attractive writing style. Truly impressive and nice information. Thanks for sharing.
Nicely explained. It’s indeed an art to stop new visitors with your attractive writing style. Truly impressive and nice information. Thanks for sharing.
An interesting discussion is worth comment.glad i came across your post, very informative indeed.
I simply could not leave your website prior to suggesting that I extremely enjoyed the standard info an individual supply to your visitors? Is gonna be again continuously in order to inspect new posts.
Get to know about C# and C++. In fact, I find there is no much difference between the two. However, If we want to do much better. I need work hard.
Australia Beats By Dre Studio dr dre beats headphones beats studio beats pro beats solo hd pro headphones music Official store Monster Beats By Dre Pro
Very good to read your most informative article. Its very informative and well written also.
Strongly Typed Languages Considered Dangerous 71 hoo,good article!!I like the post!40
I do agree with you. But you need to clear out some points mentioned above.
Here we are providing some useful tips which should be followed when you go trekking or a hiking trip?
With more than 20 years of experience, Intertech provides an extensive integrated operational ability from design to production of molds 100% made in Taiwan. Additional to our own mold making factory, we also cooperate with our team vendors to form a very strong working force in Taiwan.
For the overseas market, we work very closely with local representatives in order to take care of the technical communication and after-sales service to our customers. We also participate in the EUROMOLD & FAKUMA exhibitions and meet our customers every year in Europe. By concentrating on mold “niche markets”, we play a very useful mold maker role from the Far East whenever customers want to develop their new projects. We provide services from A to Z to our customers on a very economic cost and effect basis.