[HN Gopher] Enso: Hybrid visual and textual functional programming
___________________________________________________________________
Enso: Hybrid visual and textual functional programming
Author : ivanche
Score : 105 points
Date : 2022-11-16 08:30 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nerpderp82 wrote:
| crosslinking to relavent subreddits
|
| https://old.reddit.com/r/futureofprogramming
|
| https://old.reddit.com/r/nosyntax
| mjburgess wrote:
| 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
| worldsayshi wrote:
| >visuals often impair the quick exploration (etc.) needed to
| build the mental model.
|
| If that was true why do we use whiteboards do much?
| awinter-py wrote:
| their image processing example on the github readme is
| compelling
|
| I sort of agree that they're conflating a few things:
|
| - resumable processes
|
| - text graph description format
|
| - using graph descriptions to lint or generate code
|
| - UX / visualization for graphs
|
| But I could be convinced that these are things that go better
| together
| kitd wrote:
| Graphical representations tend to be better than 2D text when
| dealing with concurrent streams of execution. You _can_ do it
| in plain text, but either it is difficult to follow or it
| becomes a mess of text alignments.
|
| IME.
| mjburgess wrote:
| Perhaps, but how much of that it just an imperative phrasing?
|
| I think the visual capabilities of horizontal and vertical
| spacing are, certainly, vastly under-used.
|
| We could easily divide regions of files into two 60chr lines,
| or many 20char lines, GetWater .
| Boil(Water) | |
| GetCoffee, GetMilk, GetCup . Grind(Coffee) |
| | Pour(Milk) . Brew(Coffee, Water) .
| Pour(Coffee) .
| blondin wrote:
| this sounds good for pure concurrent processes. but
| synchronization will be harder to represent using vertical
| bars.
| kitd wrote:
| But you quickly come up against problems of text alignment,
| trying to show 2+ theoretical streams of text on one 2D
| page, and it's a pig to get the DX right. A specialist
| editor would help, but then you could ask, why not just use
| a structured doc in eg JSON and represent it graphically.
|
| For background, I wrote a tool that would convert an ASCII
| art diagram in comments describing the state flow of a
| class into a set of method declarations in the class. Even
| using online diagramming tools, it's not easy.
| WillAdams wrote:
| This is the route I've been going w/ my work on 3D --- I
| program in BlockSCAD and make modules for each component, or
| aspect of a component, and then the design can be visualized
| as the options/logic which arrive at a particular iteration.
| BenoitP wrote:
| 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.
| hutzlibu wrote:
| "I've always wondered why visual languages have not thrived. Is
| it because the spaghetti gets unmanageable?"
|
| Clicking is way slower than coding.
|
| Allowing both requires some sophisticated compilers and
| frameworks.
|
| "Can't you have boxes (modules/class/namespace etc) to neatly
| arrange things?"
|
| But yes you can, which is my approach. It was kind of hard,
| though and took a little longer than expected, but hopefully
| you can see the result soon.
| WillAdams wrote:
| >Clicking is way slower than coding.
|
| I think w/ a suitable UI it doesn't need to be. Things which
| need to be addressed:
|
| - it should be easy to instantiate new objects
|
| - minimize scrolling/present lists of choices efficiently ---
| when using the Blockly version of OpenSCAD, BlockSCAD I often
| wish that the variable list could be made hierarchical so
| that the variables from a particular module could easily be
| identified or limited to
|
| - being able to collapse blocks of code and expand them is
| very powerful
|
| Trying to get over my aversion to Electron wrappers to try
| this out.
| hutzlibu wrote:
| "I think w/ a suitable UI it doesn't need to be."
|
| Trust me, I tried. You can definitely reach a fast
| workflow, but typing + shortcuts will be way faster.
|
| But you can combine both.
| agumonkey wrote:
| totally and even without an ergonomic UI, some languages
| require you to type and go through so many hoops you'd
| rather click
| marcosdumay wrote:
| > Can't you have boxes (modules/class/namespace etc) to neatly
| arrange things?
|
| The limit on how complex a graph program can be before it's
| impossible to read is extremely low. Plenty of languages have
| boxes, none that I know about manage to make them fine-grained
| enough to neatly arrange things.
|
| Also, change is harder. And anything that makes changes harder
| makes your code less modular.
| carapace wrote:
| > I've always wondered why visual languages have not thrived.
|
| Some have, e.g. LabVIEW https://en.wikipedia.org/wiki/LabVIEW
|
| It's a niche UI that has trade-offs.
| jasonwatkinspdx wrote:
| There's a few visual languages I would say have thrived like
| Labview and UnrealEngine, a couple things in the real time
| audio/visual space I forget the name of, etc.
|
| But beyond those niches it hasn't caught on.
|
| One reason for this is editing is awkward. With text you can
| have things in a broken intermediate state while you make
| changes, copy and paste, etc. The tools for doing this with a
| visual graph end up being more awkward and slow vs a programmer
| practiced with their editor/ide.
|
| And the other problem is the graphs become a huge mess past
| some threshold of complexity. Even with boxes it's bad. This is
| a very common complaint about LabView. Example:
| http://forums.ni.com/legacyfs/online/4106_spaghetti.gif
|
| I'm very skeptical a visual language will catch on for
| programming in general.
| specialist wrote:
| I'm eager to try out Enso.
|
| > _why visual languages have not thrived_
|
| In my experience, "visual" gets you ~90% to done. But
| inevitably, you have to drop to code. To handle the use cases
| and edge cases not anticipated by the framework. And then
| you're fighting the framework. Which is a 800lb angry gorilla
| sitting between you and your goal.
|
| For flowchart & block style programming, the pitfall is the
| error handling.
|
| For patch cord style programming, the pitfall is conditional
| behavior and any data flows which are not 1:1 input-to-output.
| (Non-1:1 use cases are a challenge for all ontology/taxonomy
| systems, more generally.)
| somewhereoutth wrote:
| Perhaps un-intuitively, a 2D/3D continuous medium (i.e. a
| picture) is less expressive than a 1D discreet symbolic medium
| (i.e. a script). For example, the picture enforces a notion of
| nearness, of distance, whereas the script need not suffer such
| strictures (unless explicitly enforced - see GOTO vs structured
| programming). Thus the simpler topology of the script allows
| the author a more unfettered medium of expression.
| samsquire wrote:
| 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.
|
| https://github.com/samsquire/structural-visualization
| kmoser wrote:
| 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.
| 0x445442 wrote:
| Also the name of dmenu, Quicksilver like application.
|
| https://alternativeto.net/software/enso/about/
| forgotpwd16 wrote:
| First thing that name brings to my mind. That said it's a very
| niche long-dead (unfortunately) product.
| osener wrote:
| 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!
| carterschonwald wrote:
| A long time friend of mine is their advisor I believe. So I am
| pretty confident that the engineering is outstanding
| dang wrote:
| 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)
___________________________________________________________________
(page generated 2022-11-16 23:01 UTC)