i'm assuming this response is a troll, given the use of the sort
of gratuitous insults that Bozhidar mentioned; specific examples
noted below. (And this somewhat amuses me, given the recent
discussion about whether it's possible to critique different
technologies without resorting to doing little more than
trash-talking them.)
If it's /not/ intended to be a troll, then i feel it pretty much
providing data which substantiates Bozhidar's complaint.
At any rate, on this occasion, i'll respond to a number of the
points made; but feel free to have the final word (and sling some
more gratuitous insults).
Fluid Dynamics <a2093...@trbvm.com> 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.
* 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?
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.
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 ....
* 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.
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. i actually agree with the latter claim, but also feel
that /for me/ the the benefits of doing most of it just once in
Emacs have vastly outweighed the costs. i certainly acknowledge,
howver, that this is a classic instance of 'YMMV'.
Of course, there are some IDEs that run on top of the JVM, and
are thus as widely available platform-wise as the JVM ...
Granted.
* 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
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? If you
do, then it suggests you don't even have a basic familiarity with
Emacs, which has had GUI support for around a couple of decades
....
i generally use a GTK3 build of Emacs, and only use a
terminal-based frontend to the Emacs daemon when necessary (and
when it is, i'm glad such a facility is there).
As for i18n issues, here's a current thread on the help-gnu-emacs
list:
https://lists.gnu.org/archive/html/help-gnu-emacs/2015-03/msg00205.html
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).
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. 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.
* 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.
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.
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
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))))
are things that would unduly stress anyone who can program in
Clojure.
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.
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. (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?
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...
Fair enough.
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).
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.
WFM, YMMV.
Alexis.
--
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.
