We would love to have as much of the dynamism of Smalltalk as possible. Not only coding in the debugger, but also coding together with the AI in the debugger! And at the same time to have more coding assistance from type inference and autocompletion.
Could you share your use case with us? We’re collecting evidence that people would be interested in such a product.
1 Like
Thanks Yawar!
Could you please share more details on why you and your company might be interested in such an AI-powered IDE?
This sounds really exciting! Coincidentally, I have actually just started evaluating CLion for embedded development at work 
. I don’t really know what kind of pricing model there is yet but if I could get the OCaml one as well I would be really keen to try it out.
Here are some things I would like, but am not sure how feasible they are
- A solid debugging experience (I know solutions exist for ocaml but I’ve just never found them as easy as I’d like)
- Generating mli or type signatures from implementation code. I prefer to prototype in .ml and not get bogged down in module interfaces etc but they’re great for readability by others.
- Robust collaboration features and easy setup. Getting someone to install the IDE should be all they need to open a project and execute it
Here are a few more ambitious happy thought that are just off the cuff:
- Code generation tools based on OCaml. We all know that OCaml is great for DSLs, compilers, pattern matching on syntax trees etc, it would be awesome if we could write IDLs and generate either types, or, even better, FFI code in a number of languages
- (preface: I’m not all that into the webdev scene but I recognise how useful it is in general) WASM compilation with easy setup and JS interface generation (this might already exist, Im not sure)
- UI helpers for developing PPXs
- I think even an amazing project would be hamstrung by the niche-ness of OCaml, but if you pitch it with Reason syntax it would be easier to sell people not familiar with OCaml on
- More specifically about AI, it should be able to take in your project as context like GitHub’s one so as to generate more accurate responses & code
- Some sort of hierarchical state machine library that you could talk to an AI to describe as a specification, along with generated mermaid diagrams (Claude does this) that then can output accurate OCaml code that fits the specification
- The same as above but with SQL schemas and auto generating the query code
- Even crazier idea, something resembling an abstract representation of modern development that you could then codegen in multiple languages depending on the need. this would be killer for developing an API spec and then generating SDKs in multiple languages
- An easily embeddable runtime that works on mobile. I want to do some things in React Native that aren’t supported by its js runtime (you cant use gRPC?) and the native module story is painful. I dont know if this is possible but some sort of embeddable runtime that can access system calls that just “runs anywhere” ?
I think this is great idea. You should probably look into the ocsigen project which is a futuristic web framework for OCaml. It allows you to have typed communication between client and server. You can get an ocaml value from the backend into the frontend with a simple function call, the serialization and deserialization and building the request and answering it is done for you.
The current editor tooling does not work 100% with it, but of course this would not be an issue if you build a new editor.
I think that if communicated on properly, a web framework like ocsigen could really drive adoption.
5 Likes
Hello. I was just curious to know what features you think Merlin could improve in to make it better?
1 Like
I haven’t checked, but I think the current implementation of Emacs’ handling of OCaml uses ocp for indentation, and the harmony with merlin is not perfect in that regard.
The immediate practical problem is actually more about the ability to run expressions in utop. I currently don’t see a way to do this nicely from emacs, and have to do dune utop, and copy-paste some expressions in a separate terminal window. That’s annoying.
I would like emacs to switch between different workspaces more naturally, especially if there’re a lot of similarly named files. I have configured buffer switching mode to the death, and still have to spend a few seconds sometimes to switch between files I really mean to switch to.
I would like to visualize somehow the hierarchy of modules, dependencies, etc. I don’t mind a separate graphical window, even from another program, but sensitive to my current editing context. I don’t think emacs has display capabilities for that.
I think that by itself merlin is great — since its exact niche was located and it fits more or less perfectly within that niche. The tooling should be about augmenting the editing context, by adding other parallel processes. Trying to squeeze those into merlin itself would be bloat.
Yes. ReasonML. Full stack development. Thank you.
Hello,
What is the AI research envisaged ?
- LLM inferencing engine.
- Model Context Protocol
Is this a collaborative editor like what Figma has created using CRDTs ?
Thanks
OCaml seems to be breaking into the larger programming mindshare. I see people mentioning it on and off where I don’t expect it nowadays. I sense its merits and quality are finally starting to gather mainstream appreciation. That is to say, I think you might not have to do much to get people on board, certainly I don’t see it being a harder sell than F#, which you already have Rider for 
And I must say, tooling as splendid as Rider’s for OCaml sounds so enticing. Tooling that tries to innovate over that baseline is even more so. Can’t wait for that experience!
2 Likes
I would love to see great IDE support for Ocaml. What we have today in Vscode + Ocaml Platform and the ocaml-lsp is actually not that bad. If anything I’d like a company like JetBrains to ‘play nice’ with the community and put their weight behind making the lsp experience with intelliJ better and improve the ocaml-lsp itself; as well as the ease with which it can be adopted into IntellijJ.
Some thing JetBrains could do
- provide good open-source support for lsp in IntelliJ CE
- contribute to the ocaml-lsp and make sure it works seamlesly inside IntelliJ CE
- provide a great Oocaml debugging experience in JetBrains IDE (debugging in Ocaml for me as a rather ‘newbee’ Ocaml enthusiast is one of the biggest things that I am missing today)
As to the whole ‘new fangled’ IDE… I am honestly a bit sceptical. I have seen it all before it sounds a lot like Intentional Programming and that kind of ‘futuristic’ idea is now 25 years old and it never took off back in the day. It could be that we just weren’t ready for it then and today might be different… maybe AI makes the difference somehow, but I’m sceptical. Perhaps you should try to figure out why it failed 25 years ago before trying to do it again today (probably with a lot less venture captital behind you than was available to Charles Simonyi).
Also like some others in this thread I have an adverse ‘alergic’ reaction to the idea of relying too heavily on this kind of heavy-weight environment and probably commercial/proprietary IDE.
This is very exciting. I’ve used JetBrains for Scala and it was excellent - it would have been very difficult to be productive in Scala without it. A JetBrains OCaml IDE could eliminate pretty much all the friction newcomers encounter when trying to become productive with OCaml development, in part by facilitating project creation and dependency management, facilitating module management as you mention, and also by potentially helping demystify compilation errors and non-obvious gotchas - perhaps that’s where the AI would fit in.
Mainstream adoption of OCaml could quickly follow as people have a chance to actually use the OCaml language to solve problems. With a JetBrains IDE I think the world would perceive much less risk in committing to OCaml for a commercial project.
I hope you decide to build this!
As for the future of coding, OCaml could be very well-suited to a type of AI-assisted coding in which the developer thinks in types and tests, and AI guides the implementation. I’m not sure how interested I am personally in that style of coding - I like coding and I don’t like the idea of AI doing it for me - but if the world were to go that way, OCaml would be a prime candidate to make it work.
6 Likes
This is exciting!
Here’s a report from my own experience building a (research) live editor for OCaml.
If you want to show any kind of runtime data, to make it really Smalltalky, it’s going to be tough using the standard OCaml toolchain. OCaml performs type erasure and the in-memory representations it uses for data are ambiguous. You can’t reconstruct the type.
While you can use the static typing in some places to get the structure of the data, that doesn’t work at locations that have a polymorphic type. This doesn’t sound like a big limitation, but, in practice, it can be if you want to provide live feedback during program construction. While writing your program, you’ll have polymorphic types at all sorts of locations before the code is complete (if you don’t force the programmer to write type annotations first).
Hence, we forked an OCaml interpreter to log the runtime values for our fancy live programming editor, Maniposynth, including at polymorphic locations. The cost was much slower execution, but that was acceptable for demonstrating the user interface ideas.
5 Likes