[hulug]

Not to be a prick but I doubt Go users will like this, they tend to prefer simple things to more complex things. Maybe retargeting this for Java/C++ users would be better.

Jokes (not really) aside, why does an IDE need to be designed for a language anyway?

[coldtea]

>Not to be a prick but I doubt Go users will like this, they tend to prefer simple things to more complex things.

That's the party line. In reality Go users have adopted GoLand just fine for example...

[qxga]

It's a self-contained application using the Dear ImGUI library rather than a bloated framework, and is designed for a single language. It's not simple compared to the likes of vi, sure, but it's almost certainly many less lines of code and much more architecturally simple than just about any other (popular, in-use) IDE out there.

[mananaysiempre]

Because so far noöne has figured out the set of extensibility points needed for a language-agnostic one that doesn’t result in horrible bloat and sprawling API surfaces. The original language-agnostic IDE—Emacs—is probably the simplest, and it’s still quite complex. Acme[2] is interesting, but Spartan when it comes to actual IDE-ish features, and its UI always rubbed me the wrong way.

I feel this is somewhat related to the fact that noöne has figured out how to do extensible widget toolkits or scene graphs either. (Yes, Electron does in fact solve an actual problem, if in a profoundly unsatisfying way.) Actually, just a text input box that could handle the complexities of the world’s writing systems (RTL, complex font shaping, arbitrary input methods, autocorrect, all that with at least one cursor or selection) and was capable of supporting the facts vs rumors approach from FRP[1] would be a significant advancement re toolkits. As for scene graphs, I don’t actually know of any viable general approaches to assembling an interface out of independent parts (that doesn’t work by presupposing a large substrate of features in the host “shell” and providing a separate extension point for each of shortcut, menu item, toolbar button, sidebar, dialog, ...).

Actually, now that I’ve written all of that out, it seems that another way to put my second point is that the language-agnostic IDE problem is a proper superset of the composable GUIs problem, and nobody knows how to solve that one. Composable CLIs are easy—they’re called “[textual] programming”; but then composable GUIs (or TUIs, the graphics/text distinction is immaterial here) would seem to correspond to visual programming, and last I checked the latter still sucked.

[1]: https://apfelmus.nfshost.com/blog/2012/03/29-frp-three-princ... [2]: http://acme.cat-v.org/

[peteretep]

> noöne

As much as I also love the The New Yorker diaeresis, “no one” is two words, not one, so no need for one here.

[mananaysiempre]

Huh (not a native speaker). This seemed obviously wrong to me: it is clearly a single negative pronoun syntactically, not the determiner no modifying the animate(!) pronoun one—for example, you can’t add adjuncts: *no great one, like *every great one, *any great one, or even just *a great one, sounds like it’s about Lovecraftian Great Ones or inanimate used cars instead of the faceless but animate pronominal “one”.

Then I looked it up, and it turns out that both “no one” and “no-one” are accepted spellings for this linguistic gadget while “noone” is rejected by prescriptivists as a confusing spelling because of the double “o”, even if it would be in line with “everyone” etc. “Noöne” is admittedly funky and nonstandard, but if the no-diaeresis concatenated version is rejected because it’s confusing (though come on English, your whole spelling is nuts, why are you so stubborn on this one), then the diaeresis version should be completely acceptable.

[hulug]

> Because so far noöne has figured out the set of extensibility points needed for a language-agnostic one that doesn’t result in horrible bloat and sprawling API surfaces.

Rob Pike did. Acme is absurdly simple yet absurdly powerful. Because everything is text and any piece of text is executable. Combined with the plumber[0] it beats every other approach to extensibility that I've seen. You can have any "IDE-ish feature" with a plumber rule. And you don't lose simplicity.

> Emacs is probably the simplest language-agnostic IDE.

No. See above.

[0]: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb and https://9p.io/wiki/plan9/Using_plumbing/index.html (also, Russ Cox has made a great demo video, it's on YouTube)

[mananaysiempre]

I have said a couple of words about Acme as you can see, and I’ve read the Acme and Plumber papers and a couple of intros; their Unixy take on Smalltalk’s “Do It” seemed ingenious in principle... But I have to admit that I always got turned off early enough in my attempts to actually use Acme (very shallow and superficial reason: non-primary-button drag is painful on a Macbook) that I can’t say I’ve given it an honest try. So the rest of this is only from my understanding of the manuals and might well be wildly wrong (I certainly hope to see counterexamples!).

