This is coming close to the way I envision we’ll be programming in the future.
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.
I've been using Unreal Bluescript since past few months. It's probably as practical and large scale as any visual programming system ever have been designed. There are many good things about it, for example, it "compiles" instantly. There is even some visual debugging. You can change a variable name and it gets refactored automatically. It gives you definitive errors right away instead of waiting for compilation. It has nice abstraction of subroutine and macros.
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 are a few other games out there like this, but what you described reminded me of Glitchspace[0]. There was a post about zachtronics some time ago that listed similar games.
While in my optimistic moments I imagine we'll be programming visually in the not too distant future, and am doing all I can to bring this about, I still would prefer to turn on light bulbs by flicking switches, which simply close electrical circuits rather than call methods. For that, some might consider me a Luddite.
It's quite impressive that you've got so far so quickly.
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?
(1) & (2) The code is compiled using the Factor compiler so it really works like Factor
(3) Dynamically typed, type errors will be caught at runtime
(4) You use "while" and "until", you can see an example in the last screenshot in the web page
(5) There is a lambda. There are several examples of this on the web page, including a lambda inside a lambda
Back when I was studying for my degree, we used visual programming with an application called Max/MSP [1]. Having a quick glance at Skov it looks very similar although Max (and its open source brethren PureData [2]) probably has a much more mature ecosystem (it's been around for quite a long time). I believe you could even program extensions in Java that you could drop in if you needed to have a performant algorithm that wasn't supplied by the 'standard library'.
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 used Max/MSP (well, max4live) for a while and I loved it. I especially found that not having to name stuff (variables, functions etc in other languages) quite liberating when experimentally working towards a solution. Once the design solidified, I could go back and name things nicely.
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".
Awesome, great work! Personally I'm not a fan of "visual" because it requires too much mouse work and navigating around. I tried to tackle these challenges by coming up with the concept of a "tactile-spatial" programming language, which is foremost designed for coding from a phone/on-the-go/touch-based devices.
Nice, I like it's simplicity. I'm also working on a visual programming environment, but for building chatbots. Check it out, I bet you can get some ideas for yours.
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)
I think it would be hugely beneficial to allow people to code with both text and the visual interface. LabView has a graphical editor as well, for bigger projects, it would have been nice to have both formats available.
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 applaud the attempt, and it does look nice, but my impression of visual programming environments is that they never scale, and it might be an inherent issue.
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.
K is an example of a language I can code with on my phone. Because you need only a small screen with code to see a lot of functionality and you do not need a lot of input but more thinking it works. Most modern visual programming attempts come from the drive to work on small screen without real keyboards and languages like K (APL likes) and Forth likes (like this one is based on) already work because the code is very terse and you do not have all the issues with copy/paste and scrolling like you do in most languages. I experiment quite a bit with programming while on the move (even walking) and I am close to having something which works about as well as normal coding. It takes ideas from K (oK) and different forth implementations.
One of the problems with text-based programming is that it scales rather too well. I've had to deal with C functions which were 1000 lines long. You simply can't abuse a visual language like that. As you approach the Deutsch Limit, the complexity of what you've drawn becomes immediately apparent and you have to think about ways of reducing it, by structuring your code better, e.g. splitting up complex functions into two or more simpler ones.
I'm persistently getting an error "Skov is damaged and can't be opened". I extracted the folder from the disk image to my Desktop. I tried right-click->open with the same result (and Gatekeeper gives a different error anyway).
I'm still on El Capitan. Could that be the problem?
I have just tried it on my older Mac that still runs El Capitan. I downloaded the image from the website, opened it and copied the folder to the desktop. I had the same error as you ("Skov is damaged and can't be opened"). Then I went to System Preferences > Security and Confidentiality and I saw that "Allow applications downloaded from" was set to "Mac App Store and identified developers". I selected "Anywhere" and tried again: it worked. So the problem was really Gatekeeper.
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.
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
Another powerful visual programming language is called VVVV which you can find at https://vvvv.org/ I think they will be shortening it to VL with the next release. I had experimented with it back in 2011 trying to make a poor man's multi touch interface for the PC using an iPad and Touch OSC.
https://www.youtube.com/watch?v=DYEtkJSvZCk
It has a pretty clean/ minimalist UI and one of the more interesting implementations of visual programming.
I wonder if this visual chema will work for more complex projects where one needs to zoom in and out of scope (eg Reaktor). But the potential is excellent and even if it doesn't take off as a hardcore programming environment it will make an excellent educational tool.
This is wonderful for folks who can understand concepts presented to them visually. If I had access to this as a child, I could have definitely grokked functional programming faster :)
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!
Looks great, like a visually pleasing version of Prograph.
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.
I don't know why I thought it would be a visual language to develop on mobile. On desktop, I don't think this is useful. I tried to teach once using Scratch, and the IDE was not the problem, but the logic and the way to think about the problem and solution.
[+] [-] sjayasinghe|9 years ago|reply
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.
[+] [-] sytelus|9 years ago|reply
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.
[+] [-] leovander|9 years ago|reply
[0] http://store.steampowered.com/app/290060/ [1] http://www.zachtronics.com/
[+] [-] DonaldFisk|9 years ago|reply
[+] [-] dirkk0|9 years ago|reply
[+] [-] DonaldFisk|9 years ago|reply
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?
[+] [-] nicolas-p|9 years ago|reply
[+] [-] clappski|9 years ago|reply
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.
[1] https://cycling74.com/products/max/
[2] https://puredata.info/
[+] [-] dkersten|9 years ago|reply
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".
[+] [-] marknadal|9 years ago|reply
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
[+] [-] mrcabada|9 years ago|reply
I just released the beta: https://talkbot.io
How do you avoid wires overlapping other wires on more complex "flows"?
[+] [-] c4n4rd|9 years ago|reply
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)
[+] [-] rg2004|9 years ago|reply
[+] [-] dukoid|9 years ago|reply
[+] [-] kowdermeister|9 years ago|reply
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.
[+] [-] beagle3|9 years ago|reply
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.
[0] http://www.lamdu.org/
[+] [-] tluyben2|9 years ago|reply
[+] [-] DonaldFisk|9 years ago|reply
[+] [-] jbpetersen|9 years ago|reply
Eventually they won't need to.
[+] [-] Fluxenein|9 years ago|reply
[+] [-] matt4077|9 years ago|reply
I'm still on El Capitan. Could that be the problem?
[+] [-] nicolas-p|9 years ago|reply
[+] [-] JasonSage|9 years ago|reply
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.
[+] [-] agumonkey|9 years ago|reply
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
[+] [-] fernly|9 years ago|reply
http://factorcode.org/
[+] [-] tluyben2|9 years ago|reply
[+] [-] opvasger|9 years ago|reply
[+] [-] KenNichols|9 years ago|reply
[+] [-] anigbrowl|9 years ago|reply
[+] [-] dev_throw|9 years ago|reply
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!
[+] [-] paloaltokid|9 years ago|reply
[+] [-] nicolas-p|9 years ago|reply
[+] [-] cormullion|9 years ago|reply
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.
http://www.andescotia.com/examples/
[+] [-] devgutt|9 years ago|reply