[jon.kiparsky]

Quote

One of the big advantage an IDE can offer is the ease with witch one can navigate around code which is often spread around many files in disparate locations.

One of the principle functions of an operating system is to allow the user easy access to their files. If you're finding it difficult to navigate your file system, I think this is an indication that either you don't know how to use your operating system, or that your operating system doesn't work very well.

That is, your argument for using an IDE tends to support the claim I made the other day which has elicited loud and incoherent opposition, and no actual objections.

[codeMonkey_1066]

What I was referring to by navigating around the code, was more specific than just opening the correct file.

For example if you have the piece of code

 int foo = baa.someMethod(someObject);

in my IDE I can just click on the line in the IDE's editor and it can take me to the exact line in the exact source file where someMethod is define. (In actual fact I've got it set up to do it with one key stroke ).

This is far less effort than having to back track through the code to find out what classes baa and someObject is,
navigate through the file system to the source code file to the correct file, and then hunt/search the file for the correct piece of code.
It can also be more reliable as it uses the exact same logic as the compiler does.

It's the difference in speed between clicking on a hyperlink and having to find a file/line by hand.

[jon.kiparsky]

Quote

This is far less effort than having to back track through the code to find out what classes baa and someObject is

But surely you know this already, if you're working on the code? I take is as a basic that if you're working on codebase, you are familiar with the objects you're manipulating. If you're not, you're pretty certain to do more harm than good when you get in there and start stirring.

[codeMonkey_1066]

jon.kiparsky, on 07 April 2012 - 08:05 AM, said:

But surely you know this already, if you're working on the code?

Even if I do it's still quicker and less work, and I've better things to expend my effort on such as the code itself.

Also it's not a given that I know this already. This feature of the IDE is most useful when one is in the process of discovering what code does, either because it's been written by someone else or you've not worked on the code in some time.

[jon.kiparsky]

Less work? How is it any work to switch to an empty tty and type "vi Foo.java"? Or, considering that I know what I'm going to be working on, to simply switch over to the session where that file is already open?
There's a degree of effort that's simply not worth saving, and I think you've put your finger on it.

So much for the manual effort - the handful of keystrokes you've saved.

For the mental effort - if you find there is significant mental effort required to find your way to the right point in the codebase, I would suggest that the tools that make it easier make you a worse programmer in the long run, not a better one.

And this is why I think the idea of learning to program in an IDE is such a terrible one. If you are forced from day one to know your code inside and out, it's never difficult. If you have a mental prosthetic doing that work for you, you simply don't develop the skills needed to program well. If, having learned the skills, you decide to deploy an additional tool to assist you in your work, fine and good, but in this case you should really be able to build the tool before you consider using it.

Look at the poster above who lauded the auto-complete feature, which shows you what methods are available for an object. Okay, lovely. But why don't know know the methods available to an object already? If it's a class in the standard library, you should have learned its methods while you were learning the language. If it's a less commonly used class, you should know where to go to find its methods and learn what it is that this class offers.

I may be demanding an awful lot here, but knowing this stuff seems basic to the craft of programming. And if you don't know the craft, you can never even approach the art.

[codeMonkey_1066]

jon.kiparsky, on 07 April 2012 - 08:38 AM, said:

Less work? How is it any work to switch to an empty tty and type "vi Foo.java"? Or,

How is switching to a an empty tty and typing "vi Foo.java" Less work than a single key combination?
Just in terms of the amount of typing you need to do the later is faster.

Quote

And this is why I think the idea of learning to program in an IDE is such a terrible one.

This may or may not be the case. I'd suggest that what's the best environment to learn to program in is a septate topic.
However for real world cases where productivity is an issue and IDE can be a powerful and useful tool.

Quote

If you are forced from day one to know your code inside and out, it's never difficult.

Expecting some one to remember Everything they've written in not a reasonable expectation.
Also you don't just work with your code but with that of others.

I't a far better habit to acquire to prove to one self that your memory is correct by actually looking things up. I for one do not have a photographic or infallible memory.