OK, so what are the things that, to me, differentiate an IDE from “just” a programmer’s editor (mind you, I usually use the latter) but don’t seem to have an obvious solution in Acme?

- File tree with interactively collapsible subtrees (although this is not really an IDE feature, even Gedit has one). Haven’t seen an implementation, and don’t really see how one could fit into the UI paradigm without being awkward (would I have to select “collapse foo” to collapse the foo/ subtree? I’d much prefer to just click on foo).

- Jump to definition and list uses, using semantic analysis and not just text search. The former should be doable with plumbing but I don’t remember it described anywhere; the latter should be dead easy using something like cscope, but again, I haven’t seen an implementation, and also the interface would have to be a list of all matches and not in-file highlights, which is sometimes what you want and sometimes not.

- Rename identifier, again preferably non-dumb. Sure you can call out to a separate CLI tool if you don’t mind the lack of interactive feedback, but given the brilliant handling (theory, really) of multiple selections in Sam, I’m really frustrated Acme not only can’t accept multiple selection ranges from an external program, but doesn’t seem to support multiple selections at all.

- Autocompletion. While it is admittedly not essential for programming under Plan 9 (and that’s a good thing), in other environments unfamilliar libraries or horribly large APIs (looking at you, Google Apps Script) make it a necessity. As far as I can see, impossible to implement without forcing the programmer to take their hands off the keyboard.

- Debugger integration, or at least navigation through source files as the debugger steps through the program (showing variable values from the stack is good but optional). Should be implementable with a cooperating debugger, but once again not actually implemented as far as I’ve seen, and the lack of any way to highlight the current line will make it a bit unwieldy.

- VCS integration, at least a way to do `git add --interactive` (or equivalent) without going through a hundred questions in the terminal. Doesn’t really fit into how the UI works, unless I’m simply forced to edit patches manually. Even simply highlighting the dirty lines while editing would be tremendously useful, but the UI still can’t highlight lines.

- Syntax highlighting (yes, I went there). While you can indeed do without the classic syntax highlighting many people use, what I find helpful about it (even if I have to write my own syntax files) is that it can quickly highlight obvious syntactic programs that can result in pages of awful compiler spew: runaway strings, unbalanced parens inside a(n explicitly terminated) statement, etc. Jump to or highlight matching parenthesis is useful for the same reason, but I don’t consider it a must.

That’s a lot. Some of those things are possible, and many are, irritatingly, almost possible but not quite. But even if the UI admitted all of them, none of the tools that would implement them actually exist. Thus I conclude(d) that Acme is not a functional IDE, and while it is a good advance towards a more elegant “shell” (as GP called it) for one, the UI model is just a tad too restrictive in multiple directions. I suspect that trying to expand it in all of those directions, however, will ruin the elegance.

Just to be clear, this rant (I can’t seem to be able to produce anything else) is not an anti-Acme rant. Its point is not that Acme is a bad editor (it probably isn’t, it’s just that I can’t get the control scheme to click for me). Its point is that it is not a solution to the IDE bloat problem because it’s not an IDE. Perhaps we shouldn’t be solving the IDE bloat problem at all and just give up on the idea; but supposing that we want to, I don’t see how Acme accomplishes that.

P.S. I don’t use Emacs regularly either, but curiously the things for which I have used it in the past—Org mode, Agda mode, Paredit, and of course Dired—use its flexibility in such an essential way that not only are they impossible to implement atop Acme, they are probably impossible to do on top of the code editing widget in any other extensible editor except those that implement essentially the same ideology (Climacs, Edwin, et al.).

[jrockway]

> why does an IDE need to be designed for a language anyway

People want their IDE to do all the ancillary tasks, and Go builds most of these into the core, so it's a good first target. You can be "feature complete" without complexity.

Consider the case of a C++ IDE. Which compiler do you support; gcc, clang, msvc? Which build system do you support; Bazel, make, cmake, gyp, autotools? Which C++ standard version does the syntax highlighter support; can you change it per-project? If you do change it per-project, how do you configure this?

If you pick some opinionated subset, your userbase is 0 people. If you support everything people want, you have 30 people working on it for 10 years and you still fail.