[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strong Typing, Dynamic Languages, What to do?




No soothing words forthcoming ;-)  Also, I hope this isn't considered too
off-topic for this mailing list.

My observations are that different programmers react differently to this
situation.  The strongest proponents of so-called dynamic languages
typically claim that

a) they don't make many type errors anyway
b) type systems are not powerful enough to do anything really interesting

The strongest proponents of static languages say the opposite.  Possibly
the dynamic-languages camp consists of programmers who are just much more
skilled at avoiding type errors in their code to start with (through years
of practice?).  Personally, I make type errors all the time, and I find
that statically-typed languages with type inference are a godsend in this
regard.  I haven't worked enough with MrSpidey/MrFlow to say if they'll do
as effective a job for scheme.  Certainly any help is welcome ;-)

The big advantage of dynamic languages, it seems to me, is that it's
possible to have "all paradigms under one roof".  In scheme, for instance,
you can have functional programming (lazy or strict), object-oriented
programming (in several different flavors), logic programming, imperative
programming, and just about anything else (see SICP for lots of examples).
Dynamic typing is a key ingredient which gives you this flexibility.  In
contrast, to have just functional and object-oriented programming in one
statically-typed language is still AFAICT an open research problem.  The
only language I know of that does it is ocaml, and even there you don't
have the freedom to morph the object system to something else.

I think ML-style languages are amazingly expressive given the restrictions
of strong typing, but I don't think they can ever surpass the freedom that
dynamically typed languages like scheme give you.  Whether that freedom is
necessary for a particular application is a judgment call, of course.
Also, static type systems are getting more and more powerful and
expressive, but there are tons of open research problems there as well.

On a side note, I *love* type inference in ML-style languages, but it
complicates life in some ways (e.g. by making overloading difficult or
impossible).  Personally, I could live with a language that required type
declarations of functions but did inference inside a function (Haskell is
like this, but there are other issues with Haskell).  However, I might be
losing more than I think, since the generality of type inference often
gives you a type that is different from what you would have declared, and
this is often useful.

Adding-more-confusion-to-an-already-confusing-situation-ly y'rs,

Mike



> Date: Wed, 20 Mar 2002 12:10:55 -0800
> From: "Brent Fulgham" <brent.fulgham@xpsystems.com>
> 
> I find myself in an uncomfortable state of language equivocation.  I seem to be forever vascillating between the strongly-typed and "dynamic/untyped" programming languages.
> 
> The proponents of so-called "strongly-typed" languages in the Hindley-Milner school make the seemingly compelling argument that such type-checks provide superior program quality and reliability by catching syntax and logic errors before execution time.
> 
> On the other hand, such strong typing would seem to prevent the construction of polymorphic routines that allow a wide variety of types to be accepted as arguments.  It also seems to prevent you from arbitrarily expanding the types of data that a particular program might be exposed to without rebuilding the entire world.  You do not always have the luxury of revising an object (or type) heirarchy, especially if you don't have the source code for all the different units, etc.
> 
> However, my experience with some "typeless" languages (notably Visual Basic and Python) lead me to believe that this dynamicism often shifts bugs forward in time, so that you do not encounter them until users are exercising a program in ways not previously anticipated by the SQA team -- or when the program runs in an environment that differs in some fashion from the original test bed.
> 
> I'm hoping the readers on this list can offer soothing words that will help me end this internal struggle and allow me to make rational language selection choices.
> 
> Thanks,
> 
> -Brent
>