Quote

If, having learned the skills, you decide to deploy an additional tool to assist you in your work, fine and good, but in this case you should really be able to build the tool before you consider using it.

Also are you assuming I don't have the skills already?

Quote

Look at the poster above who lauded the auto-complete feature, which shows you what methods are available for an object. Okay, lovely. But why don't know know the methods available to an object already?

How does one acquire such knowledge in the first place for classes that aren't part of any standard library ?
what are efferent and effective ways to do it?

Auto complete has the advantage of allowing for long meaningful names for methods and classes without the associated drudge work of typing them in every time. Not everyone can touch type after all.

Quote

I may be demanding an awful lot here, but knowing this stuff seems basic to the craft of programming. And if you don't know the craft, you can never even approach the art.

What tool you use to write your code with, and how you build/run your programs are far less important than the actual code you write.
Having an encyclopaedic knowledge of a programming language is an impressive and useful thing to have, but such things take time and effort to acquire, and there are more important general programming skills that are more important.

If you don't know something or are unsure then you can just go look it up and an IDE can reduce the cost of doing so.

Insisting that people should already know things can be harmful and counter productive. There should be no stigma associated with ignorance, only with an unwillingness to learn.

[jon.kiparsky]

codeMonkey_1066, on 07 April 2012 - 12:27 PM, said:

How is switching to a an empty tty and typing "vi Foo.java" Less work than a single key combination?
Just in terms of the amount of typing you need to do the later is faster.

If it takes me less time to do it than to think it, the effort involved is not anything I care about. You're talking about saving a fraction of a second.

Quote

I'd suggest that what's the best environment to learn to program in is a septate topic.
However for real world cases where productivity is an issue and IDE can be a powerful and useful tool.

You're right, it is a separate topic. However, the novice asking "which should I use?" is asking "which should I learn in". As I think I pointed out to Dylan, I'm not interested in changing anyone's habits. I'm making the case for people who ask which tool is better, presumably because they have not made a decision.

Quote

Expecting some one to remember Everything they've written in not a reasonable expectation.
Also you don't just work with your code but with that of others.

Remember everything you've written? Yes, that'd be unreasonable. When you're not working on something, you unload it from active memory. If I haven't worked on a piece of code for a while, I have to remind myself of the details. However, if you write your code well it's not difficult to do this. For stuff that I'm working on, I know it, plain and simple. One of the nice things about Java is that it's very easy to write code that can be known easily. If you create good structure, it's not difficult to be very familiar with a large code base. If it's too large to be familiar with it, you should probably restrict yourself to working on a subset at any given time. If it's too complex to be familiar with it, you should definitely start by refactoring it until it's in a state that can be used. This is likely to fix the bugs that you went in for in the first place.

If I'm reading somone else's code, I look for places that are difficult to understand. This is usually a good place to look for bugs, because if I have trouble with it, it's likely the original programmer did as well. Again, refactoring these so they can be worked on usually reveals or simply fixes bugs.

If an IDE allows you to live with an incomprehensible code base, that's a bad thing, not a good thing.

Quote

I't a far better habit to acquire to prove to one self that your memory is correct by actually looking things up.

I agree that looking things up is a good idea if you're not sure of them. Do you need an IDE to do that?

Quote

I for one do not have a photographic or infallible memory.

Nor do I. Away with your straw man.

Quote

Quote

If, having learned the skills, you decide to deploy an additional tool to assist you in your work, fine and good, but in this case you should really be able to build the tool before you consider using it.

Also are you assuming I don't have the skills already?

I have no idea what skills you have. In English, "you" is used for the generic, as in the German "man". I could say "one" but then people complain that I sound pretentious.

Quote

Quote

Look at the poster above who lauded the auto-complete feature, which shows you what methods are available for an object. Okay, lovely. But why don't know know the methods available to an object already?

How does one acquire such knowledge in the first place for classes that aren't part of any standard library ?
what are efferent and effective ways to do it?

