Post #114,321
8/19/03 11:42:35 AM
|
And the answer is...
I use emacs for everything. It's more than an editor: it's a textual IDE. Because it's programmable, open source, and has a huge user community, the range of features is simply stupefying. - Must haves:
- Consistency. Everything in emacs is treated as a text buffer. Shells, directory listings, compilation results, FTP sessions... everything supports the emacs editing functionality. I can use the same edit keys to copy a block of shell input and paste it into a remote file opened through FTP. I can write a keyboard macro (not LISP program) by recording keystrokes, and use it to iterate a list of files in a directory, search for a phrase in each file, copy the next three lines, and paste them into a file opened within a .tgz archive. Because of this consistency and simplicity, everything becomes easy to learn and easy to do. And because emacs integrates the shell and many command line programs, I'm more productive with the same ubiquitous tools that programmers on Unix take for granted. Finally, the basic emacs keymappings are the same as those for all GNU readline programs such as bash. In fact, I'm using emacs editing keys in this Mozilla text box.
- NO MODAL EDITING. Yes, this isn't supposed to be a vi vs. emacs war, but I've seen so many people struggle with vi because of the modal editing... you should be able to just put your cursor whereever and start typing, with no special keys needed. Anyone who can use arrow keys and type can use emacs.
- Keyboard macros. Do something once while it's recording, then repeat that sequence X times, or over a block of lines.
- Incremental search. Only type as much as you need to find what you're looking for. People who use Mozilla's link typeahead feature are familiar with this.
- Text mode operation. If I can't use it in a remote shell or without a mouse, it's useless.
- Syntax highlighting. Almost everything (even vi if you use vim) has this. Add to it extra functionality by file type: Java-specific commands for java files, Python interpreter invocation for Python files, etc.
- Automatic indentation. This feature is useful for doing mass clean-up of badly-formatted files.
- Directory browsing and editing. This is an amazingly powerful tool when you're developing. I can split the emacs screen, put a directory listing in one buffer and open files in the other. Since the directory always stays there, I don't have to hunt through Open File dialogs or remember file names.
- Cross-platform.
- Backup files: both while editing and last version.
- Tab completion. I'm lazy and forgetful. Don't make me remember the full file name, and don't make me use a visual dialog to open the file.
OK, more than 5, but I'm a needy kind of guy. ;-)
- Why is emacs better than the others? See above. No other editor does everything that emacs does, nor as well as it does. The single most important aspect is the consistency and (because of that) the simplicity of the interface.
- Why is emacs better than an IDE? It does more. ;-)
- Directory editing, local and remote (FTP, web-dav, etc. - acts just like a local directory).
- Editable keyboard macros. I don't usually write shell scripts: I open a shell in emacs and write a keyboard macro.
- Syntax highlighting and special functionality for every language known to the human race. Example: SQL mode: make a connection to a database, edit SQL, execute queries, edit the results and hit a key to save the changes automatically.
- Programmable, and open source.
- Shell, FTP, telnet integrated.
- Programming tools: diff, grep, version control, etc.
- Browse .zip, .jar/war/ear, .tar, .tgz, etc. archive files. Edit files directly within the archive without manually unpacking/repacking. This feature has excellent awe factor when you have a fellow programmer watching over your shoulder. I just did that this morning, in fact. ;-)
- Narrow-to-region: restrict your view to a subset of a file so you can search-and-replace with impunity on that section only.
- Regular expression search/replace.
- Full context-sensitive help and tutorials. Integrated man pages.
- Kill-ring for multiple level cut-and-paste. Never lose anything accidentally.
- Browse the web in emacs. Play tetris. MUD. Whatever. :-)
- Transpose two characters. Damn, is this useful. Minor, but I really miss it when it isn't there.
- Too many other features to list. It's In There.
- Estimate productivity. Hard one... emacs is like a part of my arm. When it's not there, I can find things very difficult to do. Somewhat like having to use a shell that doesn't have tab completion. People who watch me work in emacs are amazed by how much I can get done in a very short amount of time. I'd say we're talking an order of magnitude, at least.
- Plug-ins: everything in emacs is a plug-in. Most of the functionality is provided as LISP .el files that are either loaded on-the-fly or in the startup file.
- Good editor for newbies: emacs. Spend a little more time up-front and reap the rewards for the rest of your career. :-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,377
8/19/03 4:54:15 PM
|
So....
....Scott, tell me what you really think :-)
Okay to quote you? Have a title? Is it god-of-emacs? :-)
WRT the newbie question....what if learning time up front
were limited? Could the newbie start with another editor
and then make the jump to emacs later on? Other approaches?
Thanks,
-Slugbug
|
Post #114,380
8/19/03 5:04:33 PM
|
Re: So....
I'm trying to decide which title to use. How soon do you need to know?
WRT to newbies: As I mentioned, you can use emacs if you can use arrow keys and type. Then move into the deeper functionality as you become more proficient. Emacs is very forgiving of new users -- it has a tutorial, context-sensitive help, apropos help (type a word or fragment, get all commands with that word), and a huge user community. There is some mouse capability, including help menu navigation, most-frequently-used commands, and the like. The transition from newbie to god-of-emacs can be as gradual as the user needs it to be.
My son learned a few basics in 15 minutes and was immediately able to start editing HTML files, save them, and view them in Mozilla to see the changes.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,383
8/19/03 5:21:53 PM
|
Appropriate title?
Gatekeeper for the almighty LRPD. (Or was that the "Keymaster"). :-)
|
Post #114,384
8/19/03 5:24:28 PM
|
No.... for you, it's "Sir". ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,429
8/19/03 10:12:40 PM
|
titles, brilliant kids, and comparing programmers.....
....I'm suppose to turn around a rough draft by next Monday.
So, send an e-mail over the weekend if nothing else.
Your son sounds as brainy as my daughter... Gotta make you smile.
What I was going after with my newbie questions is the perception
on the part of PHBs and commercial software tool providers that
"pointy clicky" is what is needed to make a good programmer. I'd
like to find a way to erase this notion, but need some solid data
to back it up. Still researching...
-Slugbug
|
Post #114,431
8/19/03 10:31:21 PM
|
Pointy clicky...
... makes for a programmer tied to the tool, which is the angle I'm sure the tool makers care about.
I'm not sure you're ever going to convince a manager that point 'n' drool isn't the best way to go. I work at a fairly enlightened company where we can use anything we damn well please, but they are still trying to find the ultimate IDE to make all the programmers ultra-productive. It's a hard attitude to shake, especially since one of the drivers is a phenomenally productive programmer who credits his tools (Visual Studio 6, of all things) for his productivity instead of his own brilliance.
However, their slant is more "how can we make are already good programmers more productive", not "how can we get a newbie up to speed quickly". Most of the people here use vi (or sometimes Notepad) and shell.
The only thing I'll use a visual IDE for is 1) debugging (rarely) and 2) GUI interface design.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,433
8/19/03 11:06:10 PM
8/19/03 11:18:17 PM
|
Definitely with Scott on this one...
IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them.
I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like.
Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky".
It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events.
It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database.
It comes from working with a language for at least 12 months.
It comes from having enough computer science background to build the right data structures and algorithms.
It comes from exactly the kind of development experience that most U.S. companies are laying off in droves right now.
Bosses understand "pointy clicky". It can be demoed to them. However, it takes a long time to understand EDI protocols, and sockets, and standard Unix libraries, and standard C libraries, and base Java libraries, etc. etc. etc. Smart bosses balance the fact that there "is no silver bullet" with some respect for new technology.
JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast.
However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit).
Edited by gdaustin
Aug. 19, 2003, 11:08:44 PM EDT
Edited by gdaustin
Aug. 19, 2003, 11:15:47 PM EDT
Edited by gdaustin
Aug. 19, 2003, 11:18:17 PM EDT
|
Post #114,554
8/20/03 11:29:04 AM
|
Disagree RE GUI development
I can write the GUI faster than I can draw it in nearly every environment. I learned this from some guys on a team I worked on long ago. I always used to think GUI's were too expensive to write by hand. Some guys on our team who were responsible for the UI eschewed GUI builders - they said that GUI builders only seem more productive - if you measure the actual amount of time they take to use its longer. They told me to sit down and try it - I found they were right.
The only ones I consider an exception is using InterfaceBuilder on OS X. That's because nib files are so thoroughly baked into the toolkit that its harder to do things without them.
The rest of them generate code which violates Blanchards Law - code generation is to be avoided at all costs. IB serializes object archives (ditto Morphic - the UI toolkit in Squeak).
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #114,611
8/20/03 5:08:37 PM
|
I like your Law so much I twikified it.
[link|http://twiki.iwethey.org/twiki/bin/view/Main/BlanchardsLaw|http://twiki.iwethey...ain/BlanchardsLaw]
Feel free to flesh it out. If I get time, I'll add my own discussion of why I avoid code generation.
"There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #114,651
8/20/03 8:42:36 PM
|
heh - cool
Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations.
--AndyBower
|
Post #115,052
8/23/03 11:02:42 AM
|
What he said...
...I could not agree more:
"The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky"."
"pointy clicky" is a real frustration point for me. At my current gig, I spend a fair amount of time writing code, but I also have to help others debug their code -- much of it "point clicky" derived. Just yesterday, I was helping a coworker who could not get his code to work. After verbally describing to him what he needed to do and seeing his glazed over expression, I opened the manual and read the documentation with him. I could then see the lightbulb go off over his head and he said "you are so smart". No, I just RTFM.
As Scott mentioned in his post, "pointy clicky" makes for programmers who know the tool (I concur). I'd add that this trend also makes for programmers who don't RTFM or understand a given language and its libraries.
-Slugbug
|
Post #114,451
8/19/03 11:45:54 PM
|
People buying the software...
The Managers and Directors and Vice Presidents want some things.
They want to ignore that fact that computer programmers are professionals.
Commercial software developers tell the buyers that their software will "revolutionize" the industry. I've heard it for almost two decades now. They promise that companies won't need programmers anymore. Business analysts will be able to "do most of the work", and you'll only need programmers for the last little bit.
And funny, they appear to almost accomplish it, when new technologies come along and make everyone start over again.
Back in the MS DOS days, Clipper was a pretty good non-programmer environment. Paradox was too. But, people would always stretch the tools to the limit, and then drop into programming to accomplish the last part.
If you're doing something significant, you need a large database and a server system. You can't do it on Clipper or VB or Delphi or even JBuilder. Even though people are telling you, I'm not even sure you can really do it in EJB's. But maybe you can if you decide to purchase a lot of hardware.
A GUI development tool will allow a non-programmer to get so far. IDEs facilitate that. But you need a programmer to give you the last 30-40%. The back-end server stuff.
BEA/IBM and other middleware vendors are now trying to "GUI-ize" the back end, the server part, which is usually written in a high performance language with a high performance database. EJB's are a start. And I think Web Services are another attempt. Will they succeed? I don't know. Back in my Tuxedo days, we were trying to do the same thing with InConcert, a workflow tool BEA bought from Xerox. Make a GUI that builds and exports "services", that seems to be the mantra right now.
My thoughts are you don't need BEA or IBM's GUI tools. You need some good developers. And a good Code Editor or IDE tool (but don't promise pointy clicky with it).
Glen Austin
|
Post #114,453
8/19/03 11:50:10 PM
|
And the congregation said:
AMEN!!!!!
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Your arms lengthen daily like the edges of a festering table.
|
Post #114,523
8/20/03 8:24:34 AM
|
Of Mice and Programmers...
I should have mentioned above that we have Happy Hacker Keyboards on our programming computers. I know I mentioned GNU screen - I have typically 9 screens open for programming and at least 3 desktops in WindowMaker in use.
The mouse is usually used for testing the application (it's and intranet app), or sometimes copying text. The last time I had to use a mouse to program was back on Windows when the keyboard shortcuts were awful or just didn't exist.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #114,551
8/20/03 11:03:50 AM
|
Well, then in THAT case
I actually will chime in and say I use Wordpad more than anything else. I have only a couple of apps with a traditional GUI, most are web apps. There are web-developemnt tools out there, but I'm such a control freak, I can't stand to use any HTML-generator. Because you can usually tell the difference, in cleanliness, stability, maintainability, and performance.
Of course, now that I use Python a lot, I am using the "IDE" included with Python, which doesn't do much more than window and syntax-highlight.
"There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
|
Post #114,437
8/19/03 11:24:54 PM
|
Re: So....
Do you ever write any LISP extensions to the IDE?
I must admit I find this aspect of emacs fascinating.
-drl
|
Post #114,527
8/20/03 8:58:42 AM
|
Nope.
But I have a healthy respect for it. I've modified a few .el files, but nothing major.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,543
8/20/03 10:18:59 AM
|
Re: So....
Do you ever write any LISP extensions to the IDE?
I've written some simple modes and have extensively modified the way some commands work.
Small example ... the GNUS new browser used F for followup (to the newsgroup) and R for reply (email the author), and I habitually pressed the wrong key.
So I wrote a small function that would query "Do you want to post a message or email a reply?" to the user and then do the right thing. Although I occasionally still answer the question wrong, it has eliminated most of my posting errors.
My emacs startup files contain nearly 3000 lines, accumulated over the years.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #114,660
8/20/03 10:40:03 PM
|
I modified the code...
to check for function signatures for C functions so it would handle our "style" of function.
Also, I "code reviewed" another guys lisp function changes in emacs.
But, it's now been about 6 years since I've done emacs. I need to get back into it, because it's cool. Right now I'm trying to get a Visual C++/VBScript demo done for the CEO for a customer conference next week.
But, he's promised me when he gets back that I get to replace the system with PHP, and replace all the ADO code with back-end PHP and server-side scripting.
He just doesn't think I can get the PHP done by Monday (it would involve rewriting our current GUI interface system, about 120 pages).
Glen Austin
|
Post #115,055
8/23/03 11:07:44 AM
|
Scott...
...still want to be quoted? If so, "consultant" or some other title?
If it helps, I can probably just use a title (no co. name).
Thanks,
-Slugbug
|
Post #115,059
8/23/03 11:24:31 AM
|
Re: Scott...
Either "consultant" or "Senior Software Architect". No one seems to know the company policy, so I can't use the company name until I find out.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #115,086
8/23/03 3:54:18 PM
|
thanks...
...title is fine then. Appreciate the help!
|
Post #114,381
8/19/03 5:09:45 PM
|
Re: So....
Windows has User Interface Conventions that make using it common.
For example Ctl-Z undoes things. You get a ways into a
thought process writing code, and you realize what you were
doing is a bad idea. If you follow the Ctl-Z convention, then
someone who has done MS Word or Excel can Undo, using Ctl-Z.
So, for Windows newbies, use Windows conventions.
Look at who your audience is. Newbies to code in a Windows
environment need Windows conventions.
Programmers in a Unix environment generally expect things to work
like vi or emacs, so good editors would follow one of the two
conventions, probably more like emacs than vi, because the vi
conventions are harder to learn.
So for me, that's your answer. Find your audience and test the
editor against the feature lists we have given you, PLUS what
the user would reasonably expect to do in certain situations like
1. Undo
2. Find and replace
3. Find matching braces
Etc.
|
Post #114,845
8/21/03 10:25:35 PM
|
I'm still a vim man...but I respect what emacs can do.
Part of problem that Slugbug (Maggie iirc) is going to run into is that there isn't a "right" solution imo. (Though Emacs does come close)
Personally, I think a professional programmer needs a good text editor and a good debugger. (There's always that other guy's code that you have to interface with that coredumps) They don't have to be integrated (IDE), but he has to master them both.
The trouble is that manager assumes that the tool produces the productivity (as gdaustin says below). It doesn't, but there's a reason to believe that. A good tool merely allows the professional to be productive, a bad tool hinders him.
That said - it's a poor craftsman that blames his tools.
The best people to ask are the programmers. A good programmer spends a lot of time learning his tools - knowing how to be productive in them. Emacs and Vim are good cases in point. They're "mere" text editors - but they takes time to learn how to be good with them.
My advice for companies out there? Ask your programmers. Let them try it for a few weeks, then mention that you're not picking up for the contract for it.
If there's agreement - it's definitely something to avoid.
If there's minor complaints about it - they think they might use it, but probably won't.
If they demand that you change your mind or they're walking out - they want it and they're using it.
|
