Do you have any data on the installed user base of Emacs, Eclipse, and Visual Studio?
-austin On Sat Dec 30 12:15 , hank williams wrote: > On 12/30/06, Austin Haas <[EMAIL PROTECTED]> wrote: > > > > > >Hank, no offense, but you obviously aren't familiar with Emacs, so I don't > >think you should be telling people about how it works. You are completely > >wrong on almost every point. > > > > As far as I can tell, based on your own comments, the only thing I am wrong > about is syntax highlighting. My bad. But that notwithstanding, one thing > that comes with being somewhat experienced is being able to understand the > features and comparative benefits of tools without needing to be an expert > in them. Emacs has been around long enough (certainly the early 80's when I > was in school) for those features and benefits and disadvantages to be clear > to anyone who has been in the field. > > And though you may not like my opinions, I think they are very much in the > mainstream based on the installed base of Emacs users vs Eclipse and Visual > Studio and all the other tools that do not derive anything from Emacs. You > might do better explaining why, despite the incredibly small user base > (relative to other tools) that there are circumstances where Emacs rocks. > > I totally agree with the Pragmatic Programmers. Emacs rules and it is great > >for any type of editing. Emacs has what are called "Major Modes" which are > >specific to whatever type of file you are editing. These modes customize > >every aspect of the editor to suit the language. I can edit html, css, xml, > >ActionScript, Python, and Lisp all in the same editor at the same time and > >have each buffer specific to the language, but at the same time many > >familiar keybindings will work across any language. > > > One of the reasons that Emacs is so great and powerful is that it has been > >in widespread use for over 30 years and contains it's own internal > >scripting > >language for customization. The result is that thousands and thousands of > >programmers have been refining and perfecting Emacs over that time. > > > >It is true that Emacs has been around long before graphical editors and it > >does not contain a lot of the graphical features that you might expect from > >IDE's such as Visual Studio, but most Emacs users consider that a good > >thing. If you can learn to stop using the mouse, you will find that you can > >navigate through your code and make edits much faster. Emacs has ways of > >jumping all over your code with just a few keystrokes that are hard to > >imagine if you've only been using the arrow keys. > > > I thoroughly caveatted my comments with not being an Emacs user. But I > understand the "ethos" of Emacs as this has been an argument since the early > 80's when command lines gave way to graphical interfaces. The argument will > probably continue well after I am dead. There is a (thankfully) small group > of people that want the most geeky, non-graphical, complicated, command line > driven tools based on the argument that they are "more powerful". That's > all this is. For this small minority, GUI's are bad. We really needn't argue > beyond this point. > > Specifically, I want to address Hank's claims: > > > >1. Emacs is not clunky in the least. It's more like a surgical tool for > >programming. > > > Based on everything you described, it sounds horribly clunky to me. But this > gets back to the GUI/non-GUI argument. Emacs people believe the GUI is > clunky and commands are smooth. I (and most others) believe the GUI is > smooth and command only systems are clunky. The Emacs view is not > mainstream, though I would thoroughly agree that there is a small minority > of people for which it is the most comfortable way to work. > > 2. Emacs is not a programming language, but it does utilize a dialect of > >Lisp as it's scripting language. > > > I know I studied computer science a long time ago, but way back in the '84 > when I took my first LISP class, it was indeed considered a programming > language. As I understand it, the core of Emacs is LISP and most of the > features of Emacs are built in lisp. These features are modifiable by the > users. I am not sure what you are disagreeing with here. > > 3. Emacs has incredible syntax highlighting support. > > > point taken. > > 4. Emacs can do code completion, but I don't think that it works in the same > >way as some other editors. This is something that I wish it could do > >better. > > > I am sure Emacs could fry an egg too, but you basically admit whatever it > does in this regard is not up to snuff. And I seriously doubt it compares in > any way to something like java in eclipse. One of the things that people > tend to do in these arguments is make some argument that if you stand on > your head with one hand in your pocket and one arm extended at exactly a 45 > degree angle, you can achieve the desired result. This relates to point 1. > which is that to achieve the desired result in Emacs would be *clunky*. This > is why *no one* (well very few people) code java in Emacs for example. > > > Some other benefits of Emacs: > > > >1. I can edit files remotely via ssh, side by side with my local files. > >2. I can easily add new editing functions, such as inserting a trace > >method for the current function signature. > >3. I can collapse functions to just their signatures. > >4. Very powerful regular expression searching and replacing. > > 5. I can collect the trace output from my swfs directly into an emacs > >buffer, and use all of the power of the editor there. For example, in > >multiplayer games, I can capture the output from two players into the same > >buffer and use emacs regexp-highlighting functions to highlight all > >messages > >from one player as blue and the other as red. > > 6. I've also built a runtime swf profiler into Emacs. > > 7. Every aspect of Emacs can be customized. If there is anything that you > >wish could be different, you can change it. I think this is why the > >Pragmatic Programmers recommend it. > > > I don't want to design an editor. There is nothing that I could do as well > in my spare time that could not be done far better by a dedicated team > totally focused on the given task. I want an editor that is designed for > what I am doing so I don't have to customize anything. Honestly I don't > think I am doing anything much differently than anyone else so I shouldn't > need much customization. This is borne out by the fact that the Eclipse Java > editor fit me like a glove right out of the box. No customization needed. > > 8. Whenever Emacs opens a brand new file that ends in .as, I have set it up > >to automatically insert a bunch of boilerplate code, such as the package > >line, class line, constructor skeleton, and a toString method. > > 9. I can compile my actionscript from Emacs, using either mtasc or mxmlc, > >with one button. If there are any errors, Emacs will find the error in the > >correct file, highlight it in red, and put my cursor on it. > > > >...but, Emacs has literally millions of features and add-on packages that > >I'm still discovering every day. > > > > Millions of features is *not* a benefit in most products. I think that > includes editors. As I said in my initial post, the fact that Emacs > is/contains a programming language means that it can definitely do things > that eclipse editors can't do. This is always what badly designed tools fall > back on. Emacs is an accretion of features, not a designed product. > Thousands of people adding pieces a bit at a time just *can't* yield a > seamless productivity tool for all but the most dedicated. > > I want something that works really well, not something where I have to > spend a year learning a language and customizing to work well. And of course > as you admitted it doesn't do code completion very well. And, based on your > description, it doesn't do error detection as well as the Eclipse Java > editpr either, which detects errors *as I type* and shows them to me with > markers on the side or the window without even compiling. When I move my > cursor over the error marker it suggests the fix for the problem. This may > not be important to you, but for me (and I think most) seamless error > detection, once you have experienced it, is something you will never give > up, > > But the bottom line may just be this: Emacs may just be for the smart > people, and I alluded to this in my earlier email. I may not be smart enough > to use it effectively. I'll cop to that. > > But coming back to the initial question, this argument is not about which > editor is "better", but about which one is better for a given task, and > whether it is best for the average programmer to only use one editor, which > would therefore mean not accessing what I consider to be far more advanced > language specific features like in eclipse or even visual studio. I would > definitely argue that a text based editor such as Emacs or vi is definitely > something that should be in your arsenal. As you correctly indicate, there > are things text based editors can do - like work in a terminal window etc, > that GUI's cant. And if you need to write code (in LISP) to do custom > things, then you should definitely consider it for certain tasks. But give > up the GUI for the command line for my primary editing? Nah. I don't code > much in assembler these days either. The stone age just wasn't that much > fun. > > Regards > Hank > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org -- Austin Haas Pet Tomato, Inc. http://pettomato.com _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