You find the documentation and you read it over. That's pretty effective. If there's no documentation, you read the source. If there's no documentation and no source, you break glass and pull lever - that's an emergency situation. Not because you can't find out what the method names are (you can reflect the class and get that information in about a minute) but because you don't have any way of knowing what the methods do. Fortunately, I've never found myself in that situation.

Quote

Auto complete has the advantage of allowing for long meaningful names for methods and classes without the associated drudge work of typing them in every time. Not everyone can touch type after all.

Hrm? If you can't type, learn to type. It's not hard, and there are probably any number of free programs that will help you learn. If your method names are too long to type, they're probably too long to be useful. Camel case gets pretty hard to read once it gets past a few words. orDoYouPreferToReadSentencesWhenITypeThemLikeThis? Names can be, and should be, both meaningful and short. If your IDE allows you to tolerate method names that are stupidly long and unwieldy, that's a bad thing, not a good thing.

Quote

What tool you use to write your code with, and how you build/run your programs are far less important than the actual code you write

And you thnk this is unaffected by the degree to which you understand the classes you deploy?

Quote

Having an encyclopaedic knowledge of a programming language is an impressive and useful thing to have, but such things take time and effort to acquire,

When you say "encyclopedic" it sounds like you think I'm expecting something fantastically difficult. I'm not. I'm expecting someone to be familiar with the tools that they use to make their living. A working familiarity with the libraries of the languages you work in is not a lot to ask, if you're going to call yourself a programmer.

Yes, it does take time and effort to get there. This is the price of programming intentionally instead of accidentally. If you put it off, you put off the time when you actually know what you're doing, and you prolong the period in which you're a novice, throwing code at the wall and hoping some of it sticks. If your IDE allows you to do this, it allows you to remain ignorant for longer than is necessary. I don't see how this is a benefit.

Quote

and there are more important general programming skills that are more important.

And more redundant?
I don't see that it's a tradeoff. You need to know the language, period. It's not the only thing you have to know, but if you call yourself a programmer in some language, there is a minimal subset of the language that you simply have to know, and you need to be able to learn any necessary extensions to that language quickly.
Yes, it's difficult stuff. No, not everyone can do it, and that's why programming is a highly paid profession.

Quote

If you don't know something or are unsure then you can just go look it up and an IDE can reduce the cost of doing so.

I don't know about you, but I have documentation bookmarked for all of the languages I work in or am learning. There's no cost in finding the information, as long as I've got an internet connection. If I were into writing code in coffee shops or other places where connections are difficult, I'd download the information. This is not an issue.

Quote

Insisting that people should already know things can be harmful and counter productive. There should be no stigma associated with ignorance, only with an unwillingness to learn.

Really? I think there should be a stigma associated with ignorance. Not a great one, but ignorance should be discouraged, and a little bit of social disapprobation can help with that.
But I'm precisely referring to an unwillingness to learn, and actively seeking out tools to facilitate ignorance. Just as I would never allow a child to use a calculator until they were capable of doing everything the calculator can do, because it removes the incentive to learn, I think no programmer should have a machine do anything for them until they are capable of doing it for themselves, for the same reason. Once you can write the code for yourself, once you've developed the habits of mind that allow you to visualize what a program needs to do, and to see it all the way through from start to finish, then it makes sense to consider an IDE. At that point, it can be a tool that amplifies your abilities. Until then, its features add up to a crutch that prevents your abilities from developing.

[Nikitin]

jon.kiparsky, on 07 April 2012 - 09:05 AM, said:

Quote

This is far less effort than having to back track through the code to find out what classes baa and someObject is

But surely you know this already, if you're working on the code? I take is as a basic that if you're working on codebase, you are familiar with the objects you're manipulating. If you're not, you're pretty certain to do more harm than good when you get in there and start stirring.

This is one of the reasons I suggest you try working on a semi-complicated project, because you obviously don't have a slightest clue what it feels like.

[jon.kiparsky]

Nikitin, on 07 April 2012 - 03:27 PM, said:

