90 replies to this topic

[arbitus]

I find it interesting that those who criticize IDEs heavily go on to explain how their tool chain, which accomplishes the same tasks as an IDE, is completely different because they are not part of a single executable or are command-line or something. If you have written a script or plugin to execute from Notepad++ that automates your build and debug process, congratulations, you have just reinvented the IDE. If you are describing the various tools that you use to replicate behaviors found in common IDEs, then obviously IDEs must have some positive uses. Whether they be command-line or GUI based, separate executables or part of a monolithic package with plugins, at that point the only fundamental difference is what flavor of ice cream you prefer.

Bregma, I respect your opinion, and I absolutely believe you are probably capable of running code rings around me. My last job, I worked with a 60+ year old former Bell Labs employee that I GREATLY respected who preferred VI for everything (but had to use Eclipse due to some necessary plugins). He was a hardcore Java guy, and had never spent more than 1 hour of his life in Windows (he preferred Mac for fun and Linux for work). We became good friends and I started showing him some of the new-fangled things I was doing in .NET and VS2010. Now he gleefully plays in VS2010 (run in a VM inside Linux or Mac OS of course), and creates all sorts of useful tools to help him with his Java development. He literally cackles at his computer armed with new-found power.

You see, it is not about finding the one tool to rule them all, it is about building an arsenal and knowing when to pull out the big guns. If all you write are small programs or scripts, why bother with an IDE? However, even if all you write are small programs or scripts (or work alone), why are you neglecting your technology arsenal? Maybe one day you will want to (or have to) work with a group of people or on a large project that requires certain tools. Why be unprepared?

[Antheus]

I've been a professional software developer for 30 years.

Because it works, bitches.

It's quite a sad state of the software development industry.

30 years ago, teletypes, faxes and type writers were the norm. Professionals would be using them for everything.
Printing presses specialized in rush orders and small number of copies, xerox was a novelty. Typesetters were crucial to this process.
Typists took care of transcribing discussions and secretaries retrieved archives.

Gen Y barely knows what these words mean.

---

As for software:
Emacs, best 30 years ago, still "best of breed" today
Unix, best 30 years ago, still "best of breed" today
Lisp, 30 years ago it solved all computing problems, everything invented since then is a subset
Computer science, hardly anything relevant was published after 1980

We haven't really come a far way.

While rest of the world advanced at lightning speed, adopting paradigms that changed the way society works, changing what took months into minutes - the very industry that enabled this growth hasn't moved an inch.


Depressing. Just think about it - publishing was an industry that took thousands of people across many industries and many months, today it's done by any individual at push of a button without leaving their desk.
Meanwhile, in software, the same process that was used 30 years ago is still as effective as it was back then - and all the tools invented since then do not improve it, they merely slow it down.

[Bregma]

Your tools, and your processes work well for you. Likewise Dragonion's system for laying out files. How well do they work for others on your team? With 30 years of experience, certainly you mentor more junior developers? Wouldn't you have difficultly helping them with all of the setup and configuration with their currently industry standard environment without having the experience and expertise with it yourself?

You know, I have no idea what my current cow orkers use for their day-to-day development environment. Our common point of reference is the source repo. Nobody seems to check in any kinds of project files. They all seem to be able to get work done, and their experience ranges from AAA game dev veterans to still-in-school students. Our dev environments in my current job are not dictated by central management.

I do not mentor junior developers, they already know everything.

[way2lazy2care]

I do not mentor junior developers, they already know everything.

Then aren't they just developers? o.O

[A Brain in a Vat]

Yes, it's true, I've become pretty good at using tools. I am not ashamed of my knowledge. I've been a professional software developer for 30 years. I've developed on and for mainframes, minis, micros, PCs, embedded blinkenlights, phones, and tablets. I've worked for years in shops where IDE use was mandated by management, for both Java and for Windows. I am not inexperienced in a number of development environments and techniques, oftentimes cutting edge.

