
Of course MS Windows is better It has Visual Studio - bdfh42
http://sob.apotheon.org/?p=473
======
andr
As a person that started programming on X11 in the late 80s and still uses vim
daily, I can't think of a better environment than Visual Studio (possibly with
the vi plugin) for programming. It is actually sad that guys like the author
of this post and some hardcore Linux geeks pride themselves in the lack of
good IDEs.

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.

~~~
trezor
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.

~~~
chandler
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.

~~~
sysop073
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

~~~
chandler
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.

------
DanielBMarkham
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)

------
scott_s
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.

------
snprbob86
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:

    
    
        (p.Name for p in people)
    

And in C#:

    
    
        from p in people select p.Name
    

Or:

    
    
        people.Select(p => p.Name)
    

Notice how in the C# version, the source comes before the projection. This
enables code completion when you type "p."

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.

~~~
apotheon
The first thing I noticed about that C# example was that it was written in
passive voice.

~~~
snprbob86
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:

    
    
      (word for line in page for word in line.split())
    

C#:

    
    
      from line in page, word in line.Split() select word
    

I think that translates to:

    
    
      page.SelectMany(line => line.Split())
    

The Python is a bit confusing; the first C# example is much easier to read.
Verbosity is traded for understanding. It is a careful balancing act, but I
prefer the balance in C# in this instance. (Don't get me wrong, C# and Python
are by far my two favorite languages, I love them both)

------
akeefer
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.

~~~
apotheon
> 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.

~~~
akeefer
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.

~~~
apotheon
> 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.

~~~
akeefer
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.

~~~
apotheon
> 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>

------
trezor
_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?

~~~
axod
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.

~~~
trezor
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.

~~~
cstejerean
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).

~~~
axod
Is lisp obsolete yet?

~~~
cstejerean
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

------
Maro
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).

~~~
DarkShikari
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.)

~~~
apotheon
> 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.

