[ILoveJava]

Yes they do what? I don't understand.

[jon.kiparsky]

Yes, they do use text editors or IDEs to program. Not an exclusive or, mind you...

[codeMonkey_1066]

jon.kiparsky said:

There's a high barrier to entry for that, of course, but it's an effort worth making.

This is also an argument for learning some of the more powerful features of an IDE.

[jon.kiparsky]

Quote

This is also an argument for learning some of the more powerful features of an IDE.

Not exactly, I think, since that particular move depends critically on the expressiveness of syntax versus symbol-salad languages. The effort being made, specifically, was "acquiring syntax", and the reward was "expressiveness and power", which we're not getting if we don't get the syntax part. The point of going to the effort is not to be able to say one thing, but to be able to leverage that to do many things. Learning a feature in a mouse-driven interface is generally a matter of learning to do one thing, and then another, and so forth.

The key feature of grammar is that it's productive: you can say new things in it, and you can combine existing ideas in new ways. That's very hard to do in gesture.

There may be an argument that some baked-in functionality of an IDE is worth learning, but I don't think it's the same argument.

[codeMonkey_1066]

Note I have no background in psychology so all of this is just speculation

Something I've picked up form jon.kiparsky's responses is that he has gone to great lengths to
show off that the extra effort that the use of an IDE can help avoid is trivial to him, because he's such a leet programmer.

He's repeated made the point that he already knows everything he's working on where it is and how it all hangs together so he doesn't see the need for an IDE to help him with this and that anyone who does is a week programmer.
That an IDE is an affront to his competence as a programmer maybe ???

It could be that because some of prefer to avoid extra work that we don't HAVE to do, that somehow were implying that the extra work he dose put in is of no value. Thus causing him to feel he has to justify his skills to us?

Hmm it feels like he's gone a bit into a very political mindset over the IDE vs editor debate

Spoiler

See hopefully some relvance the the thread.
Though seriously it's a very good article and well worth following the link.

Any argument that seems to support his side (editors) he MUST support and
any argument that supports the enemy (IDE) he must oppose

[jon.kiparsky]

I don't think I've said I'm an especially good programmer. That would be a mistake, because I'm not. I that what I expect a programmer to do, among other things, is to know the code they're working on. If this is some sort of superman-level programming, that's news to me. It's just what I'm used to.

Is this really an extreme expectation? That you know what your code does and why it does it?

Quote

Any argument that seems to support his side (editors) he MUST support and
any argument that supports the enemy (IDE) he must oppose

Well, no, it's just that your last argument sort of went wide of the mark. Since your IDE does not actually have a rich grammar (that I know of) you can't really use an argument based on the productivity of a rich grammar, because the premise isn't there. Like I said, there may be a case to be made for learning some features of an IDE, but this isn't that case, because there's a prerequisite which you're lacking.

Maybe I'm wrong, though. Does NetBeans have a rich command language that nobody's told me about?

This post has been edited by jon.kiparsky: 09 April 2012 - 10:38 AM

[codeMonkey_1066]

jon.kiparsky, on 09 April 2012 - 10:36 AM, said:

Maybe I'm wrong, though. Does NetBeans have a rich command language that nobody's told me about?

Well it's background scripting is controlled by ant scripts.

Also it's open source and written in java itself so if theres functionality you really can't get any other way you can introduce it that way.

[codeMonkey_1066]

Just been re reading some of your earlier posts in the thread and I noticed something you really shouldn't have got away with.

jon.kiparsky said:

To the degree your IDE succeeds, it only succeeds in replicating existing functionality.
...
If you understand the basic tools provided by any compliant OS,
including a real editor, you already know how to do everything that your IDE does for you.

An IDE does MORE.
It adds functionality that was not previously there.

[jon.kiparsky]

codeMonkey_1066, on 09 April 2012 - 01:19 PM, said:

jon.kiparsky, on 09 April 2012 - 10:36 AM, said:

Maybe I'm wrong, though. Does NetBeans have a rich command language that nobody's told me about?

