On Monday, March 30, 2015 at 7:29:36 AM UTC-4, Alexis wrote: > > > Fluid Dynamics <a209...@trbvm.com <javascript:>> writes: > > >> * 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. > > True, but i don't think i've ever heard that one of Eclipse's main > selling points is that it's light on resource usage. >
Its resource usage as a percentage of what's available with a typical developer's hardware now is probably comparable to emacs's as a percentage of what was available with a typical developer's hardware circa 1985. Of course, on modern hardware that percentage can do a whole heck of a lot more, such as presenting an actual user interface. :) >> * 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. > > You respond to me saying that /i/ like Emacs for its ease-of-use > across low-bandwidth links (which i regularly have to deal with) > by .... what, implying that i should be a so-called 'typical' > home/mobile connection user instead? > Forgive me for assuming that you meant to suggest that as a general selling point, rather than a personal idiosyncracy or something. :) > Anyway, 'typical' varies from geographic location to geographic > location. My home connection is ADSL2+, but my mobile provides 4G > speeds only within a limited geographic area - and when i visited > the city of Newcastle, New South Wales, recently, with it's > population of ~300,000, my mobile data connection was > intermittent, let alone of a decent speed. In such a situation, > i've found being able to use a text-based UI, rather than being > forced to use a graphical UI (even using something like NoMachine) > quite a boon. > In such a situation, I'd find using infrequent and discrete network accesses, such as checkins and checkouts from a remote repository, and working with local copies of checked-out files with a local editor on my own device, to be quite a boon. And who wants their UI to have noticeable latency anyways? If you're trying to arrow to a position (or worse, backspace or delete to one), it's like skating on ice: you're prone to overshoot and spend ages playing golf with the damn cursor. If you have a local laggy UI, such as due to something else abruptly hogging the CPU unexpectedly (svchost.exe being the standard culprit on Windows), at least you can resort to the mouse to click the cursor into position in one move, but with a remote terminal emulation you won't even have that option. Further, even ADSL2+ bandwidth can be heavily saturated when other > people on the connection are e.g. streaming HD movies at the same > time as one is trying to work on a remote system .... > Isn't that cable you're thinking of? Which is why sane people use DSL/4G for most needs, unless they download a shitton of giant .mkvs themselves. >> * 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. > > Not quite, at least not insofar as i understand what you're > saying. i'm talking about not having to patch the source tree and > recompile, even across new versions. In my Emacs config, i've > redefined a few different Emacs functions to behave the way i > want, such that, even when i install a new version of Emacs, i > don't need to make any changes to the source itself to get the > desired behaviour. > That sounds unbelievably fragile. Like monkey-patching clojure.core or a major Ruby class, and then updating Clojure/Ruby. > 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. :) > > A strong claim, considerably stronger than the weaker claim that > Emacs needs tweaking to get to one's 'ideal' workflow, or even > that Emacs needs more tweaking than other software to get to that > workflow. To get to something that so much as vaguely resembles your normal workflow appears to take an astonishing amount of tweaking, enough that the word "tweaking" no longer fits nearly as well as "hammering into near unrecognizability". After which, presumably, fine tuning it and actually *improving* on your normal workflow could finally commence. I suppose the process accelerates, though. The more stuff you've managed to make sufficiently sane and nonsurprising, the easier the remainder of the job presumably becomes, particularly if you start with figuring out how and then changing the key bindings for basic UI navigation, saving changes, undo, and a few other things to something natural and readily remembered for more than the first 10 seconds after reading the relevant bit of the help. :) >> * 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 > > ... :) > > A gratuitous insult, but sure, see http://emacshorrors.com/ for > such examples. > > Still, it's easy to dismiss the ugliness of legacy code when one > doesn't have the luxury of not having to deal with the needs of a > diverse user base over an extended period of time: > > http://www.joelonsoftware.com/articles/fog0000000069.html > Oddly, the needs of a very large percentage of the potential user base for any software they use to have a user interface doesn't seem to have been dealt with. :) > 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. > > Do you really think Emacs can only be run in a terminal? I do seem to recall that it is terminal software of a similar vintage to vi, trn, elm, pico, etc.... > 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. ;) > > Yes, i've occasionally been frustrated by some of Emacs' > behaviours also. Fortunately, since Emacs is so easily directly > modifiable, i'm usually able to change those behaviours (not > least, the keybindings for certain things, when i just couldn't > get used to the default keybindings). > The infinite regress of changing the keybindings for changing the keybindings before changing any keybindings ought to enter your awareness in 3, 2, 1 ... :) Having said that, i can't say i've never been frustrated when > trying to use Eclipse. Just one example: i had quite some 'fun' > trying to set it up for Android development with the ADT plugin, > with Eclipse getting itself into a broken state a few times before > i managed to successfully install the plugin. A dodgy plugin does not a bad IDE interface make. Whereas emacs fell down for me at the stage of "create new text file, type something into it, and File Save-As". There's simply no comparison. > So just as you've > had some bad experiences with Emacs (as have i!), i've had some > bad experiences with Eclipse, but /in my own context/, have found > persisting with Emacs to provide a greater benefit than persisting > with Eclipse as my main IDE. > Because, like persisting banging a head against a brick wall, it feels so good when you stop? ;) OK, OK, cheap shot, but really, the progress made "persisting with emacs", at least for a complete n00b without access to an out-of-band help resource of some sort (such as an open Firefox window on some emacs related site -- in my case, it was a unix box whose networking was noworky, without X, and without any other computers handy, let alone networked ones, this being before ubiquitous smartphones and tablets), tends to make "glacial" seem like The Flash by comparison. >> * 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). > > More gratuitous insults. > > Perhaps you missed the text box at the top of the melpa.org page > which allows one to enter filter terms? Type in 'clojure' as a > filter term and see what happens. > Obviously, no such facility was available on *that occasion*. Even once that box's networking was working, there was no GUI, so no usable web browser and no convenient way to put a non-usable browser like Lynx side by side with emacs either. Further, using the package.el UI within Emacs itself, one can use > various Emacs search facilities (not only e.g. `isearch`, but also > extensions such as e.g. `helm-package`) to quickly narrow down the > list of possibly suitable packages. > One can, if one already knows all of the arcana one is searching for. (Same problem as with the help on searching the help, natch.) > 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. > > By the same token, one could argue that one needs a degree in Java > engineering to work with Eclipse, or that one needs a degree in > Clojure to use LightTable. :-P > The funny thing is, one doesn't. Whereas I can't see anyone (short of a photographic memory, at any rate) managing to get a handle on emacs without something like live tutelage with a heck of a lot of drilling and rote memorization. The training astronauts went through to learn how to correctly operate the Space Shuttle probably comes close to being comparable to what I envision being necessary here. Anyway, i tend to feel that being able to use Emacs `Customize` UI > to modify various settings, or to write ELisp like: > > (setq a-customisable-variable 10) > > or even like: > > (defun move-buffer-file (dir) > "Moves both current buffer and file it's visiting to DIR. By > Steve Yegge." (interactive "DNew directory: ") (let* ((name > (buffer-name)) > (filename (buffer-file-name)) (dir > (if (string-match dir "\\(?:/\\|\\\\)$") > (substring dir 0 -1) dir)) > (newname (concat dir "/" name))) > (if (not filename) > (message "Buffer '%s' is not visiting a file!" name) > (progn > (copy-file filename newname 1) (delete-file filename) > (set-visited-file-name newname) (set-buffer-modified-p > nil) t)))) > Oh, don't get me started on elisp. I've heard horror stories. Mutability everywhere. No proper local variable scope. No first class hashmaps with nice literal syntax... > are things that would unduly stress anyone who can program in > Clojure. > Until they reach for a "let" binding as the most natural solution to some particular problem, maybe. And assuming they got past what passes for the user interface. :) > 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! > > That's not my experience, and that's not necessarily the > experience of every Emacs user, even though it seems to have been > your own experience. Different people find different systems > easier/harder to learn. > Now why would that be, I wonder? I mean, given that eidetic memories don't have a particularly high population frequency, so most people would need a shitton of repetitively drilled rote memorization to be able to so much as open, modify, and save a text file without reaching for the help several times. > 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.) > > The same argument could be used to dissuade people from learning > new programming languages. ?? Clojure took me about one week, to get the basics, and perhaps one month to be able to use it somewhat proficiently. And that's a *programming language*, not a mere text editor, which really you ought to be able to just sit at and use if you didn't sleep through ALL your grade school computer classes way back when. Of course it also helps that accessing the help on programming Clojure is done with Firefox, rather than by programming Clojure, so that whole chicken-and-egg thing is avoided. > (For example, many people find that > they need to pay for courses of various lengths to learn the art > of programming, and/or to learn certain programming languages in > particular.) Are you really suggesting that only things that can > be learned in moments, for little to no resource cost, have any > 'true' value? > Of course not. But if getting the hang of opening, modifying, and saving a text file in editor X requires a comparable learning effort to learning an entire programming language, then editor X has a problem, and indeed is tremendously outclassed in at least one aspect even by the lowly Notepad -- how embarrassing. > 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? :) > > Again with the claim that Emacs is a terminal-only application, > rather than being something that can be run in a windowing > environment (i run it under the i3 wm) and a terminal (at the same > time, if necessary). > Well, of course it can be run in a windowing environment. That's called xterm. Everybody who's anybody knows about xterm. :) Of course, the likeliest reason for many a sysadm to resort to something like emacs in the first place is because X is noworky for whatever reason on that machine, though ... As for switching between panes, you can use C-x o > (`other-window`), or (as i do) `windmove`, which allows one to use > e.g. C-TAB j (which i've bound to `windmove-down`) to give focus > to the pane directly below the cursor, or C-TAB l (which i've > bound to `windmove-right`) to the pane directly to the right of > the cursor. > So there was some vague attempt at a nod to being somewhat mnemonic, in that one case. Not that that helps the gazillion would-be users who will all hammer furiously on control-tab and then throw up their hands in disgust. -- 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.