jon.kiparsky, on 07 April 2012 - 09:05 AM, said:

But surely you know this already, if you're working on the code? I take is as a basic that if you're working on codebase, you are familiar with the objects you're manipulating. If you're not, you're pretty certain to do more harm than good when you get in there and start stirring.

This is one of the reasons I suggest you try working on a semi-complicated project, because you obviously don't have a slightest clue what it feels like.

Do you mean to say that you generally don't know what the objects you're manipulating are?

[codeMonkey_1066]

Quote

As I think I pointed out to Dylan, I'm not interested in changing anyone's habits. I'm making the case for people who ask which tool is better, presumably because they have not made a decision.

The impression I got from this thread was more a survey of what experienced coders actually use more than advice on which tool to use when learning.

While an IDE can become a crutch it could also provide useful training wheels and may help with getting a novice to think in a more object oriented way. I'd be interested if any experiments have been done on this ... anyway I digress.

A competent programmer should probably be able to write code using either an IDE or just an editor. What is most effective for them is often a matter of taste and experience. IDEs are most useful for large complicated projects, often with multiple authors.

Something I note from people who prefer to code in editors is that many of them prefer ones that have some form of syntax highlighting.

Quote

I think no programmer should have a machine do anything for them until they are capable of doing it for themselves,

While there is a limited set of basic skills where this is true it's my opinion that these are more the exception than the rule.
I don't know how to write a java compile, I made much use of a thread safe print stream long before I had the skills or knowledge to write one. much of the inner working of the java.awt package are unknown to me.
Having experience of how something is used can prove to be very useful in understanding how something is constructed and more importantly the reasons why something is written in a particular way.

Quote

I take is as a basic that if you're working on codebase, you are familiar with the objects you're manipulating.

Quote

Look at the poster above who lauded the auto-complete feature, which shows you what methods are available for an object. Okay, lovely. But why don't know know the methods available to an object already? If it's a class in the standard library, you should have learned its methods while you were learning the language.

From your posts I get the feeling that it would be very easy to paraphrase your attitude ( rightly or wrongly ) as
"you should know the language/ all the APIs" and that this is a necessary requirement to be a "good" programmer.

My suspicion is that such advice is somewhat pernicious, especially for a novice programmer who might easily misinterpret it some of the following ways.

• This is a somewhat daunting requirement and a source of discouragement.
  
• It teaches the bad habit of relying on what you already know. Anchoring your solutions on what you know rather than looking for different solutions that may be better.
  
• There is the danger of hubris. If you think of yourself as a "good" programmer then you already know these things.
  
• It can be distracting from the problem at hand if you've trained yourself to fully understand something new that you need to use, drawing your attention away from what you need to use it for.

These are not things you are actually trying to convey but I don't think it's too far of a stretch for someone who didn't know better to misinterpret your advice.

[codeMonkey_1066]

There are several practices that are very easy to apply for small projects of the type used while learning to code which do not scale very well.


The first that comes to mind is writing all your code in the main method of a class.
Though a lot of them are probably covered by the more common code smells

When a project is too big to hold in your head all at once not making use of the advantages of an IDE can be like typing with only one hand.
Sure you may be able to do it but it takes a lot longer and it's a lot more effort.

[edit to add relevance to thread]

This post has been edited by codeMonkey_1066: 07 April 2012 - 03:37 PM

[jon.kiparsky]

Quote

There are several practices that are very easy to apply for small projects of the type used while learning to code which do not scale very well.

I'm honestly not at all sure how this relates. I mean, I agree with it, and I've taught it any number of times, and I've explained it to a lead dev at my work once, and I've even alluded to it above. But what are you getting at? Why do you bring it up?

[codeMonkey_1066]

jon.kiparsky, on 07 April 2012 - 09:26 PM, said:

Quote

There are several practices that are very easy to apply for small projects of the type used while learning to code which do not scale very well.