The hardware, OS, and platforms on which I've worked have changed underneath me over the many years. I have evaluated and discarded tools and techniques that have not been effective, and I have readily adopted tools and techniques over the years that work well. My basic workflow has remained essentially the same.

Why?

Because it works, bitches.

And it keeps on working, even when all the trendy kids have moved on to some other shiny thing, I keep bringing home the bacon. Mmm, bacon. I have heard a lot of complaints from ponies who know one Visual Studio trick and try to jump to, say, a Mac or a Linux distro and are completely lost. I wish them luck with their careers. Maybe they could consider something in the management track.

Yeah, it works. I work with some developers who have been developing for decades. Some embrace change. They like to learn new ways of doing things in order to become better and more efficient at what they do. Others avoid change. They are really good at doing what they do, but they only learn new things when they need to. They get the job done. It does, in fact, work, bitches. What I see that they don't is that they hold the company back. Their resistance to change stifles the company as a whole.

Management doesn't realize that. They see "Old dependable Ralph" who always gets the job done, and thus keeps bringing home the bacon. Give it to old dependable Ralph, he'll get it done. And if it takes him longer to do it than if he had embraced the rest of the world has embraced, they'll never know it. And if old dependable Ralph is holding the entire company back from evolving its toolchains and frameworks from "what works" to "what is better", they'll ever know that either.

Conservatism in almost any context is, in my opinion, is an attitude that appears attractive and safe, but really undermines (by definition) any possible progress and inevitably leads to catastrophe when old dependable Ralph finds that "it doesn't work anymore, bitches... and i don't know how to move onto something that does".

[A Brain in a Vat]

And you still haven't mentioned how you do automatic code refactoring without an IDE. What tool do you use?

I ask because I don't think you actually do. I think you're just reluctant to admit that there's something useful that an IDE could do that your tool environment doesn't currently do.

It's fine to have your preferences, but it's a little silly to not be honest about the positive aspects of the alternative.

As I mentioned before, I don't have a car. I sold my car and have never been happier. I don't, however, pretend that my bike can go as fast as a car, or that it can hold as many groceries.

[Antheus]

Others avoid change. They are really good at doing what they do, but they only learn new things when they need to. They get the job done. It does, in fact, work, bitches. What I see that they don't is that they hold the company back. Their resistance to change stifles the company as a whole.

Only a handful of relevant improvements occurred during last 20 years.
1) automated testing
2) automated memory management
3) google
4) metrics

1) By automating testing, it pulled the typical Ford assembly line trick. With a switch, you can make the line run faster and it produces more output. Unlike human testing, which has hard upper bound, the hardware is effectively free these days and scales as far as needed.

2) Resource management is complicated task by itself, when applied to individual syntactic constructs it adds enormous friction. By removing a whole dimension of development complexity, the barriers are lowered. If anything, manual memory management is an anomaly that appeared in a managed world. Both languages before and after were managed. Manual memory management was needed in a short period of time where hardware could not keep up with demands. This is no longer the case.

Both 1 and 2 were solved by Moore's law.

3) At one point, software came with large manuals that had to be studied and trained. Majority of questions regarding software development today is answered by a quick Google search. Principal change here is obsoleting most higher level roles (architecture-related), which simply aren't needed anymore, experimentation leads to adequate results.

4) Multivariate testing and other methods of analyzing almost real-time and real world data affected the way software is architected and designed to provide maximum value. it's embedded in practices such agile development.

IDEs however have not improved in any meaningful manner.

And you still haven't mentioned how you do automatic code refactoring without an IDE. What tool do you use?

Text editor?

Refactoring does not have to mean that one needs to constantly rename methods and move blocks of code around. Such tool-assisted process is crucial primarily to Java for well-known reasons. Most other languages and ecosystems simply do not have such pain point. It happens, but it's mostly a non-issue.

