I can’t take credit for this statement, since I am only drawing the logical conclusion from a statement said by a man far smarter than I.
Donald Knuth wrote in his famous paper Structured Programming with go to Statements (PDF):
We should forget about small efficiencies, say about 97% of the time: pre-mature optimization is the root of all evil
Since compilation is premature optimization, it is therefore, the root of all evil. Simple!
Static typing, weak typing, dynamic typing, strong typing, WTF?
There are a number of misconceptions concerning typing.
The meaning of weak and strong typing, is not clearly defined but is mostly interpreted like this.
In a weakly typed language, such as C, the types of the variables can be automatically converted from one representation to another, while in a strongly typed language an explict conversion is required.
This is not what I am writing about here. I am referring to static vs. dynamic typing and the definition I am using is:
- Static typing, the type checking is performed at compile-time.
- Dynamic typing, the type ckecking is performed at run-time.
Development Mode
Every time I build my code, my entire code base is type-checked. EVERY TIME! When I am working in development mode, I only care about the method and class that I am currently working on. As long as my tests pass I am happy, type-safe or not.
In development mode it is actually more accurate to call static typing pre-mature de-optimization than pre-mature optimization.
Production Mode
The only reason, to ever use static typing, is because the code may be optimized better, to give better performance.
So, the strategy should be:
- Use a dynamically typed language during development. It gives you faster feedback, turn-around time, and development speed.
- If you ever get lucky enough to have performance problems, which cannot be solved with caching or algorithmic optimization, rewrite the problematic code in a statically typed language.
This is what Twitter did, and it has worked well for them.
Other Misconceptions
Proponents of Java often have the misconception that dynamically typed languages are unsafe, yet they use frameworks, like Spring, and Qi4J, that are littered with reflective code, and without the so-called safety net that static typing is believed to give. The reason these frameworks are popular is because they allow us to be more productive. The reason they are more productive is because they use dynamic programming techniques.
Anyone, who has worked seriously with a modern dynamically typed language like Ruby or Smalltalk, know that they are more productive. Working with waterfall languages after working with agile languages is just painful. (Thanks to Andreas Ronge for coining the term Waterfall Language.)
It appears however, that Twitter has replaced parts of its back-end with Scala nowadays, which is a statically typed dynamic language.
You can read about the reasons for it in this article:
http://www.artima.com/scalazine/articles/twitter_on_scala.html
Yes, I know Twitter is on Scala, that was one of my points. Twitter was developed in Ruby and after a long time they got the pleasure of having performance problems due to too much traffic. Then, they ported some of their code to Scala, which is not in any way a dynamic language according to my definition above. Scala is, however, a lot more elegant than Java.
Fair enough, but the argument that Ruby on Rails is good for developing web applications is vastly different from the discussion whether dynamic typing is overall preferable to static typing.
I don’t have an opinion about that, since the more I learn about it, the more it seems to be a matter of context, and personal taste.
I believe the biggest win with a dynamic language is when calling methods on object. In C++, and also in the Java programming language (not the JVM) classes are really just structs with functions pointers, constant set of functions pointers at that. Good for speed, but terrible for adjusting classes to the needs of your application context.
In a dynamic language such as Ruby, Smalltalk or Objective-C a class can have methods added and/or replaced at runtime, which leads to much cleaner code. Where should I put a utility method for a vector, if not onto the vector class itself?
That and allowing methods to be treaded as a primitive type, for far cleaner dynamic method dispatching. The method name
onClick()is ALWAYS a worse name than your ownonWhatIActuallyIntend(). Most Java interface are cubes in a world of round holes. Closures is a step closer, but not quite as nice to have.Fredrik: Note that the post is regarding statically typed vs dynamically typed languages and not static vs dynamic languages. It is this that makes a language like scala, which is statically typed, while still keeping most of the advantages of a dynamic language, to end up within “the root of all evil” according to the author.
I have to dissagree with the statement that “The only reason, to ever use static typing, is because the code may be optimized better”.
One of the reasons for using a static typing language is to detect the type related problems at compile time, and not have them popup randomly after deployment.
Actually, the title needs to be corrected. It should read “Ignorance is the root of all evil”, and your post is a good example. It’s “not even wrong”, to use another popular saying.
First of all, when I compile in Java, only the changed class gets compiled, not the whole codebase. If, I’m in debug mode (as I often am during developent) I can then dynamically replace the old class with the new, and try it out instantly.
Second, one of the primary reasons I prefer static typing, as in Java, is because the types allow me to communicate intent. I can tell other developers what I expect from them, and I can see by looking at the types of methods what they expect from me. It saves me, and others, a whole lot of trouble. If you don’t have to communicate with other people, meaning, you’re in your own reality bubble, then this has no value, obviously. YMMV.
Third, for users of Qi4j the reflection is an internal implementation detail. In fact, we go to GREAT lengths to ensure that users deal with statically typed interfaces so as to avoid the typical problems that arise when you can’t communicate intent using types (and there’s LOTS of such examples in invoke-style AOP frameworks). If you had spent five minutes checking this it would be clear to you, but sadly, you obviously didn’t do this. It is always much easier to make up an opinion out of thin air and post it, rather than finding out what-is.
This does not mean that I don’t like dynamic typing at all. In SiteVision, a CMS that I architected, we allowed customers to tweak and customize quite a lot by using JavaScript/Velocity. This was an essential tool, and to use Java for that would have been a bad choice. However, when we made changes to the internal API and made upgrades to the base software it was a NIGHTMARE to check whether any scripts using the old API still worked, since, well, we couldn’t just compile to find out. And no, we do not suggest that customers write tests for scripted tweaks. That would just be plain dumb. If I were to do that feature again I would probably opt for using a language which was statically typed, but which allowed eval-style compilation, so that I could go through all customizations and easily find out which ones had broken with the new API.
Lastly, as I wrote in my article “Quicker frameworks” on the DDD site, what all these so-called “productive” languages are doing is focusing on being “more efficient”, whereas it is more interesting to be “more effective”, as Qi4j allows you to be. It is less interesting to write code fast than to not have to write code at all. Which is the aim of Qi4j, due to the high focus on composability and reusability. Given your conclusion I assume you have not read that either.
As I said, “ignorance is the root of all evil”. And that holds in all walks of life, not just software development.
In a perfect world where applications have a test coverage of 100% there would probably be no need for statically typed languages. But in the real world 100% coverage is unattainable and you can (and therefore will) cheat your way around tests. So, as it is, static typing IMHO certainly adds to the robustness of the application as it is much harder to circumvent than tests and lets you see many errors right there where you write them.
I’m confused. What is the problem with your code being type-checked every time you build it, anway? Takes very little time with modern hardware and compilers, so I don’t have a problem with it.
As for runtime flexibility – well, how often do you actually, really need to add methods to a type while the software is running? I can think of very rare examples, all of which were achieved by other means (e.g., rewriting bytecode, V-tables etc) for that tiny handful of occasions in nearly 3 decades of programming experience.
I guess I have to defend my position :)
@Andreas:
> One of the reasons for using a static typing language is to detect the type related problems at compile time, and not have them popup randomly after deployment.
When did you actually have a type-related problem pop up after deployment?
@Rickard:
>”Ignorance is the root of all evil”, and your post is a good example.
Ouch!
>If, I’m in debug mode (as I often am during developent) I can then dynamically replace the old class with the new, and try it out instantly.
Last time I tried to do something like “extract method”, I got the helpful error message that reloading the class was not possible since adding new methods to a class is not supported. Please correct me if I’m wrong.
>It is always much easier to make up an opinion out of thin air and post it, rather than finding out what-is.
Aren’t all opinions made up out of thin air? An opinion is an opinion and even if others have a different experience, why should I change my opinion based on what other people think?
I’m sorry I haven’t read all the articles you mention, but thanks for pointing them out to me.
@Georg:
> So, as it is, static typing IMHO certainly adds to the robustness of the application
I disagree, I don’t think a statically typed application is more robust than a dynamically typed. It is also a lot easier to get good test coverage in a dynamically typed application where you do not need special mock-frameworks to be able to test the code at all.
@Jason:
> I’m confused. What is the problem with your code being type-checked every time you build it, anyway? Takes very little time with modern hardware and compilers, so I don’t have a problem with it.
I don’t think it takes very little time. In many projects where I have been involved the build times quickly take more than 1 minute.
Ruby is VBScript in trendier clothes and an oversize goatee, imho. The speed and Behind the propaganda the simple truth remains: proper typing is a Good Thing. With a half decent refactoring tool such as ReSharper there are no limitations during development and if you can accept that extension methods obviously only has access to public properties on the ‘this’ object, c# actually gets the job done.
One of my primary reasons I prefer Ruby over Java is that it communicate intent better.
When I work in Ruby I often look at the source code in third party libraries and maybe even modify them. In Java this is
very unusual since it’s so much harder to understand code that some one else has written.
You can also see this behaviour for Ruby projects on GitHub, for example Rails which has nearly 1000 forks of the source code.
Having read Ruby code and then going back reading Java code again is a pain.
I believe a type is often just unnecessarily ceremony which cause problems (you need a compiler, harder to test, tight coupling between components since you declare a dependency using types).
http://blog.thinkrelevance.com/2008/4/23/refactoring-from-ceremony-to-essence
Maybe it is a bit like the checked vs. unchecked exception debate.
One mistake I did when I started writing code in a Ruby was creating types for everything. Instead, it’s common to use arrays and hash (key value) data structures
which you can let your objects mimic when you need a type (e.g. by using Mixins).
I also believe based on own experience that big refactoring in dynamically typed languages is easier to do because
1. Some times it’s not even needed to do a refactoring because of duck typing.
2. You don’t have to do a big bang fix of all compilation errors before running your tests. A soon as you changed everything you can run your tests again
3. Your test code is more likely to survive a big refactoring. I think this is because it is not so tightly coupled with the producation code by a type system.
A common belief is that static typing is better for building large systems. That belief is out of thin air us much as any thing else.
What we want is strong testing, not strong typing as Bruce Eckel writes http://mindview.net/WebLog/log-0025
and readable code that communicate intent. The only way to get convinced is to use a language like Python/Ruby in a real project.
There are also other advantages which is not directly related to the language.
In a language like Ruby there is less need (or no need at all) for complex tools and frameworks like IDE, IoC/AoP frameworks, utility libraries, etc.
Even if a tool or library is needed it is usually much less complex and easier to configure (configuration is code – DSL)
In bigger Java project is not unusual to use 100-1000 external jar libraries, complex application servers.
A lot of problem in big Java projects is related to configuring IDE, build tools, over use of XML (spring/WEB-XML, etc..)
Having used Ruby tools/frameworks and going back using Java tools is also a big pain.
Anders, thanks for your feedback. Based on your input I got new information, which helps me to change my opinion, since I now understand that it was not accurate. It is this type of exchange that enables us both to grow and learn new things, so that we are not stuck in opinions that don’t match reality. So, given this I’ll have to rephrase myself: “Persistent ignorance is the root of all evil”.
@RickardOttosson
>Ruby is VBScript in trendier clothes and an oversize goatee, imho.
I have no experience with VBScript, but I know that Joel Spolsky are using Wasabi, their own dialect of VBScript to develop their flagship product.
>The speed and Behind the propaganda the simple truth remains: proper typing is a Good Thing.
In your opinion.
@RickardÖberg
> “Persistent ignorance is the root of all evil”.
Actually, I think the saying goes “Ignorance is Bliss”
I’m basing my opinion on personal experience, many years with statically typed, and a few years of dynamically typed languages.
@Andreas
Hear, hear!
I have full respect for a lot of reasons that Twitter could have had for switching parts of their stack from Ruby to Scala, but those are not the reasons they give. Instead, the argument they use for moving to Scala indicates that they never understood the language they used, and to some extend even miss important facets of Scala, which of course is a pity.
I wrote some thoughts on the “Twitter moves to Scala” interview a year ago here: http://niclasnilsson.se/articles/2009/04/06/comments%2Don%2Dtwitter%2Don%2Dscala/
Rickard’s arguments about using static typing to communicate intent is an argument I like. From an API and/or framework perspective, it becomes even more important, and static typing also makes some tooling easier to create. This is one of the weakest things with a dynamic language, both when it comes to expressing a certain kind of intent and certain kind of tooling.
(Side note: I still think static typing is a very small piece here. Intent for the order methods must be called and such is still a big problem only solved by documentation in the mainstream. One approach that at least helps a bit that I myself prefer as developer documentation is to expresses it executable BDD-style specs with nice declarative output, with the possibility to open the spec/example to see the details, but it would be nice to have a declarative, machine interpretable way to document these things too).
However, I do not see the point in comparing a framework, like Qi4J, and a general purpose programming language? To me, Qi4J is very nice implementation of a kind of style (mixing / weaving / Composite Oriented Programming), but that’s a style that can be implemented in more or less any language. Some languages fight the style and makes it hard to create a framework like Qi4J, other languages makes it easier, and if the language helps or resists actually has very little connection to the axis dynamic vs. static typing. Composability can be easy or hard in both kinds of languages. I fully agree with the points on efficient vs. effective, but I fail to see why the use of a dynamic language can not be as effective (even though the approach differs a bit)?
In the best of all worlds, I’d like to pick and choose when I want to have static typing and when I want dynamic typing. I’d like to turn it on and off in different phases of my development, and I’d like to have some interfaces more statically typed, or at least checked that they correspond to an interface, but I’d be happy if it’s duck typed, kind of like the approach Go took (if I understood it correctly). Also, (since this seems to turn into a nice collection of links as well), I think Ola Bini has an interesting point here: http://ola-bini.blogspot.com/2008/01/language-explorations.html
Kind regards
Niclas Nilsson
—
http://niclasnilsson.se
http://twitter.com/niclasnilsson
After 15+ years of experience developing systems in statically typed languages (C++ and Java) and ~3 years with dynamic languages such as Ruby and Javascript, for me the main difference comes down to basic joy of use.
Developing in Ruby feels much more elastic, kind of like using modeling clay to build something. You change it a bit, get immediate feedback, change it some more, and before you know it you’re done.
With languages like Java, the modeling clay has a scaffolding around it that you need to move and alter before you’re allowed to touch the actual clay. So much of your day goes by tinkering with the scaffolding that you think it’s normal and necessary.
Or perhaps it’s more analogous to a bike with training wheels. They give you a sense of safety and comfort, but in reality they are what’s keeping you from going faster. Don’t be the kid who builds larger and fancier training wheels in order to go a little bit faster (would this be Scala in this analogy? :), try losing the wheels for a while and see what happens.
This is how it feels to me, your mileage will vary, of course.
Hi
Thanks for a fun discussion. I’m developing Android demo application (Eclipse + Java) and I don’t really have ‘walked over’ this problem, yet. Although I have some own opinions about the ‘root of evil’ in traditional embedded realtime system, the app monolith and the lack of a real DB. When will DLL appear in this world?
“modern dynamic language….like Smalltalk” – now that’s funny
It seems that your main argument is that you are willing to give up correctness, or spend a good amount more time developing tests, in order to feel less constrained by the type system.
I believe argument is based on some false assumptions. The first would be that static type systems must constrain you more than a dynamic type system. This indicates to me you have not tried a language such as Haskell where very little such constraints apply. You are probably basing these opinions on our mainstream statically typed OO languages such as C#, Java, etc…
Second, that unit tests adequately make up for the loss of static typing. Again, in Haskell for example it is very rare that your program does not work the first time it compiles (often the only errors you will find are bugs in the FFI and imperative libraries). There are a lot of unit tests that you essentially get for free without being constrained hardly whatsoever by the type system.
Third, I find I am quite productive and can produce good software with just about any language, paradigm, type system, whatever. The problem starts when you have to work on a team with other people and/or the code base grows to a certain size. You can’t always rely on everyone to write comprehensive unit tests. You can’t always predict how code is going to be used in the future. You are not always going to be working on a team with 100% l33t developers who don’t go home at night unless everything is perfect. I can’t imagine how difficult it would be to create a large multi-team solution in a dynamic language with developers picked from all skill ranges.
So in the end I would say I strongly disagree. I believe you can have the benefits of both static typing and whatever freedom you might feel from dynamic languages. Haskell’s type system is a prime example of this.
@Niclas:
>Rickard’s arguments about using static typing to communicate intent is an argument I like
Yes, I agree with that too. Intent is a good argument.
>I do not see the point in comparing a framework, like Qi4J, and a general purpose programming language.
I wasn’t trying to compare languages and frameworks. I was just trying to show that the frameworks, that everyone sees the need for in Java, are based on dynamic programming techniques.
>I think Ola Bini has an interesting point
I read Ola’s article and one thing I think is interesting is that the programming stack Ola is writing about is reversed from, for example, Spring. Ola is talking about the bottom layer being static and the top layers being dynamic, while in Spring the bottom layer is dynamic, and the top layers are static.
@Rick:
> “modern dynamic language….like Smalltalk” – now that’s funny
I wasn’t trying to be funny. It just shows how much before it’s time Smalltalk was, and how a dynamically typed language can evolve, since you are able to change the language itself without releasing new versions of the langugage.
@Nathan:
Haskell is actually my favorite statically typed language. I have, however, never written any major application in it. Moreover when I tried to use HAppS (http://happs.org/), the Haskell Application Server , the types really got in my way. So much so, that I never actually finished the task that I had set out to do.
I know that unit tests, won’t give me the same security as a static type checking will, and I think that QuickCheck is beautiful. But I’m willing to forego that for the ease of development, the flow, that I get when programming in dynamically typed languages.
It’s quite alright for you to strongly disagree :)
Here’s a quote that I like.
I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing.
– Alan Kay
> I wasn’t trying to compare languages and frameworks
No, but I think Rickard was?
Kind regards
Niclas
—
http://niclasnilsson.se
http://twitter.com/niclasnilsson
I appreciate your response. I did not mean to make it sound like I think Haskell is perfect, as it has many other lofty goals such as purity and laziness that can be painful. But strictly in the context of static typing, I don’t feel that it is responsible for the pain and often gets a bad rap just because of poor implementations.
I once heard of a solution where a dynamic language would provide static type checking as a form of an IDE tool, and not necessarily as part of the compiler (like refactoring, etc…)
I mean when it comes down to it, languages such as Ruby/Python are strongly typed. So if the type doesn’t get in your way during compile time it is possible that it will at run time :) If not, then that is an artificial limitation of that particular implementation. Hence, my disagreement that static typing is the root of all evil. I think there is a more fundamental cause of this evil you speak of.
Pingback: itemprop="name">Is Static Typing the Root of All Evil? « Dariusz Cieślak's Blog on Software
It is funny. People arguing dynamic typing is superior often forget what they really want from dynamic typing. They need “dynamic behavior”, which is a side-effect of dynamic typing. What about if you can have “dynamic behavior” in static typing? Do you still need dynamic typing?
The following article talks about dynamic behaviors in both dynamic typing and static typing (http://www.codeproject.com/Articles/316325/Dynamic-Behaviors-Or-Dynamic-Typing). See also “Object Decoration – Solution to Runtime Behaviors for Compiled Languages” (http://www.codeproject.com/Articles/320066/Object-Decoration-Solution-to-Runtime-Behaviors-fo)
I’ve been using both statically and dynamically typed languages, on and off, for more than 20 years – to me, it’s not a contest between static and dynamic typing, but a matter of striking a balance.
In my experience, statically typed languages require more time and effort, but produce code that is safer and easier to understand for a consumer of your API – whereas dynamically typed languages lead to code that often runs on “assumptions” and may require more testing, but generally is faster to write and easier (but not as safe) to refactor.
Ideally, we should have access to static typing when it benefits the developer and/or consumers of libraries – and dynamic typing when things need to “gel” and you don’t need your “training wheels”.
To me, the best language would be one that provides both, and lets you use as few or as many typing barriers and safeguards as you see fit.
An interesting language to check out is Opa – it is statically typed, but it writes like a dynamically typed language, because it performs deep (regressive) static analysis for type inference. Worth a look:
http://opalang.org/
@Rasmus, I appreciate your balanced comment on this rather flaming topic.
I agree that it is definitely a tradeoff and I sure miss the refactoring support and the simple code navigation especially when navigating a new code base.
I will take a look at Opa, it sounds interesting.
My personal compiled favorite at the moment is Go. It has the feel and a compilation speed of a dynamic language.
I agree, Go is definitely interesting – I’ve been lurking for years to see where this goes, but unfortunately (I feel) it has not exactly seen explosive development.
Dart also has some very interesting aspects to it, and seems to have come much further in some areas, IDE support in particular.
It would probably make sense to dig into either Go or Dart at this point – but I’m holding out for (proper) IDE support for Opa, which (in my opinion) is much more interesting specifically for web-development, and has been the language I follow up on more frequently (these past couple of years) than any other.
IDEs are brain damaged.
Now that you’ve had over three years to reflect on this non-sense I hope that you have changed your tune and have given some respect to the other side of the argument (or even just learned the other side for that matter).
@Eric, I’m sure that you, in your wisdom, can enlighten me. But, calling something stupid doesn’t make it so. If you like this article, perhaps you should read another one I wrote, http://blog.jayway.com/2011/01/09/dynamic-for-the-win/
The world of programming moves increasingly towards dynamic programming languages, check out the statistics for Github as an example,
http://adambard.com/blog/top-github-languages-for-2013-so-far/
If you don’t agree with me perhaps you haven’t spent enough time with dynamic programming languages?
@Anders: Do you mean to tell me that you STILL stand by what is written in this post? Let’s look at some of the things you are saying:
“The only reason, to ever use static typing, is because the code may be optimized better, to give better performance.”
That is obviously just wrong!
“Every time I build my code, my entire code base is type-checked. EVERY TIME!”
Where did you get your compiler? From a Cracker Jack Box! Modern compiles don’t do that. It’s funny how me, in my wisdom, knows this when your silly blog post clearly demonstrates that you don’t. Also, modern type checkers run very, very, very fast — it not a problem, really.
“The world of programming moves increasingly towards dynamic programming languages…”
You must be under the impression that:
popular == right
That statement clearly doesn’t type check and is just completely wrong.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
But please don’t take my word for it just type into Google something like “benefits of Static Typing”. Read (Yes please read) about very smart people from all over the world including top Google, Microsoft, Apple, Twitter, and Facebook, engineers stating their case. Then come back and edit this silly post if not to change your stance but at very least to give some deserved credit to all the work that been going on in the advancement of static type analysis.
Boy, I’m astonished by the people who consider themselves software “experts” in this day and age.
@Eric or is it @Erci?
The post as you may tell from its title, is a bit of a flame bait and it seems
to have annoyed you. I apologize for that! But, a good thing about flame bait
is that it triggers a discussion. I have more comments on this post than any
other post, including http://blog.jayway.com/2012/03/23/braceless-programming/,
which also seemed to annoy people.
> “The only reason, to ever use static typing, is because the code may be
> optimized better, to give better performance.”
>
> That is obviously just wrong!
Yes, I agree that this is wrong, perhaps not obviously so, but still. A better
argument than saying it is obviously wrong would be to say that it is wrong
because static typing helps with documentation, to communicate intent, and to build better tooling.
I’m aware of these benefits, but I am still more productive working with dynamic languages.
> “Every time I build my code, my entire code base is type-checked. EVERY TIME!”
>
> Where did you get your compiler? From a Cracker Jack Box! Modern compiles don’t
> do that. It’s funny how me, in my wisdom, knows this when your silly blog post
> clearly demonstrates that you don’t. Also, modern type checkers run very, very,
> very fast — it not a problem, really.
The entire code base is checked by the compiler every time, but it only needs to recheck the changes. It still means that everything must be have valid
types, even if I’m just trying to figure out a simple change in a small part
of the system I have to worry about if it type checks with something I don’t
even care about now. I’m OK with the system being inconsistent while I am
developing.
> “The world of programming moves increasingly towards dynamic programming
> languages…”
>
> You must be under the impression that:
> popular == right
> That statement clearly doesn’t type check and is just completely wrong.
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
The statement doesn’t type check… yet, you are trying to make the same
argument by including the link to the TIOBE index, perhaps you like dynamic typing after all :)
> But please don’t take my word for it just type into Google something like
> “benefits of Static Typing”. Read (Yes please read) about very smart people
> from all over the world including top Google, Microsoft, Apple, Twitter, and
> Facebook, engineers stating their case. Then come back and edit this silly post
> if not to change your stance but at very least to give some deserved credit to
> all the work that been going on in the advancement of static type analysis.
I just Googled it and I came up with many interesting articles in favor of both static and dynamic typing. Here are some hits form the top ten.
* http://gnuvince.wordpress.com/2008/02/15/static-typing-%E2%88%A7-dynamic-typing/
* http://martinfowler.com/bliki/DynamicTyping.html
* http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages
> Boy, I’m astonished by the people who consider themselves software “experts” in
> this day and age.
I’ve never claimed to be an expert, but you seem to think I am one (at least an “expert”). So thank you!
I’ve worked with many different programming languages, both static and dynamic.
Here is some of my experience (Some of the languages overlap, I have only
worked professionally with programming for 18 years):
* C (6 years)
* Java (10 years)
* C# (3 years)
* Javascript (10 years)
* Ruby (10 years)
* Haskell, Smalltalk and Lisp (Never professionally, but a lot on my spare time)
Currently I do mostly web development and I am most productive when using Javascript and Ruby.
The languages I find most interesting right now are:
* Go, a statically typed language that has the feel of a dynamic language.
* Clojure, a Lisp hence dynamic.
It would be interesting to hear where you come from since you are so adamant about static typing being good.
In a language like Haskell, you can leave parts of your code un-type checked if they are the bits you aren’t currently working on.
This can be achieved with undefined (which always type checks) and, more recently, with type holes, which are even kind enough, that upon being executed (by accident, seeing as you did not intend to run this part of your code), will tell you what type should be there, and why it thinks that.
Development is not impeded by a good type system. It just leaves you with warnings if you need to come back to something later. You let the machine do the hard work.
@AnonCoward, I have never written a significant system in Haskell but I have already felt impeded by some of the typing. particularly when trying to solve issues related to the expression problem, which I wrote about here, http://blog.jayway.com/2013/06/21/15201/ How do you solve this type of problems in Haskell?
Static typing the root of all evil? Static typing will remove an entire class of mistakes a programmer may create from a program simply by not accepting it for compilation. All of those will eventually show up at runtime. And unit testing will not catch those kind of mistakes!
So you would prefer to drive a car where the airbag or the brakes are controlled by a dynamic language? Sit in an airplane with some type error. Not much of a problem because that won’t happen that often. Maybe once a year under strange conditions. Who cares anyway about them. We could just reboot the device and go on.
Dynamic typing maybe a nice idea for scripts less than 100 lines of code that won’t get reused. For anything that has to work reliably every automatic check that can detect errors will be quite helpful!
@Jack, I can’t remember the last time I saw a runtime error due to invalid typing in a dynamic language. It is simply not a problem as I see it. I suppose you have a different experience.
If you really have never written a type error in production, then I don’t see why you should be afraid of inferred static typing :P. At the least, you get free unit tests, and the same productivity because you don’t have to worry about annotating anything. And if you always use the right types,then the type system won’t ever get in the way :)
If you ever feel frustrated by the type checker…it is probably because your code doesn’t work. Think about it…if it doesn’t typecheck, what makes you think dynamic typing would help you with? You can compile and bypass the typechecker…but it’ll just “dynamically” fail at runtime :)
The big revelation for me was when I realized that every hour I spent wrestling with the typechecker was actually substituting for two hours of runtime debugging. And five years. Code that doesn’t typecheck is code that doesnt work in runtime. The problem doesn’t magically go away when you skip the typechecker.
And if you claim your code always types correctly in runtime…then you wouldn’t ever be wrestling with a type checker :)
Also, types in Haskell do much more than provide static checking…they are also the framework by which many powerful and productivity enhancing and amazing abstractions can be built and used, many of which would be impossible to meaningfully even consider in a dynamically typed language.
@Justin, I agree that Haskell is a beautiful language and I love to solve specific kinds of problems with it. But, I think it is a problem if a program has to be type correct to run. When a program fails during runtime I have a lot of information that is not available to me at compile time.
I can develop the program incrementally and fix the problems one at a time as they come up. Having to make sure that an entire system type checks during development makes my development speed slower. Your experience may be different!
Pingback: itemprop="name">Object Typing — Static, Dynamic, Generic - Women Who Code