I'm honestly not at all sure how this relates. I mean, I agree with it, and I've taught it any number of times, and I've explained it to a lead dev at my work once, and I've even alluded to it above. But what are you getting at? Why do you bring it up?

Well not directly relevant, which is why I edited the post.

What I think is that practices that you can work well with just using an IDE are often the one's that don't scale well to large complicated projects with multiple authors.

The good habitats of coding can be hard work, and by reducing the the effort required can help with reinforcing these habits. IDEs are designed to reduce the effort of coding well where as the extra effort required to do such things by restricting yourself to a text editor can prove an impediment ( no matter how small ) to learning and maintaining such habits.

Anything that forces your concentration away from the code is a distraction which can make coding that much harder, even if its as trivial as the difference between thinking "what file is this method in" as opposed to "what class is this method in"

[jon.kiparsky]

Quote

Anything that forces your concentration away from the code is a distraction which can make coding that much harder

You mean like trying to figure out which menu the damned UI hides some particular functionality in? I agree, that's a pretty distracting and flow-killing part of using an IDE. That's why I use an interface that I already know well, rather than learning a new one from scratch. And it's nice that the interface I already know well is the one that drives everything on my computer. That's pretty efficient.

I'm still having trouble with the concept that you find it difficult to work out where a given file is - that this constitutes "effort" for you. I mean, worst-case scenario I've got a huge project with multiple packages and I've lost my Foo class. It'll never happen because I know how to organize a project, and I know where a class belongs, and I put it there, but maybe I've had a massive brain injury or something. I've always got a window open at the top of my directory tree, and it's always (for personal historical reasons, ie, habit) tty2. So CTRL-ALT F2 takes me to that if I'm on my linux box, or command-2 on my mac. grep -R "class Foo" . gets it for me. There's no effort involved, any more than there would be effort involved in reaching into my filing cabinet and pulling out a draft of a translation I'm working on.

But I never need to do that because if I'm working on a project, really, I know where my classes are. And I think it's useful to actually know what's going on in my code, so I think it'd be a bad move to offload my understanding of what I'm writing onto a machine. I rely on the machine to turn my source into jvm code, and I know how that works and I don't have to think about it most of the time, but the structures that I interact with are java source files (or whatever language I'm working in ), so I keep the structure of that code in my head. Knowing that isn't an effort, it's just what programming is, and not knowing that doesn't seem like an advantage to me.

[jon.kiparsky]

codeMonkey_1066, on 08 April 2012 - 11:05 AM, said:

jon.kiparsky, on 07 April 2012 - 09:26 PM, said:

Quote

There are several practices that are very easy to apply for small projects of the type used while learning to code which do not scale very well.

I'm honestly not at all sure how this relates. I mean, I agree with it, and I've taught it any number of times, and I've explained it to a lead dev at my work once, and I've even alluded to it above. But what are you getting at? Why do you bring it up?

Well not directly relevant, which is why I edited the post.

What I think is that practices that you can work well with just using an IDE are often the one's that don't scale well to large complicated projects with multiple authors.

"just using an editor", presumably.

But what you don't understand is that I do work on large complicated projects with multiple authors, and it doesn't matter what tools any particular author uses. The source lives in a repo - you can use Eclipse, he can use NetBeans, I can use the machine itself, it's all fine.

What is it about a large project that you find difficult? Mostly the problems are organization of labor, making efficient use of resources and proceding on a reasoanble schedule - not organizing the codebase, which is pretty much a solved problem.

Quote

The good habitats of coding can be hard work, and by reducing the the effort required can help with reinforcing these habits. IDEs are designed to reduce the effort of coding well where as the extra effort required to do such things by restricting yourself to a text editor can prove an impediment ( no matter how small ) to learning and maintaining such habits.

See, I don't understand where the extra effort is that you keep bringing up. What exactly do you think is difficult about working in a the command line? Obviously, typing a handful of characters is about the same physical exertion as moving a mouse around, so it's not that. I already know grep and awk and find and mv and all that stuff, so it's not that I have to think about how to do what I want to do. So what is it that's more effort?