Howdy again, folks,
It's great to hear everyone's perspectives on the dynamic vs. static
typing debate. At this point though, I do want to officially state
that I'm very much in agreement with Peter regarding his last email.
We do all want our programs to be correct, and different problem
domains call for different language semantics. The "bondage and
discipline" description of statically typed languages was also not
meant as an insult, merely a descriptor. That description has been
floating around in the Lisp community for quite some time, and I was
merely choosing what was to me a well-known idiom.
Finally, I really should clarify something here. In my initial
email, my commentary was coming from a position of concern that too
much emphasis was being placed on classes and OO-paradigms in
today's schools and businesses. Object orientation, as a
sub-paradigm of the imperative programming style, is very useful for
representing problems in terms of actors and messages. Some problem
domains greatly benefit from this: i.e. agent-based simulations or
graphics programs. Others, such as theorem provers, compilers, and
most numerically-intensive (i.e. scientific computing) algorithms,
are IMHO typically made far less understandable when couched in the
terminology of OO languages.
Pointing people to this link was meant to encourage folks
(esp. those students whose main or sole experience with programming
is in the object-oriented sphere) to look outside of this one
paradigm and consider their options more fully. It was not meant to
fan the holy war between dynamic and static typing although that is
where we ended up ultimately going.
So, in conclusion, I'm simply advocating for coding abstractions
that are more powerful through being more generalizable and
therefore reusable. This is the key principle of modular design
(which is by far the most important tool in scaling up an
application's code size). I am arguing, as is Perlis, that although
the creation of new data types through class abstractions may seem
to be good modular practice, it often creates less generalizable
code and may therefore be harder to understand, extend, and reuse in
And when Andrew shows me a non-Lisp language which allows
programmers to easily modify the evaluation semantics of arbitrary
code blocks (and therefore implement any new flow control, exception
handling, data abstraction, encapsulation regime,
domain-specific-language, or self-rewriting code) as needed for
their problem domain (thereby improving both code modularity and
adaptiveness), then I might consider listening to his rants about
his new type system's comparative strengths to dynamically-typed
Until then, he can keep his trolling "girly" comments on reddit,
where they might be considered appropriate language by the reader
base. Like Hacker News, this list is meant for polite, intelligent
dialogue, not backbiting or name calling.
And that's all I have to say about that.
Peter C. Chapin writes:
> On Sat, 21 Mar 2009, Jacob Beauregard wrote:
> > I'd actually be less concerned about what a programming language
> > prevents me from doing than what a programming language helps me do.
> This is the crux of the matter, I think. While we all want programming
> languages that make it easier for us to write programs, what a language
> disallows is probably as important as what it allows. Ultimately this is
> because what we really want are programming languages that help us write
> *correct* programs.
> Whenever one considers a programming language feature two questions should
> be asked: How does the feature help me to express complex ideas in a
> simple way? What kinds of potential problems might the feature introduce?
> Assuming we are talking about languages that are well designed in their
> domains, languages that let you "do anything to everything" provide a
> powerful response to the first question, and "Bondage and discipline"
> languages provide a powerful response to the second.
> There is, of course, no "best" in all cases... which is why this debate
> has raged on for as long as there has been programming.