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

Re: Macros and little languages

Howard Stearns wrote:
> I don't think you're claiming that speed (in the past) was the only
> argument against dynamic typing.  For the record, another reason
> sometimes cited is "it may take me longer to get my program to compile
> with type declarations everywhere, but when it does compile, it's more
> likely to be correct."

I think that speed is what prevented the languages from becoming
mainstream (if not dominant). At the very least, it was something
quantifiable a static type checking bigot could point at when vague
arguments about safety versus expressiveness fail to convince either
side. We will see over the next several years...

> I have to admit that this is sometimes true.  Curl readily supports both
> styles, but I have tended to do my RAD work without type declarations on
> variables and operators.  Recently though, I've been maintaining
> other-people's-code and found the compile-time typing to be a great
> help.  

So you don't put type declarations in YOUR code but you are happy other
people put them in THEIR code. Isn't that like demanding that your
neighbours keep their lawns neat when you don't do so yourself?

It also suggests why optional static type checking *does not*
give you the union of the benefits of mandatory static type checking and
dynamic type checking. Saying: "we have type declarations so we're as
good at static type checking as Java" is not correct. In some cases
there are benefits that accrue from the fact that Java always forces the
declarations upon you. (and of course there are also related costs)

In particular, when I change a Java method name I know *for sure*
everywhere it breaks code in the current project. I can't have that
assurance if static type checking is optional. I get *other* benefits
from optional type checking, but not this one. That's why I don't think
we can resolve the static type checking debate merely by saying: "Let's
just add type declarations but make them optional."

> ... This has been true more than with other "sufficiently-smart
> compiler" systems I've used (e.g., CMU Common Lisp) because it's
> sufficiently easy for the programmers whose code I'm extending to have
> used good declarative practice over a large enough body of code to be
> meaningful.

How is Curl's variable declaration system different than common lisp's?

 Paul Prescod