

Beware the IDEs - rbanffy
http://www.sicpers.info/2015/04/beware-the-ides/?1428369959718=1

======
MichaelCrawford
I have long had the impression, that those who dislike IDEs only really know
products such as Visual Studio or Eclipse, rather than Metrowerks CodeWarrior
or ThinkC.

The simple fact that a tool is an IDE doesn't make it good or bad.

I have long preferred IDEs for development on Apple platforms but lately I am
working towards moving my iOS development to makefiles with Vim and
TextWrangler because Apple's Xcode IDE is so profoundly poorly designed and
implemented.

I'd love to have codewarrior for iOS development but they no longer support
Apple platforms.

~~~
quesera
> Xcode IDE is so profoundly poorly designed and implemented.

That's some strong criticism.

I loved Lightspeed/THINK C and Metrowerks CodeWarrior. I also have a generally
positive opinion of Xcode (which might be even higher if I was remembering it
from 20+ years' distance, instead of dealing with version-version
inconsistencies and incremental bits).

It's unfortunate that having a good, free, first-party compiler inevitably
sucks the oxygen out of any competitive market. But there were some lean years
in the Mac compiler world, and I'd never want to go back to that.

That said, I use vi for _everything_ else, including lots of non-Cocoa code. I
would be completely happy to do Cocoa dev in vi also, if it could be as
functional as Xcode. I'm very interested to hear more about your retooling
experiences!

~~~
notduncansmith
Xcode is a decent tool for new programmers. Also, features like Cmd+Click (go
to definition) can be a huge boon when dealing with an unfamiliar codebase.
That said, for anyone used to using "text editors" (Sublime, Vim, Emacs, etc)
it is sorely lacking. I'm not afraid to say that text editing in Xcode is
barely more tolerable than a standard web textarea in that respect. It's
sluggish, prone to crashing (or losing syntax highlighting), and often
displays errors in the middle of typing an expression (which linger for a bit
until the inline parsing catches up with the entered text, a process that may
take several seconds). This, coupled with the limited text-editing ability,
make it very painful to use coming from a text editor.

In my personal opinion, the worst part of the iOS development experience is
the fact that one is forced to use Xcode to get any clear preview what the app
will look like, or to set up connections between a view and the viewcontroller
code. One can of course lay out views programmatically, but that process is
hilarious verbose and the slow build times make the workflow infinitely more
painful than say, HTML+CSS (where one can get sub-second feedback on code
changes). This makes any sort of visual/UX work on iOS incredibly painful.

P.S. If anyone has any tips on how to mitigate either of these pain points,
I'd greatly appreciate it! I fully admit that I'm not an expert and may be
overlooking some critical feature that would erase these pains.

~~~
quesera
I agree completely with your criticisms of Xcode, but I don't find those
problems all that bothersome. I like to think of Xcode's syntax checking and
highlighting as "eventually consistent".

The text navigation aspect does foul me up at times. There's an Xcode plugin
for vi-style navigation, which I've used and removed several times. It's OK
but incomplete, of course.

Xcode as a package includes IB and the debugger and profiler, etc. I'm not
convinced they need to be so conjoined, but switching to vi for code editing
while still using Xcode for the rest doesn't seem like it would be an
improvement over the current workflow.

Xcode does a much harder job than an editor plus a web browser. I do miss the
round trip efficiency sometimes.

~~~
notduncansmith
> I like to think of Xcode's syntax checking and highlighting as "eventually
> consistent".

This made me laugh, but I suppose I've been spoiled by the responsiveness of
text editors. Honestly I wish there were a way to turn off the error checking
without losing autocomplete as well.

> switching to vi for code editing while still using Xcode for the rest
> doesn't seem like it would be an improvement

Agreed - I tried both Sublime and vi alongside Xcode, it's just as (if not
more) cumbersome than Xcode alone. I wouldn't even really mind the
sluggishness of Xcode if it offered the same text editing capabilities (multi-
cursor support, etc) as Sublime. At least then the problem can be reduced to
buying a beefier machine.

~~~
MichaelCrawford
QuickLetter from Working Software ran just fine on an 8 MHz Mac Plus with 4 MB
of memory. I expect it would have been able to run, perhaps not acceptably but
it would have run, with just 2 MB of memory.

It had a full-featured styled text engine - fonts, tabs, margins and so on. It
was built on the same CoreEdit styled text engine that MacWrite was. The very
first MacWrite, I'm pretty sure ran on the 1984 Superbowl Mac - that model was
later given the name "Mac 128k".

The Mac 128k had a 64kB ROM and single-sided 400kB floppy disk; there was a
port for an external 400kB single-sided floppy however most folks didn't have
one as the drives were quite costly.

Fast forward to today, and I have a 64-bit Core Quad i7 CPU, a 500 GB SSD
drive, 8 GB of DDR3 memory, and all the advances that academic computer
science has made in the way of algorithms but even so...

it is quite uncommon that I don't regard a GUI program - open source or
proprietary - as unacceptably unresponsive to my mouse or keyboard.

Consider Moore's Law. I don't think he actually said that hardware doubled in
speed every 18 months, rather that the transistor count per chip doubled. But
loosely speaking that produces the effect of hardware getting twice as fast.

It is incredibly difficult to double the transistor count on an already
complex chip.

How hard could it possibly be - to make your executable code run half as fast?
:-/

------
collyw
Out of interest, do those who don't use IDE's use a step through debugger?
This is my main reason for using one, plus I quite like being able to set
things up and just press a button, rather than type a command every time I
want to re-run my application.

~~~
notduncansmith
Coming from a Node.js background, I use a text editor, and debug with Chrome
using node-inspector. In other languages (Ruby, Elixir, Clojure), I just debug
with print (and make heavy use of the REPL). As for buttons vs commands, I
suspect that's largely a preference thing (believe me, I thought hard about
refuting the buttons because I personally dislike them, but eh, different
strokes). I have shell aliases for most of my common commands, and if
something needs to run continuously or on save, it's pretty easy to write a
script or Gulpfile that'll do that for me. For anything else, it's uncommon
enough that it'd be a menu item (hopefully!) anyways, not a button, so I'm
unlikely to see any effort savings from using an IDE vs the terminal.

~~~
collyw
Yes, I have a few shell aliases for commands with a load of parameters I use.
I suppose setting up Eclipse versus writing a few aliases is probably about
equivalent.

Debugging with print can only get you so far. I use Django which is a big
framework, so I couldn't understand the code without a proper step through
debugger. I would say its been essential to get to the understanding I have
now of forms and class based views.

~~~
notduncansmith
I agree. Beyond the preference aspect there's definitely a notion of using the
right tool for the job - and in an unfamiliar codebase (e.g. one that relies
on a heavy framework like Django filled with thousands of lines of code I've
never seen), as I mentioned before an IDE can be of significant benefit. That
said, once one has grokked the framework to a fair degree, I would imagine
that continuing benefit (in that respect) would be quite limited.

------
M8
Tell me automated refactoring and code exploration via ReSharper or Roslyn or
IntelliJ IDEA doesn't speed up development AND maintenance :).

------
adamnemecek
fresh perspective. for your next article you should write about emacs vs vim,
that territory is also very unexplored. /s

~~~
MichaelCrawford
The reason that I myself prefer vim, is that Emacs Makes A Computer Slow.

;-D

