2 ms·

> 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 fin

> 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 ago
Why 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 ago
  It'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 ago
  It 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 ago
IDEs 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 ago
  Another 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 ago
  Getters, 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 ago
    They'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.

superuser2 12y ago

Why 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 ago
It'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 ago
It 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 ago

IDEs 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 ago
Another 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 ago
Getters, 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 ago
  They'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.