For example, renaming is trivial part, the difficult part in refactorings is revisiting the test cases, possibly removing or adding them or correcting them to reflect new design. That is where the hours will go. Text mangling is simply not a pain point.

[phantom]

IDEs however have not improved in any meaningful manner.

That'll explain why we all still use Visual Studio 6 and just upgrade the compiler suite... oh wait...

[A Brain in a Vat]

And you still haven't mentioned how you do automatic code refactoring without an IDE. What tool do you use?

Text editor?

Refactoring does not have to mean that one needs to constantly rename methods and move blocks of code around. Such tool-assisted process is crucial primarily to Java for well-known reasons. Most other languages and ecosystems simply do not have such pain point. It happens, but it's mostly a non-issue.

For example, renaming is trivial part, the difficult part in refactorings is revisiting the test cases, possibly removing or adding them or correcting them to reflect new design. That is where the hours will go. Text mangling is simply not a pain point.

Text editor? Renaming is the trivial part?

I'm talking about refactoring in such a way that one local change takes effect across the code base. A simplistic example is renaming a method without having to edit every single file that contains code that calls that method.

Why is that an important feature? Number one, because it saves a lot of time when working with complex code bases. Number two, because it makes it much more likely that the developer is going to actively rename things when he or she should, maintaining the self-documenting element of the code.

A programmer who can't rename a method in this way is likely to not rename it, thereby degrading quality of the source code.

Add in automatic code generation, method extraction, variable and constant extraction, method signature changing, etc. All this helps programmers not be lazy. Even if you are NOT lazy and would do all of this manually, you can't deny that refactoring tools make it a lot faster and less error-prone.

[phantom]

when I looked at the size of the project folder I was honestly shocked -- 50 MEGABYTES for a program writing one line in a console!! It turned out to be some Intelli-thingy that apparently created some very large files, which, after all, can be disabled. But still; waaay to much junk in that folder compared to a single makefile ;)

See, 'junk' implies it is useless and thus confirms your 'anything new is bad' bias quite nicely.

The thing is it ISNT 'junk' because it has a use; maybe it looks bad in a massively contrived example (and lets face it 'hello world' IS a massively contrived example) because it has gone off and built a data base of every file you might well be using however there is one key point here; your make file CANT do the same thing and it is a bit dishonest to even attempt to equate the two.

If you had a step in your make file which went off a built a database of all the symbols in your project and in static headers etc in the system and gave you access to it then you'd have the same functionality and probably a comparable file size. Of course even if you could then feed this into an intellisense system (greatest. ide. feature. ever. even for someone like me who does organise their own code very strictly too) you'd still not be doing the same thing as intellisense kicks around in the background and updates the database as you change things.

Hell, VS2010 even background compiles files, including C++ ones, to let you find errors before you even hit 'build'.

I'm sure your system works for you but to say "meh, my make file can do it..." is just... well... wrong... your make file can build stuff, my IDE can do more *shrugs*

[Antheus]

Text editor? Renaming is the trivial part?

I'm talking about refactoring in such a way that one local change takes effect across the code base. A simplistic example is renaming a method without having to edit every single file that contains code that calls that method.

Why is that an important feature? Number one, because it saves a lot of time when working with complex code bases. Number two, because it makes it much more likely that the developer is going to actively rename things when he or she should, maintaining the self-documenting element of the code.

A programmer who can't rename a method in this way is likely to not rename it, thereby degrading quality of the source code.

Add in automatic code generation, method extraction, variable and constant extraction, method signature changing, etc. All this helps programmers not be lazy. Even if you are NOT lazy and would do all of this manually, you can't deny that refactoring tools make it a lot faster and less error-prone.

But none of that is meaningful work. It's shuffling the deck chairs. No matter how efficient, it won't do anything about the ship sinking.

None of these facilities solve actual problems. How does any of these features help me better align the UX experience with target demographic? How does it help reduce turnaround time on reporting? How does it ensure better culture fit across different stakeholders? How do they help me reduce failure rates in deployed software? How do they help me choose most suitable architecture trade-offs given requirements?

