Chad Perrin: SOB

16 August 2008

Of course MS Windows is better! It has Visual Studio!

Filed under: Geek — apotheon @ 12:14

In discussion at TechRepublic:

  1. Someone commented on how poor Linux-based systems must be as development environments compared with MS Windows, after (s)he gained the authoritative experience of spending probably three hours playing around with Ubuntu or some such nonsense.

  2. Someone else commented as follows (and this is where the above link actually leads):

In general the text editor and GCC or interpreter is all that is needed for any language. I've not met many windows programmers that have the old-school skills to pop open Dos Edit write code without the Studio crutch. (I'm learning to do that myself though with simply .vba coding where applicable.)

Here's what I started typing as a response, and eventually realized was long enough that I should just post it as a stand-alone, um, thingie:

Making good use of an IDE is an acquired skill set. It is not, as people who've done no programming without one seem to think, just a bunch of automatic "programming is easier now" features. There's an approach to programming that relies on using an IDE, and an IDE being useful depends on that approach to programming.

Also notable in evaluating the use of an IDE is the fact that IDEs are specifically designed to make certain programming activities easier that are particular to certain types of languages. Java, VB, C++, and C# are all languages that not only benefit a hell of a lot from a well-designed IDE, but effectively require a well-designed IDE to achieve an acceptable level of productivity (though C++, being notably closer to C than the others I listed, is less tied to IDEs in that respect). Part of the reason people often consider IDEs indispensable to development is the fact that they do all their programming in verbose object oriented languages like Java and C#, where great quantities of boilerplate class hierarchy code must be written on a regular basis, to say nothing of needing to alter those class hierarchies as one goes. Without an IDE to ease the process of generating and maintaining those class hierarchies, the volume and complexity of the code involved would quickly overwhelm otherwise productive coders on large-scale projects.

Meanwhile, on Unix-like systems, most of the programming is done in languages such as C, Perl, Lisp, and Ruby, as well as various shell languages (bash, tcsh, et cetera). These are languages that don't benefit as much from a "traditional" IDE. The lack of benefit, however, is not a result of some failure of the language — it's a result of the fact that IDEs were essentially invented and developed for the purpose of making it easier to work with the challenges particular to verbose object oriented languages like Java and C#.

Technically, I think it was a flavor of BASIC that had the first IDE, though the "IDE" developed for it wasn't something that would be recognized as an IDE by today's standards. That IDE was basically just a single interface for a set of basic tools (filesystem browser, editor, debugger, and something vaguely like a code execution shell). A transitional version of an IDE, halfway between that IDE for BASIC and something that would be recognized as an IDE today, was actually a (language agnostic) CASE tool called Softbench, which ran on UNIX and employed a plug-in architecture for extensibility. As such, if anyone tells you that you can't get good IDEs on Unix-like systems, you might want to point out that the father of the modern IDE was invented for commerical UNIX (circa 1990).

These days, the most highly regarded IDEs appear to be Eclipse and Visual Studio. Eclipse runs on pretty much any OS, including Unix and Linux-based systems.

. . . but there's the matter of these languages that don't really need an IDE. Many of them are actually supported by high-quality IDEs. For instance, Eclipse offers support for Groovy, Perl, PHP, Python, and Ruby — and even typesetting languages like LaTeX. This, despite the fact that people who have primarily worked with such languages for a long time (as opposed to working mostly with something like Java, and occasionally needing to do a little tinkering in something like Perl) actually find IDEs too cumbersome and limiting.

That's really the problem: people who have done all of their development on MS Windows using various incarnations of Visual Studio, with languages like C#, cannot imagine doing any "serious" development without an IDE because all the develoment they've done involved working with Microsoft libraries (MFC or .NET, generally) and Microsoft GUI development, and using languages like C# and Visual Basic (or Visual C++, for the "old timers"). Under such circumstances, you really do need an IDE, and because of the fundamental necessity of what an IDE provides, they never realize that there's not only a helpful aspect to such IDEs, but a limiting aspect as well.

That limiting aspect becomes incredibly obvious if you haven't really used IDEs much and have worked with languages that don't impose the challenges upon the developer that make an IDE necessary. If you started out your development with shell and Perl, eventually learned to do system development in C and assembly language, and for scripting and high-level development eventually moved on to Python and Ruby, never having had any use for an IDE, using one would initially feel like being forced into a straight straitjacket. More to the point, such experience with development might lead you to regard the code generated through the use of a modern IDE to be really atrociously written code. It would probably take a while to realize the importance of an IDE for working on large-scale projects in languages like Java, since you'd be used to being at least as productive without an IDE working on large-scale projects in languages like Ruby.