Well it's background scripting is controlled by ant scripts.

Also it's open source and written in java itself so if theres functionality you really can't get any other way you can introduce it that way.

Ant's nice, I use it myself. But I'm not talking about programming the back end, I'm talking about the ongoing interaction with the tool. When I tried this NetBeans program, if I wanted something to happen, I had to either wave a mouse at it or learn a keyboard equivalent, and neither of those (as far as I can tell) has any kind of rich and productive grammar.

Quote

An IDE does MORE. It adds functionality that was not previously there.

Can you give me an example? Apart from the canned "refactoring" tools (which have as much to do with refactoring as a canned "design pattern" has to do with design patterns) I can't think of any functionality in Eclipse that I couldn't do already.

Remember, that quote you found was about providing access to everything the OS provides or can provide. So any existing tool in the unix universe is available to me via the OS, and I don't have to do anything but install it and use it: now it's part of my IDE. Can NetBeans do that?

[codeMonkey_1066]

I can understand your frustration at having to deal with code modified or written by someone who doesn't fully understand what there doing.

The problem I have is probably more with idea that you should ALREADY! know how something works before you should start using it. Experimentation is a very useful tool in both gaining understanding and proving confirming that you understand correctly how something works.

Also as a principal it imposes a lot of upfront cost which will often be wasted.
My personal approach, which works well for me, is a more 'just in time' one.
When I discover I need to know how to use something then I go and look it up.
Now while having a general idea of what components are available is important I don't bother with all the details if I don't have to. This way I Know that I understand the code I'm working on because my knowledge is fresh and verified.

This is a valid strategy if I use an IDE or a real text editor.

The idea that a defining quality of a good programmer is that they know the code already I feel is a dangerous one. Not in itself but more that it's very easy to get the wrong end of a stick with it.
To use a coding analogy for is would be a code smell.
It's certainly has little utility as advice to aspiring programmers and may actually be harmful.

Actually I've gone over some of this before

codeMonkey_1066 said:

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.

An Experienced programmer will end up knowing what much of the classes they use every day just by shear exposure, but this is a consequence not a requirement.

Also just because you know what your code does, does not mean that you code is any good or that you can write good code.

Writing good code is important, and one of the reasons for this is that good code is easier for both you and anyone else to understand.

If you write good code you and others will understand it.
What is NOT true is that
If you understand your code then it must be good
( it may or may not be ).

Spoiler

 void method_2(int a,int B)/>
 {
  field_1 = a ;
  field_2 = b ;
 }
 

I may know what this method does and how to use it but It is however bad code.

 void setSize(int width,int hight)
 {
  this.width = width;
  this.hight = hight;
 }
 

Is better as now you know what the method does.

[jon.kiparsky]

Quote

My personal approach, which works well for me, is a more 'just in time' one.

Yes, that's reasonable. That's how I've acquired all of this. So while you're learning to program, ideally you're also learning the skills that go along with it. When you're writing your Hello World stuff, you can just use javac to compile and so forth. When you start writing more complex stuff, you start using ant to make that easier, and maybe you start using a repository to keep your stuff secure. And as you go, you're learning stuff about how the shell works. It's all learned by doing, I don't know how else you'd go about it. And as you write more serious programs, you build a more serious toolkit - which has the advantage of being exactly the tools you've found you need and use. It's not just whatever somebody else happened to have lying around.

Quote

If you write good code you and others will understand it.
What is NOT true is that
If you understand your code then it must be good

I couldn't agree more, and your example is a fine one. But I would add to that, if you do not understand your code, it will not be good. I also think that if you don't write your code to be understood, you won't understand it for long. Like I say, a large part of "best practice" is all about helping the reader construct and maintain a mental model of the code.

[codeMonkey_1066]

jon.kiparsky, on 09 April 2012 - 12:28 PM, said:

Can you give me an example? Apart from the canned "refactoring" tools (which have as much to do with refactoring as a canned "design pattern" has to do with design patterns) I can't think of any functionality in Eclipse that I couldn't do already.