All these features do is they help move text around faster. But they don't help with any important problems in a way that choice of better ecosystem would. The "solutions" mentioned above are endemic to Java and .Net which are just absurdly verbose for the trivial and mundane tasks they are solving.

[Telastyn]

None of these facilities solve actual problems. How does any of these features help me better align the UX experience with target demographic? How does it help reduce turnaround time on reporting? How does it ensure better culture fit across different stakeholders? How do they help me reduce failure rates in deployed software? How do they help me choose most suitable architecture trade-offs given requirements?

All these features do is they help move text around faster. But they don't help with any important problems in a way that choice of better ecosystem would. The "solutions" mentioned above are endemic to Java and .Net which are just absurdly verbose for the trivial and mundane tasks they are solving.

All of those things help you figure out what the hell that last programmer actually did by giving you well named methods and variables. They prevent you wasting time tracking down bugs because someone mis-interpreted what 'x' means. Maybe they don't help you from an architectural perspective, but someone's got to write code.

[Antheus]

All of those things help you figure out what the hell that last programmer actually did by giving you well named methods and variables. They prevent you wasting time tracking down bugs because someone mis-interpreted what 'x' means. Maybe they don't help you from an architectural perspective, but someone's got to write code.

Which is why I claimed above that IDEs didn't add anything of value in past 30 years.

Yes, they help mangle text more efficiently.

How about warning that a change will increase database load by 500 times.
Or that I just created a static dependency on external resource.
Or that change in some external library that requires fixing code in 5000 places is actually idempotent and merely semantic?
Or automated migration between versions, patching changes automatically (Go is working on this).

method extraction, variable and constant extraction, method signature changing,

How about "normalize", which automatically restructures code in optimal way, similar to database normalization to balance/minimize code repetition? Or, the ability to view code MyWay while others view it TheirWay, while still allowing seamless collaboration.

How about ability to run same codebase without changes but by plugging 5 different libraries and compare the performance metrics? (can be done in very limited manner)

How about multi-directional debugging, where reported faults (bug reports, crashes, exceptions) are automatically bisected down to cause based on version and deployment history, removing the need of digging through code at all? (there is some work in this area and a lot can be custom built).

Not even mentioning higher-level transformations which could map between designs automatically (due to inherent equivalence).

But agreed, modern IDEs make it very efficient to move text around.

[A Brain in a Vat]

But none of that is meaningful work. It's shuffling the deck chairs. No matter how efficient, it won't do anything about the ship sinking.

None of these facilities solve actual problems. How does any of these features help me better align the UX experience with target demographic? How does it help reduce turnaround time on reporting? How does it ensure better culture fit across different stakeholders? How do they help me reduce failure rates in deployed software? How do they help me choose most suitable architecture trade-offs given requirements?

All these features do is they help move text around faster. But they don't help with any important problems in a way that choice of better ecosystem would. The "solutions" mentioned above are endemic to Java and .Net which are just absurdly verbose for the trivial and mundane tasks they are solving.

What's your point, exactly? No one is arguing that using an IDE writes good code for you.

The question at hand is whether using an IDE has any benefit over not using an IDE. Doing the same work but making it faster, easier, and less error prone may only be "shuffling the deck chairs", but isn't it still a benefit? Doing the same work but in less time is an obvious benefit.

My bike can get me anywhere my car can. Does a car then have no benefit over a bike?

[kunos]

Which is why I claimed above that IDEs didn't add anything of value in past 30 years.

while I might agree with some of your points.. i have to say you're missing the point of the thread. Sure IDEs can be better just like any kind of software can. But saying nothing has happened in 30 years? That's just not right.

I will take only one feature: intellisense.

