Re: Small time coding [Was: Re: About Visual Basic [Was: Industry versus academia]]

[Michael Vanier <address@hidden>]

Also note that perl is getting optional type declarations, as discussed in
Apocalypse 6 (truth in advertising?):

http://www.perl.com/pub/a/2003/03/07/apocalypse6.html

Whether perl is "lightweight" or not is a whole other can of worms.

Mike

> From: "Anton van Straaten" <anton@appsolutions.com>
> Date: Tue, 11 Mar 2003 22:52:44 -0500
> 
> John Clements wrote:
> > Robby Findler's work on contracts sounds very much like what you're
> > describing;  higher-order contracts are a big part of what make it
> > interesting. I agree with you that for my purposes, this constitutes a
> > "have your cake and eat it too" approach to checking.
> >
> > The paper is available at
> > <http://people.cs.uchicago.edu/~robby/publications/>
> 
> I think Robby's stuff goes a ways beyond the simple feature I was talking
> about.  It's no coincidence that I use PLT Scheme whenever possible.  Hardly
> any other groups are actively putting out *usable* new stuff in the general
> space of advanced, dynamically-typed languages.
> 
> But I was thinking of some of the more widely-used languages.  Python, for
> example, would benefit from something like this.  It's been discussed,
> naturally - see:
> http://www.python.org/sigs/types-sig/
> 
> But these discussions invariably get into interfaces, inferencing, static
> checking, checked modules, dreams of C-level performance, etc.  It seems to
> quickly get too complicated, big and language-changing to actually be
> implementable.  If they'd just added simple type annotations with dynamic
> checking, they'd be done already, tools could be using the info, and the
> appropriate next steps might seem clearer.  And it'd be at least as good as
> Visual BASIC.  :oP
> 
> I noticed, after writing the above and deciding to actually look into what
> I'm talking about, that Paul Prescod once suggested something very similar -
> from
> http://mail.python.org/pipermail/types-sig/2001-March/001094.html :
> 
> 	"The first thing we need to adjust is our terminology and goals. I think
> that we should design a *parameter type annotation* system that will lead
> directly to better error checking *at runtime*, better documentation, better
> development environments an so forth. Checking types *at compile time*
> should be considered a tools issue that can be solved by separate tools.
> I'm not going to say that Python will NEVER have a static type checking
> system but I would say that that shouldn't be a primary goal."
> 
> Apparently, not enough people agreed: the Python types-sig list shut down in
> July last year.  The interesting thing is that it's not because the Python
> community doesn't feel it needs better type handling; it's just that they
> couldn't agree on what it should look like, or limit the scope to make it
> doable.  In particular, resistance to static checking (which is
> understandable!) often seemed to create resistance to any explicit
> acknowledgement of types in the language - which makes no technical sense
> whatsoever.
> 
> Anton
>