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

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



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