Hacker News Reader

Comment by gkya | Hacker News Reader

The point you miss is: there are thousands of packages for Emacs and Vim already. Emacs has all sorts of useful programs that you can run, a list too long to even summarize. There is an emacs version in common lisp, I guess it was called Hemlock. MIT Scheme has it's own Emacs version. But you don't have Gnus, elfeed, EMMS, flycheck, Org-mode, etc., on them, and you don't have the time to write them all from scratch.

View on HN

It's a curious thing, programmers tend to not write their own editors/IDEs... everything else is reinvented, NIH syndrone, but not that.

I don't think it's external packages (actually, internal packages eg syntax colouring, various completions, are a stronger argument), nor the related maturity quality of being debugged, and feature-gaps/annoyances filled, buffed, polished. I think it's:

(1) once you get adapted to finger bindings, you're reluctant to lose that investment by switching.

(2) when you first start coding, you have to use an existing editor. It takes some time before you are able to write an editor, or that you start looking at the editor, rather than looking through it. By then, see (1)

Those programs exist because people wrote them. And many are rewritten every day to replace those. Emacs does not have 40 years worth of plugins available. If one single person rewrote the ones you use on a daily basis, it wouldn't take very long. Divide that up by the number of people willing to do it, even shorter.

Don't believe me? Look no further than Atom. That's exactly what they did.

I won't say that it is impossible to have something like Emacs out, and get people to make the relevant packages, with a list of them just as long. It has to catch on, though. Many Emacs packages are full-fledged application programmes, and there is a large set of both core and external libraries powering them. But certainly if this Kilau or sth. else gets a big traction, everything is possible.

Atom did this with the backing of a very well-financed company, and it still doesn't fare all that well with niche languages.

I agree with the general gist of your first post, but I think it's important to recognize that unless you can build on some portable standard method for defining editor support for programming languages, there is going to be a cost to living in the niche; it is going to make you more hesitant to experiment with new languages. (This is speaking as someone who has also implemented their own Lua-based text editor.)

Oh hey Phil. Didn't see you there.

Sure, Atom has Github paying for it, and they still don't have CIDER.

But you know what? Emacs users came up with CIDER from scratch. It barely builds on top of any existing Emacs plugins. That exact same thing could have been done in an editor like kilo if it had the right scriptable foundation.

But why did they not build CIDER on Hemlock with Common Lisp available instead of Emacs Lisp? Because you need more than possibilites to get working without wasting time. Apart from plugins, Emacs has the core environment to build such a thing, and then there are many libraries that pile up in creating the plugins, that others wrote, so that you don't need to implement a networking library and a string processing library and a syntax definition library and subprocess management library and whatnot in order to build sth. like CIDER. Not that that's impossible, but certainly a waste of time when the tech and the community is already there. It's of course on one's self to choose whether to spend that time or not, and it's not bad or stupid to choose to create one's own editor, but it's undebatable that some time that instead could've been used productively for something else is spent duplicating others' effort, if a brand new idea is not being implemented.

Emacs users came up with Cider, but they were able to do it because there were a whole ton of them. Cider has had 154 contributors: https://github.com/clojure-emacs/cider/graphs/contributors

Reply on news.ycombinator.com