Very cool idea. Issues I noticed (without intending to discourage this sort of brainstorming in any way):
1. You can either define a function scattered across multiple cells in a single row, or gathered all in one cell. But as is, it doesn't look like you can define a function taking arguments in the scattered way.
2. The way the row evaluation works, each cell from left to right shares a stack. But the cells only show the top of the stack. The rest stays hidden. This feels like a departure from a key tenet of spreadsheets: to show all the data.
Hmm, so cell formulas, custom formula implementations, and presumably named cell ranges, all use the same language, a concatenative language? And all are written in cells rather than (the latter two) as auxiliary data?
I wonder, for formulas, if word stack effects are known or inferred, might the language simply be syntactic sugar? So `A:| 3 | 5 | negate | plus |` desugars as `| 3 | 5 | =negate(A2) | =plus(A1,A3) |`. Because the stack effects of negate and plus are known to be x-x and xx-x respectively. Factor is an example of a concatenative language with explicit stack effects. It does sacrifice allowing variadic words.
Might a range of code cells serve as a code block? In a concatenative language, evaluating a word simply pushes its definition on the stack. So if `A:| 1 | + |` and `B:| 2 push(A1:A2) |` then B1 would expand as `2 1 +`. So perhaps named ranges and custom formula definition are then overlapping concepts?
Meta: I find it curious that this post, variously submitted a day ago, and again at 1/2 and 1/4 day ago, were all at 1 or 2 points with no comments, and then this, the first submitted, surged to popularity. I'm glad it "caught".
(on that last bit: we put it in the second-chance pool, described at https://news.ycombinator.com/item?id=11662380, so it got an automatic placement on the front page. When we do that, we usually pick the earliest submission, modulo some technical limitations that kick in after a few days.)
Like. I use a (very primitive) Forth based language for laser machining every day. Despite how poor the implementation is (it was hobbled together over many years by novice programmers) it is amazingly productive. RPNs don't get enough love.
> I use a (very primitive) Forth based language for laser machining every day. Despite how poor the implementation is (it was hobbled together over many years by novice programmers) it is amazingly productive
This is awesome, and as the title says, very left field. I wonder what visuals would be produced if you could specify that a given parameter linearly tracks across a parameter space. Some crazy animation?
I developed but never completed a similar idea for custom business rules:
* each spreadsheet defined one function
* one sheet for inputs, each input labeled (i.e. function parameters)
* one sheet for outputs, each output labelled (i.e. function results)
* sheets for test data for inputs and expected output (examples of correct function parameters and results)
* cell values could be result tables from SQL statements, with cell formulas that could act on tables (where, join, etc) i.e. a single cell could contain a table value
* the idea was to allow consultants to naturally design business rules in a functional manner, and intuitively see how values flowed through a calculation. Debugging is natural, and test driven design is built in to the design. Business rules are often driven by examples in my experience.
* Because all calculations are a graph, I believed that the results of complex business rules could be computed efficiently as updates occur.
We've made a tool for graph calculations on tabular datasets where the results update immediately on changes. Check it out https://easymorph.com. (Disclaimer: I'm the founder).
Yes, I immediately wondered how to do the same kinds of things in OpenSCAD .. seems like adding a spreadsheet control to OpenSCAD would be low hanging fruit, also ..
It's currently focused on the narrow domain of producing SVG output to feed to a CNC machine or laser cutter.
Having generated files for CNC mills, laser cutters, waterjets, and a plasma cutter, drawing by writing commands seems like the wrong way to do the job. Everybody uses graphical tools for that. There was once a programming language for machine tools called APT, where, amusingly, GOTO moved the tool. Nobody does that any more. Maybe for CNC punching or drill lists, but not for anything with non-trivial edges and surfaces.
The good graphical software for this is expensive, though. Vectrix has a whole line of software - Cut2D, Cut2D Pro, VCarve, VCarve Pro, and Aspire, starting from $150 and each more expensive than the last. They're really all the same program.
You can also do this stuff with Autodesk Inventor, Fusion 360, SolidWorks, or other high-end CAD programs, but those are overkill for a laser cutter. On the free side, there's TinkerCAD and FreeCAD, which can do the job and suffer from the usual problems of open source GUI programs.
Back in high school, I did a bit of laser cutting using Adobe Illustrator. We would pull in 2D vector drawings from Inventor, but there was nothing stopping us from making things directly in Illustrator. I guess that would be an off-the-shelf alternative to some of these specialized programs.
Yeah, Illustrator (or SVG, DXF, etc...) as a source format is pretty common, but there was almost certainly another piece of software (or possibly firmware, depending on the device) in the pipeline there.
The source format is only the first step, you then need to generate tool paths from the source that actually direct the machine -- those involve converting the primitives from your drawing (something like "filled circle of radius r at point x,y") to a series of x/y/z motions that achieve the stated result, while accounting for all sorts of physical constraints like the nature and size of the tool, cutting speed, feed speed, etc... That's what the software mentioned is doing, and isn't something practical to do in Illustrator alone.
Actually, where the laser is concerned - probably not. Most commercial laser cutting machines have a print driver that handles all the conversion between Creation and Output.
I only ever deal with GCode when outputting to my CNC.
Exactly... g-code is a toolpath format, and something needs to generate that. It can be a piece of standalone software, a printer driver, or whatever, but it requires more information than is typical (or advisable to put) in your image format. That said, I have seen some attempts at generating g-code directly in application plugins or something...it's possible, but not with great results typically, and it's not something built-in off the shelf.
One thing you get from the specialized programs is offset. The width of the cut is not zero, even for laser cutters. The program needs to understand which side of the line is the "inside" and offset accordingly.
As someone who spends at least a few hours every day working with vectors that are then output to a laser cutter or a CNC, I'm having a hard time working out what exact problem this solves.
To my - very likely entirely ignorant - eye, it seems to hyper-complicate something much easier and quicker done with a mouse (etc) and a GUI.
Submitted title was "Loglo: A very experimental programming environment by Avi Bryant", which was a good choice because it was representative language from the article. And we love and admire Avi. But I'm wondering what title might appeal most to the readers here, and thought maybe a description of its juiciest elements would fare even better. We shall see.
1. You can either define a function scattered across multiple cells in a single row, or gathered all in one cell. But as is, it doesn't look like you can define a function taking arguments in the scattered way.
2. The way the row evaluation works, each cell from left to right shares a stack. But the cells only show the top of the stack. The rest stays hidden. This feels like a departure from a key tenet of spreadsheets: to show all the data.
But this really sparked lots of ideas for me, and even got me to make a 5.5 minute video riffing on it: https://archive.org/details/akkartik-2020-06-17-LoGlo