Flutterby™! : So this Github Atom editor thing 2014-02-27 17:55:05.979104+00

So this Github Atom editor thing

2014-02-27 17:55:05.979104+00 by Dan Lyke 15 comments

So this Github Atom editor thing: Apparently there are developers who don't end up ssh'd through 3 layers of hosts, firewalls & VPNs?

#Comment Re: made: 2014-02-27 22:48:07.160884+00 by: meuon [edit history]

If it don't run in a shell.. It's an "IDE" for my local system more than a text editor.

So work is a network of RPC servers, without a reasonable test structure to allow development of many of those RPC servers in isolation. They're all on a heavily firewalled network, with lots of rules about who can connect to what.

My work workstation can SSH to those servers, but it'd take some effort to manage the workstation being able to call RPC methods on those servers. So development often happens on those servers.

So: Connect the home workstation to the VPN. ssh into the work workstation. ssh from there into one of the rpc servers. Work on those.

Doing development work on the machine I'm sitting in front of would require some sort of two-stage copy-and-run process.

And, going a little further: You know, in every environment where I've had to develop on multiple platforms, it's been easier to just ssh into the remote machines and run editors there than to have some sort of local cross-compilation process, or compilation process that copies files over to the remote machines and runs the compiler there.

Except, of course, when I actually have a reasonable cross-compilation platform, but usually then the target machine is such that if it has an editor it's vi, not emacs.

Dang, had weird proxies setup and lost my long eloquent response. The short version:

Funny how different workflows can be. When you said "developers" I wasn't thinking of server software, but it makes sense for what you are describing.

Yeah, it's kinda weird: I don't know that my development machine has ever really been my deployment machine. In mass-market products, the machine that's representative of the customer is always quite a bit slower than the compilation box, in distributed environments of course it's client-server, even on my home network I've got an SSD in my laptop, which is awesome, but it means I often can't just throw the entire dataset at something.

And it's always handy to be able to edit on the target machine, whether you can get to that with a network or not.

I think this is way easier for people who use fairly limited IDEs, mouse their selections, that kind of thing, but when my fingers have been trained for rectangle operations and such (yeah, even most modern IDEs have record/playback nowadays) it's hard enough to switch that even if I'm in something like VisualStudio, my workflow will generally be about doing the real editing in Emacs, and keeping my VS editing to debug work; the IDE editor just isn't up to the heavy lifting.

Xcrud for me is pretty much the same. It's always a death by a thousand cuts of suck. (today's was - split a file horizontally, like with C-x 2, Type in the top pane. The bottom pane would scroll up one pixel for each character typed.) That's why emacs is still my main editor, and Xcode is just a visual makefile / gui builder / build-and-deploy (when it decides to work) to an actual idevice.

Yeah. And if we can make the GUIs work as command-line build environments for our editors, so much the better. I have vague memories that the last time I mucked about with XCode that it did, there was a way I could invoke it from a Make file, and thus make "M-x compile" do the right thing.

Interesting. There's a pattern here, and I don't think I've fully grasped it, but there's a problem which is a combination of the constant churn in computing environments and the fact that learning is expensive. Time spent learning tools has to pay back in time saved using them, but tools exist inside their environments... this is all very evolutionary.

So there seems to be one school of thought which embraces the cost of training as a part of the job, and says, here's a really complex specialized tool which can do lots of things; learn as much of it as you can and it will save you time using whichever of its specific abilities you've invested in. The IDE model, I'm thinking of here. Learning is continuous because IDE features are constantly changing and IDEs themselves are constantly coming and going.

There's another school of thought which wants to learn it once and have done with it. Pick your tool and then make the tool follow you: it doesn't matter whether the tool is adapted for the environment you're in, as long as it is sufficiently fundamental in its capabilities and you've spent enough time mastering it to be comfortable. I'm trying to express the attitudes I see in vim/emacs users here. They're willing to use tools which are alien to the platforms they're working on (and at this point those editors are alien to every platform in existence!) because they have invested so much time mastering those tools that the benefits they provide outweigh the awkwardness.

My own attitude is more that time spent learning tools is time wasted, since I can never assume I'll be using the same tools for more than a couple of years at a time. I accept the fact that the mechanical processes I'm using are less efficient than they could be, gambling that I'm wasting less time on transitory learning than I'd be saving if I knew how to use the power features of the moment. And I optimize my work toward coding projects where raw text editing does not occupy much of my time. I don't run into many other people with this outlook but it seems sensible to me.

So I use Xcode on Mac OS X, Visual Studio on Windows, pico/bash on Linux, IAR on MSP430, etc., but the only features I use are the text editor, the directory browser, and the global search & replace. A debugger is nice but not that important.

