Also useful & open source Notepad++
A chunky Visual Studio 2010 releases soon, packing more features and representing perhaps more hours of development than any other single vendor's development tool. How could you resist? And yet many do resist such highly automated and powerful productivity tools and continue to favor Emacs or other text editors and command …
1. I use Komodo for Perl and Ruby development. I wouldn't be caught dead without it - the dragon has saved my bacon so many times I've lost count.
2. I hope NetBeans survives - it's really a quality development environment. If there was a Perl on the JVM like there is Python and Ruby, I'd be using NetBeans.
3. Once a project gets to a certain size, a *standardized* IDE is a requirement. You flat out can't manage a big project without one, and if two programmers can't agree on the development environment, one of them shouldn't be on the project.
I've been happy with vi for over thirty years.
If you don't understand how the underlying code works, your editor of choice doesn't matter in the long run. Running code trumps all ...
"But developers tend to resist lock-in, are wary of bundling, ..."
Unfortunately, I've also seen plenty that are the opposite of that - wedded to the Microsoft tools and environments and seemingly oblivious to the existence of a world beyond Redmond. In fact, some that I know are now suffering pain as the stuff that worked well with IE6 now needs re-writing (in some cases to work at all, let alone well) when customers demand to run it on Firefox, Safari, and their iPhones !
And somehow, it's Apple's fault that Safari doesn't have all the same "features" as IE6 !
And don't get me started on some of the Windows "administrators" for whom a feature doesn't exist it there isn't a GUI to control it.
"But lighter weight tools offer a more rapid edit/test cycle with less waiting time."
And many more edit/test cycles than would have been necessary with a decent IDE.
Granted some individuals are exceptional and get things right first time, every time. You try putting together a development team of exceptionals and an IDE-free development cycle for a product may be feasible. For the vast majority of us an IDE is our toolbox, and a worksman without their tools isn't very productive.
Save the text editors for scripting languages, but don't come crying when the management of a project fails because people aren't using the tools that would make the project go a lot smoother.
I may have proven some of the authors points with what I've stated. My thoughts are that it's all about the right tools for the job at hand, and if a text editor will suffice then go for it. Most projects require structured delivery though, and text editors just don't cut it. They need to be complimented with the rest of the tools for larger projects to keep all tasks organised, and that is where a text editor will never be able to compete with an IDE.
One aspect of this debate which you haven't fully touched on is the extent to which (particularly junior) programmers will end up knowing how things work in their IDE rather than understanding the underlying language / platform. IDE's started out being a productivity tool for users who know what they're doing, and ended up being a crutch for sub-standard programmers who can't understand their language / platform without the IDE.
There again, maybe this all comes under the banner of "vendor lock-in", not that I'm suggesting this is anything other than an unintended (but nevertheless advantageous) consequence for the vendors ;-)
I've always used the simplest of tools for my programming.
Granted, I'm not working on anything more complex than database driven php websites, but despite this, there's a plethora of Big Dev Tools out there which are 'supposed' to make my task easier - they don't.
I've tried eclipse - bloated and overly complex.
I've tried Zend Development tools - bloated and overly complex.
I've settled for a handful of apps:
Vim (with a bunch of custom scripts)
MySQL command line
Firefox with dev tools, firebug etc.
Paros - security checks
Having recently purchased "The Pragmatic Programmer", I'm heartened to see that they too don't view the Big Dev Tools as being in any way better than a handful of lightweight ones.
I often find that those who use the Big Dev Tools are lacking in experience, relying on the tool to 'fill in' the gaps in their knowledge.
Yep, I agree that there are plenty of good reasons to slogh off the IDE's that turn one job into 2 or more, at least sometimes. HTML is inherently pretty simple, but let any of the IDE/design tools near it and you get into a horrible cycle of trying to guess which style is coming from where, whether you have tables everywhere or pure CSS etc, some odd ideas about templating/inheritance, yuk.
But you got me thinking, what would a modern IDE for punched cards look like? Colour-coded cards? Automatically appearing libraries of thousands of boilerplate cards added to every project? Bits of string connecting boxes of punched cards to add references? It's quite a fun mental exercise.
FTR I prefer emacs.
> more structured code editing
what does this mean? What is unstructured code editing?
> ...and navigation
now this to me is the big win since I started using IDEs, that and, surprisingly trivially, having syntax coloured comments. I guess some of the smallest things of the most significant.
> Code quality improves with semantic analysis, which can detect uninitialized and unused variable errors.
I'd say it's the job of the compiler rather than the IDE to detect uninitialised/unused variables, but in any event if this is the level of semantic checking we're talking about then we haven't really moved on since the 80s
> ...differentiate between static, instance, and local variables
how this is supposed to be a significant step forward I can't imagine
> Here are some tips..
from experience with the opposite approach, I have to completely endorse this
I like emacs because I can use it anywhere but it does have its problems -- I have been able to find exactly one piece of halfway useful information about skeleton.el and it look like somebody dashed it off in a couple of hours.
I've been using the SQL Server 'management studio' for SQL 2008 and it is bloody awful. It can't even cut and paste correctly and I've lost hours of work from this alone, it has its lousy IntelliSense feature which I've just discovered how to disable. I don't think they did any user testing because it just gets on the way of the most basic tasks -- like having a new line happen when you press the return key (seriously), and it keeps crashing when memory gets tight (sometimes losing work). I've had to resort to OSQL for large batches.
The help is all screwed up -- you can't easily open two help topics in the same help window so you end up opening two help windows, each of which is a 50MB app. I tried to download BOL for 2008 so I could install it outside the VM where I run the server and -- for real -- it wanted me to install .NET! So I could read *the help*! All this crap and a whole lot more. What happens when you let the marketing droids drive, I guess.
They got a lot right in SQL server 2000 query analyser and they screwed up a whole lot by trying to get all big and corporate for 2008.
So it looks like it's back to emacs, again.
I'm of the command line, vi, make and dbx generation and find modern IDE's hide too much. I watch people struggle with include, library file locations and install set ups. There's also the admin of multiple versions of VisualStudio: VS 6.0, VS2008 and then VS Express - clicking on a project/solution file and starting up the wrong version (or having your project file automatically converted).
The key to code design and development is visibility of the process and these tools break that.
I'm glad to see an honest "I like these tools..." approach to IT. It's not that I agree totally with everything said, but it's your approach to the problem that's refreshing: solve the problem, worry about the tools when it's an issue.
All I'd ask for is a stronger emphasis on the importance of tool-building. The importance of having an experienced builder of tools (or two) on a project/programme cannot be overstated. Tools tailored to a project/programme can be a massive boost that's hard to over-state.
Wasn't ruby's rise to power partly due to ruby on rails? I.e. the boilerplate code generating IDE for ruby?
Most ruby devs resist IDE's because IDE's can't offer all that much support for weakly typed scripting languages such as ruby. So the choice is between a memory hogging IDE or a simple text editor with syntax highlighting.
You might want to look at Rails again. Whatever it is, it is most definitely not an IDE. Not even remotely like an IDE. In fact it's almost exactly unlike an IDE.
....but *particularly* w/Visual Studio, is that you wind up with populations of so-called "developers" who know how to manipulate the GUI widgets in their IDE of choice, but have no real understanding of what code is or how it works.
This is an especially insidious problem in large enterprise shops, where people wind up being promoted and recognized on the basis of their ability to manipulate packaged tools from a particular vendor (OK, Microsoft) in preference for more generalized abilities like creativity and logical analysis. This, in turn, promotes a corporate IT culture that rewards mediocrity.
If you can't write code w/a text editor, you have no business calling yourself a programmer--and if you think the increased volume of half-assed work generated by Visual Studio constitutes "productivity" you have no real business calling yourself an IT manager. But if you fit either of these descriptions and work for Corporate Amerika, your job is probably as safe as anything is these days...
"If you can't write code w/a text editor, you have no business calling yourself a programmer"
Good grief, man! How are we supposed to work then? Must we bring out the Altair 8800? You're probably a Unix man.
I've been using the command-line and vi, combined with a stand-alone debugger, for more than twenty years. No IDE can convince me when it comes to productivity.
"But lighter weight tools offer a more rapid edit/test cycle with less waiting time."
If I'm using Visual Studio then a rebuild is a keypress away. I currently have the Resharper addon installed, which means that running all the unit tests just means pressing ctrl-shift-N. I can't see how a lighter weight tool would make that any faster...
Advice on picking an IDE from a former employee of the buggy bloatware factory?
Frankly, I like IDEs. When Turbo Pascal introduced the IDE twentyfive years ago, many developers liked the idea of being able to work without getting in and out of several tools and having to remember many command line parameters for each tool. When debugging and other tools got integrated, programmers' everydaly life became much more easier - a common interface to most of the tools you need is always welcome. And that usually never means you lose rhe abiltity to script tasks using a command line interface, that's always available when you need it.
I think it is really unfair to compare Ruby (or languages like that) and C++ programming. Oh yes, you can code most Ruby applications with a simple text editor - the applications themselves are much simpler then those you are coding in C++. In the past years I've seen Linux C/C++ developers used to use vi switching to IDEs as soon as their applications became more complex to code, debug, test, and mantain.
But that's a strange movement actually in IT., some kind of steampunk approach: many would like to go back to the mainframe model, they call it "the Cloud" but it means remote applications and dumb terminals anyway, and now we should go back to text editors losing much of the power of integrated tools. Hey, guy from Adobe, why don't you deliver a command line Photoshop? Why don't you edit bitmaps in one application, vectors in another, download images from a camera via a command line application, and print with another? Isn't Photoshop a "lock-in"?
"Why don't you edit bitmaps in one application, vectors in another..." We do. The program is called Adobe Illustrator.
Eclipse is a nice FREE glue layer between text editors and other tools. Many of the common editors have plugins that work, and we can do much more than just edit code .....
PHPEclipse is my own preferred editor again without any 'commercial' tie ins ...'
And I don't even have to worry about OS ..... it works transparently across all of them!
What do you mean I need an IDE to tell me what variables are unused or uninitialized? I get that for free with GCC without ever needing an IDE.
IDEs are a sick form of lockin. Anyone building your code has to use an IDE that understands your IDE's project files. Show me an IDE that loads in less than 15 seconds and understands makefiles and I might consider switching.
I just popped an instance of VS 2008, loaded in six seconds, and it supports makefile projects. Got wizard and everything.
KDevelop uses GNU autoconf - to build makefiles.
Eclipse supports at least two different kinds of makefile projects.
Netbeans will create and read makefiles.
Dev C++ supports makefiles.
Most any 'serious' IDE will support makefiles (I'm looking at you XCode, smarten up) because they are such a de facto standard in C++ development.
So, well, y'know, fail.
It's an axiom of programming that the sooner you find a problem the lower the cost of fixing it. With a decent IDE you get told about uninitialised variables or dead code paths while you are viewing your source. That's [i]before[/i] using the compiler. The only way to get such warnings even earlier (and therefore at even less cost) would be for the IDE to read your mind. One of the huge advantages of C# is that you get told of problems while you're typing. Either because a red/green underline appears or else you type a terminator and the code doesn't auto align.
IDEs certainly have their problems (vs2008 is a right PITA sometimes) but it's more than compensated for by the leap in productivity. It's true that some programmers get too wedded to templates and what I call 'mouse driven programming' but most don't.
I agree with the article where it says build processes should use the command line. An IDE should only ever be a front end sitting on top of command line utilities. That way it keeps it honest.
I've lost count of the amount of companies that expect me to develop something with vi, gcc, the terminal mode set up incorrectly, and an OS which has not had a patch applied to it in years. As for debugging, gdb is like Chinese water torture.
I still fondly remember Codewarrior for System 7 that was way ahead of its time, I suppose the closest thing nowadays is Eclipse but you've still got to fiddle around setting up the remote connection to the Unix server (samba/ssh) with varying degrees of success.
actually, I'm not sure I'm joking.
For a lot of simple web projects do you really need 90% of the complexity and overhead that and IDE drives? A simple web based checking process to help manage source if there's a couple of developers and a syntax aware editor that colourcodes and maybe helps with basic validation/autocomplete
File|Save, F5 to refresh the browser and there's your testing cycle complete
Good article, with much sense.
I (as the technical manager) like the stability and flexibility of editor+cmdline, and while I've wondered if using an IDE like Eclipse would be beneficial, the fact that we compile in a chroot environment complicates things - the IDE would have a hard time entering the chroot environment to carry out the builds (I believe).
IDE style features which we HAVE to have include: syntax highlighting and auto code indentation. However, I've always thought that the Unix/Linux environment is itself a fantastic integrated development environment.
For our developers, Eclipse is acceptable as an alternative to Emacs for editing, as both Eclipse and Emacs can make a good job of automatically indenting code, but some people seem to be inexplicably resistant to the concept of using Emacs :)
"I've always thought that the Unix/Linux environment is itself a fantastic integrated development environment."
You would hope so, since that is precisely what UNIX was developed to be, a platform for programmers to build systems.
Perhaps there will always be such dilemmas especially as in presenting CLI and/or IDE alternatives it automatically follows that a dilemma has been created and presented to users?
Then there may be mindsets issues depending upon what a person has grokked or the coping strategies one has evolved in handling development languages.
See the forest. Behold! There are trees! (IDE mindset)
See the trees Behold! There is a forest! (CLI mindset)
I suppose granularity of the language is an important factor but other factors may be purely personal preference?
The article forgets to mention another strong point of IDE's: integrated debuggers.
Before anyone jumps up and starts talking about the merits of sprinkling your code with write statements: integrated debuggers are there because they big time-savers.
In the same vein, programs like emacs are fine for two sorts of programmers: (1) the sort that has endless supplies of time and (2) the sort that thinks for a few minutes, and then basically types in the whole program (or module),compiles, and watches the thing run without problems (this is also the sort of programmer whose productivity wouldn't be impaired if he had to use punchcards).
I belong to neither class and besides, I thoroughly dislike emacs.
So long live the IDE.
Oh, and perhaps the article could mention that the development of IDE's basically hasn't added anything useful since the days of Borland Pascal and Microsoft Visual C/C++. The "enhancements" since then are almost all bloatware.
... but *real* programmers use butterflies.
Anyway, I write code myself in pretty much whatever editor is at hand, emacs being the first choice, but I like vim too. I can't see in what way is an IDE better. I use dwm as my window manager, one window (main one) for emacs, two stacked ones for make'ing, testing and such.
Extremely fast to load, extremely fast to work in, and cross platform.
Also, I don't know any good programmers who use IDEs. It's sure a good thing for beginners though, provides you with more help etc., but most programmers like to stay in complete control (that's why we code, right?).
"Also, I don't know any good programmers who use IDEs."
Then you probably don't know any good programmers.
All I need is Kwrite. Syntax highlighting, brackets autocomplete, line numbers and the ability to minimise code blocks is perfect and lightweight.
Plus it has kioslaves so I can edit live on the server (usually dev server of course).
My entire coding routine is Ctrl-S, Alt-Tab, Up Enter or Ctrl-R.
No IDE is that easy.
You: Hit F6 (or CTRL+SHIFT+B in case some plugin has taken over the F6 shortcut).
VS saves your code, compiles/links/builds it and then the pre-/post-build commands you set up will run (e.g. deploying to test environment, running the NSIS script).
I haven't used MSTest, but if you have nUnit it will detect when the binaries change and run your tests automatically.
All from one keystroke.
I'm not a total VS fanboi, but it is one of the best applications I've ever used, even without third-party plugins. My only real complaint is that ALT+SHIFT+F10 is a bit fiddly on an Apple keyboard. On the other hand, if I just need to read a source file rather than load an whole solution I will use Notepad++. Horses for courses and all that.
Count me in the "I'd rather be using Vim" crowd. I develop Coldfusion for a living, and used Dreamweaver initially. Lots of money for a truly hateful tool, which seemed to get slower and slower as time went by.
Tried Eclipse. Really wanted to like it. Too slow. The time saved by the various time saving features I would use a few times per day was outweighed by the time spent waiting for basic, mundane things which happened all the time (like, uh, editing source code) to happen. I don't consider hardware upgrades to be a good solution to inefficient software.
Reverted back to my Unix sysadmin days and installed GVim. I'm happy again.
Borland really made a nice IDE with Delphi ( and C++ Builder ) - Microsoft has a very nice IDE with Visual Studio. Eclipse was written by committee, and it shows. Writing code in vi - FTS, you're off your rocker.
IDE's do typically have good inter-project dependency management. But I was able to implement all this functionality in GNU Make. GNU Make is actually a powerful functional Touring-complete language.
Like so many things, big companies are kitchens with many cooks. One prefers Eclipse, the other Visual Studio, the undomitable island of GNU must have gmake, and the embedded rednecks swear by a ten-year-old Codewarrior toolset. The new exec VP of software must make its mark so they'll all "standardize" on ClearCase MVFS (decision not related to golfing with IBM sales execs).
The result is a big hodgepodge of standards; standardized on Shebell CRM for case management and bug tracking, standardized on Visual Stunno for the IDE, on Muddycase for revision management, Boost Marmelade as make tool, AMDTel C+- as compiler toolset (apart from the Mc people using GNoo for lack of platform support), and and and and ...
(to Big Blue: Calling all bought-in developer tools "Rational XXX" doesn't make them interoperable)
A bliss if basic support for a command line toolset remains available. You at least can get some work done without spending all your time re-learning the intricacies of the latest one-for-all craze.
My VI is somewhere in the coat pocket ...
What these developers forget is that Unix, it's shell and toolset IS an IDE.
Trying to recreate an environment that's not only productive to work in but where it's also simple and efficient to extend the environment itself remains out of the reach of 'visual' tools, because the effort required to extend it tends to outweigh the benefits gained from the extension.
It's another demonstration of the adage that 'those who don't understand Unix are compelled to re-invent it, badly'.
Claiming that Visual Studio is only the choice for C++ development is hogwash. If you're developing anything on the .NET framework, there's really no other option that comes close.
Similarly claiming that Eclipse is otherwise the default "safe" choice again ignores the reality that is Eclipse not the real-world "safe" choice for .NET. It's Visual Studio.
Then there's the claim that simple text editors are more productive than integrated IDEs. In 18 years of software development, I've perhaps seen 2% of developers use a text editor as opposed to a proper IDE when one is available.
The author does not present any arguments about the advantages of IDEs: Like integrated debugging, intellisense, object browsers, etc.
This article has a distinct whiff of Unix vi-freak about it.
Netbeans has the jvi plugin (http://jvi.sourceforge.net/)
Ooh ... reckon I'll have to take that for a spin; having used various forms of vi since 1989, I found the lack of vi keybindings in IDEs a major nuisance.
Netbeans for Java (Eclipse is way, *way* too bloated for my liking) - for everything else, there's 'vim' with syntax highlighting turned on.
As a software manager I want a development environment that allows me to move seamlessly from requirements to testing with full traceability.
As a developer I want a tool that helps me build code by taking away the mundane tasks so I can concentrate on building software to do cool stuff.
What has happened with the main IDEs is that they have assumed that the former requirement necessitates a single tool that does everything, well a lot more than is needed. Thus when I start up JDeveloper or Visual Studio, they give me a whole host of stuff that I just don,t need for the task I'm doing, and take a long time about it. What you really need is a collection of less functionally rich tools that allow the key tasks in a system delivery process to go on together, but not interfere. At the risk of using IBM terminology, You should have say, an Architect's workbench, a requirements work bench, a design workbench, a development and so on to cover the key tasks. When you get to development, the design should be relatively independent so you can feed into database and language work benches that are highly efficient for their target, and not trying to be development tools for anything and everything in the same screen.
The other thing that gets me about IDEs is they are awful at providing diagrammatic output., why? Is it beyond the whit of the companies to provide a PDF, or even a BMP of a picture?
A long time ago Oracle had a really good development tool for designing systems for implementation into Oracle Forms on Relational Databases. I'd always hoped that JDeveloper would do the same for Java, but apparently no, yet it can't have been that difficult to do. PowerBuilder managed to be a relatively good Object oriented IDE, and a darn sight easier to use than VB.
Oh well I guess the market knows best.
Stupid developers believe that vendor IDEs like Visual Studio and NetBeans are better because they will use "secret" back doors in the OS or VM to work "better". These are the developers who think their software does not work well because they have not yet learned all the "Secret Codes". In truth, their software does not work well because they are stupid, lazy, and ignorant.
The stupid developers, who are actually of merely normal intelligence, communicate this idea to their corporate masters, who are real droolers. This has sold a lot of very expensive and complex development software, and kept a lot of stupid developers climbing a pointless learning curve. The developers should be studying their code, not their tools.
Me, I think the useful parts of the IDE are the debugger and code structure and indexing tools. I used to like Eclipse, when I was doing Java. These days, I use a text editor and whatever debugger the language (python or haskell) supports. Indexing is in my head, simple programs for simple minds.
Oh yeah, I HATE EMACS ! Everything that is wrong with Unix is wrong with EMACS, and the converse. The only time I use VI is when I can't get X started. And I just use it to get xorg.conf fixed. Kate is actually a very nice editor, but here are lotsa other simple GUI editors.
clicking the random button on http://xkcd.com/378/ ?
"From a marketing perspective, the IDE helps with lock-in, product bundling, and perception that each vendor is a one-stop shop for development productivity"
Makes me wish I'd coded that C# .NET app in Emacs to get away from the lock-in and product bundling! If you are writing something that will run on a Windows machine, isn't lock-in a given? If you aren't running something that will run on a Windows machined, well, bless you, but sometimes that is the target.
I would rather eat my own chod than go back to text-editors/ command line. I used to be a Neanderthal, I remember been asked to look at CodeWarrior in the 90's, no thanks I thought, I'll stick to my editor. Debugging meant sprinkling dozens of trace statements into the code and then stare at the output to see what happened. On my desk sat a large stack of well worn API volumes, as I couldn't remember every API detail. Oh and creating a user interface by hand, the horror, the horror. Finally, I rememember the big refactorings we had occassionally, the bravest programmer would write a script, run it over the code and we prayed that the build wouldn't break, bug-tastic.
One day, somebody showed me this magical IDE that allowed you to place a break point in your code and then step through it, line by line. Bug tracking was now down to seconds. The IDE also allowed me to knock up professional looking user interfaces in 10 minutes. The stack of API books now gather dust as the intelligent IDE knows all about the API and even types it for me, what a beaut! Refactoring is now a joy and much safer to do.
Saying all that, I still use a text editor and command line C-compiler for firmware development, but then again thats real programming :)
I hear all these Luddite carpenters on this thread:
"I don't need no circle saw, dadgummit! Nor a lathe neither! I got my trusty saw and wood plane right here! Anybody can't make a table leg perfect every time with a plane ain't got the right to call themselves a carpenter!"
I hear them enthuse about emacs and company--forgetting that emacs isn't a text editor, it's a way of life--and does some of the functions of an IDE.
I'm also hearing web-developers and C++ jocks leading the anti-IDE charge, and I just shake my head.
At the *bare minimum* an IDE has 3 indispensible aids to a developer:
1) An integrated debugger that can step through code and let you alter variables on the fly as you test
2) a syntax colorizer and code indentation control with Intellisense (to use MS as an example)
3) a visual design tool for forms and reports.
These three things together can cut development time to 1/10'th what it would have been without them. And produce higher quality code.
Then lets talk about the little niceties. I'll use VS-2008 for my example since that's what I'm using this particular second. Intellisense in VS 2008 has a nifty little feature that *dynamically* remembers which of two similar identifiers you use the most, and presents it first, even if it's alphabetically second. This is a righteous feature! :)
Lets talk about code folding, also available in VS 2008. I like this, a lot. I like it even better that VS knows how to do it usefully. Makes navigation so much easier...
So to those sneering at IDE's, you really should move out of your caves. Basic Notepad level text editors (of which there are millions) make your life so much harder than it needs to be. Emacs *is* an IDE, although definitely a "roll your own" one, and much poorer than the likes of a VS 2008.
Bottom line? Why slog through the mundane stuff? Let the computer do it. Oh, and the disdain about detecting unused variables etc in the IDE? Have you lot considered being the second person through the code months later? Pretty nice to see the little squiggle underline that flags an issue right where you can immediately fix it--whatever that issue might be.
Humans are visually oriented. IDEs leverage that fact, and save you time. Learn to play to their strengths, not bitch about their weaknesses.
Like any other tool, really...
Fun article, albeit an obvious troll.
As ever, despite all the protests from various camps (mine included), the answer is that there is no one best solution.
Some people like a simple editor and the command line. They can be productive that way. Some people like a shiny IDE. Some, like me, are content to use either/both as appropriate.
As someone mentioned above, if you're running a couple windows with editor, debugger and build output, you are using an IDE. Even more so if you have build scripts/macros. It's just that your brain is doing some of the 'I' part.
In an ideal (from a codemonkey's point of view) world, each individual developer or team of developers would have the autonomy to select an appropriate CPU architecture, OS, language and/or compiler and sundry other development tools such as editors, build tools, source control systems, etc, etc for each project that they are faced with.
In the real world, unless you are an indy (and even then you may well face constraints due to client requirements), or work for a very small shop, you are unlikely to have that degree of autonomy.
There are good reasons for this which have fuck all to with 'vendor lock in', corporations with even small dev teams require standards. While the corporate codemonkeys may chafe at being treated like cogs in a machine, that is, in fact, exactly what they are.
It's no good if one member of the dev team, is using one krufty lump of ad hocery while the others use something else, possibly each their own KLoAH. I've seen shops that try and work like this, very few get away with it, usually it is a disaster waiting to happen. Someone gets sick or leaves and some vital bit of process knowledge is lost forever. Having a standard, repeatable, documented process is more important than some whining beardy fucktard's preference for vi, or indeed some mouthy recently graduated drone's obsession with Visual Studio. Or a drooling moron's preference for Eclipse, the second most bloated, ponderous and ungainly IDE in the universe (Monodevelop, in case you were wondering)
Those of us lucky enough to have the autonomy to chose should do so based on what seems to be most productive and appropriate, ideally we should get some metrics to prove it, but that rarely, if ever, happens in practice. Academia, yes, practice, no.
Here's a handy hint for anyone who feels like they're somehow 'locked in to' or forced to use an IDE that they think is not appropriate : Try and write a compelling business case that illustrates why this is so. When you fail, you will understand why your development process looks the way it does. On the off chance that you succeed, well, job done. Grab yourself a boss chair and a business card order form. Attaboy.
Basically, if you're in a position to chose, you've got nothing to complain about and a world of alternatives. If you're not in a position to chose, there is most likely an excellent reason why not. If you don't like not being in a position to chose, you made a poor career choice somewhere along the line.
High skills shops can be more tolerant of individual coder styles, corporate sweat shops and internal IT functions rarely fit this description.
Coders never get tired of writing while/do loops
Developers look at ways to speed up the *whole* development process to deliver a solution.
Just a thought.
Biting the hand that feeds IT © 1998–2017