31–40 of 192 posts
49 undergraduate students working independently on a small project over the course of a single week using a previously unseen language with no consideration of the performance or maintainability of the resulting code. I can't see how there are any meaningful conclusions to be drawn from this study other than "inexperienced programmers find learning new dynamically typed languages easier".
I once read an article about a technique Intel had developed for improving cooling of processors by changing the shape of the fan. I related this to some of my co-workers. One of them proceeded to tell me that this can't possibly work, backing up his argument with "reasoning" based on off-the-cuff remarks about the way air and physics "must" work. The fact that Intel had actually done this seemed to have no effect on his eagerness to continue the "debate" about this scientific fact.
I have a hard time believing that I get no benefit from using Haskell over Smalltalk, but if a body of science were to appear that cast doubt on that belief, the appropriate thing to do is change the belief, not stand around debating from imagined first principles why all the science is wrong and can't be so. Shut up, design an experiment and go prove it!
Perhaps there's little of this kind of actual science in our computer science because it would mean asking hard questions and accepting difficult truths. "The prisoner falls in love with his chains."
1) a REPL. Just give it a whirl and see what you get.
2) intuitive method names and good abstractions. If I call @user.posts in a Rails app, I can assume I will get an Array-like object that I can treat as an array without any problems. The actual type does not matter 90% of the time.
Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously. It's easy to hold a mental model of the code you write in your head and minimize mistakes, it's harder to hold a mental model of a larger program consisting of code written by many programmers. I'd like to see them hand a pre-written codebase of say,…
Absolutely.
And also: static typing benefits is not about "development time" but about maintenance, adding stuff, refactoring etc.
If anything, dynamic typing would be expected to lead to faster development time, which is also why it's used in most prototyping.
Lastly: small sample. Did enough of them use an editor/IDE that could take advantage of a static type system?
I recently talked to a friend of mine who expressed the frustration of not knowing what a function returns because it's a language without static typing. It was something I hadn't thought of before personally. I thought about it a bit and realized that as a Ruby programmer, I depended on two things to figure out what a function returns, and neither is the source or documentation (most of the time at least): 1) a REPL…
For the benefits of static typing I would rather look into something like Haskell which has a much stronger notion of type and builds many language features around this notion. It's probably harder to design a reasonable study comparing that with for example Smalltalk, though.
so, by swiching from python to haskell, you can get code that's 20x faster for no extra development time? sounds like a win to me. (cherry picked shootout data - http://shootout.alioth.debian.org/u32q/which-programming-lan... )
Not to mention being able to rule out large classes of errors at compile time, and ease of refactoring large code bases. You mean I get all that for free? Where do I sign up?
The study may or may not be flawed, but what's really interesting to me is the reaction. We need more science in our computer science, which means more experiments and more results like this. We should also be open to the truth that we use the tools we like because we like them rather than because they're technically superior, even though we pimp them ad nauseum as though they are. I once read an article about a tech…
so, by swiching from python to haskell, you can get code that's 20x faster for no extra development time? sounds like a win to me. (cherry picked shootout data - http://shootout.alioth.debian.org/u32q/which-programming-lan... )
Not to mention being able to rule out large classes of errors at compile time, and ease of refactoring large code bases. You mean I get all that for free? Where do I sign up?
My big problem with this study is that the project sizes and teams are too small. Static typing really starts to get it's power as the team and project get bigger. This is especially true as the skill levels from larger teams start to spread from amazing all the way down to terrible. In smaller teams you can often work with higher quality developers, but with larger corporate systems, you don't have that luxury. You…
I work for a fortune 20 company and my last employer was a fortune 10 company. My experience is the opposite of yours. I've never seen these consistent wins you talk about, despite my years at some of the largest corporations.
Someone mentioned maintenance, so I will also ask how old the codebases that you're working on are? For dynamic typed languages, as the code grows older (with more bug fixes and add-ons and one-offs) then it gets harder and harder to maintain as 100% error free (let alone debug).
I will also throw in the fact that doing software library version upgrades on dynamically typed systems is a pain in the ass. Some code branches have system level calls changed, and unless you have very good unit test coverages (which may or may not need to be re-written on a library version upgrade) then you may or may not catch the problem during the upgrade. With a statically typed language, a static analysis tool can tell you exactly where and how the library or interface upgrade affects your codebase.