I don't think beggining programmers should be allowed to use an IDE until they've passed a command line compendency test.

If you your EMACS + Javac toolchain is nothing more than that then maybe you should introduce Ant as a build tool. This is the equiviliat of using make for c/c++ developement.We, the University of Florida, basicly require Ant as the method of building projects. (It isn't set in stone but peer pressure strongly encourages it.) We let people use whatever IDE they want for developement and all the different IDE-freaks co-exists in a friendly manner.

Yup, thats how we did it at my old job. Everybody used whatever IDE they wanted to, but all projects were buildable (and a lot of other stuff) via ant.Some used vi, other NetBeans or Visual Slickedit - worked perfectly. The only problem, was with autoformatting and cvs - since people used the builtin formatter, things tended to get screwed. This should be solvable using a plugabble formatter though.

i agree. the first two basic courses will use emacs/vi + javac/jikes. i suggest that after those they can try an IDE.

Sure. But on an ancient IBM host and a 3270 terminal. Of course by making small holes into paper cards....

Honestly, I can see no reason to teach legacy stuff out of another millenium.... tools from the 1970th...

Quote

what about improving workflow? does it make the programmers work more efficiently? or is the IDE in the way?

Sure! FAR more efficiently! Java code it typically so bloated with endless names that it is really not meant to be typed into an ascii editor. It is absolutely important to have a methods parameters, result and maybe the documentation right in front of your eyes while you type.

People who advocate these old things typically just want to demonstrate how long they have been on their way....

what about improving workflow? does it make the programmers work more efficiently? or is the IDE in the way?

An IDE won't make anything, it may help the programmer be more efficient but it's a give take thing.

A good editor doesn't think of code as text, it will provide a more meaningful expression of the code that the programmer can navigate though.

An plain text editor thinks of a file as lines with bytes on them. Some provide higher levels of abstraction and let you do things like move the cursor a word at a time. Besides that the content of the file has no more meaning than each byte that makes it up.

A good IDE, I'm gonna use IDEA as my example because that is what I use, expresses the source as more than the bytes that make it up. Instead of literally injecting bytes into a file I'm modifying and changeing a meaningful structure. If I type something that doesn't validate as well formed source IDEA marks that source in red. If I type a variable name wrong, it marks that in read. If I try to call a method with the wrong type of variable it marks that too.

There are other ways IDEA helps me express code with less effort that are more than error/typo detection. If I type out a method name that doesn't exists with some parmeters, with two more clicks of the mouse I can have IDEA create a stub method in the current class with the curser in body waiting for me to write the implementation. Refactoring is powerful too. Being able to reshape and re-express code in a more meaningful manner to humans is quite powerful. Search and replace almost works but it falls apart in ways that are subtal and error prone.

You should think of an IDE in terms of how it lets you express and edit code. All that other stuff, being able to build code, intergrated debugger, or some feature of the moment, they are all secondary. Under perfect conditions an IDE would make it so I wrote perfect code the first time. I'm not sure that is possible but what many editors/IDEs do is treat the symptomns of poorly written code which is a second rate solution.

Experience programmers that compain about good editors are full of shit and simply refuse to adapt to a better means of expression. I used to be a vi/vim freak, I still am for non-java stuff. I'm sooo glad someone wacked me on the head and showed me how foolish I was being.

Now that I'm done with my rant. Use ant to manage the project. Encourage programmers to write better code by making better editors available to them.

I'm a Vim user myself. I've played with a huge number of IDEs in the past, and was most impressed with Symantec's Visual Cafe - it was the best at the time. More recently I've tried JBuilder and NetBeans, but haven't used either seriously enough for them to stick.

There are still things I can do in Vim that I really don't want to leave behind, although I do yearn for some of the more useful IDE features. Once SlickEdit gets Vim key bindings I'll seriously consider purchasing it.

I sincerely advocate using Ant as your build tool. At some point in a big project you'll want to start builds automatically (timed or scripted), or you'll deal with someone who doesn't like your IDE of choice, or someone without a fast enough computer, or someone on a different OS etc. That's the point at which using Ant really pays off.

I sincerely advocate using Ant as your build tool. At some point in a big project you'll want to start builds automatically (timed or scripted), or you'll deal with someone who doesn't like your IDE of choice, or someone without a fast enough computer, or someone on a different OS etc. That's the point at which using Ant really pays off.

True. For any bigger project there is no way around an automated build.

'bigger' is it as soon as a single IDE cannot build the whole project, for it maybe has too many modules, too many dependencies, too many non-sourcecode related build steps (compilation of graphics, BSP generation, database builds).

For our project, 'F9' still is enough effort to start a build. So obviously it is a small project But we'll have ant scripts soon....

I'm afraid NetBeans isn't able to generate (at least parts) of an Ant script for a given project and synchronize it with the changes. But at least NetBeans can USE Ant scripts for builds from the IDE.

I think you missed the point swpalmer, It's not about teaching the old ways of doing things, it's about having a complete understanding. Read the leaky abstractions article. If you don't have time to read it all start in the middle where he presents the 'law' in a box.

'Joel on Software' is always worth reading. But all the articles says is that abstractions tend not to hold and that C++ sucks. I'm sure we all agree.

A IDE is an abstraction in no way. It is by no mean a code generator. You do exactly the same things as you do in vi, just smarter, more precise, better informed. Its not more abstract, it just avoids typos. It avoids looking up the manual. It avoids jumping around between buffers. It reduces typing and RSI. It avoids learning useless things like hundreds of key combinations and what they could mean. It avoids typing redundant commands over and over again.

Do you accept the abstraction the compiler gives you? You shouldn't! Only the binary code contains the truth! (Only if you can accept the abstraction the CPU offers, bc. the binary code does not exactly describe the order of things executed.)

I cannot see why the limit of where it starts to leak should just exactly be between Emacs and NetBeans.

I think you missed part of my point.. I'm saying learning emacs and the javac console command teach you nothing about java programming and add zero to your understanding of programming in general or Java. The IDE way of doing things is no less useful than the command line in terms of understanding what is going on, as neither one of them programs for you (yes, even the good IDEs). Same could be said of file mangement with a GUI or via a commandline shell. typing del or rm vs selecting a file from a list and pressing the delete key or selecting delete from a menu - it's all the same if you know that you are deleting a file and what that implies.

The IDE way of doing things is no less useful than the command line in terms of understanding what is going on, as neither one of them programs for you (yes, even the good IDEs).

Eclipse does tons of stuff for you. it does probably the same things as IDEA does. it does the ones leknor stated and more (so does IDEA). if an error is detected in the code (the code is analyzed as you write and indicates errors on the lfy), it's marked red and a little light bulb appears to the side. a mouse click (or CTRL+1) displays the suggestions Eclipse has. sometimes it's just minor stuff like spelling mistakes, but it also fixes more important stuff like casts and other stuff as well (can't think of any more right now, a bit hung over).

this can be both good and bad.

good: the user can see there is a problem and sees the solution and learns what needs to be done and why.

bad: the user can see there is a problem and sees the solution and lets the IDE fix the problem and moves on without learning anything.

comments?

Quote

Same could be said of file mangement with a GUI or via a commandline shell. typing del or rm vs selecting a file from a list and pressing the delete key or selecting delete from a menu - it's all the same if you know that you are deleting a file and what that implies.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org