Show HN: Skov – A visual programming environment
skov.software
skov.software
This goes from traditional 1-dimensional text-based programming to 2-dimensional visual programming.
What I envision is a 3-dimensional augmented-reality programming language where program elements will be floating around in 3d space around us and we use an augmented-reality interface to interact with them.
It’ll also enable us to do IoT programming in a very literal sense.
For example if you look at an air conditioner, light switch, or some other network-connected appliance that’s in front of you in the real world then the augmented-reality display will overlay the interface exposed by that device.
Let’s say that you’re looking at your phone (not the screen but the actual object). Since this is a device with a GPS chip your AR interface will indicate that you can do location-based programming with it.
Then you create the equivalent of an if-condition specifying a 10m radius around your current location.
if (phone is within 10m of current location) {
}
Now you look at a lightbulb in the room and your interface shows you that the lightbulb has a method for turning on.
You draw a line from the then-branch of the if condition to the light bulb.
You’ve created a program that turns on the light bulb in your room whenever you’re within 10m of this room.
However, I have to disagree that visual programming will actually become more mainstream than programming mechanism for less savvy users. As soon as Blueprints gets bigger (equivalent to may be 200 lines of code), it becomes absolutely unwieldy. You will find yourself clicking all over places all day long. It becomes very hard to parse giant graphs. It becomes hard to keep layout of what is where. It simply doesn't scale. Compare this to even lousy speed of typing 40 WPM, ability to write 1000s of lines of code and be perfectly at peace with everything. Ability to quickly copy paste, refactor, move around by blazing fast keyboard navigation as opposed to just two buttons on mouse.
I was using Hololens other day and created bunch of objects around my room. It became overwhelming just after dozen of objects around me and my hands were getting tired by expensive gesturing all over place. A code that would fit in to 13" display probably takes significant portion of 3D space because each "if()", "while()" etc must be represented by space consuming graphic objects and forest of connections between them. Humans are good at absorbing small graph but as soon as nodes and connections starts climbing they become frustrated. This is why small toy examples look good in visual programming but no one seems to write 10,000 lines of code in those systems.
So keep your expectations accordingly. Visual programming is good for people who don't want to be full time developer but whose job entails them writing may be 100 lines of code every other week.
There is a distinction between incidental complexity - complex tools and languages - and inherent complexity - the problem itself, it's domain and the emergent properties of it all combined with a Turing complete machine.
You can't really do much to reduce the inherent complexity, and even professional programmers are struggling with the inherent complexity in all but the smallest problems.
Some programmers are even struggling more than others which suggests to me that programmers need to be a bit above average IQ to be efficient, and it might even be a lower limit were nothing useful happens at all.
What could potentially happen is that we could invent AI agents that could help us tackle some of the inherent complexities, and maybe non professionals could string together intents that will be interpreted by AI, but that won't happen soon.
Edit:
The insights about incidental and inherent complexity is not mine. They were popularised in the great book The Mythical Man-Month by Fred Brook that have many insights that are applicable to software development in general apart from those insights that are applicable to writing large operative systems.
As the book is 40+ years old and the follow-up essay "There is no silver bullet" - that expand on the complexity topic - is 30 years old, there is little reason that we are still trying to invent the silver bullet.
I guess it could even be described as a failure of the educational systems, because I'm sure there is a lot research in information theory that have been done or at least should have been done, that touches these topics.
I've written on the topic here: http://web.onetel.com/~hibou/blog/NoSilverBullet.html
This ability is largely influenced by having been exposed to similar problems in the past and having applied various strategies to solve those problems. One reason why a lot of programmers struggle is because our current educational systems do not expose students to computational thinking at an early age. They've simply not have had enough exposure to that kind of thinking.
Even though computational thinking draws on computer science as a formal discipline the insights are applicable to various other domains and virtually everyone will benefit if they're able to apply the same kind of thinking to other problems in their personal and professional lives. Without having to solve any problems specific to computer science people can still acquire the ability to effectively apply computational thinking by solving other problems in their lives because the inherent complexities of those other problems are going to have some similarities to the inherent complexities in designing software systems.
Now some people may already have highly developed computational thinking abilities without ever having touched a computer because intuitively they've understood how to solve analogous problems in a different domain. Such people may be far better at dealing with inherent complexity than some or most professional programmers but they could never apply those abilities in this domain due to the barrier to entry posed by the incidental complexity associated with the tools and languages.
A friend of mine, a physicist, is an example of the above. Her approach to dealing with complex problems is already far better than many developers I know, but she wouldn't be a good programmer simply because she doesn't understand the tools. However, if she were to invest significant time to understand the tools then she'd be a better developer than most. Not only that, if she had familiarity with the tools then her already developed computational thinking skills would mature much further. If she were to have access to tools that allowed her to apply her ability to deal with complexity without getting in her way then that would be the ideal outcome. What I'm trying to say is that we are a very long way away from minimizing the incidental complexities introduced by our tools and languages.
EDIT: Sal Khan gave a relevant Ted talk on the limitations of our educational systems: https://www.youtube.com/watch?v=-MTRxRO5SRA
He mentions that if you were to ask a literate individual in a past society with a 10 percent literacy rate what would be the maximum possible literacy rate they would've said something like 20 percent (80 percent of the population is incapable of overcoming the inherent complexity associated with gaining literacy). But our educational systems have progressed far enough to achieve a 99 percent literacy rate, which would've been impossible for someone in a society with 10 percent literacy to even consider as a possibility. Our estimates of where the boundary between incidental and inherent complexity lies is generally going to be strongly biased.
I doubt however, that there is much to gain from simplifying the languages, and especially not by going the graphical programming route - it's a chimera occluding the actual problems.
Graphic programming could be used as learning tool, just like a set of training wheels, but just as them it would eventually become a hindrance as both make simple problems simple and everything else much more complex or virtually impossible.
The tools and languages can be improved of course but I do not think there will be any ground breaking improvements, just like there probably will not be any ground breaking simplifications in mathematics, or the process of learning it.
As an side note, I personally wonder why not more work have been done in incorporating first class support for entity-relation and/or graphs in languages - which is probably useful when modeling actual real world problems. But as it is still possible to build using generic language constructs, no one seems to care.
Or maybe the problem is that the educational system is so bad that too many are actually struggling to not topple over with their bicycle even after some years in university.
For visual languages such as Squeak, and Skov, the idea is indeed to make programming easier for people.
However, visual programming has another important raison d'être. MIMD programs algorithms are more naturally expressed as dataflow, so that task scheduling and load-balancing become almost trivial, and dataflow is more naturally expressed graphically.
Now we have multicore machines and it is difficult to make optimal use of resources with mainstream imperative programming languages.
Graphs are, as you point out, a very flexible data structure, and there ought to be something to be gained in representing programs as graphs, and having programs operate on graphs. Lisp and Prolog benefit from homoiconicity.
Right now we have far superior tools available to us than the ones used by the average programmer, but due to a combination of historical reasons, poor education, and sheer inertia of past commitment to inferior tools, we don't yet see widespread adoption of the superior tools that are already available.
The visual languages that I've seen so far are a kind of adaptation of existing languages to make them simpler and more accessible to beginners. What I'm talking about is not merely simplification of existing languages, but more a shift to an entirely different kind of paradigm. A shift that would require the development of new abstractions that are uniquely suited for visual programming that are not just adaptations of existing abstractions.
But as with all tools there are limitations. Certainly visual languages will not be best tool for all jobs, but there are certain classes of problems that are going to be easier to tackle with a visual language. There is also the possibility of solving a particular problem (or different parts of the problem) with both visual and text-based programming concurrently. First class support for data structures like graphs are easier to do with a visual language. I use Neo4j for graphs and the cypher query language is quite good, but it's effectiveness comes from the fact that it incorporates visual elements within the text. Something like MATCH (n)-[:REL]->(y) is a query for matching a part of the graph but you're still limited by the one dimensional structure of the language. You could imagine a visual query language for graphs being vastly more powerful in ways that a text based language couldn't possibly be.
[0] http://store.steampowered.com/app/290060/ [1] http://www.zachtronics.com/
This need not be limited to network-connected devices either. You can define interfaces for any object even if they aren't electronic.
For example you can define the interface for a bottle as something that can be opened. You can define processes based on the interfaces of multiple objects. These process definitions can then be transferred to a robot that will then be able to interact with the real world based on those definitions.
There are some similarities to my own Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html), which I'm still actively developing, but I suspect there are significant differences as well. So I have a few questions.
(1) Is the computation model dataflow, i.e. do vertices execute asynchronously, when all their inputs have values?
(2) If not, is Skov a visual equivalent of factor or some other textual language?
(3) Is it statically or dynamically typed?
(4) How is iteration done?
(5) Is there a lambda?
(1) Full Metal Jacket is explicitly dataflow - that's how the interpreter works. How to compile it (and to what) is an open problem for me, but there are a number of options. I won't release it until I have a working compiler.
(2) It's not a visual version of any existing text-based language. It is implemented in Lisp, and you can mix the two languages, but it's nothing like Lisp.
(3) It's very strongly statically typed, with type inference. Type errors are prevented by the editor. Run time errors are simply unacceptable.
(4) Iteration is done two different ways: using a feedback mechanism, and using emitters and collectors.
(5) Lambdas, including non-local capture of values, are built into the language.
More information here, including papers and tutorials: http://web.onetel.com/~hibou/fmj/FMJ.html
The main difference is Max and PureData are focussed around creating audio and graphics, but they're both perfectly suitable for general-purpose programming. You could even build quite complex GUIs that were just a shim over the application logic.
However, AFAIK, there wasn't a concept of 'building'/'compiling'. You had to ship your application with the full run time which required a user to make a separate install with no option for a statically built 'fat' executable.
I also found that while Max gets a bad rep for "literal spaghetti code" (I mean, google image search for Max/MSP and what you'll find is a mess), my code really didn't reflect this. I put it down to the fact that most users of Max are musicians and artists and not programmers who have learned basic software engineering principles like abstraction and separation of concerns and whatnot. When you compartmentalism logic into self-contained little blocks, I found the code to be super clear and actually kinda beautiful.
My main complaint with Max is that its data structures are very.. lacking. As far as I remember, you couldn't even do nested lists (or any kind of references), so things like trees and such were out. You basically had their built in types and nothing else.
I'd love to see a visual programming language very similar to Max/MSP but with better support for user-defined types/data structures, unit testing and other basic things lacking from Max but present in modern programming languages (or their tooling).
This was a few years ago though, so perhaps some of these things are now "fixed".
Here is an animated gif that shows integrated live testing while you code the phone in a rapid T9 or calculator style: http://giphy.com/gifs/ast-tactile-gundb-l0HlRxRHUg0WpF3kk
I just released the beta: https://talkbot.io
How do you avoid wires overlapping other wires on more complex "flows"?
1-minute away to get your bot alive .. maybe should be "bot live"? not sure what you intention was here, but one would use "live" more likely in this context.
"Use it, is free" should be "Use it, it is free" or "User it. It's free". English always requires a pronoun before the verb (with exception)
https://www.youtube.com/watch?v=ecIWPzGEbFc
Visual programming may or may not be the next big step, but I have to applaud anyone who attempts it in an OS manner. Unreal Studio for example executed it really good and the code it generates operates in god knows how many games.
I have never met a single person that, with more than 5 minutes of time, preferes the "distance computation" as given in the skov example, to the simple mathematical (x-x)2+(y-y)2
Lamdu[0], which has been discussed on HN before, is more Haskellesque, and I have also not heard from anyone that it is actually useful (beyond very early Haskell teaching).
Personally, I'm at the other end (preferring the tersest practical language, K) but I understand the appeal of a visual programming language - it's just that I have never seen an example that delivers.
I have the awesome J Android app[0] on my phone, but J doesn't seem as polished as K.
K is not more polished, it is differently polished. It is much more minimal than J, which makes the syntax simpler and thus the shortest program is often longer and slower in K; however, in my experience typically the length and performance are on par.
We've had many programming paradigms over the years, most delivered and we can argue about their merits. To the best of my knowledge the only somewhat successful visual programming systems are simulink and lab view, which are extremely limited, and any nontrivial use does venture into the "dreaded" textual.
I would love to be proven wrong, but I suspect it is inherent. A picture might be worth a thousand words, but movie scripts are still written as text, and graphic novels are a minuscule part of the market.
In my opinion It is similar to the misguided notion that some people have that if only math notation (or physics notation, or music notation, etc) was more graphic/elaborate/readable, it would be easier and accessible. This is wrong: the notation is just the top of the iceberg you see above the water. The underlying complexity is the real issue, and it won't go away with a different notation.
Programs in general are non-sequential (MIMD). They are normally expressed sequentially because early hardware was inherently sequential.
Music notation is graphical. So are Feynman diagrams, circuit diagrams, maps, blueprints, structural formulae, etc. Not everything is best expressed as text.
Other successful visual dataflow systems include Max, Reaktor, and Flow-based programming. The field is in its infancy and we can't be sure yet what works and what doesn't.
Music notation is graphical, and still gets complaints for being "hard to read" by people who haven't mastered it. My intention for bringing it up was not "see, it's not working", but rather "see, it doesn't make things simpler".
Circuit diagrams are graphical only for very small and simple circuits, which illustrates my point about scaling - there is no circuit diagram for any circuit with more than a few tens of elements anymore. Take a simple processor, for example - there are textual descriptions (verilog, vhdl, ihdl, ...) which are compiled into logic gates and/or netlists (textual or binary), and the result of layout (which is graphical, but not for human consumption). There's a block diagram, yes, and a small number of those blocks can be zoomed into another block diagram or a circuit -- but by and large, with the exception of manual layout tweaking, it is textual -- and that's in an area that started with diagrams and still champions them in its courses.
I disagree that the field is in its infancy - we've had pen and paper diagrams for everything in computing since forever, none of which has scaled so far to a complete system (some are ok for toplevel, some are ok at the really bottom level, non work in the middle) , including flow charts, data flow diagrams, UML and its tens of different diagrams, etc.
I would love to be proven wrong, though, but personally I have given up on this kind of things.
Eventually they won't need to.
Though I'm not sure quite what it'll take for it to make sense for people to collectively give visual programming the attention it needs to improve beyond being a mostly useless oddity.
I'm still on El Capitan. Could that be the problem?
But thanks for the tip about quarantine. I removed it from the folder and app with xattr and now I can start it.
Why disguise it though? This seems like a decision to create obfuscation and make the design less-intuitive for something that is very-marginally simpler to look at.
http://community.avid.com/cfs-filesystemfile.ashx/__key/Comm... http://deliveryimages.acm.org/10.1145/510000/509455/4743f2.j...
That was for mainly 2D image compositing (aka 2D matrices).
If you dig earlier, you'll find SideFX Houdini (successor of PRISM) which isn't tied to a dimension, 1, 2, 3D, geometry. You swing between all these to create whatever you want. It's like interactive math and physics right before your eyes taken to an extreme (at least until 2010s). You can then lift parameters from the graph to "package" it as a user made function to have things like city generations
https://www.youtube.com/watch?v=4QT_-Sws_nI
Loads of fun
I can only think of one major improvement - add the concept of synchronicity/asynchronousness. Perhaps a visualization to illustrate difference in function completion times or race conditions will help!
I remember my arms starting to ache after a few days of using the mouse constantly when working with Prograph. So some keyboard shortcuts would be recommended.
Just asking, it's definitely possible. I used to work at a CAD company, they did some dev work to do these with building models...
But now, all you can do is export your code to text files (Ctrl+S) and use traditional text-based diff/merge/version control tools.
"This app can't run on your PC
To find a version for your PC, check with the software publisher."