It seems like the people who committed to vim/emacs years ago have largely stuck with it and been happy with their choice, but it wasn't until maybe ten or fifteen years ago that the eventual triumph of Unix began to seem inevitable, so it was never something I felt comfortable investing in.

Fundamentally, we're still programming with punchcards. You could take an iPhone App's Objective-C, plists, and xib-file XML, put the lines of text on cards, and feed it to the various compilers and linkers. Fortunately or unfortunately, the emacs/vim family of tools are the best cardpunches I've seen.

I know i'm a little off the beam from the rest of the word - due to the nature of my work text editing is the bulk of it, and I can be touching objective-C, html/javascript, Docbook markup, and python all in the course of one day. In an IDE-driven environment, that's three IDEs and some abortion of an XML editor. Where with emacs, it's all in one process that never crashes or needs restarting every other day to unwedge something.

I've also had the benefit of growing into some of these environments slowly. iOS is a huge sprawling API, but I'm already familiar with its previous incarnations that I don't have to be hand-held with code completion or instant documentation lookup. I'd probably be singing a different tune if I were starting out completely new.

I think markd hit the nail: a text editor is the common interface I have to everything. I use a simple-ish editor (joe), but I don't have to think about using it, the commands are all "muscle memory" and it's the same no matter what type of file I am editing.

Back in my early days of computing I used a word processor whose name I don't remember right now, and the Beagle Boys line editor for the Apple ][. Then there was the fairly ubiquitous WordStar keybindings that existed on pretty much everything DOS, including the various Turbo* packages.

But at some point in the late '80s when DOS ruled the world, I discovered Brief, and I understood what a real programmer's editor could do for me. Record, playback and save macros. Column operations. Navigating split-screen. The world was amazing.

I think it's also important that these environments were largely mouse-less, and the screen often updated less quickly than you could type, so it was rarely about a dialog with the computer. No "do something, wait for feedback", it was "do something, do something else, do another thing, the computer will catch up eventually".

I spent several years in that environment, immersing myself in that environment, and even as I moved to Un*x platforms I got CRiSP (which had Brief compatible keybindings), and my fingers remained happy.

And having learned what a real programmer's editor can do, and what having all of those things ingrained deep in my fingers was good for, I was never going to go to a lesser environment.

Then at Pixar, I was working in an environment where I was flitting between 4 Un*xes, and Windows, and my manager balked at buying CRiSP for all of those environments, and I retrained my fingers for Emacs (because it was that or VIM, and I'd drunk the "no modal environments" Kool Aid pretty solidly, enough to hate dialog boxes). Took a couple of weeks (with a cheat sheet taped to the side of every monitor I used) to get into the new swing of things, and there I was.

For a while, the various IDEs even did Emacs mappings; they weren't great at the details, but at least I could navigate files fairly well (even if "C-x C-f" did pull up a *spit* dialog box).

I think the last time I was working in a Microsoft environment, I realized that the advantage of the IDE was autocomplete for the horrendously complex and ridiculously inconsistent .NET library: Is it ".Count" or ".Length" or ".Size", and a method or a property, here? How do I read or write from this particular type of object, 'cause there's a different set of methods for pipes and files and sockets? The IDE was compensating for horrific API design, and because I needed to deploy the code on several different platforms anyway, my goals were largely "build a wrapper and get the code the hell off that platform ASAP".

It's a lot like physical tools: Many people go through life with a multitool in their pocket, or a couple of adjustable wrenches and one of those six-in-1 screwdrivers, and that's fine. It suits the handyman just fine. If your job is gluing together stuff and you need to get the lid off the glue, abusing a screwdriver or a claw hammer or going for the actual can opener doesn't matter.

However, a serious mechanic will have given Snap*On on the order of ten thousand dollars and will harm you grievously if you rearrange their tool chest; a serious woodworker will have changed the bevel and replaced the handles on their chisels; a serious metalworker will have built their own jigs and vises.

I tend to think that it's the same thing with the rest of the environment: Sure, I can learn new working methods, and there are places where that's the right thing to do, but if I just grab a chisel off the shelf I'm gonna get blisters. Same thing with a generic editor. And I could take the time to customize that environment, but given that Microsoft or Apple is going to totally change that environment in two years based on the whims of what someone thinks looks cool this season, why bother?

There's no reason for me to throw away all of that expertise and muscle memory just because someone at Microsoft has decided that the interface needs to be different in this release of Windows or VisualStudio, or that this interface is now deprecated in favor of the new interface that does exactly the same thing but with different names for everything. Just let me build enough glue to get over to the environment where I can really fly.

That last comment typed simultaneously with Meuon, but could be reduced to just that reiteration of markd: Yeah, text files are the common control system, editing them is the common interface, as long as that doesn't change I'm happy.

The IDE Divide: language mavens vs. tool mavens (personally, I'm a language maven).