Adlai said:
Adlai said:
I forgot a few notes:
[1] from page 191 of On Lisp, by Paul Graham
[2]
www.gigamonkeys.com
[3]
http://www.psg.com/~dlamkins/sl/
By the way, for the (1+ n)th time, SLIME Emacs is a modern IDE. It has
all the functionality that you've described an IDE should have. The
ONE thing it doesn't have is popping out stuff into neat little help
bubbles, but that's cosmetic, not a functionality.
Being able to see a nicely organized workspace with visible context for
displayed informaton, instead of just one page of text at a time in one
window, is "cosmetic, not functionality"? Pardon me if I disagree.
I think it depends...
Hardly ever. Even when the task being done in the application is very
simple, the user benefits from a modern interface that lets them easily
use MORE THAN ONE APPLICATION relatively seamlessly, without clunky
switching mechanics (like unix "fg" shell commands).
About the only exceptions I'd grant are a few workplace applications
that have one main screen and really really should get the user's
undivided attention at all times. The program that displays radar
information on a screen in front of an air traffic controller is the
only one that immediately comes to mind as definitely belonging to your
"it depends" exceptions.
for example, some information can just as
concisely be displayed in the status bar of the editor
One fairly short line of text may suffice for that, but not for, say,
displaying the full Javadocs of the method whose name you've just typed,
or dropping down a whole menu of possible completions, and lacks a way
for the user to select from among the latter, besides.
Not at all like Emacs. You're thinking about some version of Emacs
from before when I was born. I just now went to Help -> About Emacs,
and here's the version info:
You must be joking. The above is "like" every single pre-1990
application I have ever used, and pre-1990 applications do not have
"Help -> About", though they may have some sort of "about" feature
accessed in some way such as by typing control-A or typing "about" at an
internal prompt or "foo --version" at a shell prompt.
The final thing to note here is that emacs was already over a decade old
in 1990. We're lucky its primary means of interaction doesn't involve a
deck-sorter.
This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02
A 2007 Model T would still not be a Mercedes-Benz. Particularly if it
were sufficiently "Model-T-like" to not be a Model T in name only.
That's basically what programming in Emacs is like nowadays!
Perhaps I should let you guys know a little secret: I've used emacs.
Recently. Had to do some editing on a unix box I had no physical access
to, and which didn't have remote X capability, around mid-2006.
In a nutshell: Ugh. Next time I'm demanding hazard pay, I think it
raised my blood pressure dangerously high trying to work with the
flippin' thing, and at the age of fifty I need to start paying serious
attention to matters like my blood pressure.
The upshot here is, I know the above is bull. Right-click with what
pointer? Separate windows? The best emacs could do (in 2006) was to
split the screen vertically, which meant looking at both documents
through a pinhole, or split the screen horizontally, which meant looking
at each document through a gap between horizontal window blinds.
A script in the editor's scripting language should not be able to go
directly to the operating system to request window handles and suchlike,
yet this would be necessary for SLIME to do as you've just claimed.
The editor's scripting language capability is therefore a disaster
waiting to happen. Even Word's infamous susceptibility to macro viruses
doesn't endanger the host operating system or computer; if your emacs
scripts have unsandboxed access to the system, a hostile one could, say,
send a large volume of email spam that YOU would get in trouble for.
I can use the mouse to select text, navigate menus, choose
options, etc
Yes, when you decide to eschew emacs in favor of Notepad++, I'm sure you
can.
Heck, search and replace is child's play for this Emacs
Search and replace in emacs is an exercise in hair-pulling,
pill-popping, and spending hours poring over the (extensive, but with
poor browsing UI) online help.
it can do all the same search and replace stuff with RegExps too.
Put that in NetBeans's pipe and smoke it!
NetBeans has search, incremental search, search and replace, and
regexps. Oh, and it has a decently usable interface on these. Oh, and it
has searches that can tell instance variables, static variables, class
names, method names, package names, and other categories of identifier
apart and even know which ones are in scope where. You can find every
instance of java.util.Date in your code without it also matching
javax.sql.Date. You can't do this in a plain old text editor, a search
for "date" will find both and a search for "java.util.date" won't find
either occurrence of java.util.Date in "Date today = new Date();" in a
file whose preamble contains "import java.util.Date;".
Oh, and it can do such smart things as renaming a class properly. If you
rename mypackage.Foo to mypackage.Bar with NetBeans, it changes:
* References to the class
* Including as just "Foo"
* Without renaming references to otherpackage.Foo
* Even references that just called it "Foo"
* and it will even rename the Foo.java file to Bar.java for you.
Renaming methods works similarly, and will recognize Foo.method():
* as "method()" in Foo or a subclass
* and as "someFoo.\nmethod()", i.e. split across lines
* even when "someFoo"'s type is declared far away
* and without hitting "Mumble.method()" or any other same-name
method.
Both will update links in the Javadocs too.
No text editor can approach this degree of integration with the target
language.
Look, all we're saying is, Emacs today isn't what Emacs was 30 (?)
years ago.
Once a Model T, always a Model T. No amount of cosmetic improvements or
bug-fixing will allow it to escape its fundamental nature, nor to evade
the constraints set by fundamental design choices made in its infancy
and now woven throughout the code.
Only a total rewrite could accomplish such things, and the result would
then be emacs in name only.
It's the same as with IBM. If somebody who had been in a
coma for 30 years heard that I was using an IBM Thinkpad, he'd
probably envision some sort of "padded" mainframe, not a laptop.
Same company, different product, rather than same product, different
version. Your analogy does not hold.
OK, the shrink is a bit of a joke, it's a clone of an early AI program
that simulates a Rogerian Psychiatrist. But aside from the shrink,
Emacs nowadays is as functional a word processor as any.
Literally impossible. It might be capable of functioning as a word
processor (WordStar managed, under the same constraints), but to be "as
functional ... as any" would require features that are physically
impossible when your user interface is just a box of text.
WYSIWYG, for one. Arguably overrated, with reference to TeX-like markup
as an alternative, but I think it can be quite useful, and like it or
not, it is a feature that emacs cannot have that, for instance, Word has.
For anything with complex formatting, WYSIWYG is far better than an
edit-compile-view cycle (TeX) or worse, an edit-print-view cycle
(WordStar). The latter consumes paper and toner, the former lets you see
what you're doing as you're doing it, and the middle road lacks both
traits. (Frankly, I would like the best of both worlds: a logical markup
language in a left hand pane and a right hand pane showing a
near-real-time WYSIWYG view, possibly supporting at least a subset of
editing commands. I know of nothing that provides such. Certainly it
would have to be a modern GUI application though.)
SLIME adds integration to an external Lisp compiler (Emacs Lisp is a
different dialect of Lisp, and it's basically only useful for
customizing Emacs).
Leaving aside any quibbles about exactly how useful "customizing emacs"
really is, this especially sounds like it's just begging for trouble.
Lisp programmers using this editor are going to have to work in both
dialects, close together in time; a recipe for frequent mistakes.
(I say have to, because if for some reason you are stuck using emacs,
say because you're being forced to at gunpoint and if you reach for a
real editor you'll be shot, then you sure as heck will want to do what
you can to tame the beast, which will require working with elisp.
Without using elisp, the best you can do is fix the horrid key bindings
to adhere to some semblance of modern standards.)
Everybody here is completely serious when they say that Emacs
is just as powerful as NetBeans, or any other modern IDE.
I don't consider boxes of ASCII to be powerful; sorry. See above for
some more features of NetBeans that emacs will lack.
Even if you consider its capabilities powerful, those capabilities are
trapped behind an extremely un-powerful user interface that even makes
it slightly more difficult to use for plain-jane typing in some text and
saving it than Notepad is. To attempt anything really complex through
that interface is a task I shudder to contemplate.
There is a post by someone else in this thread that I also recommend you
read, which goes into a lot of detail about the benefits of graphical
user interfaces over text ones, some of which apply even when the user's
task amounts to text editing of some kind.
Another topic that came up is the visual diff in NetBeans. It's not
possible to emulate this in emacs, vi, or anything else stuck with only
the ASCII palette to paint with, and the same with a lot of other useful
features.
