Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

Journal FortKnox's Journal: Old Coders, Stubborness with IDE's 24

Journal by FortKnox
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??
This discussion has been archived. No new comments can be posted.

Old Coders, Stubborness with IDE's More

Old Coders, Stubborness with IDE's

Comments Filter:
  • 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
    • 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 pro

  • There are trade offs (Score:3, Insightful)

    by sielwolf ( 246764 ) on Wednesday June 11, 2003 @10:18AM (#6170691) Homepage Journal
    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 (Score:4, Insightful)

    by dmorin ( 25609 ) <{moc.liamg} {ta} {niromd}> on Wednesday June 11, 2003 @10:43AM (#6170916) Homepage Journal
    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. :)

    • 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 rea
      • 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
        • 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.a
          • 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.

          • 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]

          • 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 we

            • 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
              • 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 maintanenc

  • Race Cars (Score:4, Insightful)

    by SolemnDragon ( 593956 ) <solemndragon@@@gmail...com> on Wednesday June 11, 2003 @10:52AM (#6171016) Homepage Journal
    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

  • 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
  • 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.
  • 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 als
    • 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

      • 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
  • Not like Eclipse, you?
    • 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).
      • 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.

Slashdot Top Deals

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord

Close