Hacker News new | past | comments | ask | show | jobs | submit login

I work somewhat similarish to you (or at least, closer to you than the environment suggested in the OP), but I really don't understand why you're so disturbed. Don't use tools you don't want to use.

The reason it bugs me is that popularity drives what will be supported by companies. I used to have plenty of linux and Emacs support from official helpdesk channels. In my last several jobs, not at all. At my current job, even though we rely heavily on linux servers and there’s a strong minority of Emacs users, the company (over 300 engineers) mandated that all support for configuring our in-house build tooling and monorepo tooling will be 100% Sublime on Mac, no support of any kind for Emacs.

In one company, the primary language was Scala, and one of the primary Emacs tools for Scala is Ensime. But the company had its own bizarrely wrapped version of sbt running inside of pants tasks, so without explicit support from IT, it was not possible for a developer to use Emacs+Ensime for that Scala codebase.

I am perfectly happy for people who use these UI-heavy tools productively. But the marketing shtick attempts to raise it in popularity and promote it, like this very paper’s recommendation, seem harmful to me.

Code tooling should be extremely fractured, bespoke and customized, by its very nature, and that should be embraced and supported. Instead it seems like PR battles and a rise of (IMO) ineffective proprietary tooling.

My observation is that many geeks try to abstract away the complexity that they don't understand. Those proprietary tools start as a way to understand, but then become monsters onto themselves.

I flip back and forth between "working the big, working in the small" (paraphrasing Bill Joy). Sometimes closer to the metal is best. Other times I prefer the IDE with all its conveniences.

But I am the first to admit that sometimes I do get trapped by the IDE, distracted by fighting the tool instead of solving the real problem, and have to take a step back.

Said another way:

I only really object to IDEs and other tools of convenience when they hide the metal.

Like when you have the wrong mental model for a problem, and you're fighting the model, instead of finding a better model.

> Code tooling should be extremely fractured, bespoke and customized, by its very nature

Why? That sounds like it would make things more expensive and harder to learn.

Because different people are productive with different tools.

I think your reasoning is completely backwards on this: it’s not expensive to support many different sets of tooling. No, what’s expensive is paying a lot of money for people who can be very productive for you, but then preventing them from giving you that productivity due to poor tooling. When the poor tooling has been standardized, your good developers are heading to the exits.

There's a big push towards the Language Server Protocol type tooling, I think that makes a noticeable difference in supporting personal preferences.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact