We at JetBrains are doing research aiming to design the next-generation software development stack, able to answer the challenges posed by the rapid advancement of AI.
One of the ideas under consideration is creation of an immersive Smalltalk-like IDE targeting the OCaml ecosystem.
It should offload most of the complexities of dealing with the module system to the user interface (exposing a declaration in a module signature should be a one mouse click action), provide a new level of support for type inference, and, most importantly, designing the whole thing for AI-aided development.
If you’re interested in this and want to know more about our project or share your insights about the possible uses of such a system and your thoughts on the future of coding, feel free to contact me, pavel.mikhailovskii@jetbrains.com
We will be happy to share more details about our research and gain insights from the community.
Pavel Mikhailovskii,
Project Lead at Ludwig,
JetBrains
I would appreciate an Emacs replacement. Though, ideally, I would appreciate a better version of merlin. This is much more pluggable, and non-imposing. The latter is important — unless you could produce a replacement for emacs (not impossible actually, if you get the abstract core structure and the plugin architecture right), then any attempt at fully monolithic solution would be an imposition of a heavyweight ecosystem. That is an approach that takes the worst of Java.
This is very interesting feedback, possibly a bit at odds with our view.
We’re thinking about a radically new developer experience, fundamentally based on the “code is not text” approach. This implies such features as projectional editing and Smalltalk-style code browser UI, structural diff and merge, etc. JetBrains is a tooling company, we turn everything we touch into an IDE.
I guess you will find it quite imposing. However, we want it to be as minimalistic as possible and definitely not to bring “the worst of Java”.
My point is how would you abstract these notions into a generic editing system? The language-specific parts become plugins to it, in the same sense that various language-specific modes are plugins to emacs. If the functionality is tied strictly to a product, then it’s just another attempt (which would be viewed as a rather clumsy attempt) at vendor lock-in.
Emacs could benefit from treating the advanced features (projectional editing, code browser, structural diffs, etc., etc.) not as an abstraction on the logic of buffers and cursors, but as more integrated and explored entities. If a new editor could offer those features in a generic fashion, then it would be more compelling than emacs + merlin combination. The genericity necessarily implies a quality API. OCaml is well-suited to handle the refinement of sophisticated speficic cases, it seems. I doubt that advanced features would feel natural with lisp.
We’re trying to re-engineer software engineering and offer new ways of working with code and even thinking about it. That’s why I mentioned targeting the OCaml ecosystem and not just OCaml as a language. Think of it as a new interface to OCaml’s abstractions and not just another editor. This is already a tough task, and I don’t think that we will support more than one language from the start. It’s more likely that we will make use of OCaml’s support of various compilation targets (native, JavaScript, WASM, etc.)
As there has been a phenomenon of emergence of “Emacs OS”, there’s a phenomenon of emergence of “Opam OS”. However, an interface inspired by OCaml may either be abstract enough and thus be competitive with emacs conceptually or it may be an monolith, a thing-in-itself, in which case the emacs + merlin approach seems to win. Do yo see my point?
What I’m looking for is the ability to develop the editor towards my environment. That requires an API that is sufficiently abstract. I actually welcome API that is inpsired by OCaml. However, if it is not usable to me to allow the same level of integration (not mere “extensibility”) that emacs allows, then the editor would not really feel as a part of an ecosystem, but rather as yet another blob aimed at vendor lock-in.
It truly is.
I totally agree with you, the IDE should be extensible.
Actually, even our traditional IDEs like IntelliJ IDEA or WebStorm have a powerful plugin system.
I hope we will be able to do even more, in the spirit of Glamorous Toolkit, “the Moldable Development environment”.
If all of those functions (I see several distinct modalities in the Glamorous) could be implemented as plugins on top of a relatively lean kernel, then yes! Ideally, we should see a small kernel to which one plugin could be connected and turn it into a system editor, usable even on a headless system (highly optional IMHO, since it’s much better to make a shell replacement, and communicate over SSH with the remote session from a desktop session), and also usable in other context, while being easily and seamlessly extensible into a powerful code development solution.
Ultimately, the editor should not be imposing its ideas about user interface too much on me. Why? I have more optimal ones. That goes across the entire stack — from the custom .Xkeymap to a custom tiling window manager (e.g. xmonad), or just properly configured icewm.
Hence, I mentioned the merlin earlier. Apparently, it’s easily pluggable not just into emacs, but into other editors. The same should be with any other product that wants to solve a large problem.
A possible approach:
Provide a headless background worker like merlin that could interface with other editors. A lot of functions are generic enough that they don’t require special display.
Provide an editor kernel. Focus on display abstractions and integration into environment.
Provide plugins to editor kernel. Some of these plugins may interface with the background worker in (1).
The background worker may provide additional functions by leveraging the functionality of plugins in (3).
This way, the solution is (and would also not feel like) not yet-another vendor lock-in attempt on the one hand, and on the other hand would be desirable even in those ecosystems in which a different editing configuration had taken root.
I’m already a JetBrains customer, and I’d be thrilled to have access to an OCaml-specific IDE.
Considering it’s a niche (and wonderful) language, I’m curious what motivated your choice to target OCaml specifically?
I was briefly playing with Cursor the other day, and wondered how that would affect the tooling landscape in general.
I’ve been a heavy user of vim for many years btw, but I prefer feature-packed tooling with minimal configuration nowadays. Never played with Smalltalk though.
The possibility to support multiple compilation targets.
The first-class support for modularity.
The ease with which you can interact with the compiler
At the same time, it seems that OCaml community could greatly benefit from having a modern or even futurist IDE.
The truth is that JetBrains is a commercial enterprise and as such is not interested in supporting niche technologies. If we decide to build such a thing (as I said, we are currently still at a preliminary research phase), we will put a considerable amount of effort into making it mainstream. We need to be sure that such a technology would have a significant market potential.
We’re interested in talking with people who can help us prove (or refute) the viability of our vision. If you’re interested, we would be happy to invite you for an interview.
I just wanted to chime in to say that I’ve been using IntelliJ IDEA since the start of my (Scala) dev career and hugely appreciate the work that IntelliJ does. I wrote up some of my experiences with it and tried to apply it to the context of OCaml, if you’re interested: Next priority for OCaml? - #21 by yawaramin
JetBrains user here (for other languages). I mostly write new code in NeoVim, but often run JB IDEs for the code refactoring as it makes such task much faster and easier. So in my particular case I would be more interesting in anything that is related to the OCaml refactoring as well.
As for more concrete examples, I think for such an IDE, PPX support should be out of the box. Sadly, often in OCaml tooling it’s an afterthought, but as someone who writes Rust code daily, it’s something that should be used everywhere.
Looking forward to this new IDE!
I’m curious how Smalltalk like things (runtime introspection , code browser, etc) would work in a language like OCaml where things like modules are compilation artefacts that don’t really have a runtime equivalent like they do in languages like smalltalk or objective-c. A whole lot of compiler level data would need to be kept around if I understand the problem space correctly.
You’re right. We actually do plan to try a completely new approach to storing and working with code. Instead of storing code in text files, we’re planning to use some kind of structured format that will also allow us to store a lot of additional metadata. The user experience will be very different from the traditional OCaml, far more different than that of ReasonML or Rescript.
Our main goal is to try new approaches to software development, like non-textual representation of code and support for AI-aided development. OCaml just seems to have many properties that would fit nicely with our vision.
Again, at this moment, it’s just a research; before diving into building such a thing, we need to be sure that it will be welcomed by users. That’s why we’re trying to collect more detailed feedback from the community. If you’re interested, we would be happy to invite you for an interview.
It indeed has some ideas in common. However, our project puts a strong emphasis on minimalism, simplicity and unification, while MPS takes a kind of “Let a hundred flowers bloom” approach.