unit VS gcodepreview

https://github.com/samuelmtimbo/unit recently, which at least uses some kind of hinted auto-layout (besides the more propriety fancy)

I really want to see more graphical coding for years, but node/graph-based and blockly seem to be the only approaches that got sone traction so far. So I like this thread and it seems at the right place.

I'd wish to see

Interesting, and clearly a lot of work's gone into this (60,000 lines of Typescript), particularly the UI, which is impressive (if, sometimes, over the top). I've been developing a similar system (http://www.fmjlang.co.uk/fmj/tutorials/TOC.html) and it's interesting to note the similarities and differences.

Similarities: code as directed graphs (less obvious in FMJ); can only connect outputs to units of compatible type; if and wait (looping is handled differently); sticky values; sliders. These design decisions are practically forced on you, but are often absent in earlier visual dataflow languages (e.g. Prograph, LabVIEW).

Differences: (1) inputs are named in Unit, ordered in FMJ (though they're named in formulas and edges can be labelled). (2) I experimented with automatic code layout but found this was too slow and not always what I wanted. Well done for getting this to work. (3) FMJ is now fully homoiconic - this maybe isn't a priority for Unit.

The Unit design philosophy is explained in https://github.com/samuelmtimbo/unit/blob/main/src/docs/conc... . This doesn't mention earlier approaches (e.g. the Manchester Dataflow Computer, Prograph) and it seems to be based on vaguely similar ideas developed more recently (Morrison's Flow Based programming; possibly React and similar systems for web development - I'm unfamiliar with these).

I have a number of questions:

(1) How does the type system work? Is it Dependently typed, Hindley-Milner, or something more basic? (FMJ is Hindley-Milner, with dependent typing partially implemented). How are new types be defined?

(2) How is the visual representation stored? One criticism I faced was that people wanted a readable textual representation which would work well with existing version control systems, a problem I have now largely solved.

(3) How are runtime errors handled?

(4) Is recursion supported? (I assume yes, but I didn't see any examples.) What about macros?

(5) What does Unit compile to? (FMJ has an experimental compiler where programs are compiled by running their source without evaluating their inputs, output is Lisp.)

I enjoyed reading this. I knew of quartz composer but I never did anything with it.

I love visual tools and I think they are underutilized today. I cut my teeth in ~2005 with Houdini[0] and Fusion[1] which are both heavily graph / node based (and procedural).

Most recently I have been rekindling my love for visual programming and flow based programming and plan to spend some time in January and February doing more research around flow based programming for infrastructure management.

I plan to get this sort of info published on my website which I have neglected for half a decade or more but if you are interested in visual programming you might enjoy checking these out:

Unit from Samuel Timbó:

https://github.com/samuelmtimbo/unit

https://ioun.it/

A video of me exploring what I figured out about it (while also learning to stream) https://www.youtube.com/watch?v=vwknTfGVDq8

Behave-Graph from Ben Houston:

https://github.com/bhouston/behave-graph

And the products I learned so long ago

[0] Houdini https://www.sidefx.com/products/houdini/

[1] Fusion https://www.blackmagicdesign.com/products/fusion

https://github.com/samuelmtimbo/unit

- A code drawn in unit is simply a Directed Graph.

- Programming can be partially performed by Gesture and by Voice.

I've been working on this sort of thing for a while.

For a Japanese spin on this see Tsugite:

http://ma-la.com/Tsugite_UIST20.pdf

which I worked through at:

https://community.carbide3d.com/t/a-study-of-joinery/28492

Traditional joints (box, dovetails, or obscure variations such as Knapp (cove and pin)) require a vertical fixture and 3 setups (at a minimum) --- cut parts to length and machine internal features, mount four board and cut joints in 2 corners, flip boards (with correct orientation) and cut other two corners.

Rabbet joints are simpler --- so simple that they were covered in a video as "The Simple Box":

https://www.youtube.com/watch?v=V93xDM3lXsM

(ob. discl., I work for Carbide 3D)

There have been a number of programs developed for joinery. A current commercial option is:

http://www.g-forcecnc.com/jointcam.html

(but it requires a vertical fixture)

One commercial option became freely available:

https://fabrikisto.com/tailmaker-software/

and ingeniously has an option where a 30 degree V endmill is used, but to cut boards held at a 15 degree angle, affording a 90 degree cut with a great deal of control and flexibility --- this can multiply setups to 9.

A variation I've been experimenting with is full-blind box joints:

https://community.carbide3d.com/t/full-blind-box-joints-in-c...

They're reasonably easily drawn up, though they do have some rather specific tooling requirements (a narrow 90 degree V endmill, a square tool of that or smaller diameter, and to make things easier, a large V endmill)

One test project was so tight that after putting it together for a dry-fit before gluing I was unable to get it apart:

https://cutrocket.com/p/63781eaf9822f/

I've been working on a programming system to make this sort of thing a bit easier:

https://github.com/WillAdams/gcodepreview

and have some sketched out joints which I've not been able to make using existing CAM tools which I hope I'll be able to do using this system (if anyone could recommend books on conic sections, I'd be grateful --- that's where I got bogged down last time).

While I certainly appreciate the virtues of a Domain Specific Language, and that OpenSCAD has been wildly successful because of its limitations, the limitations are downright infuriating at times.

An interesting potential alternative (which hopefully won't result in a fork) is adding Python:

https://pythonscad.org/

which I've had some success with:

https://github.com/WillAdams/gcodepreview

ImplicitCAD is interesting --- and the (new?) ability to open files from GitHub is _amazing_ (OpenSCAD recently gained that same facility, _and_ it supports the customizer: https://seasick.github.io/openscad-web-gui/?https://raw.gith... ), but it's a heavy lift given the need to work out how to edit files, preview them, and so forth.

Do you have a need to?

Do you have a project which might be able to make use of this? What sort of work do you do?

I am bookmarking this for re-reading later because I hope it will help me to understand how to implement Bézier curves in a tool I've been working on for controlling a CNC machine/creating files for cutting on a CNC:

https://github.com/WillAdams/gcodepreview

(but first I have to get arcs working)

Interesting.

I've long been frustrated by traditional CAD/CAM, so finally worked up:

https://github.com/WillAdams/gcodepreview

which allows me to use:

http://pythonscad.org/

and:

https://github.com/derkork/openscad-graph-editor

to create joinery:

https://forum.makerforums.info/t/openscad-and-python-looking...

which would otherwise be tedious to draw up:

https://community.carbide3d.com/t/creating-drawers/19475/26

The problem here is that a fundamental question has not been answered, and as far as I can tell, has not been addressed by any of these visual environments:

What does an algorithm look like?

Herman Hesse alluded to this in his novel _The Glass Bead Game_, but despite decades of discussion and work, no one has made a convincing pysical representation of that system.

I love the concept, and have made some moderately complex attempts, e.g.,:

https://www.blockscad3d.com/community/projects/1430644

https://github.com/WillAdams/gcodepreview

it always devolves to screen size being out-paced by problem complexity --- one gets something of an inkling of this at:

https://scriptsofanotherdimension.tumblr.com/

Alternately, one can just break a project down into modules, but then the top-level view becomes the wall of text representation (albeit w/ nice lines or captured into pretty boxes) which one is ostensibly trying to escape.

I'd love to see someone succeed in this, and I've been using:

https://github.com/derkork/openscad-graph-editor

quite a bit, and put a bit of money towards:

http://nodezator.com/

or perhaps Solvespace --- certainly FreeCAD, and if you're inclined to do programming, OpenSCAD --- see: https://github.com/WillAdams/gcodepreview for an approach which uses RapCAD