Of course MS Windows is better It has Visual Studio(sob.apotheon.org)
sob.apotheon.org
Of course MS Windows is better It has Visual Studio
http://sob.apotheon.org/?p=473
54 comments
Agreed. All of his arguments are weak and because they are built on false foundations.
I develop games with C#. The libraries we have are very thin and do not really benefit from IDE designer support. However, VS still makes my life a whole hell of a lot easier. The debugger is superb. Complete integration with my bug tracking and source management tools. On the fly error checking, saves me from a bad compile.
Especially with Resharper http://www.jetbrains.com/resharper/ If you do any C# development, you MUST try resharper and train your fingers to press alt+enter and ctrl+shift+r a lot. It makes Visual C# much more like JetBrain's other product, IDEA IDE. When your IDE is this good, you never be able to go back.
I have worked two jobs in the past which were at Linux shops. I've used VIM quite extensively and become reasonably proficient at it. It is pretty good for editing all types of text. Too bad that I spend most of my time editing only one type of text: code of a particular language. Visual Studio is EXCELLENT at editing each type of text it supports, but it sucks something awful if you give it a new type and don't write plugins to handle it.
Part of my job is writing VS plugins which is certainly no fun because of the COM legacy. Future versions are getting more C#-ish, nice, managed extensibility APIs that will be closer to that of Eclipse.
I develop games with C#. The libraries we have are very thin and do not really benefit from IDE designer support. However, VS still makes my life a whole hell of a lot easier. The debugger is superb. Complete integration with my bug tracking and source management tools. On the fly error checking, saves me from a bad compile.
Especially with Resharper http://www.jetbrains.com/resharper/ If you do any C# development, you MUST try resharper and train your fingers to press alt+enter and ctrl+shift+r a lot. It makes Visual C# much more like JetBrain's other product, IDEA IDE. When your IDE is this good, you never be able to go back.
I have worked two jobs in the past which were at Linux shops. I've used VIM quite extensively and become reasonably proficient at it. It is pretty good for editing all types of text. Too bad that I spend most of my time editing only one type of text: code of a particular language. Visual Studio is EXCELLENT at editing each type of text it supports, but it sucks something awful if you give it a new type and don't write plugins to handle it.
Part of my job is writing VS plugins which is certainly no fun because of the COM legacy. Future versions are getting more C#-ish, nice, managed extensibility APIs that will be closer to that of Eclipse.
> C# needs more boilerplate class code than C++ or other languages.
RTFA. C++ was used as an example alongside C#.
> close to Python and Ruby.
You must be using a different Ruby than me (or maybe C# 3.0 has magically gotten rid of all its repetitive BS).
> C# and Visual C++ have huge class libraries, which makes it impossible to use without an IDE.
That was kind of part of the point.
> I'm sorry, but I would always go for the language with the big class library, rather than the one without it.
That says more about you than about whether the lack of VS on Slackware makes MS Windows a better development platform.
> I guess the real problem is sour grapes.
This "they hate us for our freedom" crap gets old really fast, y'know. It's not all about jealousy, no matter how much you wish it was.
RTFA. C++ was used as an example alongside C#.
> close to Python and Ruby.
You must be using a different Ruby than me (or maybe C# 3.0 has magically gotten rid of all its repetitive BS).
> C# and Visual C++ have huge class libraries, which makes it impossible to use without an IDE.
That was kind of part of the point.
> I'm sorry, but I would always go for the language with the big class library, rather than the one without it.
That says more about you than about whether the lack of VS on Slackware makes MS Windows a better development platform.
> I guess the real problem is sour grapes.
This "they hate us for our freedom" crap gets old really fast, y'know. It's not all about jealousy, no matter how much you wish it was.
Agreed.
The article pretty much reveals that the author has never used a good IDE like Visual Studio for anything besides the obvious like adding new class-files, making some GUIs and then running a compile.
I bet he didn't even customize the default layout, panels and toolbars.
My list of top 3 features in Visual Studio, and I suspect most of them to be in Eclipse as well:
1) The built in debugger which can be invoked at any time, having conditional breakpoints and which automatically tells you where your code fucks up, with full statefull variable inspection. This single feature has saved me more hours than I can possibly count up trough the years. For any project not microscopic, I can't imagine not having a feature like this.
2) IntelliSense and code completion. Having the editor automatically look up all possible members and fields while writing code isn't just handy when it comes to speed and avoiding typos. It allows constant discovery of features in the .NET libraries whenever writing code. And when it stops working, you know you just did something wrong in your previous line of code. Absolutely invaluable.
3) The built in refactoring tools. Granted Resharper provides you with a even better toolset, but the importance of having a editor which actually understands your code as more than just "text" can't be overstated.
These are just a few of the things which I love about Visual Studio. It seems obvious to me as a developer that all these features would be handy for any language.
As for the author's praise of emacs as the text-editor which can be hacked and extended into something resembling a Lisp-IDE (using Lisp no less!), I guess he missed the memo that Visual Studio already is an IDE and can be extended infinitely as well. Last time I checked there were addons for Visual Studio for Python, Ruby and Perl. And addons for Visual Studio can be written in any language with a .NET compiler, Lisp included.
That the author somehow feels more "limited" when using a IDE, that is a editor with intelligent code-related features, than when simply using a editor, show that he is clearly full of himself.
To me, that seems about as intelligent as complaining about how you are feeling more "limited" with unused commands in /bin/ that you don't fully know or use, than if the commands weren't there at all.
The article pretty much reveals that the author has never used a good IDE like Visual Studio for anything besides the obvious like adding new class-files, making some GUIs and then running a compile.
I bet he didn't even customize the default layout, panels and toolbars.
My list of top 3 features in Visual Studio, and I suspect most of them to be in Eclipse as well:
1) The built in debugger which can be invoked at any time, having conditional breakpoints and which automatically tells you where your code fucks up, with full statefull variable inspection. This single feature has saved me more hours than I can possibly count up trough the years. For any project not microscopic, I can't imagine not having a feature like this.
2) IntelliSense and code completion. Having the editor automatically look up all possible members and fields while writing code isn't just handy when it comes to speed and avoiding typos. It allows constant discovery of features in the .NET libraries whenever writing code. And when it stops working, you know you just did something wrong in your previous line of code. Absolutely invaluable.
3) The built in refactoring tools. Granted Resharper provides you with a even better toolset, but the importance of having a editor which actually understands your code as more than just "text" can't be overstated.
These are just a few of the things which I love about Visual Studio. It seems obvious to me as a developer that all these features would be handy for any language.
As for the author's praise of emacs as the text-editor which can be hacked and extended into something resembling a Lisp-IDE (using Lisp no less!), I guess he missed the memo that Visual Studio already is an IDE and can be extended infinitely as well. Last time I checked there were addons for Visual Studio for Python, Ruby and Perl. And addons for Visual Studio can be written in any language with a .NET compiler, Lisp included.
That the author somehow feels more "limited" when using a IDE, that is a editor with intelligent code-related features, than when simply using a editor, show that he is clearly full of himself.
To me, that seems about as intelligent as complaining about how you are feeling more "limited" with unused commands in /bin/ that you don't fully know or use, than if the commands weren't there at all.
Reading these posts about the "excellent, bug free" VS development environment: in my experience, this isn't quite the truth.
I've used VS6 since the late 90's, mostly on small projects (less than ~10 000 lines, four or five source files) until 2004, where I signed up to work maintenance on what is essentially a very large codebase (thousands of source files, between 500-50 000 lines per file). In 2006, my frustration with VS6's inability to handle a codebase of this magnitude finally convinced me to try a different IDE toolset. My specific complaints:
- Starting VS6 is slow, and brings the computer to a halt.
- Compiling & linking through the IDE is slow, and brings my computer to a halt. This doesn't happen when run from the commandline, nor, as follows, from a subprocess within Emacs.
- Intellisense stops working a lot; nothing breaks programming flow like having your favorite crutch be unavailable for half the methods (this seems to affect large files more than small). Incidentally, though Emacs has Intellisense type functionality, I much prefer the generic completion available in Emacs/Vim (M-/ in Emacs, Ctrl-N in Vim), as it works within comments and for undefined/undeclared (and unprocessed) structures.
- The method navigation panel fails often, with it listing a method correctly, but displaying "method not found" when selected (the workaround is to select different methods until one is found, then jump around the file for the desired method). I suspect this is related to the parser not handling default arguments correctly in certain cases.
Finally, VS is the only application that has blue-screened my XP machine (this happened only twice, however, and wasn't involved in my decision to migrate to a different toolset).
Regarding software, either you bend software to meet your needs, or it bends you to meet its limitations. Unfortunately, because VS has a high difficulty regarding the former, I found I was consistently having to integrate workarounds into my day to day coding practices.
I've used VS6 since the late 90's, mostly on small projects (less than ~10 000 lines, four or five source files) until 2004, where I signed up to work maintenance on what is essentially a very large codebase (thousands of source files, between 500-50 000 lines per file). In 2006, my frustration with VS6's inability to handle a codebase of this magnitude finally convinced me to try a different IDE toolset. My specific complaints:
- Starting VS6 is slow, and brings the computer to a halt.
- Compiling & linking through the IDE is slow, and brings my computer to a halt. This doesn't happen when run from the commandline, nor, as follows, from a subprocess within Emacs.
- Intellisense stops working a lot; nothing breaks programming flow like having your favorite crutch be unavailable for half the methods (this seems to affect large files more than small). Incidentally, though Emacs has Intellisense type functionality, I much prefer the generic completion available in Emacs/Vim (M-/ in Emacs, Ctrl-N in Vim), as it works within comments and for undefined/undeclared (and unprocessed) structures.
- The method navigation panel fails often, with it listing a method correctly, but displaying "method not found" when selected (the workaround is to select different methods until one is found, then jump around the file for the desired method). I suspect this is related to the parser not handling default arguments correctly in certain cases.
Finally, VS is the only application that has blue-screened my XP machine (this happened only twice, however, and wasn't involved in my decision to migrate to a different toolset).
Regarding software, either you bend software to meet your needs, or it bends you to meet its limitations. Unfortunately, because VS has a high difficulty regarding the former, I found I was consistently having to integrate workarounds into my day to day coding practices.
Visual Studio 6 is a full three versions behind the current version ( VS 2008). I use Visual Studio 8 and have none of these problems. Complaining about a version of VS that came out 10 years ago is ridiculous.
I can't imagine how building is freezing your computer when using the command-line isn't; all VS does is call cl, link and mt in that order, you can procmon it and watch it happen. The Intellisense thing, on the other hand, is the most ridiculous thing I've ever seen - the official Microsoft solution is to delete the Intellisense database and restart VS, apparently it "gets corrupted over time" and they don't feel the need to look into it
It's specifically at two points of the build--firstly, when VS6 is starting the compile (and trying to find modified files, I suppose), and during the link step.
I think the IDE is doing something with the toolchain to give it an incredibly high priority (and therefore build faster). The only evidence I have for that is a) command-line compiles take longer than they do through the IDE (using msdev to process the dsp file, not using nmake/cl/link), and b) windows messages (e.g. Send/PostEvent) don't seem to be processed during the link stage.
Regarding the Intellisense bit, you've reminded me of our "process" used to fix VS when it stops compiling files correctly: try deleting all our non-source controlled files (which includes the VS specific databases for things like classwizard, object files, etc) and see if that fixes things. If not, then restart.
I think the IDE is doing something with the toolchain to give it an incredibly high priority (and therefore build faster). The only evidence I have for that is a) command-line compiles take longer than they do through the IDE (using msdev to process the dsp file, not using nmake/cl/link), and b) windows messages (e.g. Send/PostEvent) don't seem to be processed during the link stage.
Regarding the Intellisense bit, you've reminded me of our "process" used to fix VS when it stops compiling files correctly: try deleting all our non-source controlled files (which includes the VS specific databases for things like classwizard, object files, etc) and see if that fixes things. If not, then restart.
You are comparing VS6 to something current, which is not fair. Lots of these hitches you've had (which I don't doubt, since I've been forced to deal with some old VB6 projects) has been fixed long time ago.
I'm not saying Visual Studio 2008 is flawless, perfect or the second coming of Christ(tm), but in general I've had very few issues with it.
I'm not saying Visual Studio 2008 is flawless, perfect or the second coming of Christ(tm), but in general I've had very few issues with it.
Whether it's fair or not, I can only knowledgeably critique what I
know. However, I've heard (and propogated) this basic comment
describing the robust solid development experience that is Visual
Studio for more years than VS.NET (or, obviously, 2008) has been
around.
(Not that VS6 is terrible--I still think it's a serviceable IDE for small to medium sized projects. However, it doesn't scale well to our large projects, and, personally, I've found that IDEs in general foster a lazy attitude towards improving personal workflow)
(Not that VS6 is terrible--I still think it's a serviceable IDE for small to medium sized projects. However, it doesn't scale well to our large projects, and, personally, I've found that IDEs in general foster a lazy attitude towards improving personal workflow)
The title was a plug for windows, the gist was to try out unix editors before you decide on one, and the common thread was this wandering around the IDE world comparing random features of various products.
As somebody who has hacked code with both notepad and batch files and various IDEs, I can say unequivocally that that most IDEs are configurable enough to win hands down.
Pick a feature, and you can either find an IDE that comes with it out of the box or easily code one up. Good IDEs are a superset of good text editors.
Maybe I'm missing something, but this didn't look like too good an article. It looked like a big morass with "Paul Graham" stuck in about half-way down, no doubt triggering the auto-feed into HN. (grin)
As somebody who has hacked code with both notepad and batch files and various IDEs, I can say unequivocally that that most IDEs are configurable enough to win hands down.
Pick a feature, and you can either find an IDE that comes with it out of the box or easily code one up. Good IDEs are a superset of good text editors.
Maybe I'm missing something, but this didn't look like too good an article. It looked like a big morass with "Paul Graham" stuck in about half-way down, no doubt triggering the auto-feed into HN. (grin)
Windows programming needs an IDE because Windows is not a programmer's OS. Unix was designed by programmers for programmers. Windows was designed for end-users.
The author got close to this distinction with the "Unix is my IDE" point, but didn't quite make the connection.
The author got close to this distinction with the "Unix is my IDE" point, but didn't quite make the connection.
On the subject of toolable languages, the Microsoft Languages teams do a faaaantastic job of making languages that are designed to be used with a proper IDE.
For example...
Generator expression in Python:
The VB, C#, and F# teams work their asses off to make all those little things work so nice. These are things that even the most experienced developers might not notice, but they attribute to that confusing "this sucks" shock when VS users need to use VIM or Emacs.
For example...
Generator expression in Python:
(p.Name for p in people)
from p in people select p.Name
people.Select(p => p.Name)
The VB, C#, and F# teams work their asses off to make all those little things work so nice. These are things that even the most experienced developers might not notice, but they attribute to that confusing "this sucks" shock when VS users need to use VIM or Emacs.
The first thing I noticed about that C# example was that it was written in passive voice.
Let's look at a more complex example. Assume "page" is a list of strings. We want to get every word on the page (exact whitespace treatment and tokenizing behavior isn't important; just the gist)
Python:
Python:
(word for line in page for word in line.split())
from line in page, word in line.Split() select word
page.SelectMany(line => line.Split())
For anyone who's worked extensively in both worlds, I think it should be obvious that a great IDE is better than a just a text editor. Yes, Emacs and Vim are amazing tools, but no, I'd never go back to Emacs after having used IntelliJ IDEA. There are a lot of hardcore Unix guys that I work with and even the most stubborn Vi/Emacs fans have been converted; it's just that good. VS for C and C++ was never worth giving up Emacs for, in my opinion.
My perspective is that Java and C# have really amazing, helpful IDEs because the languages have really been designed with that sort of tooling in mind. You just can't have that same level of tooling support with dynamic typing; I've read arguments from people like Steve Yegge but I'll believe it when I see it.
So sure, Java is more verbose and the IDE is the only thing that makes it more tolerable. And yes, I'd rather use a text editor for Ruby or Python. But that's not because text editors are inherently better than IDEs, or that the IDE is only useful for Java because it helps you manage the verbosity; it's just because the IDEs for those other languages aren't that good yet, and it's unclear if they really can be that good.
My perspective is that Java and C# have really amazing, helpful IDEs because the languages have really been designed with that sort of tooling in mind. You just can't have that same level of tooling support with dynamic typing; I've read arguments from people like Steve Yegge but I'll believe it when I see it.
So sure, Java is more verbose and the IDE is the only thing that makes it more tolerable. And yes, I'd rather use a text editor for Ruby or Python. But that's not because text editors are inherently better than IDEs, or that the IDE is only useful for Java because it helps you manage the verbosity; it's just because the IDEs for those other languages aren't that good yet, and it's unclear if they really can be that good.
> that's not because text editors are inherently better than IDEs
Who said they are inherently better? They're better for some languages, and not for others -- and that (alone) doesn't make either set of languages inherently better than the other, either. That's sorta the point in the original essay.
> it's just because the IDEs for those other languages aren't that good yet, and it's unclear if they really can be that good.
Those other languages are designed for people to actually enter a state of "flow" with the language, while IDE-oriented languages like C# are designed for people to actually enter a state of "flow" with the IDE. This does not mean that the only reason to use Vim instead of VS to write Ruby is the fact that VS doesn't support Ruby. Instead, it means that one can be at least as productive with Ruby/Vim as with C#/VS, because Ruby is designed to be highly productive under those conditions, while C# is designed to be highly productive under IDE conditions.
That's the whole point -- and it looks to me like you missed half of it in your eagerness to decide that the reason people use Vim to write Ruby is that the clear superiority of IDEs cannot be achieved by a shitty language like Ruby.
Who said they are inherently better? They're better for some languages, and not for others -- and that (alone) doesn't make either set of languages inherently better than the other, either. That's sorta the point in the original essay.
> it's just because the IDEs for those other languages aren't that good yet, and it's unclear if they really can be that good.
Those other languages are designed for people to actually enter a state of "flow" with the language, while IDE-oriented languages like C# are designed for people to actually enter a state of "flow" with the IDE. This does not mean that the only reason to use Vim instead of VS to write Ruby is the fact that VS doesn't support Ruby. Instead, it means that one can be at least as productive with Ruby/Vim as with C#/VS, because Ruby is designed to be highly productive under those conditions, while C# is designed to be highly productive under IDE conditions.
That's the whole point -- and it looks to me like you missed half of it in your eagerness to decide that the reason people use Vim to write Ruby is that the clear superiority of IDEs cannot be achieved by a shitty language like Ruby.
I think you read too much into that . . . I think Ruby is a fantastic language, and my point is merely that people don't use IDEs for languages like Ruby and Python because the IDEs for those languages are comparatively poor.
If there was an IDE for Ruby that reliably did refactorings like "rename method", found usages, had auto-complete, and could pull up documentation for the particular type/method in question, I honestly think it would be helpful and that it would make people more productive than they already are with Ruby.
To me the author is incorrect in essentially arguing that people don't use IDEs with Ruby because they're too limiting: it's just that the IDEs for Ruby aren't good enough to make it worthwhile to deal with those limitations. For technical reasons I don't really think that's possible, but if it was possible to craft an IDE for Ruby that was as good as IntelliJ IDEA, I really do think it would improve people's productivity.
If there was an IDE for Ruby that reliably did refactorings like "rename method", found usages, had auto-complete, and could pull up documentation for the particular type/method in question, I honestly think it would be helpful and that it would make people more productive than they already are with Ruby.
To me the author is incorrect in essentially arguing that people don't use IDEs with Ruby because they're too limiting: it's just that the IDEs for Ruby aren't good enough to make it worthwhile to deal with those limitations. For technical reasons I don't really think that's possible, but if it was possible to craft an IDE for Ruby that was as good as IntelliJ IDEA, I really do think it would improve people's productivity.
> I think Ruby is a fantastic language, and my point is merely that people don't use IDEs for languages like Ruby and Python because the IDEs for those languages are comparatively poor.
Translation:
"I think Ruby is a fantastic language, except that it can't be used effectively with an IDE as good as VS, which is a glaring flaw in the language."
My point:
"I think Ruby is a fantastic language, and the fact it may not be usable with an IDE like VS is not a flaw -- it is the result of design decisions based on a different approach to programming than that mandated by use of a VS-like IDE."
> If there was an IDE for Ruby that reliably did refactorings like "rename method"
That sort of thing is trivially accomplished by very simple tools that are present in every full Unix environment implementation. You don't need an IDE for that. The same is true for other IDE features you mentioned. I don't need all that stuff integrated into a single monolithic application to be able to use them effectively.
> To me the author is incorrect in essentially arguing that people don't use IDEs with Ruby because they're too limiting
They're too limiting for Ruby.
> IDEs for Ruby aren't good enough to make it worthwhile to deal with those limitations
More accurately, what an IDE provides over the tools people tend to use with Ruby isn't enough to offset the limitations, because what an IDE provides is for the most part superfluous for Ruby, and the IDE way of approaching programming isn't very compatible with the characteristics of the language that make common IDE "benefits" superfluous.
It seems our main point of disagreement is something like this:
1. You think the fact Ruby doesn't have good IDEs is that it's designed in a way that prevents it from benefiting from them, because it just wasn't planned out well enough to take advantage of IDEs. As a result, Ruby will always lack the benefits of IDEs.
2. I think the fact Ruby doesn't have good IDEs is that it's designed in a way that ensures it doesn't need IDEs, and IDE functionality wouldn't really be a benefit because it's superfluous to a language like Ruby. As a result, Ruby will never need the benefits of IDEs. Instead, it's more geared to taking advantage of the benefits of powerful text processing applications like Vim and Emacs.
Translation:
"I think Ruby is a fantastic language, except that it can't be used effectively with an IDE as good as VS, which is a glaring flaw in the language."
My point:
"I think Ruby is a fantastic language, and the fact it may not be usable with an IDE like VS is not a flaw -- it is the result of design decisions based on a different approach to programming than that mandated by use of a VS-like IDE."
> If there was an IDE for Ruby that reliably did refactorings like "rename method"
That sort of thing is trivially accomplished by very simple tools that are present in every full Unix environment implementation. You don't need an IDE for that. The same is true for other IDE features you mentioned. I don't need all that stuff integrated into a single monolithic application to be able to use them effectively.
> To me the author is incorrect in essentially arguing that people don't use IDEs with Ruby because they're too limiting
They're too limiting for Ruby.
> IDEs for Ruby aren't good enough to make it worthwhile to deal with those limitations
More accurately, what an IDE provides over the tools people tend to use with Ruby isn't enough to offset the limitations, because what an IDE provides is for the most part superfluous for Ruby, and the IDE way of approaching programming isn't very compatible with the characteristics of the language that make common IDE "benefits" superfluous.
It seems our main point of disagreement is something like this:
1. You think the fact Ruby doesn't have good IDEs is that it's designed in a way that prevents it from benefiting from them, because it just wasn't planned out well enough to take advantage of IDEs. As a result, Ruby will always lack the benefits of IDEs.
2. I think the fact Ruby doesn't have good IDEs is that it's designed in a way that ensures it doesn't need IDEs, and IDE functionality wouldn't really be a benefit because it's superfluous to a language like Ruby. As a result, Ruby will never need the benefits of IDEs. Instead, it's more geared to taking advantage of the benefits of powerful text processing applications like Vim and Emacs.
In my work, an IDE is beneficial in two main cases. First of all, for someone new to a language or library, auto-complete and instant doc lookup help you figure out what's available to call and what the various methods and classes do. That's also useful if you only use a particular library occasionally and just don't remember how it works. Secondly, refactoring and find usages is useful if you're working on medium-to-large projects with a large number of people; on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful.
The average Ruby project is probably a lot smaller than the average Java project because it's far more concise and powerful, which is a good thing and one of the huge advantages of the language. For smaller projects, smaller teams, and expert users, the weight of managing a project in an IDE could outweigh the benefits, so I can see how plenty of people would ignore an IDE in those situations even if it were the best tool in the world, simply because it might get in the way more than it would help.
I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.
But I can see how there are plenty of development scenarios where even the best IDE would just get in the way, and my judgment is probably just clouded by the fact that my current working scenarios (a few million lines of Java code, 80+ developers, working infrequently enough in Ruby that I forget everything in between) are greatly aided by an IDE. So personally my work style is now tailored to using an IDE, which slows me down when I have to shift out of that mode, and I'd use a great Ruby IDE instead of Emacs if one were available. But I'll accept that other people whose work style isn't tailored to using an IDE wouldn't find it as useful.
The average Ruby project is probably a lot smaller than the average Java project because it's far more concise and powerful, which is a good thing and one of the huge advantages of the language. For smaller projects, smaller teams, and expert users, the weight of managing a project in an IDE could outweigh the benefits, so I can see how plenty of people would ignore an IDE in those situations even if it were the best tool in the world, simply because it might get in the way more than it would help.
I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.
But I can see how there are plenty of development scenarios where even the best IDE would just get in the way, and my judgment is probably just clouded by the fact that my current working scenarios (a few million lines of Java code, 80+ developers, working infrequently enough in Ruby that I forget everything in between) are greatly aided by an IDE. So personally my work style is now tailored to using an IDE, which slows me down when I have to shift out of that mode, and I'd use a great Ruby IDE instead of Emacs if one were available. But I'll accept that other people whose work style isn't tailored to using an IDE wouldn't find it as useful.
> auto-complete and instant doc lookup help you figure out what's available to call and what the various methods and classes do. That's also useful if you only use a particular library occasionally and just don't remember how it works.
Lucky for me, I can have those things with languages like Perl and Ruby without having to resort to an IDE.
> on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful.
The kind of tools you describe as being better than a text search are, in essence, just text search (and replace) tools. They're obviously much more powerful than the search and replace tools familiar to many MS Windows users thanks to the style of search functionality offered with editors like Notepad, Wordpad, and even MS Word -- but then again, so are the search tools available in a typical Unix environment, especially when using an editor like Vim or Emacs.
> I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.
I think that applies more for people who are used to an IDE approach to programming, really. The kind of development done with Ruby without an IDE near at hand actually uses a very different approach to development than an IDE-centric approach, and for someone used to that IDE-centric approach, having an IDE to help make the transition might be very helpful.
Maybe an IDE for Ruby will eventually be a clear win, but before that happens I think a whole new set of IDE features will have to be invented -- features that are both necessary and otherwise rare for tools suited to developing in Ruby. In other words, IDEs as they currently exist probably won't ever cut it as the best way to develop for a language like Ruby, even if the dynamic nature of the language can be accounted for to make the current common IDE features work with it where they don't already.
> So personally my work style is now tailored to using an IDE, which slows me down when I have to shift out of that mode, and I'd use a great Ruby IDE instead of Emacs if one were available.
That makes sense. As Oliver Steele pointed out in "The IDE Divide", language-centric and IDE-centric approaches to development are almost mutually exclusive in a way that supports the idea that for some people, IDE-oriented languages coupled with excellent IDEs are more productive, while for others, languages that (currently) are not well-suited to IDEs because IDEs that interact well with their more powerful capabilities are the more productive choice.
I'm not sure I buy Steele's reasoning, exactly, but he makes some excellent points about the difference in development approaches between IDE-centric developers (what he calls "tool mavens") and language-centric developers (what he calls "language mavens").
Err, the URL, in case that sounds like a topic of interest:
http://osteele.com/archives/2004/11/ides
Lucky for me, I can have those things with languages like Perl and Ruby without having to resort to an IDE.
> on a 500k+ codebase there are probably enough methods named "add" that just doing a text search is going to be pretty painful.
The kind of tools you describe as being better than a text search are, in essence, just text search (and replace) tools. They're obviously much more powerful than the search and replace tools familiar to many MS Windows users thanks to the style of search functionality offered with editors like Notepad, Wordpad, and even MS Word -- but then again, so are the search tools available in a typical Unix environment, especially when using an editor like Vim or Emacs.
> I think that there are other situations, primarily for working on larger projects but also for people new to the language or who use it less frequently, where the benefits of a really good IDE would still help out Ruby.
I think that applies more for people who are used to an IDE approach to programming, really. The kind of development done with Ruby without an IDE near at hand actually uses a very different approach to development than an IDE-centric approach, and for someone used to that IDE-centric approach, having an IDE to help make the transition might be very helpful.
Maybe an IDE for Ruby will eventually be a clear win, but before that happens I think a whole new set of IDE features will have to be invented -- features that are both necessary and otherwise rare for tools suited to developing in Ruby. In other words, IDEs as they currently exist probably won't ever cut it as the best way to develop for a language like Ruby, even if the dynamic nature of the language can be accounted for to make the current common IDE features work with it where they don't already.
> So personally my work style is now tailored to using an IDE, which slows me down when I have to shift out of that mode, and I'd use a great Ruby IDE instead of Emacs if one were available.
That makes sense. As Oliver Steele pointed out in "The IDE Divide", language-centric and IDE-centric approaches to development are almost mutually exclusive in a way that supports the idea that for some people, IDE-oriented languages coupled with excellent IDEs are more productive, while for others, languages that (currently) are not well-suited to IDEs because IDEs that interact well with their more powerful capabilities are the more productive choice.
I'm not sure I buy Steele's reasoning, exactly, but he makes some excellent points about the difference in development approaches between IDE-centric developers (what he calls "tool mavens") and language-centric developers (what he calls "language mavens").
Err, the URL, in case that sounds like a topic of interest:
http://osteele.com/archives/2004/11/ides
Expand your horizons a little. Learn to use Vim or Emacs, then spend a year doing serious development in something like Ruby instead of C# or Java, and do it in a Unix-like user environment.
So does the author suggest anyone working with Java or C# should quit their job?
Or does working with vim also provide you with an alternate space-time continuum which allows you to "just" spend one year doing doing something else entirely without it affecting the world around you and the requirements that you have a job which needs to get done?
So does the author suggest anyone working with Java or C# should quit their job?
Or does working with vim also provide you with an alternate space-time continuum which allows you to "just" spend one year doing doing something else entirely without it affecting the world around you and the requirements that you have a job which needs to get done?
> So does the author suggest anyone working with Java or C# should quit their job?
No. The author (me) doesn't even suggest that anyone should stop using an IDE for Java or C# development. In fact, the author suggests that development in Java or C# is best done with an IDE, and development in Ruby or Lisp is better done with powerful text processor (like Vim or Emacs) in a Unix-like environment.
If you got the impression I was saying Java and C# programmers should quit their jobs to write code in Ruby and avoid IDEs for the rest of their lives, you weren't reading what I wrote so much as reading into it.
> Or does working with vim also provide you with an alternate space-time continuum which allows you to "just" spend one year doing doing something else entirely without it affecting the world around you and the requirements that you have a job which needs to get done?
It wasn't meant to be taken as "only do this, and nothing else". It was instead meant to be taken as "this is all you need to do to test my point".
No. The author (me) doesn't even suggest that anyone should stop using an IDE for Java or C# development. In fact, the author suggests that development in Java or C# is best done with an IDE, and development in Ruby or Lisp is better done with powerful text processor (like Vim or Emacs) in a Unix-like environment.
If you got the impression I was saying Java and C# programmers should quit their jobs to write code in Ruby and avoid IDEs for the rest of their lives, you weren't reading what I wrote so much as reading into it.
> Or does working with vim also provide you with an alternate space-time continuum which allows you to "just" spend one year doing doing something else entirely without it affecting the world around you and the requirements that you have a job which needs to get done?
It wasn't meant to be taken as "only do this, and nothing else". It was instead meant to be taken as "this is all you need to do to test my point".
Do you not do any programming in your spare time? Give that a shot, and try using something other than Java or C#.
You can code java extremely well just using a text editor (Shock horror!)
The idea you can't, or that you'll be less productive than an IDE user is just idiotic.
What has the language got to do with anything? Yes, java is sometimes verbose, so? If most of your time is spent typing, you're doing it wrong IMHO, not matter how verbose the language.
The idea you can't, or that you'll be less productive than an IDE user is just idiotic.
What has the language got to do with anything? Yes, java is sometimes verbose, so? If most of your time is spent typing, you're doing it wrong IMHO, not matter how verbose the language.
Using a good IDE does make you more productive. Taking the java example, most people will accomplish more using IntelliJ-IDEA than Notepad. A good IDE allows you more freedom to explore ideas and experiment faster (especially when doing something like GUI design, debugging using statefull variable inspection, or just learning new features with intellisense/autocomplete), though I'd agree most of your time should be spent thinking than typing.
I couldn't disagree more.
What magical feature of an IDE "allows you more freedom to explore ideas and experiment faster"?
Most people might write more lines of code or produce more classes in an IDE than text editor in Java, but most people aren't good programmers. Lines of code and number of classes often bear no relationship to productivity.
Essentially though, everyone uses an 'IDE', they just don't call it that... Mine is a text editor, bash shell and browser. All you need...
GUI design is a whole different kettle of fish. But a mockup builder is probably more useful for that.
What magical feature of an IDE "allows you more freedom to explore ideas and experiment faster"?
Most people might write more lines of code or produce more classes in an IDE than text editor in Java, but most people aren't good programmers. Lines of code and number of classes often bear no relationship to productivity.
Essentially though, everyone uses an 'IDE', they just don't call it that... Mine is a text editor, bash shell and browser. All you need...
GUI design is a whole different kettle of fish. But a mockup builder is probably more useful for that.
> What magical feature of an IDE "allows you more freedom to explore ideas and experiment faster"?
Refactoring.
Code completion/validation/formatting (make fewer errors, and reformat external code to suit you).
GUI design (a lot of times you will have to make GUIs, no point in avoiding it).
Code analysis (on-the-fly code analysis and error-detection (syntax, compile, and run-time) = less creep-in errors, easier to spot errors earlier, and less compiles = more productivity).
Performance bottleneck detection.
Testing made easier (simpler an faster to build and do unit/integration/etc. tests)
Framework/Design-Pattern skeletons (got an idea, think pattern X may help, try it out quickly = make a good/bad decision faster).
Teamwork features (version control, changelist management, build management etc. made easier).
Etc. Etc.
Who said anything about more LOC being the/a measure of productivity?
Refactoring.
Code completion/validation/formatting (make fewer errors, and reformat external code to suit you).
GUI design (a lot of times you will have to make GUIs, no point in avoiding it).
Code analysis (on-the-fly code analysis and error-detection (syntax, compile, and run-time) = less creep-in errors, easier to spot errors earlier, and less compiles = more productivity).
Performance bottleneck detection.
Testing made easier (simpler an faster to build and do unit/integration/etc. tests)
Framework/Design-Pattern skeletons (got an idea, think pattern X may help, try it out quickly = make a good/bad decision faster).
Teamwork features (version control, changelist management, build management etc. made easier).
Etc. Etc.
Who said anything about more LOC being the/a measure of productivity?
I think it's best to agree to strongly disagree :)
An ex-coworker was arguing how great IDEs are, his comment being "The IDE makes it so you don't have to think" I think that's the best argument against IDEs I've heard so far.
An ex-coworker was arguing how great IDEs are, his comment being "The IDE makes it so you don't have to think" I think that's the best argument against IDEs I've heard so far.
Okay :)
If we ever meet in person, I'll buy you a beer/coffee/meal, and we can debate such things as in general I'm liking the comments you make on a multitude of topics.
An IDE is just a tool and like any good tool can help those that don't want to think, think less, and for those that do, think more?
If we ever meet in person, I'll buy you a beer/coffee/meal, and we can debate such things as in general I'm liking the comments you make on a multitude of topics.
An IDE is just a tool and like any good tool can help those that don't want to think, think less, and for those that do, think more?
The author suggested you should change not only the toolset you use, but also the languages.
That makes it more than a light switch, and will probably interfere with getting work done. Since, you know, many companies have standards about which languages and platforms they stick to.
That makes it more than a light switch, and will probably interfere with getting work done. Since, you know, many companies have standards about which languages and platforms they stick to.
Firstly, learning more than one programming language will make you a better programmer.
Secondly, you are at liberty to write code in your free time, where you can experiment with whatever language/IDE/OS combinations you deem fit. I'd argue this will also make you a better programmer.
Secondly, you are at liberty to write code in your free time, where you can experiment with whatever language/IDE/OS combinations you deem fit. I'd argue this will also make you a better programmer.
Fine, don't change the language. Keep using the same thing for 10 years until it becomes obsolete and then wonder why you're unemployed (hint: nothing to do with outsourcing).
Is lisp obsolete yet?
From the point of view of the average programmer: yes. There are some Lisp jobs available but those are usually taken by the best programmers (as opposed to the ones that look for excuses not to learn new things).
From a quick search on dice here are the number of job listings for lisp, cobol and java.
Lisp: 26 Cobol: 1007 Java: 15494
From a quick search on dice here are the number of job listings for lisp, cobol and java.
Lisp: 26 Cobol: 1007 Java: 15494
"serious development in something like Ruby "
As if Ruby is a more "serious" language than Java or C#?
As if Ruby is a more "serious" language than Java or C#?
I don't think doing serious development in Ruby has anything to do with Ruby being a more serious language. The point is to use it for a real project as opposed to yet another blog in X minutes.
I think UNIX users, seeing they're never going to get something as kickass as VS simply adopted an elitist approach and claim that for various reasons (language, vi, emacs) they don't even need one.
The benefits of VS are obvious:
- tabbed: (could you live without a tabbed browser?), also control+tab brings up a smart switcher
- search: suppose you have a large project and are looking for a function call, irrespective of the language. VS brings up a docked window where you can double-click to jump straight to the line (compare with eg. TextMate, where search results are displayed in a window on top, so you can't see the results)
- solution explorer: see the files and click them if you need them
- for supported languages: code refactoring such as "smart" renames
- and so on...
- important: "it just works", it's fast, stable, etc.
I've been trying to find something comparable for MacOS --- it doesn't even have to be an IDE, as in I don't want it to understand the code or compile it, just be a comparable text editor to VS. TextMate is promising, but it's not there yet, lots of little things are missing (good search, tab switcher, etc.) So for now I'm using Komodo Edit, which is pretty cool, only problem is that it's cross-platform and uses some middle API layer, so it's kind of slow (right-click a tab and wait a second for the menu to appear).
I've been trying to find something comparable for MacOS --- it doesn't even have to be an IDE, as in I don't want it to understand the code or compile it, just be a comparable text editor to VS. TextMate is promising, but it's not there yet, lots of little things are missing (good search, tab switcher, etc.) So for now I'm using Komodo Edit, which is pretty cool, only problem is that it's cross-platform and uses some middle API layer, so it's kind of slow (right-click a tab and wait a second for the menu to appear).
Given what features you describe as "benefits of VS", it sounds like you haven't actually used any of the other editors you claim it is better than, since they have most of the same features. I'd guess most UNIX programmers have used Visual Studio at some point in their programming life (its hard to avoid it!), and the reason they don't like it is because their experience wasn't very good.
I used Visual Studio for a week for a small project and got so sick of its interface that I ended up using it solely for the "compile" button (since the project had to use the Visual C compiler).
The Visual C compiler has its own problems: for example, it is completely incapable of maintaining stack alignment, which required us to write a rather large workaround in the x264 code to disable all functions that depend on stack alignment when compiling with MSVC. Its lack of C99 support is also rather aggravating and gnaws at me every day when I find out that I have to reorganize the code I just wrote because I can't do something like declare a variable somewhere other than the top of a function. It all makes me want to throw away support for MSVC completely, but there oddly enough still seem to be people who try to compile x264 with it...
In summary, there seems to be this arrogant attitude among Windows programmers that the UNIX programmers don't use their tools because they're being "elitist"... but in reality, they don't use the tools because they don't like them. And there's plenty of good reasons not to like them.
(Which strikes me as odd--I've always found Windows programmers to be on average more elitist than *nix programmers--the former insists that their single IDE is unquestionably the best, while the latter will recommend dozens of editors, saying that you should pick the one you like most.)
I used Visual Studio for a week for a small project and got so sick of its interface that I ended up using it solely for the "compile" button (since the project had to use the Visual C compiler).
The Visual C compiler has its own problems: for example, it is completely incapable of maintaining stack alignment, which required us to write a rather large workaround in the x264 code to disable all functions that depend on stack alignment when compiling with MSVC. Its lack of C99 support is also rather aggravating and gnaws at me every day when I find out that I have to reorganize the code I just wrote because I can't do something like declare a variable somewhere other than the top of a function. It all makes me want to throw away support for MSVC completely, but there oddly enough still seem to be people who try to compile x264 with it...
In summary, there seems to be this arrogant attitude among Windows programmers that the UNIX programmers don't use their tools because they're being "elitist"... but in reality, they don't use the tools because they don't like them. And there's plenty of good reasons not to like them.
(Which strikes me as odd--I've always found Windows programmers to be on average more elitist than *nix programmers--the former insists that their single IDE is unquestionably the best, while the latter will recommend dozens of editors, saying that you should pick the one you like most.)
> Given what features you describe as "benefits of VS", it sounds like you haven't actually used any of the other editors you claim it is better than, since they have most of the same features.
As I read the list of features that are apparently "missing" in everything but VS, I found myself wondering what I'd been doing all these years that made me think I had capabilities I've just been told I don't have. Vim allows me to do all kinds of stuff many VS users seem to think I can't do without VS. What's up with that?
I guess the problem is that VS users expect to be able to transplant their IDE skills from VS to Vim and achieve the same level of productivity in only a week. Taking that approach to it is bound to lead to failure, just as the reverse (taking text processor skills from Vim to VS and expecting to achieve the same level of productivity in a week) would, in large part because doing the same things often requires a very different approach. That different approach doesn't necessarily make one approach any better than the other, but it is different.
. . . and nobody seems willing to keep that in mind while trying out something new and different.
As I read the list of features that are apparently "missing" in everything but VS, I found myself wondering what I'd been doing all these years that made me think I had capabilities I've just been told I don't have. Vim allows me to do all kinds of stuff many VS users seem to think I can't do without VS. What's up with that?
I guess the problem is that VS users expect to be able to transplant their IDE skills from VS to Vim and achieve the same level of productivity in only a week. Taking that approach to it is bound to lead to failure, just as the reverse (taking text processor skills from Vim to VS and expecting to achieve the same level of productivity in a week) would, in large part because doing the same things often requires a very different approach. That different approach doesn't necessarily make one approach any better than the other, but it is different.
. . . and nobody seems willing to keep that in mind while trying out something new and different.
For the last several months, in an attempt to use the Mac OS that came with my Macbook I've been trying out text-editors and IDEs available for this platform as a replacement for Visual Studio, in an attempt not to broaden my personal horizon and not be a platform-nazi. (Okay, MacOS is not UNIX..) So your claim is false, I actually have tried out many other tools to reach the approximate conclusion I described in the original post. I'd be happy to report that I found a good replacement as it would weaken my "dependence" on a particular platform (Windows).
I am almost positive based on this that you've never opened Visual Studio before. VS has lots of really helpful and useful features; the first ones that come to mind are not "tabbed" and "search". Most of the things you listed there exist in virtually every text editor there is besides Notepad
Well, I have used VS in a professional environment (working at a semi-large software house). Part of the point I was trying to make is that VS is not just great as an IDE, it is also great as an editor, and that these particular features do not exist in any UNIX/MacOS I have come across.
Your claim that most of the things exist in virtually every editor is simply not true --- many editors have many features, but none have all the features AND work well (fast, stable, etc.). E.g. Eclipse has most of the features, but I find it rather sluggish.
Saying things like "I am almost positive ... you've never opened VS before" is a personal attack, childish and not true.
Your claim that most of the things exist in virtually every editor is simply not true --- many editors have many features, but none have all the features AND work well (fast, stable, etc.). E.g. Eclipse has most of the features, but I find it rather sluggish.
Saying things like "I am almost positive ... you've never opened VS before" is a personal attack, childish and not true.
"I'm positive you've never open VS before" isn't a personal attack, "I'm positive you're ignorant and ugly because I dislike your opinions" is a personal attack. I have no troubles with Eclipse, but I don't use it for big projects so maybe it does get slow. Nonetheless, the features you listed (tabs, searching, project browser and refactoring) are in every halfway decent text editor; I think Notepad++ has most or all of those.
Also, you're adopted and your parents don't really love you
Also, you're adopted and your parents don't really love you
you'll find that a lot of unix programmers use tools such as cscope when they need to navigate around large code bases. If you're a vi sort of person, having one terminal in cscope, and another on the command line to compile/checkin code, and another for the debugger gives a totally acceptable result. Of course, as always the optimal solution for a development environment depends on many things - language, host is, target, type of application etc...
It also depends on the developer's own personal preferences -- which is part of the reason I, for one, prefer the far more flexible and configurable IDE that is known as "Unix" over the more rigidly designed IDE known as "Visual Studio".
The two main arguments are:
1) C# needs more boilerplate class code than C++ or other languages. Wrong. It definitely needs less boilerplate code than C++ and is close to Python and Ruby.
2) C# and Visual C++ have huge class libraries, which makes it impossible to use without an IDE. I'm sorry, but I would always go for the language with the big class library, rather than the one without it. Also, C++ has fairly hefty Unix libraries, too.
I guess the real problem is sour grapes. For languages other than Microsoft's and Java (and maybe Lisp - I don't know), there aren't any good IDEs, which really understand your code, are stable and bug-free, and provide useful refactoring tools (e.g., change the name of a method and update all of its invocations). For one, the lack of a good IDE and toolchain really does reduce efficiency in large projects (although I would guess the average Rails project is not that large). It also steepens the learning curve. While learning Scala I've spent ours trying to find a mistake in a single line, which neither the IDE nor the compiler could reasonably point out, but Visual Studio would have explained right away.