Hacker News new | ask | show | jobs
by galfarragem 1929 days ago
Unpopular idea here (from a hobbyist programmer).

I would "kill" for a text editor/IDE/REPL shaped as a spreadsheet where each cell is a block of code with 2 possible views (text or result) linkable to other cells. This "spreadsheet" would be programming language agnostic (each cell could use a different language) and I could organize/format my cells (location, colors, size, etc) as I wish.

9 comments

This is actually a great idea. I had a conversation over beers with some people in a higher intellectual realm who were discussing the details of flow-based languages. It was the general consensus among them that in the future, flow-based programming will be the way everyone learns structural thinking, and we will look back on sequential instruction programming the same way we look back on punch cards today.
this seems obviously true. but why has it failed for like 40 years so far? many attempts have been made. for some reason all tools seem to fail, no matter how simple, they cause more problems than they're worth.
I think an interface providing proper abstraction hasn’t been properly built yet. Imagine every API call to Amazon was a block in a flow based system- some of those endpoints have hundreds of options and multiple accepted input formats, so designing an abstraction layer that doesn’t add more complexity than it takes away is a difficult problem to solve.
We tend to design API calls over the net as stateless. It's more efficient to implement in a server and prevents abuse (keeping client states on servers for unknown amount of time lead to DoS attacks).

A flow based system would require more flow on the other (server) side. Imagine each sentence to be a request in the following, and how many avenues of potential service abuse it could bring. That's why we avoid designs like this today.

Here lets's begin a new (cloud?) server definition. Inside this server definition let's begin network specification. Inside this network specification let's begin open ports specification. Here, there's a batch of ports we computed we need. Here, there's another batch of ports we need. End network specification. [...] Let's get back to that port spec, because of something emergent. [...]

Thanks for this perspective, I think from my naive standpoint I would build a flow-based system at the application layer and simply code generate/translate to standard networking calls.

However even with such a paradigm I could see plenty of potential for abuse, even unwittingly - while sequential programming forces you to try-catch, flow based programmers may end up connecting the “error flow” back to the original flow that caused the error, creating an infinite loop that would be much harder to debug.

I am very curious about this idea of yours.

Do you have a draft drawing of the concept or could you otherwise elaborate a bit more?

As an anecdote I used to use a spreadsheet to visually "assemble"[0] HTML code for a niche blog. Some cells would compute values to be used in other cells that would compose the final HTML code. Of course existent spreadsheets are way too rudimentary to use as an "Excel Code": cells don't act as a REPL for the language of your choice nor allow a "text view" with syntax highlighting.

[0] Maybe because I have a background in Architecture, I tend to look at code as I would look at a house plan.

Sounds like microservices taken to the atomic level.
Check out this early prototype of eve mentioned here: https://youtu.be/5V1ynVyud4M?t=279

Not language agnostic, but table based.

(eve went in to a different direction afterwards though)

I suspect Emacs could be convinced to do this. Right now there's the Simple Emacs Spreadsheet which uses elisp as a formula language and has a grid view, but I can't imagine shelling out to alternative interpreters would be beyond the wit of man.
That's an idea that seems to be forming in the heads of a lot of people. I started working on something like that a couple of months ago. Blender is adding spreadsheet now. Excel is getting a more advanced language. ...
Yes! This concept aligns with MWeststrate's ideas about reactivity / observables, implemented in MobX

https://mobx.js.org/README.html

Ellx.io is doing this at the moment afaik
Ellx.io seems promising, I'll toy with it a bit, thanks! Unsurmountable objections:

- not language agnostic (JS only, AFAIK).

- lack of native desktop app to keep it fast.

- not spreadsheet view only. I would then hide/collapse syntax highlighted code inside of cells as I wish.

Replit has touched on this idea, @tylerangert on twitter