as you asked.

A few thing off the top of my head.

• real time full code validation. I don't have to wait till I try an compile to find out I've missed a typo.
  
• Interactive code animation for debugging.
  
• code profiling
  
• Listing ALL the overridden occurrences of a method in a super class.
  This also works for inner classes too.
  
• Listing All the the locations (complete with links) where a method is use.

And all of these are designed and tested to work together.

Now there may be other tools that do these things.
But I'd have to spend time installing and learning how to use them. ( possibly each with its own different interface) I already know how to use my IDE.

And if there's nothing at all stopping me form using another tool if I wanted or need to.

If you already have a tool that does what you want and you know how to use it. good for you use it.

The right tool for the job.



The refactoring tools are actually very useful. I don't write perfect code first time and having something that is aware of the java context of the code ( as opposed to just the text as say sed is ) makes my life a lot easier. Also I change my mind/ requirements change etc and such tools can make such changes significantly easier and quicker to make thus allowing me to be more productive.

[jon.kiparsky]

Well, if you like those features, I suppose you'd better use an IDE. I've never found much use for debuggers, I find my head works pretty well for that.

This one, I'm curious about:

Quote

Listing All the the locations (complete with links) where a method is use.

Why do you care about that? Surely a class should never have to know where it's called! That's basic OO design.

Quote

Listing ALL the overridden occurrences of a method in a super class.
This also works for inner classes too.

And you know what I'm going to say about this one...

[codeMonkey_1066]

You will still need to use things you don't know or understand the inner workings of ( or even all the functionality of), even if it's just the core Java API or a third party code. ( eg some third party jdbc drivers )
That been said actually looking at some of actual java API source can be quite informative.

Quote

Quote

If you write good code you and others will understand it.
What is NOT true is that
If you understand your code then it must be good

I couldn't agree more, and your example is a fine one. But I would add to that, if you do not understand your code, it will not be good. I also think that if you don't write your code to be understood, you won't understand it for long.

"if you do not understand your code, it will not be good."
Yes this is true,
My concern though that it's far too easy to internalize this as
"if you understand your code it will be good" and it's a potentially dangerous cognitive slip to make.

It's still not that much use as actual advice though.

Quote

Like I say, a large part of "best practice" is all about helping the reader construct and maintain a mental model of the code.

I might disagree a bit on that.
for me "best practice" is at it's core about writing easily understood code.
It's the resulting quality of the code that matters, not what goes on in someone else's head or the thought processes that are required to produce it. Not all brains work the in the same way after all.

[codeMonkey_1066]

jon.kiparsky, on 09 April 2012 - 02:30 PM, said:

Well, if you like those features, I suppose you'd better use an IDE. I've never found much use for debuggers, I find my head works pretty well for that.

This one, I'm curious about:

Quote

Listing All the the locations (complete with links) where a method is use.

Why do you care about that? Surely a class should never have to know where it's called! That's basic OO design.

The class doesn't have to. I on occasion do.
This could just be to see how a class has been used to understand it or to check that there will be no untended consequences to any changes I'm about to make.

Quote

Quote

Listing ALL the overridden occurrences of a method in a super class.
This also works for inner classes too.

This could probably be better expressed as.

I can see all the occurrences where a child class overrides a specific method of a parent class.
(The method in the parent class being the starting point )
This is useful as I don't have to search through all the code of every decedent class to find this information. Actually it saves me even more work as I don't have to read all the classes in the project as there may be an inner class in one of them that extends my super class and may override that method.
It can also search all the source code I have that I've told it about so it's not just restricted to searching in the current project either. ( for cases where the project your working on is used by other projects)

Quote

And you know what I'm going to say about this one...

Spoiler

I'm assuming its "you should already know this" or "why don't you already know this" or something along those lines. how close am I ?

My point is if don't initially know this already, if it's information I have to obtain some how then using the IDE means I don't have to hold the entire project in my head all the time. I can just focus on the area of code I'm working on and any related code.