On Monday, March 30, 2015 at 4:18:03 AM UTC-4, Alexis wrote: > > > Bozhidar Batsov <bozh...@batsov.com <javascript:>> writes: > > > Anti-Emacs stuff really gets to me. > > i too find it somewhat tiresome. It makes me wonder how many > people have actually stopped and asked themselves: "Given that > Emacs seems like a crusty ancient artifact from The Land That Time > Forgot, why do so many people keep using it?" > > i can't speak for other Emacs users, of course, but here are some > of the main reasons i prefer to use (GNU) Emacs[1]: > > * i don't have to learn and use a distinct, possibly > resource-hungry, > IDE[2] for every new programming language or environment i > need/want to work in. (When the Swift language was released, for > example, basic Swift support in the form of `swift-mode` became > available within less than a week.) >
Eclipse has plugins for a wide variety of languages. * Further to the resource-usage issue, i can more easily use Emacs > remotely over low-bandwidth links than i could use an IDE. > Typical home and mobile connection speeds are multiple MBPS these days. * IDEs typically don't allow one to change their basic behaviours > whilst > they're running. Related: if there's a bug fix or feature i want > applied, i can apply it myself, rather than having to hope that > the maintainers will (a) accept that it's something that > /should/ be applied, and (b) actually apply it. > The second, at least, applies to every open source IDE, including a certain EPL-licensed one. > * In my experience, Emacs tends to be less of a 'black box' than > some > IDEs, in that i can more easily get a better sense of what's > going on "behind the scenes". This in turn means that i've got a > better sense of the relevant build system, and how to fix and/or > tune it in particular circumstances. > Unfortunately, one MUST do all of that and CANNOT use it as a black box, because it is the software analogue of a computer with no keyboard or monitor or anything else resembling a user interface, so one must toggle everything in and know the hardware internals backwards and forwards to get anything done. :) * Emacs is available for a wider range of platforms than most > IDEs, > meaning it's more likely to be available to me should i need to > work on a particular platform. > Of course, there are some IDEs that run on top of the JVM, and are thus as widely available platform-wise as the JVM ... > * Emacs is the product of approximately three decades of constant > development, such that it handles many corner-cases of many > scenarios (e.g. in the area of i18n) and continues to adapt to > new ones. > Three decades worth of accumulated legacy code. I can barely begin to imagine what horrors must be lurking in some of the darker and less well-traveled corners of that thing's /src directory. But you could probably form a fairly accurate basic picture by reading the collected works of one H. P. Lovecraft ... :) And what kind of i18n corner cases tend to arise with a 7-bit 80x24 character-based display (or emulation of same)? Just out of curiosity. * Emacs is, in my experience, one of the best-documented pieces of > software i've encountered. Absent or poor documentation is > typically treated as a bug. > The issue with its documentation isn't, of course, its existence or comprehensiveness. Rather, the last time I tried using emacs, I seem to recall always ending up with this sequence of events: a) I am trying to do some task X, for which the obvious key combination bleeps or does something weird but definitely doesn't do X for some reason. b) Soon, I have a split pane with my document on the left and the help files on the right, with the latter open to a page on task X and the input focus in it. c) A little bit later, I have a split pane with my document on the left, the input focus in my document, and the help pane on the right open to a page on how to switch focus between panes, and I don't remember the long and complicated sequence of keystrokes needed to perform task X any more because it was deleted from my brain's short term memory to remember the long and complicated sequence of keystrokes that is how one says "alt+tab" in the obscure and archaic dialect known as emacsese. d) Repeat b) and c) a few times, while experiencing an acute event of abnormal pre-menopausal hair loss. e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to current task. ;) * The Emacs ecosystem is growing rapidly; http://melpa.org/ > currently > lists ~2400 packages ("extensions" or "addons") available for > easy installation via Emacs' package.el UI. > I wonder how anyone can find anything in that mess. The Java and Clojure IDEs are probably each sandwiched amongst hundreds of consecutive entries all the rest of which are for languages nobody has ever heard of outside of one obscure city near Bernhöfen, or that nobody has used since 1987, or that nobody has used period because the whole thing was invented as an obscure joke (e.g. Befunge). * Clojure-oriented point #1: since ~80%[3] of Emacs is written in > Emacs > Lisp, a lot of work has been put into support for sexp-based > languages; cf. `paredit`. > Point #1, period. ;) * Clojure-oriented point #2: having a polyglot dev system written > in an > easily-modifiable Lisp environment makes it more attractive to > me as someone with a Lisp mindset, as per my interest in > Clojure. :-) > Point #2, period, with some caveats about how "easily-modifiable" something really is if it's easily modifiable by anyone who understands its innards, but understanding its innards requires completing a four-year degree program in emacsology at an Ivy League university. Yes, there can be a steeper initial learning curve with Emacs than > with IDEs, This easily qualifies as a very strong candidate to be crowned understatement of the century, and we're not even 1/6 of the way through this one yet. Steeper? It's like comparing a gentle hill to the part of a roller coaster track that's more than halfway up the side of a loop-the-loop. The emacs learning curve is so steep it has overhangs! e.g. things like 'frames' and 'windows' not meaning > what one might expect (which is hardly surprising, given that GNU > Emacs predates the existence of GUIs-as-standard, and the > Web). Yet this is a one-time cost that, in my experience, is > rapidly amortised as one starts to use Emacs in an increasingly > wider variety of contexts. One-time cost. That's what they tell students about their thirty-thousand-dollar tuition debts they'll be paying off for the next forty years, too, isn't it? :) (See quip about emacsology degree programs, above.) For example: being able to use CIDER > when i wanted to start learning Clojure meant that i could focus > on learning Clojure itself, rather than an entire new dev system. > And I already was familiar with Eclipse... Emacs is surely not the best tool for all developers in all > contexts, And now our fresh new candidate for understatement of the century already has to accept also-ran status as there's a new contender in town that now looks nearly certain to achieve victory. but i also feel it's something that developers - and > Clojure developers in particular - should perhaps at least give a > second look. > Have they gotten around to adding a feature that makes it simple and intuitive to switch between the help pane and a document pane without having to navigate the help pane away from the thing you can't memorize to some other, pane-switching thing you also can't memorize? Such as, say, making alt-tab (or control-tab since nowadays you'd run it in a terminal emulator embedded in a real window system) switch panes? :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
