Enso: Hybrid visual and textual functional programming
This seems like a great endeavor.
I've always wondered why visual languages have not thrived. Is it because the spaghetti gets unmanageable? Can't you have boxes (modules/class/namespace etc) to neatly arrange things?
> GraalVM, Performance meets polyglot
> Import any library from Enso, Java, JavaScript, R, or Python
A use of GraalVM in the wild! Seems like a perfect fit for this project. Can it use the C-accelerated libs from Python like numpy? I always thought it was up to the programmer to make libs go through Sulong, then bind things later on.
This is one of the systems discussed in a recent talk that had a couple of threads on HN:
Stop Writing Dead Programs - https://news.ycombinator.com/item?id=33270235 - Oct 2022 (60 comments)
Stop Writing Dead Programs [video] - https://news.ycombinator.com/item?id=33251799 - Oct 2022 (230 comments)
This looks awesome.
I find the problem with visual programming is that often there is multiple representations or diagrams that would be useful to combine and render into a program.
* A box and line diagram with arrows is enough for representing event handlers and event dispatchers and message queues automatically.
* There's multiple approaches or methods to think of a computation: pipeline, communication, mathematic operations, projection. Each of these can be visualised.
* Behaviour composition - how do you combine behaviours together visually? Too many things on the screen and the underlying insight to the problem becomes hard to see or notice.
I'm working on a representation of code that is visual but it's not traditional.
My initial reaction, from an SEng POV, is that visualising code in this way is pointless: the text of the code is the graph of the code. And if you really really value an identity here, use lisp.
So visual coding, for SEng, I think just is pointless. The text isnt the hard part, the hard part the is mental model -- and visuals often impair the quick exploration (etc.) needed to build the mental model.
Likewise, in the YT video introducing this, the creator distinguishes between "code" and your mental model of its execution, as if the latter can and should be ditched. This, of course, is a fallacy as far as SEng is concerned. The whole point is the mental model.
Nevertheless, after watching for longer, the sales pitch here seems directed towards data science (, + DEng perhaps) where applications are often trivial amounts of code.
Coupled with interactive visualisations, this is at least a more plausible use-case.
There the creator's distinction between "how the machine runs your code" and "the problem you're trying to solve" makes more sense. Since practitioners arent building automation systems, apps, etc. they're using code instrumentally to arrive at an outcome.
Also, cf. https://enso.org/docs/developer/enso/enso-philosophy.html
Narrator at 0:25 in video: "All of these things can be done without writing a single line of code"
Demo at 2:10: [Narrator begins writing many lines of code in a proprietary language]
Not saying this is a bad tool, but the breathless "no code!" hype is a bit much.
Modern FPGA designs actually work very similarly. You have a high level graphical representation of all the different modules and IP cores you use, and connect their inputs and outputs together using the GUI, but then the actual "code" (VHDL/Verilog/etc.) inside those modules is still written in text form like normal programming languages.
A long time friend of mine is their advisor I believe. So I am pretty confident that the engineering is outstanding
crosslinking to relavent subreddits
Also the name of dmenu, Quicksilver like application.
I remember hearing about this language at Curry On conf in Amsterdam back then when it was called Luna. Happy to see that it's still going strong and finding its market fit!