So here's my topic of debate: Static-Typed languages versus Dynamic-Typed languages. I'm going to place Groovy, Python and Ruby at the forefront of the discussion for Dynamic-Typed Languages. I'm placing Scala, C++ and OCaml at the forefront of the dicussion for Static-Typed languages. I'm refraining from adding Java because although it is statically typed, there's far to much class-casting for my tastes to call it a "well-done" static languages (although annotations have really helped that problem!). I'm ignore C for the same reason. I'm ignoring C# because I don't know it, and I fear it may suffer from similar problems to Java to count as a real static language.
Here's some points of contension:
- Statically-typed languages will always be better than dynamically typed languages because you can ensure more compile-time safety.
- Content Assistance is one of the "power triad" features of an IDE (those being Debugging, Searching and Content Assistance). As such, static languages will always be better to develop in, as they have much better support for accurate content assistance
- Dynamic languages are much better for getting things done quickly, using less code.
- Static languages are made by more intelligent people because their compilers have to be more complex than dynamic languages
- Dynamic languages are always slower than Static languages
Anyway, feel free to argue one or many points. I'd like to see what all your opinions are! I tried to make these statements strongly on one side or the other, but I can also make them insulting if it helps discussion :)
If you'd like to include sample code, please use the following HTML: <div class="sourceCode"><pre class="prettyprint">SOURCE CODE HERE <pre><div>
Posts
12 comments:
I don't buy this "shorter code = better code" bullshit. I love functional programming languages, but sometimes making "elegant" code just means the next poor bugger having to maintain your code will have to do mental gymnastics in order to make any changes/fixes to it. This becomes very exciting with complex interleaved recursion! SLOC is a bullshit metric - what really matters is how complex the code is, how many places the same thing is repeated, and how well documented the code is. Sure SLOC has some correlation to this, but so does total characters of code, the total number of method invocations, etc etc.
So, I guess I could say I'm not sold on dynamic languages except for prototyping. I've been using perl since 2000 to get a lot of things done, but to be honest... most of my time programming is not spent typing, or setting up variable types, etc (hell the IDE does most of that!). It's spent thinking. Extra thought specifying types etc rarely interferes with my mental processes, and makes code easier to read - my biggest problem with python is figuring out what type I get back from a given method.
I'm a *HUGE* OCaml fan, so I love static type safety. I work in defense contracting, so I'm a big fan of anything that saves us tens of millions of dollars of rework, and more importantly, anything that saves lives on the battlefield. There's a reason missile guidance systems are not programmed in perl/python/lolcode, and that reason is that when someone's life is on the line, an ounce of prevention is worth a ton of cure. Anyone who is, IMHO, too lazy to type a little extra type information in deserves exactly what they get.
Also, idiots like me who cannot spell things are unfairly punished by dynamic languages. Autocomplete sorta works (ala emacs) in dynamic languages, but it has nowhere near the power that something like Eclipse/Java would have.
I'll always happily use dynamic languages for code that I don't care if anyone has to read again, or where speed of coding is more important than speed of execution. But color me crazy, I've been bitten by so many hard-to-debug perl/python errors that it would take a lot to convince me to use either as my primary dev language.
And, for the record, this is 2008, not 1968. I have no sympathy for people who insist on developing in notepad/ed/cat or whatever. Use an IDE (or nifty emacs/vim mode), quit whining about how many terabytes of memory it takes to open a single file, and kick some ass!
Python wins. Never worked in a language that let you be so productive. Groovy has similar promise but has yet to reach the shiny polish in Python.
Sorry, the argument is over. Deal.
When dealing with a new API in python how much documentation did you have to read to program? Were you able to program without anything other than a good IDE? Did you ever have to refactor your code? As an 'agile developer' I'd argue that refactoring is just as important to productivity as initially writing code. How are the code-analysis tools?
(I'm actually unfamiliar with the python particulars... but I'd like to get feedback on python for large-projects).
Would you care to elaborate on why python wins? Your argument was merely assertion that it does, not an explanation thereof.
You aren't, by chance, a teenage programmer? Your word choice and lack of even attempted rhetorical sophistication would seem to indicate either relative youth on your part, or inexperience with many of the situations in which a static language confers a major advantage (say, high performance numerical computation, computer graphics, mission critical applications, real-time programming, embedded programming, driver development, kernel development, and automatically verified applets/distributed agents). While there is a large amount of buzz about web applications these days (and their importance continues to rise), there is and will always be many classes of computer programs that are not even remotely similar.
Personally, I don't like snakes, so the dynamic codes are out and I would go with static codes, but I find it hard to believe that after like 30 + years with computers the best we can do is a C, even if it has two pluses. I mean, sheesh, if static codes can't get at least a B by now, I just don't see the point.
I guess that leaves me with Morse. It been around for a while, it has its bugged worked out and everyone can understand it. I'DE like to see anyone create another code where you can transmit entire words across the nation in only a few minutes. It just can't be done, and besides the rest of your are stupid heads and I am right.
Joe, I think your comment had its desired effect.
Josh, I'm speechless. Your wisdom always astounds me! However, you forgot that although snakes are poisonous, they can also be used to make purses, and purses carry money. So... dynamic wins. And, Morse is just Worse with an upside-down W.
Justin,
Clearly, from your 2nd sentence, you grasped the nature of my post. (As did Josh, not to be confused with Josh, when he commented on its desired effect.)
But since you took it seriously, and to the next level, I will reply in kind. Your second paragraph goes off track quickly, however, and seems to stay that way.
I haven't been confused for a teenager for a decade or two. Your supposition of youth followed by an insult reeks of immaturity and intellectual arrogance, so I'll ignore it and move on to the real topic, Python.
I don't feel static or dynamic languages make much of a difference, because in my 20+ years of building working software systems the technology has always played a minor in determining success. Success in systems development is about delivering things that the customers want and need, no other measure matters.
The buzz moves, I remember when the buzz was Smalltalk, Lisp, C++ instead of C, C instead of FORTRAN and COBOL. There will always be buzz (and prayer in school if there are exams). Theory is great, but I still can't buy a fuel cell car. Ignore the theory and look beyond to what actually works for you and others (unless of course you plan on working in education where theory counts more).
In my experience, the people and process determine success much more reliably than technology. A good team can build good software ever on bad technology. Arguably, they may be able to build better software, or cheaper software, or faster software on better systems/languages. I look to hire problem solvers regardless of specific experience or training, because they will be able adapt and apply their skills to any system or language.
Static versus dynamic doesn't determine success any more than advanced degrees or amount of capitalization.
After ramping up some on Python, I could solve real world problems quickly and efficiently in Python with an appreciable uptick in productivity compared to Java (in spite of my Java certifications). Some experienced programmers say there's a 2 to 10 fold multiplier, like here http://www.ferg.org/projects/python_java_side-by-side.html and http://www.paulgraham.com/pypar.html. I don't know about the high side of that, but my experience is that I can build apps that WORK faster.
One of my systems was a large Java framework with a catalog of Jython scripts to manipulate and query the system. The users benefitted immeasurably from our ability to quickly and easily build and test Python (Jython) code to answer their needs. It would have been much harder in Java to query, manipulate, and return the data sets we were processing. When you finish the Python Challenge (http://www.pythonchallenge.com/) if you are still not impressed, let me know. The code would have been bloated and hard to read, and I wouldn't have been able to have functional staff creating solutions with minimal training time if those were written in Java.
Based on your post, you appear to be a recent CS graduate with a chip on his shoulder and some "super cool" job building software. You may find a job making a lot of money somewhere, and will find that fulfilling until the next crop of wunderkids makes you obsolete. At which time you will likely either move to another field, or settle down and realize that it is fun to build systems and more fun to get paid for it and the most fun if your customers/users find your work helpful (on top of you enjoying it and getting paid for it) without caring how or why it works and what language it is in.
If you are more productive in static languages, use static languages. If you can crank Ruby fluently, go for it. If snakes scare you, stick to C, or as Josh points out, try learning Morse (though its application is fairly limited in IT). And only 10% of the snakes in Maryland are poisonous, so don't be afraid to try Python, you might like it. Python has been used in almost all the situations you mention, and is an inextricable part of many Linux distros and even my last two HP desktop computers.
And Josh (not Josh),
Its the power tri-Force, not triad. Triad's are so pre-Zelda.
You forget... Power is only one of the three triforces. And for some reason Link is always stuck with Courage. Why oh why couldn't he have gotten power? Think of all the cool things you could do with the triforce of power (besides turning into a pig and being repeatedly sealed away for thousands of years and losing half your name).
This isn't really a fair comparison, and I don't think most of the comments so far properly reflect upon the issue under consideration.
For starters, static/dynamic isn't the only duality to be considered; furthermore, it isn't even a duality -- it's a continuum. There's also the strong typing vs. weak typing debate; while it is true that most static languages are strongly typed and most dynamic languages are weakly typed, there are exceptions in both cases.
Your beloved Scala isn't a purely static language. It's got some dynamic features -- in a way you could almost think of it more like a strongly-typed dynamic language with explicit type checking. (Of course, it's more static than that, but this just goes to show you that static vs. dynamic isn't a black-and-white issue.)
Meanwhile, C is static, but weakly typed. (If you want proof that it's weakly typed, consider void*.)
C++ is static and strongly typed, but it, like Scala, offers a number of dynamic-like features through use of templates.
Python is dynamic and strongly typed, and while you can introduce static-like behavior into it, doing so destroys some of the idioms associated with the language.
So really, what it boils down to is what your code is intended for. Different tools for different tasks. Some tasks benefit from the rigid structure of a static language. Some tasks benefit from the flexible "try to work with everything" nature of a dynamic language. Having experience with languages on both ends of the spectrum, I can say that I think that a mostly-static language with some dynamic features is probably the best general-purpose choice.
C++ falls a little bit short of this, as it lacks sufficient reflection -- even at compile-time -- to make decisions about template specialization based on some aspect of the type, such as the presence or absence of a certain function. I don't know Scala but it looks like it takes care of this nicely. (Does it compile to native code?)
I agree with the "static-vs-dynamic + weak-vs.strong". However, deosn't static = "in the compiler" and dynamic = "at runtime"?
Yes, Scala allows some "dynamic" type behavior (like obj.asInstanceOf[ClassName]), however I think this is mostly to deal with Java APIs (and java's problem with forcing you to cast to make a "clean" api). Most of Scala's core language features ARE static.
If I am writing a python program, and I've pulled back an object from a function, how do I know what methods I can call without some form of partial execution or path analysis? With Scala, it's in the information given the compiler already. You can enforce a lot more safety/security inside the compiler, and leave runtime errors for *actual* runtime errors (vs. semantic). Obviously, unit testing should take care of your logical errors.
I would argue that strongly-typed static languages (that are also expressive) can gain you more productivity in the end, as you'll have less runtime checking you have to perform (as the compiler will do it for you). Therefore when your code compiles, it will be at a level above a dynamic language in terms of bugs.
Oh, also, Scala does not compile to native code currently. Their compiler IS pluggable, so if you learn enough Scala (yes, the Scala compiler is written in Scala), you could write a plugin that outputs natively. I believe they integrated with Java to pull in its libraries and to solve the distribution issues native compilation can bring.
There *was* as C#/.NET implementation at some point. Not sure where that stands.
Post a Comment