5 ms·

> thinking that "building" is the action of pressing a button in an IDE GUI (and that "writing a program" means launching a big wizard that pukes a dozen files

> thinking that "building" is the action of pressing a button in an IDE GUI (and that "writing a program" means launching a big wizard that pukes a dozen files into a new directory) is just depressing. I use UNIX as my IDE almost exclusively. When it comes to Java however, I don't think there's any way to avoid using Eclipse or Netbeans or something. Any nontrivial Java project is going to be convoluted enough that using the traditional tools is an exercise in futility.

debacle 14y ago
ant was built specifically for building large Java projects, was it not?
- strictfp 14y ago
  I thought that it was written to prove that the supposedly declarative data format of xml still is vulnerable to imperative misuse. :)
- mseebach 14y ago
  Needing an IDE for Java in my experience has to do with two things: The amount of boiler plate and really good refactoring tools/autocomplete. Building the project is not really that difficult, and make can be made to do it just fine.
x1 14y ago
I grudgingly agree. It is frustrating but something created while using an IDE tends to create specific ways of thinking. For example, most IDE developers tend to love their debuggers... want to learn something? Just run the debugger! Want to debug something, hey run that debugger and watch 'dem breakpoints! When I code without a debugger I tend to write smaller, easier testable code because I lack a real way to step through a convoluted process. I feel this encourages a simpler application (but I have no study to prove that). Another example is most Java/C# work tends to be in the center of the unknown universe. You are editing something twelve layers deep in a mess of public/private/protected objects and you aren't sure if the item you should call is the MarginalFlowStateController or the ControllingMarginalFlowState... with an IDE you would just open up both of them, their unit tests, and any documentation until you discover which one you should be calling. It bothers me because I really enjoy my vi/tmux development environment where every time I :w a file and run a test I am running on virtually the exact same environment as dev/qa/pre/prod.
- nradov 14y ago
  While writing small, easily testable code is a good practice it isn't sufficient. Running your code in a debugger and actually watching things happen exposes a lot of bugs and inefficiencies that tests don't tend to catch. Getting that dynamic view of control flow and state is a huge advantage for improving quality.
  - x1 14y ago
    Meh, I think you are over-inflating the benefits of a debugger. Everything you described can be achieved through proper testing. Want to know if something is efficient? Then build a test to gauge it. That way if it changes and becomes less efficient in the future your test will break. That's a much more solid approach than simply walking through the code a couple times and noticing something out of place.
    - eropple 14y ago
      > Meh, I think you are over-inflating the benefits of a debugger. Everything you described can be achieved through proper testing. You're falling into the trap of "one tool to solve all problems." Why waste your time writing tests to "gauge efficiency" when a profiler tells you more, more effectively?
      - x1 14y ago
        The test will persist and always be there to test again where as a gauge will be a one time thing. What happens next week when someone does an x += hugeBlockOfText in a loop? I'd rather have a set goal and a test/process that validates it over a one time event where human error is involved. You want X process a million records in under three seconds? Build a test. I'm not advocating one tool. I'm simply saying that everything described so far is better solved with a test first approach over a debug first approach. Build a test to replicate the problem. Solve the problem. Keep the test to prove that the problem is solved.
        14y ago
bluekeybox 14y ago
I don't think anyone is saying that IDEs like Eclipse or Xcode or Visual Studio do not have a place. They absolutely do. HOWEVER: (1) from my experience of working with people fresh out of school who were exclusively familiar only with the IDE way of building programs and who knew little to nothing about the command line tools -- such people were curiously unaware that many tasks (testing for example) could be automated. People who used command line extensively, on the other hand, would be the first ones to write a simple script that performed testing of their program. Testing is just one example (I'm sure there are many IDE-tailored solutions for it). There are other things that are done repetitively; using an IDE can mold one into thinking that such tasks are impossible to automate and that they can only be performed by clicking buttons. (2) (Again this is about people either in school or fresh out of it -- certainly not about highly professional IDE users). People who were taught IDE first and who are not familiar with the command line will often assume that running command line utilities is an old-fashioned way and that they are more "modern" (therefore somehow "better") programmers just because they are using a GUI. Such people will then go on to write programs that completely ignore the standard way of interacting with the shell, even if their programs do run from the command line. One example: One of the programmers (who used exclusively GUIs for building programs) would write command-line utilities which, when outputting a text file, would place '\n' at the beginning of each line and not at the end, which then resulted in parts of the output being truncated when I ran them through sed/gnuplot/whatever. Firthermore, even though his programs were quite complicated (read: painful to debug), he had no idea what the difference between stderr and stdout was, and would write any errors that would come up to stdout. The same programmer was then curiously defensive when I told him that his way of doing it was wrong (his answer basically was: "I've been programming for a long time, and I've always done it that way, and I don't care that my programs don't play nice with that sed thing with which I'm not familiar with").
- roguecoder 14y ago
  I have encountered the inverse: 1) People who exclusively use the command line, especially when recently graduated, have extreme difficulty thinking in an OO fashion, because they have not had the tools to support exploring inheritance and call stacks the way someone with a visual OO development environment has (Smalltalk is ideal for this.) 2) People who have used the command line exclusively are content without visualizations, which can be massively more effective at conveying information, especially about performance and architecture. 3) People who have used the command line exclusively are less likely to employ refactoring tools and more likely to tolerate long, poorly factored code because vim/emacs makes it easy to navigate and ignore the ugliness. 4) People who have used the command line exclusively, especially when they are recent graduates, believe that their approach is inherently better and necessary in order to be a good developer. They get curiously defensive if you expect them to be able to instantly jump to the definition of a method in question or actually use the Strategy pattern.
