What is an IDE if not Integration of Multiple Tools?

I was not really suggesting that ProjectBuilder and Interface Builder was all alone. But they stood out in their time. You cannot find the wealth of old war stories from people using VisualAge. I certainly have no recollection of them while I have met plenty people over the years who had used a NeXTSTEP machine and marveled at its development environment.

It is somewhat an ironic turn on this exchange, that you are pushing the CLI tools in this exchange. The IDE guy who primarily cares about the editor and debugger part. One may question at that point really what makes an IDE different from an advance editor. Many have exactly this capability. Although I agree the distinction between a powerful coding editor and an IDE is at times blured.

Benchmarking GUI Tools

I find it somewhat odd that you don’t see a role for GUI tools dealing with things like benchmarking or testing. This is performance testing of an iPhone app using Intruments. Surely having a graphical interface you can drill into and visualize performance must be and advantage?

Measuring performance with instruments

Testing Tools

Testing is of course also more than simply running some unit tests. You also might also want visualization of results, look at continous integration results.

As I have said, I am not a huge IDE fan, but I use the tools at my disposal when doing particular types of development. When working in XCode having a GUI integrated with the tests where I can easily click tests to run, review failed tests etc seems like a nice bonus to me.

XCode GUI showing availble unit tests and status after executing them.

Or how about visualizing code coverage?

UI Tests

Testing is also a library thing, although ability to run or debug one or many tests is definitely a part of IDE.

A bit surprising statement from someone praising the wonders of IDEs but who seemingly don’t seem to cheerish very many of the opportunities offered. When doing UI tests e.g. I find using the GUI of the Xcode IDE to be a great advantage.

Recording GUI interactions as code into test cases in Xcode

It has been a while since I did iOS development but I remember testing the UI was a pretty difficult job and having the ability to record interactions as code in the IDE was some pretty amazing stuff.

Where Am I Going With This?

Why am I elaborating on all these different tools? What point am I driving towards? The point is that you try to invalidate my claim that I prefer Text Editor and terminal based development over IDEs. Your assumption the whole way from this is that I have used only second rate IDEs, which do nothing and has thus never really experienced the power of an IDE. Ironically watching your response here I almost wonder if it is the opposite.

GUI tools are irrelevant for me and a majority of backend developers, so I don’t consider them as necessary part of IDE and really don’t care who should hold a candle to whom.

In other words you have been expose to only a small fraction of the functionality an IDE can offer you. It might actually be then that I have actually utilized IDE functionality more broadly than you. I am not trying to make this into a pissing match. I just want you to accept, that a person can have had extensive experience with IDEs and still prefer not to use them when possible.

Yes when doing iOS development and coding in Swift, I like my Xcode. I still regard Xcode as the best overall IDE I have used. Yes I am fully aware that it is not strong in refactoring, but it is about the whole package. Xcode have a lot of tools to improve you productivity that matters a lot more in the end for a mobile developer than refactoring tools IMHO.

Smalltalk and IDEs

That’s why I don’t understand why you write that it was designed for IDE use, if there were no IDE’s and there were even no GUI at the moment when the language was conceived and implemented.

I honestly cannot make any sense of this statement. Why would the IDE have to exist before the language existed? That is like saying a C compiler could not be written in C, because the language must have existed first. Come on this is bootstrapping. Smalltalk went through several incarnations, derived from mutations of a series of smalltalk images.

The Smalltalk that the world knows is tied to an IDE. Basically nobody programs Smalltalk without an IDE. It is image based development. What other way would you do Smalltalk development besides an image? No Smalltalk book I ever read describes a project with files. How to import code by including other files like traditional development works. No, you are in an IDE always.

There is nothing which prevents to implement the same model of code manipulation with another language.

Of course there are countless problems with picking a random language for this purpose. Try doing image based C programming. Good luck with that.

Of course, not all languages would be equally convenient in this role, but Java definitely fits here.

I am not convinced at all of this, although it takes time to really reflect deeply upon the possibility of this. However I can see several problems.

Java is a statically typed language, that means you must know the type of anything you use. Yes sure you Java got reflection, but that offers an extremely clunky interface. Every line of Smalltalk code is basically doing something akin to using some reflection library in Java. Imagine how insanely verbose and clunky the the Java code would be if every method call you made and every object instance you created was through a reflection API?

In image based development, you can in principle change any object or type. That plays very poorly with a static type system. Statically type languages have elaborate and complex build systems because they need to know where all their types come from. No type is allowed to be unknown. If it is unknown you must access it through a clunky verbose reflection API.

bar.doStuff(foo)

Consider the simple case above. In static language like Java, the compiler must know that bar has an interface with the method doStuff which takes an object adhering to some specific interface.

Imagine if I change the class bar belongs to so it doesn’t have a doStufff function anymore. Oops now you are screwed. Java isn’t based on message passing so trying to call a method that doesn’t exist on an object I can imagine will blow it quite badly. But honestly I don’t know Java well enough to speculate exactly on how Java handles this.

Finally, one of the reasons Eclipse introduced their own compiler for Java was a need to parse parts of the code on the fly, so internally Eclipse does exactly the same as Smalltalk IDE.