. . . but wait, there's more! There's this so-called "text editor" called Emacs which provides much of the same capabilities as an IDE, but with a very different approach to how tools are integrated. Furthermore, Emacs is particularly good for Lisp development, as it has been adopted as essentially the unofficial official IDE for Common Lisp, and has thus received a lot of loving attention from Lisp developers who have extended and improved Emacs' Lisp-oriented development support features. GNU Emacs is even written in Lisp, and extended with Lisp.

Emacs certainly isn't necessary for Lisp, or any other language, though. One of the most famous Lisp hackers in the world — Paul Graham — is a devoted vi user.

Vi was the editor created by Bill Joy when he assembled the original Berkeley Software Distribution of Unix, because he decided it needed a good editor. In a manner somewhat similar to the way Emacs (then EMACS) was originally created as extended functionality for TECO, so was vi originally created as extended functionality for ex, and the two came out at about the same time. Their respective user communities have basically been engaged in an ongoing religious crusade against each other ever since (though a mostly friendly one, believe it or not). The vi editor has since been forked and extended in many different ways, but the most widely used variant today is almost certainly Vim — which is my favorite editor. In fact, I'm typing these words into an instance of Vim right now.

Vim is more like an actual text editor than an IDE. In fact, calling Vim an IDE would be a disservice to Vim, in many respects. While Vim is probably not an adequate replacement for Visual Studio by any stretch of the imagination, when writing code in C#, Visual Studio is not by any stretch of the imagination an adequate replacement for Vim when writing code in Perl. Vim doesn't come with class hierarchy boilerplate code management features the way VS does, but by the same token VS doesn't provide the incredible productivity enhancing editor interface you get with Vim. Once one has become sufficiently familiar with the way Vim works, in my experience at least, productivity when writing code in a high level language such as Ruby or Perl, as well as when writing essays and articles in English, increases by between 50% and 300% — and the productivity enhancement increases with the complexity of the project, so that it probably gets even more impressive working on projects of a scale greater than my usual range, as long as you're using a language better suited to Vim than to VS or Eclipse.

There's no straight straitjacket in Vim, but there's no comprehensive class hierarchy management either. I do essentially work in an IDE-like environment when developing on my BSD Unix laptop, but it's not really an IDE as you'd probably recognize it: Unix is my IDE, as I run a group of basic tools all in the same workspace, each in its own terminal emulator window.

Before anyone points it out, as though it disproves something I said, I know you can get a Vim knock-off installed as your default editor for Visual Studio. It's not quite the same, though — just as using gVim on MS Windows isn't quite the same as using console-based Vim in a terminal emulator on FreeBSD or Debian GNU/Linux. It really is a poorer experience, to some degree, and that relative paucity of productivity enhancement is magnified when a vi variant is shoehorned into a straight straitjacket IDE like Visual Studio. I'm sure it improves development productivity for many C# developers, but moving from pure Vim to VS with a vi-like editor plug-in would be a definite step down in productivity for a serious Ruby developer.

So . . . if you think MS Windows is a better development environment than something like FreeBSD or Debian, just because it has Visual Studio and Unix-like systems don't have it, that must be because you think all development must be like C# and VB development. In fact, it's probably true that most development isn't like C# and VB development that way.

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. When you're done, compare that experience with the idea of doing Ruby development in Visual Studio on MS Windows (or, worse yet, in Notepad), and you may find yourself shuddering in disgust at the thought. You may even not want to go back to C#.

In any case, judging the development environment of Unix-like systems by giving a Unix-like system a cursory glance and thinking about how (un)fun it would be to develop C# in a text editor like Kate is not going to give you anything like an accurate view of the actual Unix development experience.