lftl 14y ago
Having just picked up Android development (and my first real usage of Java), I've been pretty happy using eclim (http://eclim.org/ http://eclim.org/). It bridges the gap nicely, I get eclipse's error checking, decent completion, automated import statements, refactoring, etc. all inside vim. The only two features I've found myself bouncing into eclipse for are the debugger, and android GUI layout previews.

debacle 14y ago

ant was built specifically for building large Java projects, was it not?

strictfp 14y ago
I thought that it was written to prove that the supposedly declarative data format of xml still is vulnerable to imperative misuse. :)
mseebach 14y ago
Needing an IDE for Java in my experience has to do with two things: The amount of boiler plate and really good refactoring tools/autocomplete. Building the project is not really that difficult, and make can be made to do it just fine.

x1 14y ago

I grudgingly agree. It is frustrating but something created while using an IDE tends to create specific ways of thinking. For example, most IDE developers tend to love their debuggers... want to learn something? Just run the debugger! Want to debug something, hey run that debugger and watch 'dem breakpoints! When I code without a debugger I tend to write smaller, easier testable code because I lack a real way to step through a convoluted process. I feel this encourages a simpler application (but I have no study to prove that). Another example is most Java/C# work tends to be in the center of the unknown universe. You are editing something twelve layers deep in a mess of public/private/protected objects and you aren't sure if the item you should call is the MarginalFlowStateController or the ControllingMarginalFlowState... with an IDE you would just open up both of them, their unit tests, and any documentation until you discover which one you should be calling. It bothers me because I really enjoy my vi/tmux development environment where every time I :w a file and run a test I am running on virtually the exact same environment as dev/qa/pre/prod.

nradov 14y ago
While writing small, easily testable code is a good practice it isn't sufficient. Running your code in a debugger and actually watching things happen exposes a lot of bugs and inefficiencies that tests don't tend to catch. Getting that dynamic view of control flow and state is a huge advantage for improving quality.
- x1 14y ago
  Meh, I think you are over-inflating the benefits of a debugger. Everything you described can be achieved through proper testing. Want to know if something is efficient? Then build a test to gauge it. That way if it changes and becomes less efficient in the future your test will break. That's a much more solid approach than simply walking through the code a couple times and noticing something out of place.
  - eropple 14y ago
    > Meh, I think you are over-inflating the benefits of a debugger. Everything you described can be achieved through proper testing. You're falling into the trap of "one tool to solve all problems." Why waste your time writing tests to "gauge efficiency" when a profiler tells you more, more effectively?
    - x1 14y ago
      The test will persist and always be there to test again where as a gauge will be a one time thing. What happens next week when someone does an x += hugeBlockOfText in a loop? I'd rather have a set goal and a test/process that validates it over a one time event where human error is involved. You want X process a million records in under three seconds? Build a test. I'm not advocating one tool. I'm simply saying that everything described so far is better solved with a test first approach over a debug first approach. Build a test to replicate the problem. Solve the problem. Keep the test to prove that the problem is solved.
      - 14y ago

bluekeybox 14y ago

I don't think anyone is saying that IDEs like Eclipse or Xcode or Visual Studio do not have a place. They absolutely do. HOWEVER: (1) from my experience of working with people fresh out of school who were exclusively familiar only with the IDE way of building programs and who knew little to nothing about the command line tools -- such people were curiously unaware that many tasks (testing for example) could be automated. People who used command line extensively, on the other hand, would be the first ones to write a simple script that performed testing of their program. Testing is just one example (I'm sure there are many IDE-tailored solutions for it). There are other things that are done repetitively; using an IDE can mold one into thinking that such tasks are impossible to automate and that they can only be performed by clicking buttons. (2) (Again this is about people either in school or fresh out of it -- certainly not about highly professional IDE users). People who were taught IDE first and who are not familiar with the command line will often assume that running command line utilities is an old-fashioned way and that they are more "modern" (therefore somehow "better") programmers just because they are using a GUI. Such people will then go on to write programs that completely ignore the standard way of interacting with the shell, even if their programs do run from the command line. One example: One of the programmers (who used exclusively GUIs for building programs) would write command-line utilities which, when outputting a text file, would place '\n' at the beginning of each line and not at the end, which then resulted in parts of the output being truncated when I ran them through sed/gnuplot/whatever. Firthermore, even though his programs were quite complicated (read: painful to debug), he had no idea what the difference between stderr and stdout was, and would write any errors that would come up to stdout. The same programmer was then curiously defensive when I told him that his way of doing it was wrong (his answer basically was: "I've been programming for a long time, and I've always done it that way, and I don't care that my programs don't play nice with that sed thing with which I'm not familiar with").

roguecoder 14y ago
I have encountered the inverse: 1) People who exclusively use the command line, especially when recently graduated, have extreme difficulty thinking in an OO fashion, because they have not had the tools to support exploring inheritance and call stacks the way someone with a visual OO development environment has (Smalltalk is ideal for this.) 2) People who have used the command line exclusively are content without visualizations, which can be massively more effective at conveying information, especially about performance and architecture. 3) People who have used the command line exclusively are less likely to employ refactoring tools and more likely to tolerate long, poorly factored code because vim/emacs makes it easy to navigate and ignore the ugliness. 4) People who have used the command line exclusively, especially when they are recent graduates, believe that their approach is inherently better and necessary in order to be a good developer. They get curiously defensive if you expect them to be able to instantly jump to the definition of a method in question or actually use the Strategy pattern.

lftl 14y ago

Having just picked up Android development (and my first real usage of Java), I've been pretty happy using eclim (http://eclim.org/ http://eclim.org/). It bridges the gap nicely, I get eclipse's error checking, decent completion, automated import statements, refactoring, etc. all inside vim. The only two features I've found myself bouncing into eclipse for are the debugger, and android GUI layout previews.