"The area of non-verbal programming languages has not been unexplored."
Starting out with the aggressive triple negative in sentence two!
Λ-2D: An Exploration of Drawing as Programming Language
21–30 of 58 posts
Re: Λ-2D: An Exploration of Drawing as Programming Language
#22Why did it have to be pixelated in appearance? It would be far more attractive as anti-aliased vector lines and type. The red highlighting reminds me of electricity in the classic circuit problem game _Rocky's Boots_ on the Apple ][. As I've posted in similar discussions: https://news.ycombinator.com/item?id=42051536 The problem here, as always is that there isn't an agreed-upon answer for the question: >What does an…
The problem is that while on text based languages folks quickly learn to use subroutines and modules/packages, apparently the same concept seems alien to anyone that hasn't done digital circuit design. Most visual languages, support subroutines and modules/packages as well, no need to design a gigantic piece of spaghetti. If anything, visual languages make it clear straight away when the code is a mess.
Yes, but if one uses subroutines/modules, then one ends up with the wall of text which one was presumably attempting to escape from --- just wrapped up in coloured boxes/connected with lines.
GraphSCAD at least affords an option to add an image to a module representation, preserving some of the visual aspect --- I believe OpenSCAD Graph Editor has that in the works (if it's not already done).
Re: Λ-2D: An Exploration of Drawing as Programming Language
#23Looks unreadable and reminds me of Factorio.
Re: Λ-2D: An Exploration of Drawing as Programming Language
#24If you like this, you may find automation project engineer work fun... or at least familiar. Function block diagrams are quite like this: There function blocks are connected together with wires, and the order of operations is defined by block order. Blocks themselves are like builtin functions in the engine, or they can also be composites. The diagram is executed once per control cycle and generally (if no jump block…
Like PLCs or something similar?
Re: Λ-2D: An Exploration of Drawing as Programming Language
#25Something that always struck me about this sort of thing, or in similar games, is that it is only 2D and so rapidly becomes incredibly crowded with lines going everywhere.
We code in a 2D nature (rows and columns) but the flow is non-euclidean I guess
Re: Λ-2D: An Exploration of Drawing as Programming Language
#26Takes me back to the good-old-days of block diagrams. Those went away with few complaints.
Re: Λ-2D: An Exploration of Drawing as Programming Language
#27These things have been done in Labview, and it's hard to get anywhere. It's also been done in sound/music generation programs, with Max [max] as a (the?) granddaddy. While you can get things done, it quickly becomes messy too.
Does it look good? I don't think so.
Re: Λ-2D: An Exploration of Drawing as Programming Language
#28Beautifully executed. The animated run feature on the online demo is exciting to watch.
Re: Λ-2D: An Exploration of Drawing as Programming Language
#29I've been interested in graphical formal specifications since I first heard about Petri Nets like a decade ago. It always felt like engineers would be more likely to utilize formal methods if there was a graphical representation instead of a bunch of scary math notation and language associated with it. Sadly, every time I've tried showing Petri Nets to other engineers, they get pretty disinterested almost immediately.
Before I abandoned my PhD at University of York, I was working with something called "RoboChart" and RoboSim [1], which I actually think might be more approachable, but it's pretty tied into the robotics semantics. A pet project I've been working on has been trying to adapt and extend RoboSim to something a bit more useful for the network and server world.
Re: Λ-2D: An Exploration of Drawing as Programming Language
#30These things have been done in Labview, and it's hard to get anywhere. It's also been done in sound/music generation programs, with Max [max] as a (the?) granddaddy. While you can get things done, it quickly becomes messy too. Does it look good? I don't think so. [max] https://en.wikipedia.org/wiki/Max_(software)
Simulink should be included in the list?
All this "block programming languages" look promising, abstraction by black-boxing, doing boxes of boxes... I wonder if the implementations are bad, they are badly used, or the paradigm just does not work...
One thing to take into account, is that those things are typically used by people who have no idea how to program and abstract things. Maybe if somebody is good ad programming would not do a mess out of it; but then (s)he could just go ahead and write code. so.....
I must agree, LabView is terrible, not just because of that, but updates break everything, licensing, etc... just PITA