Perhaps this exists in some ways already, but I’m thinking of an IDE that would allow for interactively exploring/changing your system like in smalltalk.
You could see all of your processes and how they’re linked, graphically.
Imagine Erlang’s observer, except you can click on each module/process and it takes you directly to the code where you can edit it.
Grokking elixir code can be painful for me because of all the jumping you have to do between files/directories and it’s difficult to keep the mental model of how everything is connected. This graphical representation could ease that struggle.
You start zoomed out like in observer, then you can zoom in and in to see the details, then back out to the whole system again.
Processes have no source code and modules have not necessarily processes.
Modules can call into each other dynamically using apply/*.
But I rarely have to open more than three files at once to work on a certain aspect, whereas one of the files is the one that contains the corresponding test.
Using the fuzzy-finders of my editors (emacs or vscode) is often enough to find the correct file.
And to be honest all those graphical stuff just disturbs me.
Observer is a fine thing to introspect a running system, but nothing I’d like to use to develop in.
While Smalltalk isn’t as mainstream as JavaScript, Java, Python, etc. its history (Smalltalk-71) and influence makes it more maintream than Erlang/Elixir.
Graphical IDE support tends to develop later in the technology adoption life cycle once the technology is more mainstream.
And that makes sense given that there is only so much effort to go around when there is only a relatively small community effort that can be expended on developing the ecosystem - i.e. there is an opportunity cost to developing graphical tools that only becomes worthwhile once a technology acquires a certain critical mass. Before that point is reached, effort is probably better spent on language, deployment and runtime improvements and command line (i.e. scriptable) tooling.
People preferring graphical tools are usually neither in the “innovators”, “early adopters” and possibly not even the “early majority” group - because technologies in those phases tend to be largely supported by command line or text-based tools.
I suspect that Elixir is still early enough in it’s life cycle that there are more productive ways to expend community development effort than creating graphical development tools (though in OSS anybody can develop and provide what they want).
it’s difficult to keep the mental model of how everything is connected.
That’s simply a matter of familiarity.
Also there is no guarantee that any particular graphical representation (or interactive model) provided by any tool is in fact a good basis for a mental model - often multiple representations are required to cover all the useful views.
For example, with UML people often provided class hierarchy diagrams because they were easy to provide rather than providing activity and sequence diagrams which actually show how the system works.
I never paid much attention to Smalltalk, but after read that Smalltalk was a strong inspiration to @joeerl, and that he admired Alan Kay I started to looking for mor information about SmallTalk and found Pharo. Now all @joeerl rants about the fact that we are on a pre historic age regarding computing makes sense.
I really would like to see something along these lines in Erlang.
Please, if you haven’t already started and worked on this, do it as much as you can. Don’t pay too much attention to the "can’t"s of this. If you succeed even in the slightest you’ll have made a much better development environment than most functional languages have.
The statically typed ones are neat because at least they can tell you something about things while you’re coding, but it’s really nothing compared to a Common Lisp or Smalltalk (look to Pharo nowadays, probably). I really don’t like working with dynamic languages anymore because honestly I don’t think they can even be rigorous except when used by robots… With the exception of Smalltalk (and probably Common Lisp) because they’re so incredibly simple, compact, inspectable and interactive.
A running Erlang/Elixir program is a living system, but Smalltalk and Common Lisp go one step further; the program you’re currently working on is a living system. In the case of Smalltalk, so is your editor/IDE. It’s truly a marvel of tooling. If someone said they could offer me a job with Pharo I’d probably try to start next week.
Looks very interesting, please share some link to the place we can discuss at least.
The problem I see is Smalltalk and Erlang’s approaches to semantics differ a large. While Erlang/Elixir focuses on a process that holds its internal state in dynamics, Smalltalk OOP is tightly focused on stateful static data. At the same time, they both have some notably retard with modern requirements to the software systems – homogenic dynamic clusters in clouds and/or corporate LANs where you never know which part of a cluster alive, disk-based and NVRAM persistence, data and API specs interchange between multiple language stacks, etc. So, even its VM cores requires to be rethought.
To be more realistic, your ideas can be reduced to integration between Pharo and running BEAM instances. Smalltalk part should provide an interface, and dynamic code generation for use with genertive (meta)programming, and BEAM + Erlang compiler should provide runtime, and code recompilation & reload from the Pharo’s head.
