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

RE: Macros and little languages




> Howard Stearns wrote:
> > 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?

You are ignoring the "RAD" qualifier.  Static type declarations can be an
annoyance when you are doing rapid prototyping but can pay for themselves in
production code.

> 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 is a good point.  The way we deal with this in Curl is to support
compiler directives that force explicit type declarations and prevent you
from implicitly using runtime typing features that could lead to runtime
type errors or slower code.  So rather than switching languages to get
different levels of type checking enforcement, you can adjust your compiler
directives to suit your development style for your current project.

- Christopher