3 ms·

I use textmate + shell. Once you get rid of all the crap in textmate - bundles, auto insertion of closing brackets etc, it's actually a usable editor. The main

by points 16y ago

I use textmate + shell. Once you get rid of all the crap in textmate - bundles, auto insertion of closing brackets etc, it's actually a usable editor. The main thing is just to get good at using the shell. Grep, awk, etc etc With all the tools at the cmdline, you can do anything.

koenigdavidmj 16y ago
Unix was the first IDE, they say.
riffraff 16y ago
> With all the tools at the cmdline, you can do anything. only if your definition of 'everything' is limited, all the refactorings in a half-decent ide are quite hard to get right with awk & sed. For what is worth, even something as simple as finding all elements in a type hierarchy are quite unobvious to do with shell tools for me.
- points 16y ago
  I think if you write good code the case for needing advanced re-factoring tools is minimal. If you're writing the same thing time and time again, that should ring alarm bells. FWIW, for other types of refactorings (I mainly use Java): 1. Change the name/type of something 2. Compile 3. Work through the errors fixing stuff it broke Maybe that's less efficient than using some IDE tool to do it, but it's not like it takes a long time.
  - riffraff 16y ago
    well, if I was so good to get code right at the first time, I would not need refactoring at all. Alas, I'm not :) I agree that, all the things you can do with automatic refactoring you can do with a change/compile/fix loop, but it imposes an higher amount of friction, which (even in a subconscious way) pushes you into not making changes. As a ruby and python dev using vim, I can even feel this in changing a single method name (with sed, obviously not syntax aware), as a java one without a supporting ide I'd seldom venture in a "extract superclass and use it where possible as return value" kind of change.
    - points 16y ago
      Sure, maybe I like that friction. If a refactor is going to be a bit of hassle, it makes me think about it more, and evaluate if it really is a good change to make.
  - ewjordan 16y ago
    Let's talk again when you're dealing with a codebase with >1000 classes, 5 different programmers of varying ability that you don't have direct control over, a build process that takes 5 minutes to complete as it works its way through a dozen different complex tasks with dependencies on just as many external tools and servers, and you need to do one of these simple "rename" factorings right now because a colleague made a spelling error in a widely used internal method that's about to be promoted to a part of a public API. I guarantee you'll start to question whether change/compile/fix is the right approach to these things...
    - points 16y ago
      In that case I'd just write a simple shell script :/ But thank god I don't work on large systems like that.
- silentbicycle 16y ago
  That's because many of the people who build those tools have coupled them to an IDE, rather than making a standalone tool that could be made to work with any editor with a little effort. And while it would be changing files without the IDE knowing, version control systems run standalone and modify file currently being edited, too - it's not a problem when you expect it. A standalone tool can either do static analysis (like a tag index, but more so) or communicate with the language runtime, and just leave the UI to the editor/IDE. Either way, it doesn't need to be in sed & awk.

by points 16y ago

koenigdavidmj 16y ago

Unix was the first IDE, they say.

riffraff 16y ago

> With all the tools at the cmdline, you can do anything. only if your definition of 'everything' is limited, all the refactorings in a half-decent ide are quite hard to get right with awk & sed. For what is worth, even something as simple as finding all elements in a type hierarchy are quite unobvious to do with shell tools for me.

points 16y ago
I think if you write good code the case for needing advanced re-factoring tools is minimal. If you're writing the same thing time and time again, that should ring alarm bells. FWIW, for other types of refactorings (I mainly use Java): 1. Change the name/type of something 2. Compile 3. Work through the errors fixing stuff it broke Maybe that's less efficient than using some IDE tool to do it, but it's not like it takes a long time.
- riffraff 16y ago
  well, if I was so good to get code right at the first time, I would not need refactoring at all. Alas, I'm not :) I agree that, all the things you can do with automatic refactoring you can do with a change/compile/fix loop, but it imposes an higher amount of friction, which (even in a subconscious way) pushes you into not making changes. As a ruby and python dev using vim, I can even feel this in changing a single method name (with sed, obviously not syntax aware), as a java one without a supporting ide I'd seldom venture in a "extract superclass and use it where possible as return value" kind of change.
  - points 16y ago
    Sure, maybe I like that friction. If a refactor is going to be a bit of hassle, it makes me think about it more, and evaluate if it really is a good change to make.
- ewjordan 16y ago
  Let's talk again when you're dealing with a codebase with >1000 classes, 5 different programmers of varying ability that you don't have direct control over, a build process that takes 5 minutes to complete as it works its way through a dozen different complex tasks with dependencies on just as many external tools and servers, and you need to do one of these simple "rename" factorings right now because a colleague made a spelling error in a widely used internal method that's about to be promoted to a part of a public API. I guarantee you'll start to question whether change/compile/fix is the right approach to these things...
  - points 16y ago
    In that case I'd just write a simple shell script :/ But thank god I don't work on large systems like that.
silentbicycle 16y ago
That's because many of the people who build those tools have coupled them to an IDE, rather than making a standalone tool that could be made to work with any editor with a little effort. And while it would be changing files without the IDE knowing, version control systems run standalone and modify file currently being edited, too - it's not a problem when you expect it. A standalone tool can either do static analysis (like a tag index, but more so) or communicate with the language runtime, and just leave the UI to the editor/IDE. Either way, it doesn't need to be in sed & awk.