Post #114,252
8/18/03 11:02:05 PM
8/18/03 11:15:05 PM
|
Care to be quotable on code editors?
I've been tasked with writing a feature about code editors.
This is not a "vi" versus "emacs" piece. The idea behind the
piece is to describe when to use code editors versus when to
use IDEs. Personally, I use a text or code editor as I find
IDEs to be a pain in the butt.
Do you use any of these editors (random order):
jEdit, Visual SlickEdit, TextPad, Programmer's Studio, emacs,
JED, SourceEdit, Glimmer, vi, Jext, Crisp, nEdit, ProjectBuilder,
Gel
[Are there other editors I should add to the list above?]
If so, questions I'm seeking to answer:
1). What are your top five must-haves in an editor?
2). Why is your editor of choice better than other editors?
3). Why is your editor better than an IDE?
4). Can you estimate how much more productive you are with an editor versus an IDE?
5). Do you use plug-ins with your editor? If so, which ones and why?
6). What would be a good editor for newbies? why?
I'm looking to form quotes by answering these questions. If you care
to participate and possibly be quoted, post answers here or send me an
e-mail (maggiebiggs at acm dot org). I'll need to include a title and
company for anyone I quote. If you don't wish to list a title/company,
consultant always works :-)
If you are not interested, simply hit "mark read" now...
-Slugbug
Edited by slugbug
Aug. 18, 2003, 11:15:05 PM EDT
|
Post #114,257
8/18/03 11:26:36 PM
|
Sounds like you want to talk to our admin.
[link|http://z.iwethey.org/forums/render/content/show?contentid=103736|#103736] gives some of his thoughts on emacs, etc.
Cheers,
Scott.
|
Post #114,267
8/19/03 1:08:46 AM
|
I'll give it a shot
Currently my three editors are, in no particular order, vi, BBEdit and ProjectBuilder.
(ProjectBuilder is actually a GUI front end to the GNU dev tools and almost qualifies as an IDE. Some might argue this point.)
- I use vi when I have to knock together a small script (shell, python or perl) or when I have to do a quick search and replace and I'm on a UNIX command line. (I have also used ed for quickly modifying large text files since it doesn't have to load the whole file into memory like vi.)
- BBEdit is by far my favorite text editor on my Mac. It's quick, powerful, has syntax-coloring, programmability (Applescript and shell script) and lots of nice macros. I tweak HTML with it as well as use it to knock up text files quickly to dump into another program. (For example, I might take notes in BBEdit during a lecture, meeting or while I'm performing a software installation/configuration. Then I can keep it as plain text or dump it into a word processor or presentation package for fancier work.)
- ProjectBuilder I use for most of my C/C++ code and occasionally for Java. (I'm still trying to find the time to teach myself Objective-C and Cocoa. Sorry, Todd.) As I mentioned above, I feel it's more of an IDE than an editor. Although you could technically consider it an editor with hooks into gcc, g++, gdb and other dev tools.
Tom Sinclair
Instructor, Computer Programming
Westwood College of Technology
Baldrick : Don't worry mister B, I have a cunning plan to solve the problem.
Blackadder : Yes Baldrick, let us not forget that you tried to solve the problem of your mother's low ceiling by cutting off her head.
- BlackAdder III, Amy and Amiability
|
Post #114,352
8/19/03 3:51:26 PM
|
Thanks....
....forgot to include BBEdit....will add it.
Follow on question: when teaching students or other newbies,
which editor do you recommend to them? Why?
I appreciate the help!
-Slugbug
|
Post #114,370
8/19/03 4:40:19 PM
|
Teaching is a slightly different issue
There are a couple of constraints I have to work with here:
- Budget (as in usually none)
- Required platforms (in our case, Windows 2K Pro and Linux for the programming classes)
Linux really helps with budget issues. Our students don't usually have a lot of money to throw around, so I'm always on the lookout for free/extremely cheap solutions. I hand out a lot of Knoppix CDs as well as Red Hat install disks. My current standard Linux build for programming is based on Knoppix so I can just hand out the CD on the first day and they have all the tools we use in class. (We have a standard Windows build as well.)
For Windows, the choices are a bit more limited. We currently use Visual Studio .NET in the classroom but our license agreement with MS does not allow us to give our students copies for their home machines. We have an academic version of VS 6 but I'm told it won't run under Windows XP.
Anyway, back to editors. On Windows, I'm currently recommending ConTEXT, a free programmer's text editor that has syntax highlighting along with a host of other nice features. You can get a copy at [link|http://fixedsys.com/context/|http://fixedsys.com/context/] . I also hand out GNUWin CDs (available at [link|http://gnuwin.epfl.ch/en/index.html|http://gnuwin.epfl.ch/en/index.html]) which provide many FLOSS software designed to run on Win32 PCs, including a number of editors and other development tools.
Most of our programming classes can be run on either Linux or Windows and it's up to the instructor to pick the platform. I prefer using Linux when I can and recommend that students learn more than one platform and try to code to standards as much as possible.
Frankly, I feel that if you're trying to 'future-proof' up-and-coming technical professionals, you could do worse than get them comfortable with Linux.
This seems to have turned into a bit of a rant. However, schools always seem to be locked in battle with hardware and software vendors, wrestling over control of the hearts and minds of our students. (Publishers jump in on the rest breaks.)
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #114,556
8/20/03 11:47:24 AM
|
Teaching - use whatever you like
I let them use whatever they want. I don't care. I recommend things if they don't know what to get - but generally they don't ask - they use what their friends tell them to. The programs are generally small enough that they send me a few source files anyhow - plain text. I write scripts to import them and run them in whatever environment I'm using (I used to grade C and C++ using Metrowerks).
For one thing, I'm an anti-windows activist of sorts. I don't recommend it, it never require it, and I don't do anything that increases the value of that platform to anyone - I simply pretend its not there. If asked specifically about it I suggest they ask someone else - I'm not the best source of information about that platform as I'm willfully ignorant of it. That prevents me from being qualified for anything I don't want to do.
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,579
8/20/03 1:43:00 PM
8/20/03 1:47:58 PM
|
I do that as well
With the exception of our C++ .NET course, all of our programming course work can be done on any computer that has a compatible C++ or Java compiler. I make sure my students know that they can use what they want.
I also tell them what platform I'll be using to test their code. (Usually Linux or OS X)
I push OSS for as many of our courses as possible for three reasons:
- It's budget-friendly
- It's license-friendly
- We can give copies of the software to the students without feeling paranoid. (SCO notwithstanding.)
It's not forced on anyone and the platform choice is always up to the individual instructor.
In the classroom, I use a standard Linux build with VNC to share my desktop.
Another plus: With Linux, I can give all my students root access, whereas with Windows we have a policy of not allowing Admin access. (This may change with Visual Studio .NET, which requires more than User access to compile and run code.)
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
Edited by tjsinclair
Aug. 20, 2003, 01:47:58 PM EDT
|
Post #114,580
8/20/03 1:46:22 PM
|
rofl
-drl
|
Post #114,263
8/19/03 12:54:16 AM
|
Re: Care to be quotable on code editors?
Personally, I use a text or code editor as I find
IDEs to be a pain in the butt.
Borland C had an IDE that was not only not a pain in the butt, but was a perfect, advanced interface to C on the PC.
Now, yes, MS IDEs are horrible. But, they are MS. Everything they do is bloated, stupid, and ugly.
But don't blame the idea of IDEs.
You missed Ultraedit and (x)wpe.
-drl
|
Post #114,355
8/19/03 3:54:46 PM
|
no blame here....
...not trying to focus so much on IDEs as much as when
code editors are more effective. I have to leave my own
opinion out of this. However, I will say that I do like
some of the Borland tools.
Will add Ultraedit and (x)wpe....thanks!
Can I quote you on your comment re: MS IDEs? :-)
-Slugbug
|
Post #114,390
8/19/03 5:43:52 PM
|
of course!
You can send Billy a perfumed telegram if you like!
-drl
|
Post #114,423
8/19/03 9:41:58 PM
|
rofl
|
Post #114,264
8/19/03 12:56:56 AM
|
Re: Care to be quotable on code editors?
I've used Visual SlickEdit, emacs, vi, and nedit. In addition, I've used the Borland, Visual Studio, and Visual Age IDEs.
1. Code editors are "lighter" than IDEs. Don't require tons of memory and resources. Code editors are better on multi-user environments, and environments where resources (memory) are limited.
2. Source code highlighting and syntax checking speed up development and prevent recompiles, saving machine cycles.
3. Nedit is nice for people who have to do double duty in Windows and Unix. The cut/paste commands mirror Windows, so you're not cursing at the editor (like you sometimes do with vi or emacs), when you're Windows cut/paste combinations don't work.
4. Vi is on just about every Unix platform. It's always there.
5. Emacs is so much more powerful than vi, but you have to invest time in installing it on most machines. The lisp scripts are very powerful, but it takes time to learn.
6. I used Visual SlickEdit in my OS/2 days about 10 years ago. We had the OS/2 and Windows versions. It replaced a DOS code editor we had. It was excellent, when you didn't have the resources to run CSet++.
One thing you haven't mentioned here that MUST be in your article is the need for compare utilities. Unix has diff, but diff is really just a start, especially when you're doing code merges in a significant code base and you don't want to auto-merge. We use a tool called Beyond Compare at our office that is simply amazing. It will diff a whole directory (or tree) of files, then allow you to quickly go down through two source code trees simultaneously, merging code.
As for IDEs, I think they're too slow on most Unix environments, and I would recommend them only on a 1.7ghz Windows system or faster, especially the larger ones.
Visual Age is the worst. It crashes frequently, and seems to be a nightmare to even keep it running. Visual Age may very well be the largest reason that people don't use IBM's middleware. You need about 512meg just to start with Visual Age in a graphical environment.
Visual Studio is tried and true at this point. I'm not excited about it, but I'm familiar with it, and it's flexible enough to do what I need to do in C++ or Internet Development with Visual Interdev.
Borland is the standard. Their tools are awesome. They rock. We used JBuilder on my last Java project and it really rocked. The OptimizeIt suite of tools paid for the $3000/seat cost by helping us find bottlenecks in our code. JBuilder is flexible enough to allow you to customize JVM's, work with different App Server tools. It does require at least 256meg of memory, and 512 is recommended, but it's way more stable than Visual Age.
There's my two cents, Maggie.
Glen Austin
|
Post #114,291
8/19/03 7:40:48 AM
8/19/03 11:04:59 AM
|
I diverged. Here's the list.
These aren't ranked highest to lowest, but just a list. We'll start with 10, but I may come up with more as I work today.
1. Good indenting tools to reformat code.
2. Good cut/paste capabilities. The best can even cut/paste between Windows and X-Windows.
3. Global search/replace, preferably with grep-like capabilities.
4. Ability to do compares/diffs between files (or even directories).
5. Quick navigation, goto a line. Search next. Emacs even produces a member list on OO programs, and allows you to jump to a member.
6. Online code highlight/syntax check to prevent typo errors.
7. Auto tab conversion to spaces for shops that don't have a standard editor (like ours). Or code reformatter to fix the indents.
8. Ability to save/load code fragments to/from separate files.
9. Ability to edit multiple files at one time.
10. Easy navigation of the files in a project.
11. Undo capability (Ctl-Z in nedit and most Windows editors)
12. Find in file or grep capabilities. (Find this string in all the files in this tree.)
13. Integration with version control system (getting close to an IDE there)
14. Scriptability (or at least a significant level of customizability)
15. Ability to repeat commands.
Actually, I stole the last three from Scott M. and Arkadily, but they're things that I use all the time. My JBuilder had VSS and CVS integration. Nedit and emacs are very customizable. And vi's dot command allows you to repeat commands.
Glen Austin
Edited by gdaustin
Aug. 19, 2003, 11:01:53 AM EDT
Edited by gdaustin
Aug. 19, 2003, 11:03:26 AM EDT
Edited by gdaustin
Aug. 19, 2003, 11:04:59 AM EDT
|
Post #114,358
8/19/03 4:07:02 PM
|
This is great...thank you!
|
Post #114,357
8/19/03 4:05:40 PM
|
great input...compare utilities?
...this is very useful commentary. I appreciate the help.
I will add some info on compare utilities. Still trying to
get my arms around the piece so all input is helpful.
WRT compare utilities...any others aside from Beyond Compare
that are equally as useful? For example, I use a few different
compare plugins when using jEdit and they seem to work well for
my purposes. Other compare tools that rock or don't?
BTW, I do need title/company to do the quote. I can do some as
"Computer Consultant", but not every quote can be consultant-based.
You can e-mail title/company if you like. Thank you!
-Slugbug
|
Post #114,365
8/19/03 4:25:42 PM
|
Compare Utilities
I just ran across Beyond Compare recently, at my new job.
I really like it because you can do compares across two
directory trees, comparing files with the same name.
Both files are displayed side by side, with options to
copy sections of code from one file to another, as
differences are encountered.
Traditionally, I've used diff and grep heavily in the Unix
environment, and IDE tools like those in JBuilder in the Windows
Environment.
Glen Austin
CTO of DoThePlan.com (personal company)
Senior Programmer for iSoft, Corporation (full-time)
I'd rather you quote the personal one, 'cause I get free publicity
and I'll get a web page up before the article is published.
DoThePlan.com is a project of mine to provide project planning
tools over the web. I also have MedSched.net which is another
project to provide Medical Scheduling tools.
But, if you must, then my "day job" is at iSoft.
|
Post #114,369
8/19/03 4:40:01 PM
|
On Second Thought
Just use the iSoft one for now. I need to get my prototype up and
going before I get web page hits on the server.
Glen
|
Post #114,378
8/19/03 4:58:04 PM
|
Ok either way....
|
Post #114,379
8/19/03 5:00:18 PM
|
How far out is the article?
If the article isn't going to be published until October or
November, I could have something out there by then.
Use the DoThePlan.com
If it's a September article, use the iSoft id.
Thanks!
Glen Austin
|
Post #114,426
8/19/03 9:57:03 PM
|
It running....
...in September. iSoft it is...thank you.
|
Post #114,406
8/19/03 6:12:12 PM
|
opendiff on OS X is the best I've ever used
And for version control I recommend CVL - a decent CVS UI - open source from SENTE.
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,278
8/19/03 3:37:25 AM
|
OK
I've been tasked with writing a feature about code editors.
This is not a "vi" versus "emacs" piece. The idea behind the
piece is to describe when to use code editors versus when to
use IDEs. I typically use whatever editor fits in best with the rest of the build tools I'm forced to use. I use ProjectBuilder a lot. At the moment I'm using IntelliJ IDEA because PB's java debugger is broken for non-trivial projects. I'm just as likely to use vi - most important feature is ease of initial invocation followed by ease of fixing indenting, ease of jumping to a line number, ease of finding/replacing text in multiple files. Otherwise I could care less about the rest of it.
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,360
8/19/03 4:13:51 PM
|
best tool for the job....
...given the environment at hand. Usually a good approach.
IntelliJ's debugger is better than PB's? What is the issue
with PB's debugger? Have not used it...
Does anyone have any other favorite debugging tools they use?
Thank you,
-Slugbug
|
Post #114,364
8/19/03 4:21:11 PM
|
Debuggers...
Honestly, I don't use them. Well, I do for C++, but it's frigging necessary there.
Unit tests and printlns do for me.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,399
8/19/03 6:00:54 PM
|
I really need one
for this project.
I'm doing a very complicated decision tree/mass balance kind of thing (it figures out how to butcher cattle to produce different products based upon demand for various cuts). WIthout the ability to stop the program and inspect the stack during the tree traversal, I'd never figure out what's going on.
A single unit test involves very extensive calculations. I do a huge amount of logging and I still need to halt the system regularly to check its state to make sure that stuff is going on.
And of course, in Smalltalk, I do most of my coding in the debugger while the program runs.
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,404
8/19/03 6:08:32 PM
|
PB stops working on projects above a certain size
And they're not in a hurry to fix it because its deprecated for the XCode thing coming out.
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,405
8/19/03 6:11:52 PM
|
Often overlooked
Some editors seem fine until you try to do something BIG with them. One reason I love UltraEdit - you can't make it gag no matter what you throw at it.
-drl
|
Post #114,279
8/19/03 3:58:58 AM
|
2c deposited...
I use vi. Well, actually, I use vim, which is commonly installed as vi on Linux and BSD. I also (GNU) screen as a far more versatile way to have multiple code windows open than vim's buffers and windows, however I do sometimes utilise the latter.
> 1). What are your top five must-haves in an editor?
I don't know that I can come up with 5 "must-haves", but the biggest reason I use vi is because it doesn't fence you into a beginners mode. I guess the second thing is that I don't have to use the mouse, followed by multiple-file support. And for error-checking, I have to be able to goto a specific line by number.
> 2). Why is your editor of choice better than other editors?
Mostly because I know it! :-) Plus there is a tendancy for IDEs to heavily use the F-keys, the cursor cluster and key-combinations.
> 3). Why is your editor better than an IDE?
> 4). Can you estimate how much more productive you are with an editor versus an IDE?
I've yet to use an IDE that I can enter or edit code quite as fast as I can in vi. Especially coupled with screen.
> 5). Do you use plug-ins with your editor? If so, which ones and why?
Syntax highlighting is exremely useful. The biggest advantage is that it can tell you the names of built-in functions...
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,363
8/19/03 4:21:01 PM
|
deposit accepted :-)
This is good input....
Question on this:
"I use vi is because it doesn't fence you into a beginners mode"
Ok, the comment above is fair enough. But, what if one were a
beginner? Is vi(m) appropriate or overwhelming? Which editor
would be good for a noob?
Also, do you want to be quoted in print? If so, got title/company?
Thank you,
-Slugbug
|
Post #114,520
8/20/03 8:03:53 AM
|
Gotta think about that...
Question on this:
"I use vi is because it doesn't fence you into a beginners mode"
Ok, the comment above is fair enough. But, what if one were a
beginner? Is vi(m) appropriate or overwhelming? Which editor
would be good for a noob?
(Trying to be quotable...) It is an unfortunate truth that vi requires some persistence to learn. Pair programming makes this easier, incidentally, as does the desire to "do tricks" with it that you may see a vi-expert do. Fortunately, Vim specifically makes learning it easier in two ways: it knows about cursor keys, which makes the learning curve a bit easier, plus it has a tutorial called vimtutor which teaches you the basics. ] I personally found that vi was easiest to learn when it was the most capable editor available. It was on a university box where the alternative was ed (line editing was done with regexps!). Also, do you want to be quoted in print? If so, got title/company?
I will have to check. We're only a small company, so titles are somewhat indistinct. 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,661
8/20/03 10:57:27 PM
|
Quoting okay.
I would be Senior Developer at Excido Pty Ltd.
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 #115,047
8/23/03 10:20:43 AM
|
Thanks very much!
|
Post #114,293
8/19/03 8:13:51 AM
|
I'll come back to this, but...
emacs is not just an editor. It's an IDE, for all intents and purposes.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,366
8/19/03 4:30:52 PM
|
so, maybe there is a more fundamental question....
....how to define what is an IDE versus a code editor?
For the purposes of this lovely piece, I'm defining code editing tools as having an editor and *separate* pluggable modules that enable you to do other functions, such as debug, compare, etc. You pick and choose the modules you need.
By contrast, I'm defining an IDE to mean that the tool includes both an editing function and all the other tools *within* the environment. In other words, your editor, debugger, compare tools come included together out-of-the-box, as it were.
Sucky definitions? Got any better ideas? I'm all ears...
-Slugbug
|
Post #114,368
8/19/03 4:39:22 PM
|
That's a physical description...
As in how versus what.
I'll use two examples: emacs and JBuilder.
JBuilder has a built-in debugger. You can't get rid of it, and it only does Java.
Emacs uses whatever debugger you have on the system by wrapping it in a buffer and tying it to file type.
Both, for all intents and purposes, have an "integrated debugger". The only difference is whether you can swap it out or not.
"Integrated Development Environment" to me says that the program allows you to run various tools within the environment, whether they come as plugins or integral to the environment. Many code editors are approaching this from the bottom with plug-in architectures, and there are very few editors that *just* edit. The key in "IDE" is that the environment is aware of the tool and can use it in more than just ancillary fashion. Most IDEs and editors let you shell out to external tools.
I guess emacs is more of a unique beast. It's flexible, programmable, and agnostic, unlike most IDEs. However, it is aware of a wide variety of file types and external utilities, unlike most editors. It's an editor that has been extended into becoming an environment.
This is why I wub it so. ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,302
8/19/03 10:10:17 AM
|
I use Emacs,
so my top 5 are almost a list of IDE requirements:
- Syntax highlighting and autoindent, braces checking
- Compilation and jump to compilation errors
- Version control support, file comparison
- Scriptability (including ad-hoc scripts)
- Powerful search/replace, including multifile
- Powerful cut and paste
The fact that Emacs allows me to add the first 3 for any language by a bit of coding definitely helps. The fact that Ionly had to do it for one language helps even more :) .
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #114,367
8/19/03 4:37:54 PM
|
but, but, but....
....good input, thank you.
If you were going to teach my 9 y.o. niece some simple
programming would you get her into emacs or something
else? There is a perception out there that newbies
really need the "comfort" of an IDE. However, in my
travels I have found it much easier to teach 9-90 y.o.
using things like TextPad. Agree? Disagree?
-Slugbug
|
Post #114,372
8/19/03 4:43:14 PM
|
Data point:
Skewed, but here it is:
My son Duncan uses emacs to program his web pages. He uses an IDE to do BASIC and Smalltalk.
He likes emacs because it can edit anything. He likes the BASIC IDE because everything is laid out for a kid (multimedia, point and drag stuff, etc.). I just had him run through the emacs tutorial and he picked it up fairly quickly.
IDEs will handle the nitty gritty of file creation, directory arrangement, etc. better than an editor. The editors will have a much simpler set of things to learn. Emacs, of course, has it all. ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #114,376
8/19/03 4:52:54 PM
|
I will let you know in 4 years :)
For _programming_ for a 9 years old, I'd probably use an IDE.
Easier to teach to press a button than to type "gcc test.c; test" in a window. Plus, built-in debugger would allow to step through the code and see it in action. I still remember the thrill of first real debugger session in Turbo Pascal 5.5.
Or, I might just add a button to emacs. And it supports debugging too. But then emacs turns into an IDE, and the whole question becomes moot.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #114,306
8/19/03 10:37:37 AM
8/19/03 6:11:37 PM
|
Well in a Windows World...
I use GWDSoft's GTEdit.
[link|http://www.gwdsoft.com/|GWD Soft]
I rather like the layout and repeatability of it. Ben Tilly clued me in on this one.
It is fast, flexible, does syntactical(and you can make more than available), runs, decodes, debugs, has projects, interfaces with Version Control...
Nice.
Also List of Features: [link|http://www.gwdsoft.com/about/index.html|HERE]
Very nice.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Where it not for the dizzy whiptail ambivalence of your crumbling fleece, I could never contemplate the ways of so many merchant bankers in heat.
Edited by folkert
Aug. 19, 2003, 05:57:53 PM EDT
Edited by folkert
Aug. 19, 2003, 06:11:37 PM EDT
|
Post #114,371
8/19/03 4:40:39 PM
|
Forgot that one...
....have tried it too based on Ben's recommend. Will add it...
Assume you meant "fast"... care to be quoted in the piece?
Thanks for the help,
-Slugbug
|
Post #114,397
8/19/03 5:54:35 PM
|
Yes I meant Fast....
And sure iffn anyone will believe it... coming from me.
I'd be glad to be quoted.
I have bought it twice...
But my different employers have bought ~10 times for me.
:)
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
Marmots will stick to you in Delaware.
|
Post #114,315
8/19/03 11:02:57 AM
|
My necessities
I use Textpad and emacs.
- What are your top five must-haves in an editor?
1). Regular Expression Search and Replace. Not that crappy junk they throw into a lot of IDE's like Visual Studio. A true regexp facility. Especially helpful if it throws in a grep like utility to do search directories. For that matter, I want to be able to manipulate several hundred files in one edit session, and have the ability to do global search and replaces - and it's got to be fast.
2). Column based select, cut, paste, tab, etc... Editing code is a 2 dimensional task. Not only must you be able to insert, delete, and move on a line by line basis, but it helps tremendously when you can manipulate it on character columns.
3). Small fonts and long lines. I'd like to be able to see across some 200 characters in width, will settle for 140. I want to be able to see a lot of code (lines, properties, methods, classes) at the same time. The more I can see at any one time, the more I can manipulate. Maximum information density!
4). Syntax highlighting. It's just something that grows on you and becomes a necessity.
5). Macro facility. Lot's of repetitive stuff when you start editing text files. A good macro facility is something that gets used very often. For that matter, programmability is something that comes in extremely handy. Emacs shines in the area of programmability, whereas Textpad is limited to keystroke macros.
- Why is your editor of choice better than other editors?
Emacs because it can be tasked with anything - the swiss army knife of editors. Textpad because it is very easy to use but quite featureful
- Why is your editor better than an IDE?
The editors in most IDE's suck, not nearly packed with enough features, but not easy to manipulate text either. Most have good syntax highlighting and the fonts can be manipulated. But the regexp engines are ugly, the column based editing is clumsy, and the macro facilities are pitiful.
- Can you estimate how much more productive you are with an editor versus an IDE?
I could, but it would probably be a meaningless metric. I know I can write more code at a higher quality. The code is easier to manipulate, extend and understand with a proper set of tools. Beyond that, I don't have much tolerance for mediocre environments, so I've never benchmarked the comparison.
- Do you use plug-ins with your editor? If so, which ones and why?
Never used commercial plugins. I've written some in the past for VB and VC++ environments, but they were quite narrow in purpose.
- What would be a good editor for newbies? why?
Editors are a personal choice and preferences many times revolve around familiarity - this editor is easier because I'm familiar with the keystrokes required to do any particular task. Keystrokes are something that get burned into your brain over time. Also, you have to factor in the amount of time you are going to be spending with the editor on a day-by-day basis. Emacs, for example, has a steeper learning curve, but if you use it heavily, you find that your productivity can be orders of magnitudes higher than with the easier alternatives.
That said, I like Textpad as a choice for the best balanace between simplicity and features. Or to put it understandable terms, as easy to use as Notepad but not braindead like the MS offering.
Chris Rathman,
Consultant, etc...
|
Post #114,373
8/19/03 4:46:48 PM
|
good info...
...I especially like this comment:
"The editors in most IDE's suck, not nearly packed with enough features, but not easy to manipulate text either. Most have good syntax highlighting and the fonts can be manipulated. But the regexp engines are ugly, the column based editing is clumsy, and the macro facilities are pitiful."
Thank you,
-Slugbug
|
Post #114,374
8/19/03 4:49:54 PM
|
The problem I have with most IDE editors is the keymapping
They all claim to have "emacs style editing", but none of them do it quite right. This comes of not having the basic editing constructs (point and mark, kill ring, etc.) that emacs has. Or they just get the emulation wrong. There's nothing worse than jumping into an editor expecting that the editing keys work exactly like what you're used to, then getting tripped up because, for example, the kill key doesn't just kill to end of line on the first use (this is an actual example from JBuilder in emacs mode, IIRC).
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
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.
|
Post #114,388
8/19/03 5:38:01 PM
|
emacs and visual slickedit
Emacs in *nix world and Visual SlickEdit in Windows world.
Things I want:
Multiple documents and buffers that are easy to switch between are a must. Split screen is nice in a graphic environment. Multiple cut and paste buffers are nice as well.
Built in Diff is something I don't think I can do without anymore.
Access to compiler and debugger such as exist. SlickEdit is nice for this; it integrates with Visual Studio nicely, but doesn't insist on it if I just want to use the DDK. I can get to Visual Studio help and MS C symbols reference too. Getting to version control is also good.
Macros! On the fly or build your own. That's something else I don't know how I got along without.
Editing in hex mode is an awful nice feature.
I have use a lot of editors, but those have been mostly what I have used for the last 8 or 9 years.
Hugh
|
Post #114,391
8/19/03 5:45:39 PM
|
Split-screen is nice in a text environment too...
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #115,372
8/25/03 11:09:31 PM
|
Aww, c'mon. This is always how the wars start!
I stopped using IDEs eons ago. I went from TurboC on
MS-DOS to cc on SCO Xenix. It was a shock. I moved
from C to Perl about 10 years ago, which limited my
options as far as IDE.
I don't even like debuggers now. If you don't understand
enough about what your code should be / is doing based on built
in instrumentation (which you should have put in while
coding) and a few well placed print statements, you really
should not be coding. The only time I break this rule
is when I need to modify someone elses code and I'm not
sure what it is doing. Then I really like DDD for the
debugger.
Gvim
Must haves.
Autoword completion by using ^P and ^N.
This has made a huge difference on my variable and function
naming, since I can use really large descriptive names and only
type them once.
Syntax highlighting. Miss a closing quote and the
rest of the screen goes red.
Paren / brace / bracket bouncing with the % key. I'd kill
for it now if I was forced to lose it.
Columnar cut and paste.
Multiple named buffers.
Ability to edit remote files using scp for read and write.
'.' - dot. do the last command again and again.
Incremental highlighting while you build a search expression.
Ability to jump back and forth between a bunch of files
very quickly. Control^ for the last, number Control^ to grab
a particular one. Split screen isn't a real big draw for
me since I like to see a LARGE amount of text and if I need
more than one file open at a time I'd open another window.
Ability to execute a command and collect the output of
that command for editing, ie
:r !command
External filtering of highlighted text, ie:
Example: Sort / Unique 10 lines by highlighting them
and then typing "!sort -u". Can use this to create
off the cuff Perl filters.
Identical editor in Linux, Unix, and Windows. Always
available, free.
I spent some time in Brief. It was very nice.
I then used Slickedit on Sco Xenix. I went from vi to it,
I loved it. I reimplemented vi style named buffers in it's
macro language and it was almost perfect. I probably
bought 20 copies of Slickedit as I moved from computer to
computer.
But gvim brought me back home!
|
Post #115,376
8/25/03 11:14:30 PM
|
Yeah, forgot about paren automatch.
I don't even think about it any more. But I know when it's missing.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #115,418
8/26/03 11:06:17 AM
|
Are there still people who work without syntax coloring?
How? I just can't do it any more.
That and paren matching. If I can get those two I'll use about anything. I use vim because I know it. If I had to learn emacs I'm sure I would. But those two are about it for me.
Well, that and incremental regex matching.
And line mode. ie: In most Windows-based editors if a line wraps and you hit the down arrow you go to the second half af the wrapped line. I want line breaks where I put them, not where the current screen width puts them.
I'm sure there's more I'd miss, but it's so natural now I don't think about it.
===
Implicitly condoning stupidity since 2001.
|
