Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Old Coders, Stubborness with IDE's

FortKnox (169099) writes | more than 11 years ago

Programming 24

I have a question.

I work in Java (which you should know, unless you are new or living under a rock), so my IDE of choice is JBuilder. I have JBuilder setup to do everything. Debugging, quick search, quick checkouts, ant plugins, etc...
Now, some of the guys I code with prefer to just d/l vim, and use that. I have no problem with that. Someone who is good with vim can program quickly and effectively.I have a question.

I work in Java (which you should know, unless you are new or living under a rock), so my IDE of choice is JBuilder. I have JBuilder setup to do everything. Debugging, quick search, quick checkouts, ant plugins, etc...
Now, some of the guys I code with prefer to just d/l vim, and use that. I have no problem with that. Someone who is good with vim can program quickly and effectively.

My point, though, is that if one person is really good with vim, and another is really good with JBuilder, who will be the more productive? JBuilder has more tools associated with it to really make debugging and maintanence easy; with vim, you have to pull out some ackward command line tools that aren't as effective.

So the question is, by being stubborn at not learning new IDE's, are you becoming less productive?

Does anyone have arguements with my points??

cancel ×

24 comments

Time to Learn vs. Comfort (1)

baldass_newbie (136609) | more than 11 years ago | (#6170640)

Biggest comfort factor is key strokes.
I could never get comfortable with SQL*Anywhere or the MS SQL client because I couldn't do things command line like I could with Oracle's SQL*Plus.
Now SQL*Plus is just a terminal window, while the others are IDEs.
Some IDEs can be configured to take vi keystrokes (I'm not sure which ones right now and I'm not sure if they're for Java) and that might be a plus.
But any time I have to go to mouse when I could just do a CTRL + anykey, I prefer to keep my fingers on the board.
It's one of the reasons I loathe Domino Designer.
*argh*
Anyway, I don't disagree with your points, but until they feel they can key things as quickly, all of the other bells and whistles won't mean squat.

Re:Time to Learn vs. Comfort (1)

dthable (163749) | more than 11 years ago | (#6170969)

Biggest comfort factor is key strokes.

Being a diehard vim fan, this is very true. I found that it's quite natural for me to hit the escape key when I finish typing. In some IDEs and editors, this causes the current window to close. A good program will confirm this action, but most programs I've seen just dump the file and changes.

I've been toying with the idea of using an IDE for better tools but find that anything an IDE can do, I can build into my ant script. It's taken some time, but I'm now quite productive and never need to remove my hands from the keyboard. (Evil mouse...how I loathe thee!)

There are trade offs (2, Insightful)

sielwolf (246764) | more than 11 years ago | (#6170691)

The benefit of using a single editor for all projects is that you have a uniform interface... so editing should be much faster and responsive. I feel this is especially the case with vim because it was designed to be used with fingers on the home keys... no mousing, no menues. The commands, although abstract, are simple and easily run off with a few simple strokes (instead of forty CTRL-X commands in a row).

Now the root of your argument is that you have access to support tools. True, there is a benefit of having all of that integrated. But then there are a lot of good Java dev commandline tools, again obtuse but strong when understood. And vim's genericness can be offset with some intelligent scripting (a script to do CVS, a script to do a dependency flush, etc). And many times scripting is easily portable. Also vim is integrated well with many compilers and debuggers.

And then let's say you switched over to doing JSP or Fortran for some reason. The gain is that vim continues to be just as useful. So if you use vim for everything, then you should improve uniformly at your use of everything (??)

A Wordperfect Story (3, Insightful)

dmorin (25609) | more than 11 years ago | (#6170916)

Once upon a time I sold software at a retail shop in the mall. I remember when Wordperfect was the top of the food chain. Version 5.1 had just come out, and the big feature was that they'd added mouse support and a menu. A customer came in asking if he should upgrade, and I told him this. His answer, and I'll always remember this, was "Well that's stupid. They expect me to take my hand off the keyboard, put it on the mouse, and go point at things to click on? Do you know how much that will slow me down?"

The battle of the IDE vs text editor is sometimes as simple as that. The GUI world is not friendly to keyboarders. Lots of old school geeks can type well over 100 wpm, and the idea of anything slowing them down (be it a mouse click, a dialog box, or just a slow screen refresh) is nauseating. The typical response to IDEs these days is "It runs slow for you? Then just get a faster computer." It's not like that's always an option. Sometimes there's even a mental block that tells you GUI apps are slower than text apps and that's just the way it'll always be.

But your question was about productivity. Are you using your IDEs ability to generate code? Do you then trust and run that code or do you check/edit it? Obviously if an IDE is generating large parts of your code for you and the vim guy would have to write them by hand, there'll be a productivity issue.

But if it's just an interface thing, and the question is whether the guy with a "debug" button is faster than a guy that keeps an extra shell running with a "tail -f output.log", then I think it's still a toss up. I think you have to go with the system that is the most natural to you.

Which leads me to my last and thankfully final point, that this will often be mistaken as learning curve. I haven't gotten into JBuilder yet, therefore the excuse could be seen as JBuilder has a high learning curve. That's not necessarily true. It's more a case of being comfortable in what you've already proven. I know how productive I am with emacs and the command line. I have to take a step back when working with JBuilder in order to someday, hopefully, get even more productive. But why take that risk? What's the payoff? When I'm pressed for time I'll go with what I know. Therefore I'm more likely to try out JBuilder on less than pressing projects. Which, of course, does not test it to its full potential. Catch 22? You are only comfortable with an environment that can support you in a crisis but you won't test new environments in a crisis?

On an interesting sidenote, just this morning I was reading about the inclusion of "metadata attributes" in Java1.5 and how they are being positioned to do away with deployment descriptors. So now the fact that your IDE can generate a deployment descriptor automatically and save me all that typing suddenly doesn't look so hot if I can do the same thing by just inlining a couple of keywords. An interesting development.

Rambling done. :)

Re:A Wordperfect Story (1)

FortKnox (169099) | more than 11 years ago | (#6171026)

Most IDEs (including JBuilder) have ctrl-keys to do stuff. Like I hit CTRL-(minus) to pop up a list of all classes, and type in the classname and hit enter to bring it up.

I rarely use the mouse, and I'm a fan of ctrl-combos (also being an emacs person from school). So I don't know if the 'mouse slows you down' really matters. The comfortability of the IDE is a good arguement, but it doesn't really take that long to acustom yourself to an IDE. Maybe a week to learn the key-combos.

I guess the only real 'advantages' you get is that most of these IDEs are written by guys that used text editors but wanted something to be more effective. Like, "I don't want to switch to a command line to compile. Why don't I just make a ctrl-combo to run make for me." I guess that's a bad example, but I think I made my point.

I'm not really harassing those that stick to vi/old text/code editors, but I wanna know what opinions are when I get old enough that I don't want to learn a new ide ;-)

Re:A Wordperfect Story (1)

Surak (18578) | more than 11 years ago | (#6171835)

I guess the only real 'advantages' you get is that most of these IDEs are written by guys that used text editors but wanted something to be more effective. Like, "I don't want to switch to a command line to compile. Why don't I just make a ctrl-combo to run make for me." I guess that's a bad example, but I think I made my point.

Of course, you can do that with Vim (and emacs, and a number of other editors) as well. ;)

I'm a guy who's done it both ways and I've been efficient at it both ways. It really is just a matter of personal taste and/or what tools you have available to you.

I don't think using one set of tools over another is necessarily going to make you more efficient...coding efficiency is mostly up to the coder. There is less learning curve associated with an IDE, I think, because it puts everything right in front of you. You have to learn to use a myriad of different tools to do it the old fashioned way, or learn one tool to do it the IDE way.

Of course IDEs, being all-in-one tools are the Mac/Windows/New World way, and a bunch of separate tools (text editor, gdb, tail, xterms, command line compiler, make tools, etc.) are the *nix way,
so those of you working in the Windows world will tend to gravitate toward IDEs, while those of you in the *nix world will tend to gravitate towards using separate tools. But as Larry Wall once said, TMTOWTDI. ;)

Re:A Wordperfect Story (1)

FortKnox (169099) | more than 11 years ago | (#6172171)

It was a bad example, let me use code completion.

In JBuilder, I put in the name of an obstantiated object and hit type in a couple letters of the method I want to use and hit CTRL-(space), it fills in the method and puts it in correctly (in case of spelling errors/cap errors). This is an edge that vim doesn't give you.

IE - I have a class:
class Foo
{
void aReallyLongMethodName(){ /* code */ }
}

Now I type in the following code:
Foo fooObj = new Foo();
fooObj.aReal
hit CTRL-(space), and get
fooObj.aReallyLongMethodName(
and a little display box with all the params of that function.

Re:A Wordperfect Story (1)

Surak (18578) | more than 11 years ago | (#6172416)

Actually, vim will do this for you too, sans the cutsie little display box. ;) With with Cream for Vim [sourceforge.net] , it's even the same hotkey (Ctrl+Space). Stock Vim will also do this for you, but it's a bit more complicated to work with (Ctrl+X,N, I think) and there are lot of other different completions it will do, such as complete line completions.

Re:A Wordperfect Story (1)

TechnoLust (528463) | more than 11 years ago | (#6173126)

Yeah, I use that for object name checking more than anything else. I.E. Type "myObject." and if you see the box with the functions you expect, you typed it in correctly. If you see nothing, check the spelling or capitalization.

As for debugging, as someone else mentioned, I use System.out.println() statements at specific intervals in the code to debug. I haven't used jdb. Does it work well with Web apps? I may have to try it.

Oh, by the way. What is DOSH [slashdot.org]

Re:A Wordperfect Story (1)

FortKnox (169099) | more than 11 years ago | (#6173273)

DOSH? I musta forgot that story... I'm unsure.

Re:A Wordperfect Story (1)

TechnoLust (528463) | more than 11 years ago | (#6173845)

glh said you would know. Maybe you should send him a message OOB and make sure it's a story you want told. ;-)

Re:A Wordperfect Story (1)

Tet (2721) | more than 11 years ago | (#6173633)

IE - I have a class:
class Foo
{
void aReallyLongMethodName(){ /* code */ }
}

... then you deserve everything you get for choosing such a stupidly long identifier. What's that? You don't have an option? Then you deserve everything you get for chosing such a braindead language. One of the myriad reasons I don't code in Java. Can't remember the arguments to a call? Hit ctrl-Z and read the man page. Oh that's right, you can't do that because most things are documented in Javadoc, so you need to fire up a web browser to read it. Way too slow. Can you tell I'm firmly in the vi camp, here? :-)

Re:A Wordperfect Story (1)

FortKnox (169099) | more than 11 years ago | (#6173842)

Can you tell I'm firmly in the vi camp

No, but I can tell your firmly in the I hate java more than Bill Gates camp ;-)

Regardless of language, I always use explanatory method names. Just makes maintanence a lot easier (especially if I'm passing the code to someone else).
And I'll take javadoc over any man page :-P

Re:A Wordperfect Story (1)

Tet (2721) | more than 11 years ago | (#6174068)

I can tell your firmly in the I hate java more than Bill Gates camp

Well, no, but it's a close call :-) Today in particularly isn't a good day to be trying to sell me Java. The almost complete inability to diagnose a problem with a running Java process has really been bugging me today, as a couple of rogue processes chewed up 95% of the CPU and even restarting them didn't help. See my reply further down to see my arguments for vi over an IDE...

I always use explanatory method names. Just makes maintanence a lot easier (especially if I'm passing the code to someone else).

Explanatory, yes, but unnecessarily verbose, no. I suppose it's the difference between strncmp and CompareStringsWithMaxLength. Oh, and I hate CaMelCase indentifiers. They're far harder to read than underscore_separated ones. I guess we'll just have to agree to disagee wrt javadoc vs a man page!

Race Cars (3, Insightful)

SolemnDragon (593956) | more than 11 years ago | (#6171016)

Can a mediocre driver in a brand new race car outdrive a race driver in a beat up '82 sedan?


Probably not. They'll either hit the wall or go 25 mph while they try to figure out what all the options do.



If you're good at what you do with the tools that you use, then that's what counts. There are fifty million ways to accomplish the goal (i.e. what you want your code to do) and so in the end i guess it partly depends on what the other people who will be touching it are going to be using, and whether the person asking for it (if there is one) knows what they want the first time. If they don't, and are likely to start handing the project around as they figure it out, use the lowest common denominator. Otherwise, stick with what you can race, because knowing what you're doing makes the difference, not just what tools you use.



That specialisation theory again. If you can produce twice the viable code with your tools as the guy next to you can with his, you should use yours. If you can produce the same amount of viable code by using another, you've lost some but possibly let other people understand what you're doing.

All of which is to say... i only know some java and nothing newer, but i'm in favour of learning new stuff... when i have time. I can make a reliquary in half the time and effort using my current silverworking tools than others in my class- but if i get around to getting newer tools and use slightly more standard techniques, other people would be able to mend my work if somebody takes a hammer to it in an iconoclastic fit of pique. This doesn't happen often, so i'm guaranteeing myself a line of projects by doing good work my way. The stuff doesn't break often, and when something drastic happens, i'm the goto gal for fixing it.

I'm not sure if these analogies actually help you much, but they're my two cents in scrap silver, so there ya go.
sol

comes down to comfort level... (1)

jeffy124 (453342) | more than 11 years ago | (#6171047)

personally, I feel I am very productive with the command line tools. my entire sr project was nothing but vi, cvs update/ci, make, and some shell scripts taht launched the program. we never used jdb, instead we inserted System.out.printlns in relevant places while tracking down bugs, and that worked quite well.

if, however, I was forced to use a windows box for development, using an IDE might be the better choice given that windows command line shell is not all that great. however, there would be a brief learning curve as I learned how to use the IDE. a week at most to learn the essentials. but how my productivity in the end would change is unknown.

best of both worlds (1)

John Harrison (223649) | more than 11 years ago | (#6171725)

I am going to repeat my support of VisualAge for Java. You can use a vi pluggin to have vi support while doing your text editing plus have all the power that VAJ provides. Oh you like EMACS? It can do that too.

My take... (1)

(H)elix1 (231155) | more than 11 years ago | (#6172000)

Coding can go either way. IDEâ(TM)s have the nice auto-complete and other features that make it a bit easier when you are doing something new to you. If you are just tweaking code, it is hard to beat a strait text editor. If you have two competent people coding, the VI d00d can probably make the change and check it into CVS before Jbuilder launches. What Iâ(TM)ve seen is IDEâ(TM)s tend to lower the barrier of entry for programmers - weaker programmers may use the IDE as a crutch. They also wonâ(TM)t have the assortment of custom scripts to move/build/checking either⦠Sometimes the IDE builds stuff where you want it. Sometimes no.

The place where an IDE shines is debugging. You may have perfect code, but nothing beats a good debugger when you are trying to hammer out a problem. I tend to use both, but find myself spending more time in the IDE. CVS (or something like it) is key to making both work.

Re:My take... (1)

Tet (2721) | more than 11 years ago | (#6173795)

The place where an IDE shines is debugging.

You're going to have to explain that to me, because in my experience, an IDE is much slower at debugging than using the native tools. How is it better?

As an aside, I'm very firmly opposed to IDEs. They provide no tangible benefits (to me, at least), and many downsides. I guess at least part of this is a consequence of me growing up in the Unix world, and hence the "do one thing and do it well" mentality is very firmly ingrained. IDEs on the other hand, are very much jack of all trades, master of none. By far the biggest problem I have with all IDEs I've found is the absence of an editor. No, really. They have little more than a glorified text box, not a proper editor. How anyone can write code without decent editor support is beyond me[1]. An editor is designed to do one thing and one thing only -- input text as efficiently as possible, and in that respect, vi excels. Similarly, a debugger deos just that, and something like ddd/gdb does it very well. Perhaps the thing that most people overlook, though, is that the window manager should be allowed to do its job -- manage windows. IDEs use MDI to present multiple windows in a single workspace, and not a single one of them gives me the flexibility that I have with a bunch of rxvts, an editor, a debugger and a decent window manager.

I fully agree that an IDE provides a lower barrier to entry, and can hence seem more appealing to the novice coder. But once you reach a certain level, it'll start to hamper you rather than help.

[1] By decent support, I mean things like multiple cut/paste buffers, full regexp search/replace, tags, named marks, split windows, user definable macros, and most importantly, all accessible without touching a mouse. Note that I don't use auto indenting or syntax highlighting. I toyed with them, but found they didn't improve my overall coding experience, so turned them off. Occasionally, I have comments displayed in bold, but nothing else.

Re:My take... (1)

robi2106 (464558) | more than 11 years ago | (#6175624)

I used to be an avid vi only user. Then I tried Sun's One (for java). Now it isn't the best, but when it comes to opening up a large project with 20+ source files, the IDE starts to benefit. All those system resources go to track all your modules and their related calls, properties, methods, etc.

It is nice to open up an IDE, and grab a list of all of the methods in the project, or all the methods in a class with a simple drop down menu.

vi simply can't do that.

robi

Eclipse? (1)

The Bungi (221687) | more than 11 years ago | (#6176659)

Not like Eclipse, you?

Re:Eclipse? (1)

FortKnox (169099) | more than 11 years ago | (#6181194)

I have no idea what you are asking, but I have used eclipse, but prefer JBuilder (which also has a 'free' version) for two reasons:
1.) Eclipse can get bogged down fast. It can slow to a crawl and take a ton of time to load up a page of code you haven't looked at in over 10 minutes.
2.) Eclipse doesn't have any nice EJB tools (although I haven't looked hard for any plugins).

Re:Eclipse? (1)

The Bungi (221687) | more than 11 years ago | (#6184193)

Yes, I meant "don't you like Eclipse?".

Admittedly I have not used it to do anything big. I wrote a couple of servlet thingies and a kinda sorta web service that works with JBoss on Win32. And a few standalone JARs.

It's slow as hell to load, but in my experience it works mostly OK. I wouldn't really know anything about EJB.

But I will say it's the only application written in Java that I have *ever* enjoyed using. The first that didn't look like it was designed by a 6 year old on Prozac.

designed by a 6 year old on Prozac (0)

Anonymous Coward | more than 11 years ago | (#6187212)

have you ever tried

jedit?
photomesa 2.0?
anything by jgoodies?
netbeans?
any of the java3d demos?

thought not.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...