Java reflection WTF
-
@HypocriteWorld said:
I fail to see what the correlation is between the kind of app and the preferred type system.
Right tool for the job? Do you not see a correlation between the choice of platform or language and the kind of app? It's not the only concern, but why would I want to take any chances if I can save myself some long-term pain by moving some runtime issues - or many potential runtime issues - to compile-time (before it's released)?
The issue to me is software "correctness", which I view as more crucial in a system that must be distributed to a wide installed base instead of a web server farm. I also tend to think that static typing helps force me to get it right prior to distribution, not that it's by any means the only way or the right way to develop software.
I view most projects from a standpoint of what ongoing maintenance a customer will demand and how effectively we'll be able to do so. The chosen platform and language are absolutely a consideration, especially if there are problems that a compiler could've saved me from. But I tend not to care about that if the project has a smaller audience or smaller deployment footprint.
There are better arguments for static vs weak typing. Maybe a bad use of the word "heavily." Whatever.
-
@Soviut said:
That's sort of the point of static types in the first place. It more or less forces you to program defensively. You have to explicitly declare what types can go in, what types will come out, what parts can be extended, etc.
Yes, but even with static types you still need to program defensively; even with the right types you have no assurance that the data makes sense.
-
It also sort of depends on what your language does - a statically typed Lisp, or a dynamically typed Haskell just doesn't make sense.
-
@HypocriteWorld said:
It also sort of depends on what your language does - a statically typed Lisp... just doesn't make sense.
You mean like ML?
-
Well, if you consider ML a Lisp... well almost everything can be a Lisp in some form... but anyways, ML and Lisp code have very different styles, and they're closely related to ML being static and Lisp being dynamically typed. That's what I mean.
-
@HypocriteWorld said:
Hey, this sounds familiar:well almost everything can be a Lisp in some form...
@Greenspun's Tenth Rule said:
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
