What's your favorite IDE/text editor when it comes to programming? Also, what's the setup in the banner up top? http://static.4-ch.net/images/boardtitles/programming.gif, that is.
vi
Emacs
leo
another vote for vim.
vim
Evergreen or Cream
The thing up top may be TextMate. I haven't used it.
ed
vim
VI baby. Download it for windows or unix.
vim
Visual Studio, please.
kate
I use eclipse on windows, and vi on bsd. I find that I can get more work done in eclipse, so that's what I prefer.
nvi. vim is worse than emacs.
vim boots slower than emacs and does less. I don't see the point of it at all.
emacs for lisp, irc, and email. vi for editing text files.
Scintilla / Scite. I like my lightweight editor with good syntax editing. I shouldn't have to "wait" any time for a IDE to load.
Nano if im just making a small change in the shell =)
But then again, real programmers tap out their code to their hard drive manually with a ball point pen!
Elvis!
If you break into the command line on an OLPC, there's a copy of vim inside, aliased as vi because someone thought they were being clever. I've been learning to use it and like what I see.
Notepad, Dreamweaver
>>21
the difference that bothers me the most is that vim is slow enough that i actually notice it.
Banner definitely looks like Textmate, which I use and recommend.
Can't see any good reason to use clunky editors that barely changed since the 70's and are a pain to integrate with all my desktop tools.
emacs for coding
ultraedit / notepad++ for quick and dirty text editing
vi on remote server (coz it's a pain to use emacs without my .emacs)
emacs, vim, textmate
and textpad of course
copy con
coda
I seriously don't understand why people continue to say stupid shit like vi, elvis, and nvi.
vi was made in the 70's for unix. it hardly does anything. if you aren't running a propriety version of unix, or perhaps solaris now that it's free, then you're not using vi. Linux simply links the vi name to vim, and *bsd links vi to nvi. So everytime you type 'vi' you're running vim or nvi. nvi hasn't been maintained in years and i doubt freebsd even uses it, they probably just use vim now. elvis isn't maintained anymore either, and hasn't been forever. talking about those ancient editors if fucking ridiculous unless you working from some remote terminal, but is the OP really asking about that?
and idiots saying vim is slower than emacs, or noticing that it is slow at all is complete bullshit. this might be true if you're running gvim on some ancient computer, but nobodys mentioned gvim, we're talking about vim.
vim
> vi was made in the 70's for unix. it hardly does anything. if you aren't running a propriety version of unix, or perhaps solaris now that it's free, then you're not using vi.
it does a lot more than emacs.
$ emacs
emacs: Command not found.solaris uses it's own vi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=SunOS+5.10&format=html
HP-UX does too:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=HP-UX+11.22&format=html
OS X uses vim:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/vi.1.html
apparently they somehow managed to get OS X certified UNIX 03, despite vim not being fully POSIX compliant:
http://www.opengroup.org/onlinepubs/009695399/utilities/vi.html
http://www.polarhome.com/vim/manual/v71/vi_diff.html
Vim is mostly POSIX 1003.2-1 compliant. The only command known to be missing
is ":open". There are probably a lot of small differences (either because Vim
is missing something or because Posix is beside the mark).> nvi hasn't been maintained in years and i doubt freebsd even uses it, they probably just use vim now.
the latest version is from less than 7 months ago:
http://www.kotnet.org/~skimo/nvi/devel/
[ ] nvi-1.81.6.tar.bz2 18-Nov-2007 18:02 1.7M
[ ] nvi-1.81.6.tar.gz 18-Nov-2007 17:57 2.2Mfreebsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html
netbsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=NetBSD+4.0&format=html
openbsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=OpenBSD+4.3&format=html
> and idiots saying vim is slower than emacs, or noticing that it is slow at all is complete bullshit.
$ /usr/bin/time -h nvi -c :q TWL06.txt > /dev/null
0.49s real 0.40s user 0.06s sys
$ /usr/bin/time -h elvis -c :q TWL06.txt > /dev/null
Read TWL06.txt, 178690 lines, 1763166 chars
0.26s real 0.08s user 0.15s sys
$ /usr/bin/time -h vim -c :q TWL06.txt > /dev/null
Vim: Warning: Output is not to a terminal
2.33s real 0.22s user 0.04s sysWell, to be different, I guess I'll be honest and say I use gEdit for typical stuff, bluefish for perl/php/xhtml, and eric3 for python. The only time I use vim is when I set up the sudoers file, and I suppose I use nano to some extent when I'm running as root from the shell and can't be bothered to start something graphical.
nano is dangerous because it breaks lines in an effort to be helpful. Make sure you have set nowrap in your ~/.nanorc file or use nano -w to avoid breaking important files.
This is especially important when running as root.
I've been using Eclipse on my desktop, and it works wonders for a language like Java (and is still pretty useful for Python), but it lags like hell on my low-end laptop; until now I've been using Komodo editor for my Python code because of its syntax checks and popups for functions, but it's really lacking in any ability to run and test code and previously stated features seem to only work selectively.
Is it possible to get these features into emacs or a vi derivation? From what I've used of emacs, it only really has auto-indentation (which is mostly useless in python) and coloration of code. Moreover, do any of them have useful debugger features like in Eclipse?
>>41
yes they do. both of them. (vim & emacs)
I use E Text Editor. It's supposedly modeled after Textmate which I've never used since I am on Windows, but it's pretty easy to use and I don't really need anything more or less.
nvi
Sometimes I wish there were an X server+window manager that rendered into emacs frames...
>>45
You mean like basically all tiling WMs?
>>9
+1 for ed. I really hate having to move a cursor around.
Real programmers don't use arrow keys, including "hjkl".
ConTEXT
>>43
At least you won't realize how badly they butchered it. Can't stand E as a Textmate user.
vim
vim
my .vimrc
syntax enable
set autoindent
filetype plugin indent on
set nowrap
nnoremap <silent> <F8> :tabnext<CR>
nnoremap <silent> <F7> :tabprevious<CR>
>>51
learn to use buffers instead of tabs you idiot.
Move out of the eighties.
inType
I use the Hessling Editor, and also sometimes XED.
Nib pen and paper.
vim
VIM
colorForth
vigor
vi
>>49
What about InType? It's only in early alpha stage tought...
So I went there, and got to:
Intype is a powerful and intuitive code editor for Windowsand stopped treating it seriously.
Is this some kind of personal problem or what?
vim or vi
wats VIM??
Wow, it's nice to see all the VIM users out there.
VIM
always used VIM as long as I have been testing, using and trying out non-win systems. I have used linux and BSD for a couple of years now, and vi(m) has almost always been preinstalled or available as a package.
I also used emacs for a while, but found the vi-way to be easier to me =)
But I'm still wondering if I wouldn't be better served with a good and mature IDE for developing though =/
I usually use THE or Xed, but I'm learning TECO.
I use VIM to develop my Verilog modules, then synthesize and simulate them in Xilinx ISE. My favorite feature of VIM is that it colors differently the important parts of any language you type in there, be it C or verilog or HTML or ASP or anything else I've used for it.
>>64
Actually, yes, and don't mind it. He has issues.
Of course the users here are too cool (read: unknowledgeable) to admit that Visual Studio is the best IDE.
I became a little envious watching a co-worker of mine show of Visual Studio's SQL tool or whatever you want to call it. Beats my Emacs sql-mode.
All that functionality is availble as a stand-alone app whoes name I can't think of at the moment. It is better than doing SQL in emacs and it is better than MySQL's query browser, But I wouldn't say that would be a the showcase item for me. Although I do love the fact it does integrate some great features like this in to the IDE.
The whole process is incredebly refined. Triple comment code meta data is fucking fantastic. (you enter 3 comment delimiters in a row immediatly preceding a procedure signature and it automatically creates the XML to enter in detailed comment metadata.)
It always stays ahead of the curve on code completion with intellesense.
VB.Net's constant precompliation makes finding many errors in code trivial as they are displaye dbefore compile. (Strangley C# doesn't do this though).
The built in web server makes quick tests trivial as well.
Then there is all the team, testing and other shit built in.
The whole process is incredebly refined. Triple comment code meta data is fucking fantastic. (you enter 3 comment delimiters in a row immediatly preceding a procedure signature and it automatically creates the XML to enter in detailed comment metadata.)
Board title image is TextWrangler, with the "title" commend inbetween some random opensource code.
CODE::BLOCKS
I have read some stupid shit on here but that is the absolute stupides in quite a while.
XML is perfect for creating a markeup to markup comments in every way. To think otherwise means you really don't understand anything about this topic.
>>80
XML is barely human readable. The only purpose this sort of thing serves is to make code even harder to maintain because now the comments are illegible too.
Structured comments solve a non-problem; Extracting useful documentation directly from the source code is useless if there isn't any useful documentation directly in the source code.
There are a large number of nearly empty javadoc and doxygens published on the Internet. Worthless documentation isn't better than no-documentation. At least with the latter it's harder to delude yourself into thinking you've got something. That means autodocumentation tools are simply making things worse.
Good documentation, means prose, not property lists on program definitions. XML simply doesn't enter into it.
Oh wow. More stupididty.
You arguement is meaningless. XML markup of comments has nothing to do with the quality of those comments.
Bad comments are bad. Good comments are good. Good comments with meaningful markup are better.
Comments don't suddenly become bad when you add extra meaningful information to them that identifies exactly what the comment is for.
If you can't see why the ability to have a standard meaningful way to document a function paramter is a good thing, you need to stop "programming." If your comments aren't good enough to provide even basic useful documnetation, then you suck at commenting.
In summary, just because you are bad at something or don't fully understand it, does not make that thing worthless.
Hay guyz,
if you can't present an argument without juvenile ad hominem jabs (<-), please go the back to 4chan.
That is all.
Structured comments make it easier to automatically extract information from comments; it does not make it easier to add information.
Comments are so limited, you cannot put meaningful documentation inside them, and by enforcing a rigid structure you are encouraging poor documentation, and making it impossible to write good documentation.
Generally speaking, I find that if a function parameter isn't apparent from the code or its name (prototype, minidoc, etc), then the API is probably stupid and was written by an idiot. I have never seen those situations saved by documentation.
>>83
It's very possible to add that ``meaningful'' information without adding the clutter XML does. This isn't mainly about structured comments (though >>85 is right about those), it's specifically about using XML to do it.
As far as attempts at literate programming go, XML is a failure because it makes the source code messier and harder to read.
Visual Studio makes the XML trivial as it adds it for you, you only need to provide the content.
Comments are only limited by a persons ability to accurately describe the code. Its apparent that you have not used a mature API extensively. Take something like the .Net APIs. The Visual Studio object explorer displays the XML comments for the APIs (and any other well commented code you are using). This tool is invaluable as is intelligence which also gets its info from the XML comments.
Parameter names should be self evident, but they can't always be. If a function takes a path to a file name, and it has to be a fully qualified path do you name it "strPathName"? That doesn't tell you shit about it. Its obviously for a path, but is it a relative path or a fully qualified one or doesn't it matter? What if there are overloads that take other paths, do you have to get super descriptive? Do you name it "strFullyQualifiedPathNameToTheFileYouWantToWorkWith"? Or maybe I should just memorize the API's full documentation, that sure is reasonable.
Or would it work better if you name it "PathName" and a little tool-tip came up when you got to the point to enter the parameter in the IDE and it read "String: Fully qualified path to the file to work with." Think about that for a while.
/// <summary>
/// Summary of LoadXMLFromFile.
/// </summary>
/// <param name="FilePath">Description of FilePath parameter.</param>
public void LoadXMLFromFile(string FilePath)
That is a basic C# XML comment (that is autogenerated with me adding the text between the tags). If you find that hard to read or pushing the comment delimited 3 times to auto-gen the XML to hard to do, you might want to choose a different hobby.
Any good developer today should be able to view XML and understand it. But since you don't, I suppose you have a better idea for a markup language to use to give context and meaning to programming comments. You can't be a true badass programmer until you have dismissed, without a reason, the ideas that teams of computer scientists and computer engineers have put way more thought in to that you have.
> Visual Studio makes the XML trivial as it adds it for you, you only need to provide the content.
I didn't disagree with that. I said the hard part is adding the content- something that automatic documentation has made harder by removing incentive, not easier.
> Parameter names should be self evident, but they can't always be.
Prove it, cock for brains.
> If a function takes a path to a file name, and it has to be a fully qualified path do you name it "strPathName"?
Straw man. Don't make an API that requires a fully qualified path, duh.
I'm still waiting... Maybe you can try an argument that doesn't depend on such a weak strawman next time.
> Any good developer today should be able to view XML and understand it.
Why set the bar so low?
Good developers can eat XML and shit strawberries!
Wow, I am seriously seeing a pattern develop here. You really have a hard time understanding these simple concepts.
>something that automatic documentation has made harder by removing incentive, not easier
Yes, automating a task will remove incentive to do that task. Brilliant! And this whole time automation is used as incentive to do some task, but you have turned that whole idea on its head with your brilliance.
>Prove it, cock for brains.
Did, you didn't understand.
You claim straw man argument, but fail to even prove you used the correct word there. I chose a simple example that you see in many APIs on many platforms. So what I said was not a fallacy (hence no straw man claims to be made).
>Don't make an API that requires a fully qualified path, duh.
Depending on the scope of an API that is not always reasonable. And given that there is no standard, one can't know what they should expect by default.
How is one supposed to know if the argument is a fully qualified path, or a relative path to some other directory? If it is relative, from what directory are we starting? This is all answered in documentation, not paramnames. And if that documentation has some way of identifying that a certain piece of it refers to the pa ram in question, it can be more effectively utilized by tools (most notably IDE in this case) and be of greater use to the developer. Since creating the markup to make the documentation more useful is automated, it is no extra work for the developer to utilize.
I can't be more clear and I totally expect you to not understand that at all.
It is obvious you don't program enough of create sophisticated enough programs.
> Yes, automating a task will remove incentive to do that task.
So you agree that autodocumentation decreases the quality of good literate documentation, you simply disagree when I say bad autodocumentation is worse than no documentation?
> Depending on the scope of an API that is not always reasonable.
Wrong. Making a good and solid API is always reasonable, and sacrificing code quality and robustness causes other problems that your precious autodocumentation cannot fix.
> How is one supposed to know if the argument is a fully qualified path, or a relative path to some other directory?
That's insane. How does POSIX.1 open() know? How does Common-Lisp's make-pathname know? How does Boost.Filesystem know?
Pick a different example besides relative paths. This is a solved problem; a strawman at best, and a demonstration that your whole argument is without merit at worst.
> I can't be more clear and I totally expect you to not understand that at all.
Of course you do! You think "How could anyone hate those little yellow tooltips that say 'absolute path required'" and you know that those little yellow tooltips are what make you productive enough to handle tasks you could never handle before.
Grow up and re-read what I've been saying here. I am saying I would trade those little yellow tooltips for good documentation or a good api.
> It is obvious you don't program enough of create sophisticated enough programs.
Seriously. People wrote "sophisticated programs" before xml, syntax hilighting and Visual Studio. How naive are you to think that others don't need the crutches that you do?
Banner is definitely TextMate, Monaco non-anti-aliased 10px. Mac classic theme.
I love Sudden View, unfortunately it's rather archaic and Windows-only.
XML comment:
/// <summary>
/// Summary of LoadXMLFromFile.
/// </summary>
/// <param name="FilePath">Description of FilePath parameter.</param>
public void LoadXMLFromFile(string FilePath)
Non-XML comment
/* Summary of LoadXMLFromFile
*
* @param Filepath Description of FilePath parameter.
**/
public void LoadXMLFromFile(string FilePath)
Or, Python-style:
def LoadXMLFromFile(FilePath):
"""Summary of LoadXMLFromFile
.. describe:: FilePath
Description of FilePath parameter.
"""Notice the difference? With comments, you don't need a bunch of XML cruft obscuring the text.
>>95
And when it's that obvious from the function and variable names what's what, adding the comment at all actually reduces readability of the source.
Even a simple function like that needs documentation. Is FilePath absolute or relative? Should it be in Unicode, or the local filename encoding? What exceptions will be raised if the data cannot be loaded? Why is the return type "void" instead of the data, is it modifying private variables? If so, which ones?
When somebody says that a function's purpose is obvious, what they actually mean is "I'm too lazy/ignorant to figure out what that function does".
> Even a simple function like that needs documentation.
If it's a library function, and the source isn't available, I agree completely. However, that isn't a case for xml automatic documentation.
> Is FilePath absolute or relative?
If it matters, the function is wrong.
> Should it be in Unicode, or the local filename encoding?
If it matters, the function is wrong. This is more a symptom that the Windows API is designed by brain-damaged 3 year olds.
On windows: If it is a pathname, it should allow \\?\ and your programs should always begin all paths that they produce (but that the user does not produce) with \\?\
On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
There's a reason fchdir(open(".",O_RDONLY)) exists.
> What exceptions will be raised if the data cannot be loaded?
If it matters, the function is wrong. This demonstrates what is wrong with exceptions, and why they shouldn't be used by library code.
> Why is the return type "void" instead of the data,
> is it modifying private variables? If so, which ones?
That problem is orthogonal. Why isn't the return type "foop"? Why doesn't it read my mind?
This problem demands documentation, but doesn't demonstrate the value of XML autodocumentation.
> When somebody says that a function's purpose is obvious, what they actually mean is "I'm too lazy/ignorant to figure out what that function does".
I agree, but I don't think that's relevant.
> If it's a library function, and the source isn't available, I agree completely. However, that isn't a case for xml automatic documentation.
Why isn't it? Auto documentation, XML-based or not, is also used for documenting libraries.
>> Is FilePath absolute or relative?
> If it matters, the function is wrong.
In this case, document how relative paths are resolved. Common roots I've seen are the user's home directory, their desktop, the location of the application binary, filesystem root, etc.
> On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
At which point, everybody using a non-UTF8 locale can't read their files.
> If it matters, the function is wrong. This demonstrates what is wrong with exceptions, and why they shouldn't be used by library code.
Fine, have it your way. Which error codes does it return? Or, if you're a LISP guy, which conditions does it set? Any way you look at it, you need the function to be able to do something aside from exit the program when the file it's trying to load from doesn't exist, or is malformed. And that error behavior should be documented for when you revisit the code in a few months trying to find a bug.
> Why isn't it? Auto documentation, XML-based or not, is also used for documenting libraries.
That doesn't mean it's good at it. Read back in this thread, through >>80,82,83,85,86,87,88,90,91,92
Recap: Automatic documentation makes it easy to extract structured information. Unfortunately, that doesn't make it useful, and because people rely on automatic documentation, they have a tendency to let "the real" documentation slip.
As a result, sites that use autodocumentation, tend to have worse documentation than sites that don't.
> In this case, document how relative paths are resolved. Common roots I've seen are the user's home directory, their desktop, the location of the application binary, filesystem root, etc.
See POSIX.1 to see how relative paths are resolved. On UNIX, the current-directory is per-process, so this is a non-issue.
On Windows, the current-directory is per-session, so it should only be queried for paths entered directly by a user. Win32 is remarkably consistant in this regard; if you're not doing it like Win32 does it, you're doing it wrong.
Relative paths are a solved problem.
> > On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
> At which point, everybody using a non-UTF8 locale can't read their files.
I don't think you program on UNIX often enough, or well enough to understand what you're saying. Almost all UNIX desktops are UTF-8; those that aren't frequently display some file names wrong at worst, but it doesn't prevent the user access to their files. It just prints the name wrong.
Non-desktop UNIX users tend to use a limited set of us-ascii for filenames simply to make them easier to type.
Programs should not attempt to decode pathnames given to them; they shouldn't as a rule attempt to decode /'s or ..'s except as a reason to reject the path outright.
> Fine, have it your way. Which error codes does it return? Or, if you're a LISP guy, which conditions does it set? Any way you look at it, you need the function to be able to do something aside from exit the program when the file it's trying to load from doesn't exist, or is malformed. And that error behavior should be documented for when you revisit the code in a few months trying to find a bug.
That means we need documentation, which I agree with. It doesn't mean we need autodocumentation.
It's fine to hold up the strawman of documentation and say "if we need documentation, then surely autodocumentation is good".
It isn't. Autodocumentation is bad. Real documentation isn't. They aren't related. Using autodocumentation tends to produce awful real documentation.
And see here: Real documentation needs to be really good, and that's hard. Microsoft has a hard time keeping their documentation correct, so what could lead me to believe a computer can document things better than Microsoft? Shouldn't I suspect good, real documentation require at least as much effort as Microsoft puts into it?
Autodocumentation tends to make companies and organizations skimp out on the real documentation. Autodocumentation was a trick to try and get the programmers to write documentation, never mind the fact the programmers they hire aren't able to write.