27 Comments

  1. Their respective user communities have basically been engaged in an ongoing religious crusade against each other ever since (though a mostly friendly one, believe it or not).

    That's a gem. (:

    Comment by Joseph A Nagy Jr — 16 August 2008 @ 06:11

  2. You are spot on about C#/VB needing an IDE. In fact, all language decisions for VB are predicated on the question "What will the IDE support be like?".

    However, you didn't actually make his case for not using an IDE. You say they are limiting, but you didn't really give any worthy examples.

    And the bit about boilerplate code, you are close but wrong. The IDE doesn't really help with boilerplate code, that is something the languages need to address directly.

    Where the IDE is really shines is when dealing with generated code, the stuff in .designer files that no one is supposed to look at. The .NET languages actually have constructs specifically for working with generated code that serve no purpose at all in any other context. Specifically, the "Partial Methods" added in VB 9 and C# 3.

    Comment by Jonathan Allen — 16 August 2008 @ 11:07

  3. Thanks for commenting, Jonathan.

    However, you didn't actually make his case for not using an IDE. You say they are limiting, but you didn't really give any worthy examples.

    Sorry. I didn't feel like digressing for a couple thousand words on the subject of how higher level, more dynamic languages make the code generation and complex boilerplate management capabilities of an IDE irrelevant at best. Maybe later.

    The IDE doesn't really help with boilerplate code, that is something the languages need to address directly.

    When a single click gets the opening boilerplate out of the way, and moving crap around doesn't break things because the IDE helps you restructure your class definitions appropriately, that means the IDE is helping with boilerplate code. Maybe you just have a different definition of "boilerplate" than I have.

    Where the IDE is really shines is when dealing with generated code

    . . . a lot of which is "boilerplate" code.

    Specifically, the "Partial Methods" added in VB 9 and C# 3.

    I'm not terribly familiar with VB 9 or C# 3, I'm afraid.

    Comment by apotheon — 16 August 2008 @ 11:41

  4. I don't know about early BASIC environments, but I think it's likely that the Interlisp programming environment predates them. It's also likely that the SmallTalk browser predates SoftBench. You could also make the case that Borland tools weren't all that far from a modern IDE in the late 1980s.

    Comment by Giuseppe DiMaggio — 17 August 2008 @ 01:04

  5. Unless you've written assembly language both with and without an IDE, you're in no position to comment on this subject I'm afraid.

    Comment by Mike G — 17 August 2008 @ 03:01

  6. A good post. If I may make one small criticism, the following sentence took me a couple of tries to parse:

    "It is not, as people who've done no programming without one seem to think..."

    George Orwell would have your balls for not simplifying those double negatives ;)

    Comment by Daniel — 17 August 2008 @ 03:03

  7. Please learn to spell straitjacket

    Comment by Mark — 17 August 2008 @ 03:05

  8. I agree with much of your post, being an old-time Unix hacker myself. For years I've stressed to my coworkers how, as you also say, "Unix is the IDE." Using tools such as RCS/CVS/Subversion/insert-equivalent-here, autotools for CM (in a C/C++ project), make for builds, g?vim (for me), and select aliases/shell scripts, that is precisely what the shell becomes.

    A parallel might exist between IDE's vs this approach and imperative vs declarative program architectures. As with imperative implementations, the IDE paradigm only allows extension in very controlled (if any) circumstances and mandates a very specific interaction model. "Drift" out of what it is intended for and the tool starts fighting you. Contrast this with the "declarative" nature of the tool-set used in a Unix oriented development environment. There, for example, if you need a special preprocessing step then you simply use the program which provides it! No need for a "plug-in", as the "plug-in API" is the shell.

    Comment by Blue Beard — 17 August 2008 @ 04:05

  9. You're quite right that the need for generated code is bad and a language flaw however it is wrong to claim this is anything to do with IDEs. After all if you want to generate generate boilerplate code just type:

    rails myapp

    Yes, there is a class of programmer that cannot function without IDEs but do not assume they are the majority.

    The purpose of an IDE is to collect every tool required for development into one place. Specifically; text editor, language reference (help + intellisense), debugging and deployment.

    So what is the difference between using separate tools and an IDE? What features available with separate tools that cannot be done in an IDE? In my opinion there is no difference and the choice is purely personal.

    So rather than worry about Windows or Linux, Vi or TextMate, Emacs or Visual Studio I'd suggest progammers would gain much more from learning multiple languages.

    And finally real programmers write code by editing the disk directly with magnets.

    Comment by dan — 17 August 2008 @ 04:14

  10. Here is a real selfish one...Partial classes were introduced in C#2(2005) not C#3 :)

    Comment by sdon — 17 August 2008 @ 05:06

  11. Charlie Petzold gave a talk along the same lines a few years back.

    http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

    Comment by Dave — 17 August 2008 @ 07:27

  12. Good post. I'm filing it next to The IDE divide

    Comment by troelskn — 17 August 2008 @ 08:09

  13. Good observations! I just wanted to add (as a java guy that spends all day in Eclipse) the first thing i do when i get a new workspace going is switch the default keybindings to Emacs. People that have grown up with windows- or have just only used windows, haven't been exposed to the sheer joy, steep learning curve, but HUGE payoff of things like keyboard only navigation/search/replace/file management/etc in vim and emacs.

    Put down the mouse and you'll immediately see productivity gains- that's just something that windows only users rarely discover, due to the indispensability of the mouse to the core os experience.

    Comment by rickd — 17 August 2008 @ 09:40

  14. For me, boilerplate code is stupid, repetitive code that I have to write.

    Generated code, a.k.a "Designer code", is the code that is safely tucked away in a purely generated file. Often this code could be generated at compile time but for whatever reason isn't.

    Quite often I have a mix of the two. Tons of boilerplate in an XML file (LINQ to SQL), matched with generated code derived from it.

    For Partial Methods, here is my writeup: http://www.infoq.com/news/2007/04/PartialMethods

    Comment by Jonathan Allen — 17 August 2008 @ 10:49

  15. text editors are for wimps. Back in the day, we had to type machine language code directly. We didn't even have an assembler. ... Actually, if me and my friends had had an assember on the Apple ][+, we might have done more machine language coding.

    Not having tools is more likely to stop people from learning a language, than having tools that do too much for you. But really, the key to good programming is feedback. The faster the feedback about a line of code that is typed, the more I as the developer will be helped. An IDE can deliver the feedback faster than Emacs. Underlining a syntax error in red is very helpful. The smartest thing about Visual Studio is Intellisense. I can't run to the reference library every time I forget what the parameters are in a function call. Yes, for some, an IDE is useful for the wizards and the graphical designers. But, I think of the IDE as a smart blank page, one that will give hints when I am stuck, and spot my typos.

    I think the boiler plate stuff has helped me learn more than if it had not been there. I don't know how many times I have let some wizard generate a piece of code, and then I have peaked under the hood and learned from the code it generated.

    Comment by Xalem — 17 August 2008 @ 12:13

  16. I'm afraid I'll digress a little bit here, sorry 'bout that...

    While I use VC++ express 2008, I don't really use its integrated editor. OTOH, the IDE has another interesting feature: a line-by-line debugger. When I encounter a weird problem, I can see the evolution of all variables through the code. And that's something you need a IDE for, since you have to see, at the same time, the source code, the call stack, the variables' values, and the output of the program itself.

    Granted, it's not often useful. But the next time I'll have a weird bug, I know VC++'s debugger will be there.

    Another feature: with an IDE, I find it easier to add/remove .cpp files to the project. It's especially useful around the beginning of the project, when its structure can change often.

    And to digress even more: g++ is insanely slow, so any other compiler can only be faster.

    Comment by Fabien — 17 August 2008 @ 01:07

  17. Giuseppe DiMaggio:

    You're probably right about all that.

    Daniel:

    George Orwell would have your balls for not simplifying those double negatives

    I wouldn't want that. I'll fix up the sentence a bit, if/when I figure out how to better phrase it while keeping the emphasis where I want it.

    Mark:

    Apparently, "straightjacket" is an accepted variant almost as common as "straitjacket". On the other hand, since "straitjacket" is the correct spelling, I'll start using that now. Thanks for pointing out the prescriptively correct spelling.

    Blue Beard:

    A parallel might exist between IDE's vs this approach and imperative vs declarative program architectures.

    The paragraph that begins with that sentence is an excellent response to Jonathan Allen's complaint that I didn't make a strong enough case for common modern IDEs being too limiting. Thanks for putting it so clearly.

    dan:

    You're quite right that the need for generated code is bad and a language flaw however it is wrong to claim this is anything to do with IDEs. After all if you want to generate generate boilerplate code just type:

    rails myapp

    Rails is a framework — which has a lot in common with IDEs. In fact, in many cases (notably .NET and Java-based examples), there is effectively no point of separation between the IDE and the framework.

    Dave:

    I remember reading that Petzold presentation a while back, though I had forgotten about it in the meantime. Thanks for linking to it: I'll give it another look.

    troelskn:

    I skimmed the page on the other end of the link you provided, pausing to read little snippets more carefully. It looks pretty good: I'm definitely going to read through it in greater depth. Thank you for the link, and for the compliment.

    rickd:

    Put down the mouse and you'll immediately see productivity gains- that's just something that windows only users rarely discover, due to the indispensability of the mouse to the core os experience.

    I agree about 98%. As far as I'm concerned, both mouse-driven interfaces and keyboard-driven interfaces are important and can provide impressive productivity enhancement. The key (pun intended) is to have an interface that focuses on one or the other, and not to go mixing the two willy-nilly.

    Vim (and some would argue Emacs as well) provides an ideal realization of that approach to interface design, in that it has that whole "never leave home row" thing going on. World of Warcraft is actually another good example, in that you can very easily play the entire game with one hand on the mouse and the other resting on a specific set of keys — it's a more mouse-focused interface, in other words. Meanwhile, GUI IDEs such as VS and Eclipse are designed around the assumption that you'll use the mouse a lot. If you do so, when engaging in any serious development, you're significantly damaging your potential productivity by having to essentially interrupt the flow of your work on a regular basis to reorient your approach to the interface. It's like a minor form of context switching that has to occur far too often.

    I guess I might even agree with you 100%, but you didn't specifically state the bit about the value of a mouse-focused interface, so I basically just had to say something like "I agree, with the proviso that this stuff about the mouse's value is kept in mind."

    Jonathan Allen:

    For me, boilerplate code is stupid, repetitive code that I have to write.

    For me, boilerplate code is repetitive and derivative code that should not be needed — but, for some reason, is. There's sort of a gray area there, in the case of certain types of generated code (the types you seem inclined to forgive); it fits under the heading of "derivative code", but one might make a reasonable argument that "boilerplate" is the wrong term. I wouldn't really argue against that, but I don't really know what else to call the whole collection of code that shouldn't be needed (including both the boilerplate itself and the strictly derivative code) such that people will have any idea what I'm talking about by simply reading the term I use. Any ideas?

    I'll check out your writeup on partial methods later. Thanks for the link and the discussion.

    Xalem:

    Not having tools is more likely to stop people from learning a language, than having tools that do too much for you.

    In my experience, having tools that do too much for you is just as likely to discourage people from learning how to program effectively in a given language as not having any tools other than some Notepad-like editor and a compiler or interpreter. There's a disturbing number of "programmers" out there who have spent years assembling applications with IDEs that are almost WYSIWYG software "designer" applications who still, after all those years, don't actually know how to program worth a damn.

    In any case, I for one have not suggested people should have too little tool functionality rather than too much. I meant to point out that a different approach to tool functionality may look like a lack of tools to a typical long-time MS Windows VS-using developer or J2EE developer, but it isn't — especially when the languages with which you use the tools are designed so differently that much of the functionality of those C# and Java optimized tools is irrelevant.

    In other words, I think you missed my point. Maybe I did a bad job of explaining my point in the first place.

    But really, the key to good programming is feedback.

    That's one of the reasons I like REPLs (such as irb) so much.

    I can't run to the reference library every time I forget what the parameters are in a function call.

    That's why I like stuff like perldoc and rdoc/ri so much.

    I don't know how many times I have let some wizard generate a piece of code, and then I have peaked under the hood and learned from the code it generated.

    One of the benefits of working on an open source system is that it's absurdly easy to find real-world, working examples of code that isn't half-baked crap generated by an automated tool. I prefer other people's code on my FreeBSD system over tool-generated code.

    Fabien:

    the IDE has another interesting feature: a line-by-line debugger.

    . . . as do several debuggers available for on Unix/Linux systems.

    And that's something you need a IDE for, since you have to see, at the same time, the source code, the call stack, the variables' values, and the output of the program itself.

    You don't need an IDE for that. You only need a text editor, a REPL, and a good debugger — and the ability to organize a workspace worth a damn, of course.

    Another feature: with an IDE, I find it easier to add/remove .cpp files to the project. It's especially useful around the beginning of the project, when its structure can change often.

    I made that point about how developing in different languages requires different tools, and C++ was one of the languages I used as an example.

    And to digress even more: g++ is insanely slow, so any other compiler can only be faster.

    Compiling C++ is insanely slow, in general. I'm not a fan.

    Comment by apotheon — 17 August 2008 @ 02:20

  18. Not really much to add; this post is pretty spot-on.

    Although to be honest, I don't even see the boilerplate code when developing in VS, probably because it's all hidden away in files automatically generated when you create a Web form (or Windows form, if you're doing desktop app development). I guess looking at it would be the equivalent of seeing the sausages made, and I'd rather stay ignorant and happy in my IDE-driven world. ;-)

    Certainly it is possible to use text-based tools to write C#–but I'd only recommend it for writing class libraries or other non-GUI code, since trying to create server controls and forms outside the IDE would be an exercise in self-flagellation. So this goes directly to your point that some languages demand an IDE to achieve any sort of productivity. (Given the size and complexity of the .NET Framework, I wouldn't even attempt to write code in an editor that didn't support Intellisense.)

    I do remember my first experience using an IDE–Borland's Turbo C++ for Windows. Pretty great tool, but the funny part was that the debugger wasn't integrated into the IDE–it had to run in DOS! (I assume this was because it needed access to hardware interrupts to support breakpoints, and it could only do this in DOS. Also, I think that particular version of Turbo C++ used the debugger from Turbo Assembler, which was a DOS-only product.)

    OK, I guess I had more to add than I thought. ;-)

    Comment by Brian Martinez — 18 August 2008 @ 12:50

  19. Oddly, I started programming Windows applications in C (not C++) using vi (MKS version). I can't say that VS and MFC made that work any easier or better. C#, the .NET framework, and associated enhancements to VS are a definite improvement over MFC in terms of consistency and completeness, but their one unintended (hopefully) consequence is that they get you used to doing things slowly. You wait for VS to start up, you wait for a project to load, you wait for symbols to load, etc.

    Recently, I went back to using vim as my editor and compiling only at the command line. I can't believe how much more productive that is, even on Windows.

    Comment by Sterling Camden — 18 August 2008 @ 11:09

  20. [...] Chad Perrin: SOB » Of course MS Windows is better! It has Visual Studio!I only ever use VS for debugging now. I edit with vim, and compile at the command prompt.Tags: none [...]

    Pingback by Chipping the web: August 18th from 09:45 to 11:12 -- Chip’s Quips — 18 August 2008 @ 12:01

  21. Recently, I went back to using vim as my editor and compiling only at the command line. I can't believe how much more productive that is, even on Windows.

    Does that include writing C#, or are you mostly speaking of Synergy/DE? If the latter — do you think the differences between Synergy/DE and C# might account for some of your successes with improving productivity? I don't know much about Synergy/DE (basically just what I've found out from you), so I'm not entirely sure how it fits into all of this.

    Comment by apotheon — 18 August 2008 @ 12:16

  22. I was talking mostly about C/C++. It's damn hard not to use VS for C#, just because there's so much scaffolding that needs generating for most project types. Even in C++, depending on the project, I'll sometimes generate the project in VS and then use vim to modify it (read "cut out a lot of crap").

    Synergy/DE isn't really clued into VS yet (although they're working on that project). But I've been coding Synergy/DE without VS for 25 years now, so I don't think I'll need to move over to that when it becomes available.

    Comment by Sterling Camden — 18 August 2008 @ 01:25

  23. Okay — your discussion of how you use VS for C++ and the fact that C++ was the language you were talking about (along with C) rather than Synergy/DE or C# makes a lot of sense. In fact, it sounds kinda like you're basically using VS functionality like a collection of separate stand-alone tools.

    Synergy/DE isn't really clued into VS yet (although they're working on that project).

    I thought I remembered something about Synergy/DE being directly usable with VS, perhaps via some plug-in. Obviously, I was mistaken.

    Comment by apotheon — 18 August 2008 @ 02:19

  24. Brian:

    I finally figured out what I wanted to say in response to your comment.

    Not really much to add; this post is pretty spot-on.

    Thanks!

    OK, I guess I had more to add than I thought.

    I'm glad you did. I just don't really have anything to add to what you said.

    Comment by apotheon — 18 August 2008 @ 05:52

  25. Someone commented with words akin to "Have you ever tried developing Lisp in Visual Studio?" and suggested trying SLIME (the Lisp development mode for Emacs). Unfortunately, whoever was in charge of updating the moderation interface for WordPress in recent versions needs to get drug out in the street and shot, because it's really good at deleting all kinds of shit you don't want it to delete. As a result, that comment was deleted by the moderation interface's bugginess even after I approved it. I wonder if some other legitimate, non-spam comments might have been deleted that way without me noticing.

    Sorry 'bout the problem, folks.

    Comment by apotheon — 19 August 2008 @ 10:46

  26. This guy has a nice series of posts about using Vim for C# development: http://kevin-berridge.blogspot.com/2008/09/visual-studio-development.html

    Comment by slypheed — 27 December 2008 @ 06:50

  27. That was an excellent read, sylpheed. Thanks for the link. I haven't looked too closely at the series of links related to C# development with Vim, largely because I don't do any C# development right now, but the introductory post made some excellent points and got me thinking. Getting me thinking, of course, is what I call "a good thing".

    Thank you for adding to the discussion.

    Comment by apotheon — 31 December 2008 @ 11:03

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License