I have already remarked on Java IDEs doing this, and I pointed out this as a problem. You have two seprate views of your Java code. There is only one view of the Smalltalk code. What the IDE sees and what happens when you run it are the same thing. I don’t use Java enough, to tell but from what I can seem to remember it is not infrequent that the IDE view of the code and what the build system think of it gets out of sync.

VS Code vs Visual Studio

Also, Atom and VS Code are quite heavy once all necessary parts are added. So, again there is no point to use them.

I never said my primary reason to use a Text editor oriented workflow was because IDEs are heavy on the system. Although I guess you may have gotten that impression from my characterization of them as bloated. What I primarily meant by that is complexity in usage. The sheer number of integrated tools.

While among the more complex editors Atom and VS Code are still very editor focused in how their UI is designed. I remember last time I was doing some C++ development on Windows. Not sure what possessed me to do that. I used Visual Studio briefly before getting annoyed at its idiosyncrasies and complexity. Ironically it was much faster to get C++ development properly setup and working in VS Code. Despite the fact that Visual Studio was pretty much designed for that.

Visual Studio must to me be the ultimate example of the sickness of modern IDEs. An diareah of icons,menu entries, panes. You would almost expect the whole thing to cave in on itself. Sure JetBrains does a pretty good job, but you cannot pick among the best of IDEs to claim they are to be representative of what an IDE is like. We cannot forget that things like Visual Studio, Eclipse and others exist.

Do IDEs Need to be Universal?

IDE was never positioned as something suitable for any language, so there is no point to blame them for the lack of universality.

It most definitely is! Say I tell you I prefer motor bikes. Then you tell me SUVs are better. As a reason for preferring motor bikes I mention that I like them because I drive a lot through narrow alley ways. You cannot then object by saying “SUVs where never designed to drive through narrow alley ways!” Well duh! Of course that is the whole point! I have preferences for Text editor and terminal based development because they do things I prefer doing when I develop. If IDEs are shit at doing these things that I do, then that is a perfectly valid reason for me to dislike them.

As I have repeatedly stated, but which I am not sure has sunk in with you, I am not making some universal claim about coding editors being better than IDEs. No, I am making a very specific claim:

I personally like text editors over IDEs because they suit me better with respect how I prefer to develop code. I am a language guy, not a tools guy. I prefer a more modern language over a better tool.

That companies are increasingly making more plugins for different languages doesn’t really change that. So what? I developed my preference over some 25 years of development where that was not an option. I think I have used TextMate now for nearly 20 years. In that time I have seen countless IDE fall in and out of fashion. I am tired of wasting energy on aquireing skills that go out of date. I am not getting younger.

Besides as IDEs have become more flexible in supporting more languages coding editors have started to acquire a lot more IDE features. The prevalence of language servers is seeing to that.

Of do the same with GoLand or CLion. The integration is pretty smooth. The only limitation is the lack of debugging in IDE’s other than CLion

I admit my knowledge on this is not up to date. But a lot of what I have seen of IDE plugins for various languages doesn’t impress me one bit. The they add so little functionality that you will be much better off with a nice code editor. I tried a Go plugin at various times years ago, and I could see no benefits to using an IDE. It gave me absolutely nothing I didn’t have in TextMate at the time. Only difference was getting the same functionality with a more bloated interface I was less acustomed to. So what is the point?

What is True Modularity?

while I understand what you’re talking about I don’t think that only true modularity is the “set of independent binaries”.

There is not correct answer to this question. I am simply stating a preference. I see this as better from a UI design perspective. Each application gets a smaller and more focused interface. And I see the benefit from an ease of integration perspective.

Most editors and many other tools assume that modularity does not contradict to the presence of the common platform. And this common platform not necessarily should be Unix pipes or files.

Unix pipes and environment variables is a very well established technology. It is something every language understand how to work with. It makes is trivial to write a plugin in almost any language. As someone who who has a passion for new programming languages instead of passion for new IDEs, having that kind of flexible choices is awesome.

This paradigm has stood the test of time because it is flexible and robust towards change. Look at these ancient Unix tools that have stood the test of time. Why? Because they use simple text based interfaces. Binary interfaces are brittle and never really last.

A platform based on a rich binary interface is not a receipt for a something that will last through the ages.

I will not claim to know JetBrains and their plugin model well, but what I have seen thus far looks quite complex and complicated. What I looked at had a build script of some 150 lines of code which had to be stitched together by looking at various blogs only understanding a fraction of what all the lines meant. Tons of Java source code.

Adding a plugin to TextMate is ultra simple in comparison. There is not build process. I can develop it and try it out as I am using TextMate. I could test the plugin entirely separate from TextMate as all I need is to communicate with stdin, stdout and environment variables, which any Unix guy knows how to setup.

To repeat myself, I am a Unix guy, I like small versatile tools, with simple plain text interfaces that I can easily integrate. I don’t want complex binary structures. Complex build systems with elaborate dependencies defined. No, I want interactive playful environment where I can rapidly iterate and experiment. Not everyone is like that, but that is how I am. That is why I don’t prefer IDEs. It isn’t because I am clueless. I just have a different preference from you. I value different things.

Written by

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store