[Ilugc] Python and Ruby Frameworks vs Statically typed languages
- From: vamlists@xxxxxxxxx (Vamsee Kanakala)
- Date: Mon Jul 17 15:52:14 2006
Prem Kurian Philip wrote:
I agree with you that these frameworks are far simpler to use than J2EE.
However, one of the problems I have noticed with these frameworks has
nothing to do with the frameworks themselves but rather with the
dynamically-typed nature of Python and Ruby which makes it very difficult
to catch some errors.
For very large applications, it is best to use a language which does not
have dynamic typing turned on by default.
Oh boy. The age-old dynamic vs. static typing argument. Check out the
recent comp.lang.lisp threads for a particularly long-drawn discussion
on this. They are much more detailed and make valid technical points on
both sides better than I can.
There are ways of getting around this limitation ofcourse - such as
writing a whole range of unit test scripts for each and every aspect of
the solution. But in my experience, that is easier said than done because
it is almost impossible to unit-test some blocks of code such as UI
handling code.
I don't know about desktop apps - but UI testing would be overkill for
most webapps. Validation checks, yes - but writing unit tests for how a
certain div will appear on your html page will quickly bog you down. A
good web designer is all you need. So I would consider this a moot point.
Also, if I were to use unit-tests to get around this problem, it is in
anycase just a work around to a problem with the platform. This problem is
perhaps more elegantly solved if Python / Ruby includes a run-time switch
which turns of dynamic typing (but this will require fairly extensive
changes in these platforms).
Sorry, I have to strongly disagree. Just because you have static typing,
it doesn't mean that you don't need unit testing at all. In that case,
you wouldn't have JUnit, and all those XP methodologies and tools to
make Java projects a little more manageable.
Unit tests are written mainly for things like clarifying design (when
you do TDD, you will be surprised how many design flaws you find
beforehand), enabling change (smaller feedback loops between coder and
customer) and finally, to create a strong test suite (so that new
changes don't break old code) - so as to enable better integration
testing and the likes.
I use statically-typed languages for coding for the same reason I set the
compiler preferences to display even very minor warnings when I develop in
C/C++; it is best to catch variable type errors at compile time rather
than at run-time.
Yes, it would be nice to have the type errors flagged beforehand. But,
type errors are one of the minor errors to worry about. You are going to
find them sooner or later (either during unit tests or manual testing).
What is more important to worry about is how fast you are able to
market your web product or how fast you are able to roll out the
first-but-buggy version to your customer.
As we all know, release early and release often is a good strategy. You
can always correct your mistakes in the second round. Static languages
hobble you in this respect that you have the extra compilation step.
Development becomes slower because you have to recompile the entire
webapp or parts of it every time you make a change. Dynamic languages
win in this respect that they will remove that extra unnecessary step -
you're gonna write unit tests anyways (for the above reasons), so why
slow you down with an extra step?
I know it can be argued both ways for quite a long time, but I think for
now I support dynamic languages unless I really think they're
compromising my web app. So far, I had no such complaints. In fact, I'm
happier now because my compiler won't complain that I used a BigInt,
SmallInt, WhateverInt instead of an Int. It's a friggin number dammit,
now get on with it!
Well, this is where the subjectivity and religious wars come in -
purists want type safety at any cost; pragmatists don't care about it
until it hits them on their head - which it rarely does. I'm certainly
in the latter camp.
Vamsee.
Other related posts:
