State of the Art in IDE and Language Integration
Well certainly some features do have tools in mind. E.g. type annotations in Python very much is intended to help tools like an IDE.
I am not much of a Java developer myself but I have spent a lot of time with Objective-C and Swift. One of the reasons I have found it interesting to keep up with Kotlin is its greate similarity to Swift. I guess because they got developed in similar time frame when the general opinion of what a statically typed language should look like has coalesced around many similar ideas.
In Swift we certainly have a number of features meant to aid the IDE such as @IBOutlet which helps tag variables you want to connect to something in the UI design.
Interesting language to explore for those interested in IDEs
Actually if you have a great interest in advance IDEs and their relation to languages you should check out Smalltalk if you haven't already done so. I don't keep up much with smalltalk anymore but I think state of the art today is Pharo Smalltalk.
Event though the opportunities for professional work in Smalltalk is not that great, it is still an interesting environment for anyone interested in technology. Smalltalk is sort of the original language designed for IDE development. In fact there is no way of developing Smalltalk in another way. Smalltalk is not text file based like Java, C# and most other languages today.
Basically you use an IDE to add objects to a database (the Smalltalk image). Below you see browsing methods in the IDE. You see methods are listed in a the GUI. There is no separate file the methods are clustered in. Methods belong to categories under classes. In fact you can kind of move them around as if they where objects.
In Smalltalk everything is an object, so you can see that the Boolean values False is in fact a class with methods.
What is interesting with Smalltalk from a geek or technological point of view, is that it is a dynamic programming language with a advance IDE features, because everything you do is always live. The abstract syntax tree of the code you write is basically there all the time, which means anything and be introspected and moved around with the IDE.
The IDE itself is usually written in Smalltalk and not clearly separate from the rest. Meaning you can use the IDE to also alter the code of the IDE on the fly. You can thus easily extend and modify the IDE to suit your needs and this happens instantly. There is no complicated building and packaging step because this is a dynamic language.
I used to be an IDE guy years ago, so Smalltalk fascinated me. But I kind of hate IDEs today, so I have not bothered to explore Pharo Smalltalk further. Although the capabilities there seem way beyond what I had when I played with Smalltalk.
Git History at the Granularity of Individual Methods
One interesting example of what this IDE centric language design give you is features such as version control at the method level. Rather than look at the history of a whole file, you can look at the history of individual methods if you like.
Smalltalk is of course not made for file based development, which was long an issue integrating with tools such as Git. But I believe what Pharo has done is to create a special layout and format which they export to your use internally that is setup to work with Git and then they have their own tool on top of Git to be able to browse history.
Why am I Mentioning All This?
So, why I am a writing about all this if I don’t really care about IDEs? One of the key issues I have with IDEs is the time of investment required to fully utilize them.
But I do find it fascinating to read about what is possible with them and learn about people who use them and what they are capable of doing. I have always been curious about how Smalltalk style IDEs stack up against traditional IDEs. The people who usually write about these have been long time Smalltalk users and cannot compare well with other tools.
It would have been interesting to read at some time, what somebody experienced with a more standard software stack would think about this kind of environment.
It is hard to come across such experiences these highly productive languages and environments such as Smalltalk, LISP, Rebol/Red etc are such niche.
My understanding is that highly productive languages don’t scale to larger teams. I think e.g. Smalltalk developers tend to make highly personalized and tailored environments for their work. E.g. they modify the IDE to fit the task they are working on. And this probably doesn’t scale to teams for 10–20 or larger. It is more for teams up to maybe 5 people.
