
The IDE As a Bad Programming Language Enabler - vanwilder77
http://developers.slashdot.org/story/12/10/30/065244/the-ide-as-a-bad-programming-language-enabler?sdsrc=popbyskid
======
knightni
I've used a wide variety of languages, and I've yet to encounter one that
wouldn't have been better with good IDE support.

I like having the ability to refactor quickly, to hop to method definitions
with ease, to have a quality integrated debugger, and blah blah blah. A good
language might make some of that less _required_ , but it doesn't stop it
being useful. And, really, if an IDE is required for a language to be useful,
but once that IDE is in place the language _is_ useful, why would you not
consider language + IDE an indivisible pair? What real relevance does it have
that the language on its own is not that great?

Java + Eclipse is Perl + CPAN, or JS + jquery/dojo. Something you have no
business criticising unless you've made the effort to use/understand it in its
whole.

Java isn't a great language, but Java + Eclipse is really quite tolerable. The
majority of people I've known who really _hate_ it (as opposed to the usual
sense of vague frustration that obvious improvements haven't been made...) are
people who are unwilling to adapt themselves and their tooling to fit.

------
peq
Having IDE support is a feature of a language. You have to design your
language so that IDE support is possible [1]. Most dynamically typed languages
and functional languages fail in this regard and if you use such a language
you always are jumping between API docs and your editor.

[1] <http://blog.efftinge.de/2011/04/dear-java-killers.html>

------
Uchikoma
Interesting how people without good IDE support rationalize things.

~~~
alinajaf
Interesting to note how people without good programming languages rationalize
things.

~~~
scanr
What happens when you have a good IDE and a good programming language?

I say we have both!

~~~
facorreia
That's why I mostly stick to C#.

~~~
AndrewDucker
Yup. Great language, awesome IDE.

------
smoyer
My only question is whether Faler switched to vi or emacs when he ditched
Eclipse. If we're going to start flamewars with broad generalizations, perhaps
we should do it properly (hmmm ... it appears I can troll effectively on HN
without an IDE).

In the mean-time, I'd recommend the use of a good IDE and extensive test suite
when you're refactoring. Use whatever you like (or are fastest in) when you're
producing new code.

------
hayksaakian
When I jumped from android dev to rails dev I was hesitant to using sublime
text instead of a true IDE, but now I hesitate to go back. With a good
language you don't have to scroll though an auto complete to find the exact
method call you want, good conventions enable me to often guess what method or
class I want without ever having encountered it prior.

------
rbanffy
LTOA: [http://www.recursivity.com/blog/2012/10/28/ides-are-a-
langua...](http://www.recursivity.com/blog/2012/10/28/ides-are-a-language-
smell/)

------
Strilanc
We are in a world where computational and networking resources are absurdly
cheap and abundant, compared to the past. Why shouldn't we design languages
and environments that take advantage of this fact?

Designing a language that leans on an IDE, or other forms of tool support, is
not bad. Analogously, designing an application that leans on having an
internet connection (e.g. put documentation in a wiki, Go's URL imports) is
not bad.

You can put together a GUI using only textual code in a text editor, but
you'll do it faster and better with the help of live previewing and typo
underlining.

------
michaelochurch
Not just bad _languages_ but also bad _processes_ and, I would argue, bad
_programmers_.

IDEs are a good tool that (a) won't venture into some places that a good
engineer needs to go, because to be decent at the job you really do need to
understand the command-line interface, and (b) is very often put to bad use.
I've developed the reputation of being an inveterate IDE-hater, but even I
have to admit: abstractly, they _are_ a good thing. They're an attempt to
solve a very hard problem (code comprehension) and the reason why they fail
(by which, I mean that they tend to reduce the overall quality of the software
environment) is not that they are intrinsically bad, but that managers tend to
use them as license to hire weaker programmers and launch larger and more
poorly-thought-out software projects, and IDEs can only go so far. It's like
idiot-proofing: someone will design a better idiot.

The real problem is the horde of untalented, tasteless programmers and the
clueless management that most software organizations hire, not the IDE itself.
IDEs have just become, unintentionally, a symbol of How The Other Half Codes.
There's nothing wrong with the tools themselves (although it is a bitch to
support them if your environment has a lot of wonky in-house plugins).

There's also a Blub-like problem where people use "IDE" to mean "more featured
environment than I'm used to", with the tacit assumption that "more featured"
is a bad thing, because it's believed (and, sadly, often correctly) to be
compensating for tasteless programming. As with Blub, IDE isn't even a well-
defined term. Is SLIME an IDE? You could make a strong case for "yes", but
you'll get flamed if you call it that because good programmers (rather than
"IDE programmers") use it.

What are IDEs good for? Hell is other peoples' code, but reading other
peoples' code is still a necessity. In the real world, we can't just throw out
millions of lines of software because the code is tasteless. We often have to
try to make use of it, and IDEs give us a fighting chance. This also explains
the negativity toward IDEs. The one thing they are really good for (reading
low-quality code) is something engineers hate doing.

IDE-dependence is evil, and bad code is evil, and IDEs only compensate
partially. Having good processes, competent engineers and management, and
writing high-quality code are all a lot more important than whether you use an
IDE or not. In the real world, you probably want to have the IDE as an option
because, even with everything going well, pockets of gnarly code are
inevitable. Even Google (which has its faults, but its code quality is
superior to most corporate environments) has a read-only IDE, served over the
web.

One thing I would love to see is for Github to turn itself into a read-only
IDE, with code navigation by link. The truth is that a read-only IDE provides
all of the benefits of an IDE (except for interactive debugging, but that can
be provided at the command line). While automated refactoring is slowed down
in an non-IDE environment, that's actually a good thing. If a change is going
to affect a large number of interfaces, there's a discussion that needs to
happen. The 30 minutes that it takes to write the script that does this is a
trivial cost in comparison to the communication effort that a major,
potentially world-breaking, change deserves. So I'm a major fan of the "read-
only IDE" concept.

~~~
kstenerud
"won't venture into some places that a good engineer needs to go, because to
be decent at the job you really do need to understand the command-line
interface"

This is only true if the IDE has not kept up with the command line interface.
Visual Studio and Xcode do pretty much everything their CLI can do except
maybe some tool integration like CI or deployment. But that's operations, not
programming.

"IDEs are a good tool that ... is very often put to bad use."

So is every other tool out there. What's your point?

"The one thing they are really good for (reading low-quality code) is
something engineers hate doing."

They are also good for:

\- Writing good quality code.

\- Looking up methods.

\- Code completion.

\- Code navigation.

\- Interactive debugging.

The list goes on.

"IDE-dependence is evil"

No it is not. You might as well say static analysis dependence is evil or
compile-time optimization is evil or profilers are evil or any other
convenience is evil. Should we all remain puritans and suffer cryptic and
unwieldy tools just because making them more powerful and friendly also makes
them more powerful and friendly for bad programmers?

Bad programmers will write bad code no matter what tools they use. Blaming the
IDE is disingenuous and quite frankly comes off as arrogant and elitist.

------
Toshio
HN submission linking to Slashdot submission of a story that has already been
discussed on HN ages ago.

What was the name of that movie again?

Oh yeah, Inception.

~~~
ww520
Reposception

~~~
stcredzero
Lipo-?

------
kicktheshoe
This must be setting a new record for an old article.

~~~
nsns
\- and the Redditization of HN comments...