You're on some command line crazy stone age tool chain you think is great, I am on VS 2010+VAX, we need to write a new class with a function member using some other class designed and implemented by somebody in our team. You have to go to the file manager and create 2 files.. me I click "add class" and I am done.
Then we get to the .h file.. you have to add your #ifndef WHATEVER #endif pair, your class thing, the public: , the constructor and destructors.. me I am ready to go.. everything is already there.
We write the function declaration.. to the implementation.
You have to find the cpp file, open it and include the header and write the function implementation stub. me.. I am ready to go, everything is already there after a right click using VAX.

Then the function itself.. it uses a class you've never seen before, you know it's there somewhere in your code base.. you start looking for the right .h file to include. Me.. I type #include " and start typing.. good chances with a couple of good words VS2010 will figure out what file i am trying to include... let's move on.
You have to open the header of the foreign class and study it.. find which costructor is good for you.. remember the params and go back to your code... I never left my code, I just write the name of my variable and open a ( .. look at the various costructors provided by intellisense (with doc) choose the one I need and get on with it.
Everytime you need to use a single function of that foreign class you need to switch back to the header, look, find, remember come back and hope u dont get it wrong.. me I just type "." and see what's available.

You see where I am going right? You might be the smartest programmer out there, but if you're fair to consider me at least as smart as you are, you have to accept I will be drinking coffee on my way home with my implementation done by the time you're finished fiddling wtih your hand coded makefile.. hoping that you didn't introduced any error in all the additional hand made additional steps you had to do.

Reiterate this over and over for the duration of a software project and it'll add up to days or week lost just fighting the language when you really shouldnt because there is a technology designed to handle that for you and let you concentrate on what you are actually trying to create.

[BuffaloJ]

Good topic, btw...

I started programming on a Timex Sinclair 1000, Vic-20 and Commodore 64 and have loved IDE's since VisualStudio came out(was Turbo Pascal considered an IDE?). I have been curious why people wouldn't want to use and IDE. For me, having to log out the value of a variable instead of putting in a breakpoint and mousing over the var to see it's value feels like going back to the Commodore. And wastes a bunch of time since I would have to stop the app, add a log statement, run again and get back to where I was in my test. And then needing to see a value 2 lines below and having to repeat the process. Ug

The way I see it,
Pros:
- Breakpoints
- mousing over vars to see value after a breakpoint is hit
- add stubbed out code files in seconds
- having a view of all files in the project at my fingertips and neatly organized for easy searching
- Intellisense
- having clickable options instead of memorizing options and typing into Make file
- IDE marking errors like misspelled words on the fly
- Jump to Definition - being able to goto the def of a class or file even if I don't know where the heck it is or don't want to take the time to look for it
- Interface builders - try writing a decent sized iPhone app purely thru code and see how long it takes.
- Refactoring
- Find in Project
- Data Breakpoints - so useful to find who/where a variable magically got changed

Cons
- I don't have experience in areas where it's not needed, so I can't really list any cons:)

[phantom]

Which is why I claimed above that IDEs didn't add anything of value in past 30 years.

Yes, they help mangle text more efficiently.

The thing is an IDE isn't just about 'text' its about integrating all the tools in one place so they are easy to get at and work together. The standard setup at work for any coder is VS08 + VAX, soon to be VS2010 + VAX as an SDK upgrade is requring us to do so.

How about warning that a change will increase database load by 500 times.
Or that I just created a static dependency on external resource.
Or that change in some external library that requires fixing code in 5000 places is actually idempotent and merely semantic?
Or automated migration between versions, patching changes automatically (Go is working on this).

So the IDE can't do those things, although maybe someone is working on the plugins.

But the features have certainly gotten better; the VS debugger is pretty much the best around and with VS2010 it got better still.

Integrated tools let us do more in the same enviroment; I can write an OpenCL app and spin it up for profiling right in the IDE. I can write an OpenGL app and do the same. NV have tools for their CUDA/Compute work built into the IDE. Intel have multi-threading profiling tools which you can integrate directly into the IDE.

No extra files, no command lines, just click a button and off you go.

That's the power of these things; the fact they happen to make writing code faster/easier is a benifit too but having the tools you need in the same enviroment is also a huge one.

[mhagain]

But none of that is meaningful work. It's shuffling the deck chairs. No matter how efficient, it won't do anything about the ship sinking.

None of these facilities solve actual problems. How does any of these features help me better align the UX experience with target demographic? How does it help reduce turnaround time on reporting? How does it ensure better culture fit across different stakeholders? How do they help me reduce failure rates in deployed software? How do they help me choose most suitable architecture trade-offs given requirements?

All these features do is they help move text around faster. But they don't help with any important problems in a way that choice of better ecosystem would. The "solutions" mentioned above are endemic to Java and .Net which are just absurdly verbose for the trivial and mundane tasks they are solving.

What's your point, exactly? No one is arguing that using an IDE writes good code for you.

The question at hand is whether using an IDE has any benefit over not using an IDE. Doing the same work but making it faster, easier, and less error prone may only be "shuffling the deck chairs", but isn't it still a benefit? Doing the same work but in less time is an obvious benefit.

My bike can get me anywhere my car can. Does a car then have no benefit over a bike?

Seconded; this is meaningful work. Would you rather spend a day doing something productive (like fixing bugs or adding new features) or spend that same day renaming functions? I know which one I'd pick, and any tool that helps me do the boring drudge work faster, safer and more efficiently is a good tool in my book.

[Hodgman]

The situation is a bit different when working as part of a team of 20 on a many-million-line project, plus another 20 authors who no longer work there, plus a million lines of middleware and other external libraries mixed in.

Well, I am not working in a team of 20 people, and I do not have source-code from 20 ex-employees, so even though the situation would indeed be different if that had been the case, it's utterly irrelevant.

Irrelevant to what?
Irrelevant to you personally? -- I didn't say "your personal experiences are disproved by this other category of experiences", or "you should change your personal practices because they don't scale in other environments", did I?
Irrelevant to the discussion about IDE usage? -- Isn't explaining situations where they're useful just as relevant as explaining situations where they're not needed?
I don't even...

Being able to quickly explore and comprehend a foreign code-base is a very important feature in the real world.

That's funny because despite the fact that I don't work in a team I am pretty sure I do live in the real world, and reading the documentation for the SDKs and 3rd party tools I use has always eliminated the need to manually explore the source code in order to figure out how it works. As a matter of fact, I would recommend you begin doing the same. (Trust me; it's much faster!)

"the real world" is a common pejorative for "the business world", no need to be offended.
Regarding comprehending foreign code-bases, this is still important whether you have a need to read the source of your middleware or not. The code written by the rest of the business is going to be foreign to you.
However, having to maintain/edit middleware is a common task, so I was obviously referring to this need, not the need to read documentation.

But none of [those features perform] meaningful work.
How does any of these features help me better align the UX experience with target demographic ... reduce turnaround time on reporting ... ensure better culture fit across different stakeholders ... reduce failure rates in deployed software ... choose most suitable architecture trade-offs given requirements?
All these features do is they help move text around faster.

Solving any of those problems simply involves moving text around, ergo...

[e‍dd]

You'll have to tear vim and a console window from my cold dead hands

Having had to go back to VS for a new job has been a less than pleasant experience so far, but perhaps I'll get used to it again. All IDEs seem to be 'optimised' to make uncommon tasks easy, but actually writing code is painfully slow compared to vim.

The only time I'd choose to use an IDE is when I need to do serious debugging. And that's rare these days as if I ever find myself in need of a debugger I give myself negative marks for not writing my code clearly enough to spot problems at a glance, or not adding sufficient asserts and tests to catch any non-trivial cases in the first place.

OTOH, it's not too much of a stretch to call vim an IDE given all the plugins and scripts that are typically bolted on top... most of the IDE features mentioned herein so far I have available in vim in some form or other.