Hacker News Reader

Comment by jimmaswell | Hacker News Reader

Using the tools available to you to their fullest extent, rather than doing things the hard way on purpose just to be more "hardcore", is not a sign of a bad programmer

View on HN

Definitely agree, however I can also see the shortcomings of the "IDE languages". One of the nice things about non-auto-completable scripting languages is that they force you to write code that you can reason about yourself. IDEs let you write really inelegant code that you can still continue to slog through because of autocomplete.

Another big downside of IDEs is that they constrain your choice of tooling to only the IDE. There's a rich ecosystem of editors, preprocessors, templating, etc. for JS, but (for example) in iOS development you only get xcode's half-working gee-whiz features like the interface builder. In my experience, the more IDE features there are, the more of your program moves into hidden, IDE-specific automagical stuff.

So resistance that you may see to IDE's is not because someone wants to be "hardcore", but because they recognize that it is desirable for code to be able to stand on its own and be understood by a human no matter the editor used.

"recognize that it is desirable for code to be able to stand on its own and be understood by a human no matter the editor used."

That and hardware constraint.

I especially hate IDE features that don't have a corresponding plaintext representation that you can edit. For example, a graphical layout editor which saves data into a binary blob that then requires a special merge tool which is only available in the IDE.

"rather than doing things the hard way on purpose just to be more "hardcore", is not a sign of a bad programmer"

I agree, IDE's boost productivity. The next question I ask is, what's your client? Mine is a tty terminal over ssh. This limits the kind of IDEs I can use, so it's cli/vi/[languate]. Simple tools from a more elegant time.

Why do you choose to do it that way? If you really wanted to use an IDE you could just keep it on a github repo or even dropbox, or if it's a local or very fast connection it could even be reasonable to use X11 tunneling. But, if the CLI environment is the most convenient or efficient for whatever's being done then it's a better choice.

You could also mount it as a remote filesystem (such as sshfs) and run an IDE locally.

"mount it as a remote filesystem (such as sshfs) and run an IDE locally."

could but a PIA.

"Why do you choose to do it that way?"

One word, RaspberryPi. [0]

Though I use a small laptop as a client and sometimes at the machine with monitor and keyboard, most work I do is on a Pi, remotely. I'll be upgrading my Pi to version 2 and splash out the necessary $40.

Forty dollars, think about that.

All I need to hack with: #raspberrypi & #robertsradio ~ https://flic.kr/p/o1yXKe

[0] https://www.flickr.com/photos/bootload/tags/raspberrypi

Isn't your small laptop a more powerful system? You state what you do, not why you are doing it, which was the original question.

FTR I support your decision to include your own constraints. I believe better things are developed from constrained systems than from without.

"Isn't your small laptop a more powerful system?"

EeePC with win.

Now I could fire up the beastly server I have on my desk with 300W power supply, multiple HD's with linux, but as an experiment I moved all the dev over to a Pi. Add a few more Pi machines and I can use one for image processing, another for dev, another for sound/media & I have the core of what I used to do on a desktop for the price of a fast HD.

Not the person you were asking, but I do it that way because I work with a software package that bundles a ton of proprietary libraries that would be difficult at best to set up on a separate dev machine and because the "IDE" included with it is just a bunch of glue for CLI stuff anyway (with a text editor literally no better than Notepad). SSH+vim is seriously a better option than the tools I'd have to work with otherwise. Bad IDEs do exist.

But that's a niche tool in a niche field with a niche language.

(It's the Cloverleaf interface engine used in healthcare and built on tcl, for the curious).

Agreed. People wouldn't appreciate it if I ignored the "interactions" warnings when prescribing medications just because I felt like I should be able to recall every drug-drug interaction myself...

Reply on news.ycombinator.com