I indeed wouldn't extend the argument down to semi-colons and the like. I apply that definition only to higher level constructs (e.g. Frameworks). The whole following a pattern thing kind of falls into what I meant by that argument - but like the Java community learned the hard way: just because you have a pattern doesn't mean that its appropriate for every single problem ;) My statement about being forced into one particular way of doing things is not so much a problem when you're trying to solve exactly that problem, but rather that you seldom have to solve that exact problem - but one similar to it. So if the construct doesn't allow for a certain amount of flexibility you're up the proverbial creek without a paddle :)
And I completely agree with you last sentence :D
On 17 Jan 2006, at 14:01, Weyel Mathias wrote:
I sometimes notice the downside of code completion as well. I start typing and exactly know what I want to type, but on having typed a dot, a tooltip pops up with methods and stuff and even if I sometimes want that, I find it annoying at other times so I can understand your point.
Your note about IDEs making language design flaws less painful is one of the best arguments for a careful language design. Not everyone uses modern IDEs and they have their downsides, too. A good language design can make life easier for everyone and even with the best possible language design there is enough room for an IDE to provide support.
Forcing people to a particular pattern swings a sword with two edges. The downsides you mentioned already but on the other hand people will understand your code much easier if it follows a known-before pattern. I don’t know, how far you would extend your statement. If it’s for low-level things as semicolons and newlines/indentation, I would prefer to have one solution because I believe it won’t make the language not turing-complete any more… ;)
* I had an extra battery on my 15" which is the one I was using when doing a lot of work on trains - but even with two batteries, they'll only last so long, and there are only so many batteries you want to drag around with you ;)
* Difficult to ignore as it actually impedes my productivity instead of aiding it (but again, that really is just me and some very small percentage of people out there ;))
But I have for myself at least noticed that I get more out of touch when using code completion than when I do (I try to use the latest IDE at least once a year to see whether they're usable in my context or not). Its not that I suddenly forget the entire API. And, <insert deity here> forbid, I wasn't asserting that its impossible to learn the API when using code-complete ;) Of course, this is not something that one can appreciate without actually having done it. I've done both - coded for years without code completion - coded for years with code completion. And I can assure you that the former will lead to the API being ingrained deeper than the latter ;)
As for having to type out getters and setters, I believe that's actually a classic example of a point you yourself made earlier - that's an IDE making a design flaw in a language more bearable :D Take a look at how properties are handled in Ruby, for example - now that's a good language integration of that idea. Similarly I find using the KVC/KVO of OS X a nice way to handle properties. Having explicit getters and setters for every property as is done in Java is most definitely a bad example of how to implement properties in a language. BUT - again, your absolutely right here - if you DO have to use a language feature which is pretty much broker by design, then having an IDE take the pain out of it is the right way to go ;) (Of course, you could also use shell scripts or code annotation to do a similar thing for you without using an IDE - but that's another discussion entirely ;))
I wasn't advocating relying on learning by heart as the way of doing programming (see Einstein quote from before) I was merely suggesting that by following a certain pattern of using the resources at hand, one symptom of this will be having learned the API off by heart ;)
One other metaphor I thought of: being 'fluent' in the language you work in will certainly be a benefit just as being fluent in a 'human' language will make it easier for you to convey information in that language to others. The faux pas committed by people with a loose grasp on a foreign language can be really hilarious at best or have catastrophic consequences on foreign affairs at worst ;)
I've often found that having a really deep understanding of not only the APIs but also the runtime makeup of a language / system can be paramount to success. Now, of course, that begs the question of how one defines success, but I won't get into that here ;)
But if all these discussions are proving one point, then its that everyone likes to work a different way and is even reasonably (to different degrees, admittedly) defensive about this way of working :D
I always like to describe a good API / framework / tool / language as follows:
It helps you achieve your goal easier without getting in your way or forcing you into a particular pattern.
For example, that OR mapping thing that Oracle bought a while back - you have to set up your DB *just so* for it to work. You have to use it *just so* for it to be of any use. And if you want to use it even slightly differently you start hacking around it so much that you would have been better off not using it in the first place. This is an argument levelled against the MS products quite often (although I don't have enough experience with the recent versions to be able to make a call on whether that's true or not ...)
A bad API / framework / tool / language on the other hand will force you to do it just the way it wants you to and will not be flexible enough to handle other situations. In-house frameworks are often the worst culprits for this.
But I digress - this could get really long winded, so I'll stop here ;D
PS: Sorry for the long post!
On 17 Jan 2006, at 12:57, Weyel Mathias wrote:
The same applies to me. I have done enough coding with Java to know large parts of the API by heart. But when I use some new API or cannot remember what exactly method x does if you put in a null reference or things like that, I am glad I don’t need to. ;)
*) Buy an extra cell for your notebook ;)
*) You just need to ignore the fact that your IDE types slower that you. Additionally, you can safe such a lot of typing with an IDE, especially when doing routine work as writing getters and setters. Not to mention the refactoring capabilities of a modern IDE.
*) Well I do that in the same fashion.
*) I never formulate anything in my head, I only can type…
But rest assured that even with code-completion you learn the API, it just doesn’t hurt that much… ;)
As you are mentioning the look-up of documentation: Here a good IDE is even better. I hate it to browse javadocs with a browser, because you scroll yourself to death finding the right class and then have to look for the method and so on. Within an IDE you can have a small tooltip window telling you just what you want to know. That’s a large step in the right direction. If you rely on not having to learn something by heart, the speed of access to the desired information becomes crucial.
Your absolutely right - you shouldn't be *forced* to learn an API off by heart, but here's some reasons why its compelling (and they WON'T apply to everyone out there ;)):
*) You aren't forced to code-completion. You can hence effectively and efficiently use a text-only editor (ViM e.g.) for editing, which when sitting on a train with a notebook and no power outlet nearby can help you work longer ;)
*) Another related point is that I find the IDE's currently available for Java to be too slow for my liking. And I'm definitely one of about 0.5% of users to whom this applies in this case due to the speed I type at.
*) You have to spend quite a bit of time in the documentation at first - when browsing through the code for the particular answer you're looking for, you often skim across information about other areas which then come in handy later on - you think 'I read something which sounded like it would be relevant to this problem I'm having right here at around that point in the documentation' and hence find solutions quicker.
*) It enables you to easier formulate solutions to problems in your head before you even start typing. (I've been accused of Java being my native tongue by some :))
On the *other* hand, I do think that this is an evolutionary process which naturally comes about by having used a particular API for years and years and years - I wouldn't actually set out to learn the whole API off by heart! Its something that will happen naturally depending on how long you use a language.