What is an IDE Friendly Language and What is my Problem with IDEs
Sergiy please note I am not suggesting that IDEs are not productivity enhancing and useful to you. Nor am I even suggesting they are not to me. If I was programming Java, I would be using an IDE. I would be using it if I was programming Swift. As an IDE I actually quite like XCode, it is one of my favorite IDEs. I simply don’t love IDEs. If I can pick languages which reduce the need for an IDE I will.
I hope you don’t take offense for me saying this, but some of the things you are responding with here seems based on speculation and not actual intimate knowledge with the situation. Let me take some examples.
There were just no enough demand for Objective-C and Swift IDE.
I am not sure you know the history of Objective-C here. Some of the first mainstream rapid development environments existed for Objective-C on the NeXTSTEP platform. The Project Builder and Interface Builder development environments where years ahead of the competition. It is not without reason that the first Web browser was made in this environment and this is where the DOOM game and its level editor was made.
By the time Swift came around XCode was a very mature product. I think a lot of Java guys get a bit hung up on IDEs being about refactoring. They are about a lot more than that. If it was only about refactoring, you could really have been fine with a sophisticated editor. It is also about integrating debugger, benchmarking tools, testing tools, GUI editors, GUI testing tools, managing compiler setting, project dependencies. I have never used a Java IDE which could hold a candle to the GUI designer in XCode and its integration with the rest of the Development Environment and code editor. XCode also has superior project management, performance measuring tools etc.
I think you are trying to make the case that XCode is some kind of toy IDE, but I reject that. Yes sure it is not nearly as good as Java IDEs in refactoring but development is about a lot more than refactoring and I find that XCode excel in other areas. Otherwise I would have switched to JetBrains tools instead. The problem was that while their refactoring was superior, their other tools where not.
“Designed for IDE use” is something unknown to me. Smalltalk was not designed for IDE either.
Again you seem to be speculating. Do you know any of the history of Smalltalk or have you ever actually used a Smalltalk IDE or know how Smalltalk as a language works? The worlds first GUIs came out of the development of Smalltalk. Graphical user interfaces and Smalltalk was intervowen from the very beginning.
Smalltalk was indeed designed for IDE use and still is like that. Smalltalk has no system for defining dependencies between files. There is no syntax for defining a method as part of a class e.g. A lot of the syntax existing in other language such as Java, does not exist in Smalltalk because it is part of the IDE tools. If I want to add a method to a class in Smalltalk I cannot just jump to some arbitrary location and type in the method code like in Java or any other “normal” programming language. No, you got to press a button in the IDE to do that. Same thing if you want to add a class, or create a category for methods. Why? Because Smalltak programming is not editing plain text files. There are no “source code” files. In Smalltalk you continuously manipulate a live image with an IDE. That is why Smalltalk IDEs are superior.
A Java IDE will have to parse source code files to create some kind of live representation of the code, and cross all fingers that this representation actually matches the code that will get built and run. This representation is basically an in-memory database of classes, methods and their relationships. In Smalltalk in contrast you are essentially directly manipulating this IDE syntax tree representation, rather than writing source code which has to be parsed. Yes individual code snippets have to be parsed but inserting a new method or class is an IDE operation. Code is also immediately parsed and its syntax tree added to the database, thus making everything live. What your code is at runtime and how the IDE sees it is essentially the same thing.
Strictly speaking with such a platform Smalltalk could be replaced with another language without loosing properties of the entire system.
No you couldn’t. Yes there are other language which could work, but you cannot take an arbitrary language and do it. Java, C++, C#, Rust etc would not work. For the Smalltalk approach to work you need a dynamic language of some kind, as the power comes from the fact that all the structures of the code are live. The whole system is available at all times. The IDE itself is typically part of the Smalltalk image, so you can modify the the IDE as you are working in it and those changes take effect immediately.
Most IDE’s have identical basic key’s (cursor movement, block selection, cut/copy/paste) and similar (or configurable) set of extended keys.
Come on! I have used plenty of IDEs, you don’t need to be telling me this. Usually what we are talking about are the more advance parts. How you do navigation, completion, macros, plugins, snippets, multi-cursor editing etc. These things will usually differ a lot. With e.g. TextMate because I have use it a lot I can easily extend. Sure you can extend most IDEs too, but that tends to be limited to the language the IDE was made for. What I like about TextMate e.g. is that I can write plugins in any language I like. So because I am good at Julia, I can write a plugin in Julia. If I used a JetBrains IDE to program say Go, they tough luck trying to use Go to extend it. You will have to use Java, whether you are a skilled Java developer or not.
Go and Rust have quite good IDE’s — GoLand and Rust plugin for CLion (quite good, BTW). So, it’s not true that IDE’s exist only for “old” languages.
I cannot comment on the current state. But each time I tried Go plugins for IDEs in the past, they offered nothing I could already to better in a good coding editor. Things like code completion or refactoring was no better. Today Go and Rust are getting quite mainstream. But for something like Julia which is a lot newer I think an IDE will typically just get in your way. I see how people used to using an IDE, really get hamstrung by trying to use a IDE oriented workflow with it.
Yes, I know that there are language servers and command line tools for performing refactoring. But most of them quite inconvenient in setup and configuration, connecting them to editors takes a lot of efforts and resulting usability is still worse than with IDE.
Sounds like you had some unlucky experience. That has not been my experience at all. E.g. in Atom or VS Code it is usually quite trivial to add a language server. Go refactoring tools work out of the box in my experience.
With IDE one gets everything configured, integrated and smoothly working out of the box.
Only because you are using the IDE with the one language it was designed for. Tough luck if you want to use it for a nother language it was not designed for. Then an advance coding editor is a much better pick. It gives a more versatile tool better fitting for people who jump between multiple languages.
And what you call “monoliths” are just pre-configured bundles of components. Needless to say that these platforms are at least as flexible as most popular editors or even more flexible.
Okay, I will have to clarify what specifically I mean with monolith. XCode in its current incarnation is much like you describe. It is made up of various plugins. Yet as it now stands it is far more of a monolith by my standards than previous incarnations. Why? Because previously many of the tools where seprate programs such as Interface builder. Because interface builder was a separate program it was made to be easily launched by other tools and open in specific configurations. This made it possible for people creating Ruby development tools to integrate their workflow with Interface Builder. People could use an entirely different code editor and still be able to use Interface Builer to edit user interface files it used. When XCode became a monolith this became impossible. Using interface builder as a standalone tool for other language setups and development workflows became impossible.
Likewise I cannot rip out the Eclipse Java debugger and use it in another setting than Eclipse. All these parts are tightly integrated. They cannot live separate from each other. If you don’t want to be monolith, then you need loose coupling between the individual parts so they can easily be reused in other context. Modern IDEs don’t have loose coupling. Everything is very tightly coupled. Even plugins tend to be highly language specific.
Compare this with e.g. TextMate which tried to make a truely loosely coupled system, which meant the library of TextMate plugins built up over years got reused by entirely different editors later.
I see no reason to limit myself to any set of tools, so I feel comfortable in many editors as well as in many IDE’s. Same is true for languages.
Me neither. I also use IDEs. And in some languages there is no better option. I am simply stating a preference for non-IDE based development when possible. I don’t necessarily have an issue with various tools that exit in an IDE. Refactoring tools, project management, GUI designers, debuggers etc are great. However if possible I greately prefer these tools to be standalone rather than tightly integrated into a single monolithic IDE.
Yes as discussed earlier, I know they are built from plugins. But this is just as much about the reality you present to the user. As discussed in my article criticizing IDEs, the key problem is the complexity created by integrating that many tools into one program. E.g. when XCode and Interface builder was separate tools I found them easier to manage as when I switched to Interface builder the interface is then entirely focused on GUI design. All the menu entries, buttons etc is related to that. Once you integrate, you create a more complicated spagetti.
It is one of the reasons I like TextMate a lot, is because it is quite good at cleanly separating the various plugins also at the GUI level, something I don’t think VS Code and Atom is very good at.
I am a Unix guy at heart. I believe in the philosophy of small simple tools which can easily be used together. I don’t believe in the monolith philosophy of gargantuan integrated applications. I have spent much of my career making applications like that, which made me increasingly convinved it is entirely the wrong way to go about software development.
There has been operating systems such as Plan9 and BeOS which has tried to show us an alternative way of building software more in line with this vision, but which sadly entered the world too late and made other mistakes. E.g. in Plan9 even windows where represented as files in the file system which you could easily communicate with, with standard tools. In BeOS your view of email message was simply your file manager showing extra attributes such as “from” and “two” on each file.
Sorry this reply got quite long. You just got me into writing about something I am quite opinoate and passionate about.