3 ms·
> The Sniveley/Laucher talk included a comment that people like dynamic languages because their syntax is terse. Sure. Trying to have a strongly-typed Java pro
by mercurial 12y ago
> The Sniveley/Laucher talk included a comment that people like dynamic languages because their syntax is terse.
Sure. Trying to have a strongly-typed Java program, for instance, means a lot of boilerplate. As a consequence, it's often not done, or at least not done enough.
> To suggest that any distaste for types comes from annotation overhead is a way of dismissing it as a superficial issue.
On a large codebase, there is nothing superficial about it. The more boilerplate you have, the more difficult it becomes to understand the codebase and to find code which actually does something.
> If everyone would just use a modern language with a fancy type system, all our correctness problems would be over, right? If you believe this, you've drunk far too much Kool-Aid. Yet, apparently our profession is full of willing cult members. Let me say it simply. Type systems cannot be a one-stop solution for specification and verification. They are limited by definition. They reason only syntactically, and they specify only at the granularity of expressions. They're still useful, but let's be realistic.
Let's be realistic, and not pretend this is a widespread opinion.
> Rich Hickey's transducers talk gave a nice example of how patterns of polymorphism which humans find comprehensible can easily become extremely hard to capture precisely in a logic. Usually they are captured only overapproximately, which, in turn, yields an inexpressive proof system. The end result is that some manifestly correct code does not type-check.
Possibly, but it's all a question of tradeoffs. There is a lot more incorrect than correct code which doesn't typecheck.
- mateuszf 12y ago> On a large codebase, there is nothing superficial about it. The more boilerplate you have, the more difficult it becomes to understand the codebase and to find code which actually does something. In case of types it's true for humans. IDE will be able to build a very precise model and ease navigation and code changes when it understands types.
- superuser2 12y agoWhy should this be a property of the IDE and not the language itself? No, seriously. If the language sucks but your interaction with the IDE is fine, why not have a language that is closer to your interaction with the IDE to begin with, and use a text editor?
- mercurial 12y agoIt's the old "verbose getter and setters are not a problem because I can generate them in Eclipse" argument. To some extent, over-reliance on an IDE indicates issues with your language of choice, just like the overuse of design patterns.
- mateuszf 12y agoIt is property of the language - type annotations. Yes - maybe types can be infered, but I haven't seen any IDE with good refactorings for languages without types annotations (smalltalk doesn't count).
- mercurial 12y agoIDEs can help, but they're not a panacea. There is still a mental overhead when dealing with a more verbose codebase. Not to mention increased programmer time, especially when coding guidelines mandate the creation of builders.
- mercurial 12y agoAnother point I wanted to address is that people will tend not to fight the language. Make types harder to create than necessary? You'll have less well-typed programs. Make types syntactically light? You'll have more well-typed programs.
- mateuszf 12y agoGetters, setters, builders, special design patterns are not related to existence of type annotations. They are related to lack of different constructions or misusing existing ones.
- mercurial 12y agoThey're very much related to the point I was addressing, namely "What does it cost to add a new type in a language like Java". You're going to have type annotations in your signature no matter what, but adding a new type is relatively expensive.