Very half baked, even took that demo site featured in the video down. Intended to run hundreds of "channels" of music, each of which could support thousands of independent sessions (think cloud gaming but for audio/music).
Uses Pion WebRTC, Gstreamer, JACK, SuperCollider and a simple Golang API for converting http requests to OSC toggles to manipulate audio running on a cloud server in realtime over the internet.
Questions – is this crazy? Would game makers ever be interested in adopting a third party SDK for their music needs? What if that music had to be streamed over the wire (not baked into their console/mobile client builds)? Is the prospect of game player input influencing the sounds/music they're listening to compelling, or not really?
Do you support the seasonal / annualized quarterly estimated payments tax form? I used that for many years for fluctuating freelance income, but I’ve not seen an app that supports it.
The people behind Dots are an eclectic mix of illustrators, musicians, animators, designers and engineers that believe everyone can enjoy a great game.
We're a happy team with great people in a beautiful office located in downtown Manhattan, with lunch provided four days of the week (breakfast on the other day):
Taleb talks about this (though he doesn't use the term Sortition) in Antifragile: "instead of having the rulers randomize the jobs of citizens, we should have citizens randomize the jobs of rulers, naming them by raffles and removing them at random as well. That is similar to simulated annealing—and it happens to be no less effective. It turned out that the ancients—again, those ancients!—were aware of it: the members of the Athenian assemblies were chosen by lot, a method meant to protect the system from degeneracy. Luckily, this effect has been investigated with modern political systems. In a computer simulation, Alessandro Pluchino and his colleagues showed how adding a certain number of randomly selected politicians to the process can improve the functioning of the parliamentary system."
Although I very much like the idea of sortition I found the paper by Pluchino et al. very flawed, the simulation they made captures none of the effects of sortition, and the effects they measure have no equivalent in the real world.
Just to get an idea, in their model politicians make many laws that help the population a little bit, instead the randomly selected citizen make make laws that help the population a lot, but they make only a few laws. And things have been defined in such a way that the optimal solution happens when mixing the two. They do a pretty good job at analyzing this simulation, the problem is that the simulation has little to do with the real world.
(I read the paper a few years ago so I hope I'm remembering things correctly).
I ask myself this question as it pertains to the future of music. Digital Audio Workstations such as Ableton Live and Logic Pro dominate the scene when it comes to making music with a computer (at least in pop music), and companies such as Splice are trying to create collaborative networks around them.
Text based interfaces and audio programming languages such as SuperCollider open up a whole new world of musical creativity, and would lend themselves to collaboration (IMO) better than GUI based ones. The obvious hurdle for people is learning how to create things/music/art with text.
If the algorithm is to be distributed over multiple processors capable of executing different instructions, it is best represented as dataflow. (Dataflow algorithms are directed graphs, with data flowing along edges between vertices, each of which contains a single processing step.) This is because dataflow captures all the parallelism inherent in the algorithm without the programmer having to assign tasks to processors explicitly. While text-based dataflow languages exist, the directed graphs which comprise dataflow programs are more naturally represented graphically.
Having started down the dataflow route, further advantages then manifest themselves: most program development can be done by drag and drop, rather than typing; strong type checking can be done while edges are being drawn; the directed graphs used to draw code can double as completely general data structures; and the graphics libraries used to develop the language can be made available to the programmer.
Some visual languages, such as DRAKON and GRAIL, are based on conventional flowcharts showing flow of control, rather than flow of data. Flow of control, however, can be adequately represented as text.
You make an important point about the distinction between control flow and data flow. They can both co-exist in a visual programming languages, but many VPLs tend to focus on one or the other.
Grasshopper [1] is very data flow oriented and functional, so you can program loops implicitly by flowing arrays, arrays of arrays, and trees along the wires, and the nodes know how to implicitly iterate over their inputs.
SimAntics (the visual programming language in The Sims) [2] (and I presume Dracon, but I haven't programmed in it) is very control flow oriented and imperative, almost like visual assembly language, and there is an implicit state (like a set of registers or local variables) that travels along with the program counter that flows along the lines between nodes.
A data flow switching "if" statement can be embodied in a data flow programming language as a node that takes three inputs: Condition, A and B, and outputs A if Condition is true, or B if Condition is false. Like "Condition ? A : B".
Or a control flow branching "if" statement can be embodied in a control flow programming language as a node that takes one input: a Condition (or it is activated by a flow of control input and the node contains a condition to evaluate against the VM state, like a flow chart branch node), and outputs the flow of control to A if the condition is true, or B if the condition is false (the road not taken). Like "if Condition goto A else goto B".
Some languages have a mix of both. Body Electric (aka Bounce) [3] is a real time data flow oriented visual programming language used for VR simulations, that primarily uses data flow switching "if" statements. The order of execution of the nodes is implicitly determined by a partial ordering of their dependency graph, and each node has an optional explicit "enable" input and output that you can use to turn on and off the execution of any node (behaving like an on-off switch type of "if" statement), and explicitly wire up the dependencies to control the order of execution (if the order of side effects is important, like for drawing commands).
Grasshopper is a good example of a successful data flow oriented visual programming language, with an excellent user interface, and a vast library of powerful features that elegantly dovetail together. I'm working on a project that uses Grasshopper for 3d printing houses. [4]
I'd caution against casually projecting anything you know about one visual programming language (like "it sucks" or "it rocks") onto any other visual programming language (and especially all other visual programming languages), because they can be EXTREMELY different! (Just like text programming languages.) And a lot of it boils down to ergonomics and user interface design, as well as the vocabulary of built-in primitives and libraries and abstraction mechanisms.
To the degree more eyes makes all bugs shallower, more eyes. That's a big deal when bugs mean people die. Bugs in space flight are likely to be fatal. Drakon takes a sound approach to software engineering as a serious discipline bound by professional ethics.
I did a fair amount of work with LabVIEW long ago. I also played with another visual language for the Mac that was floating around in the 90s. This isn't a slam against LabVIEW, which would be unfair in any event since it's been that long and their product has changed a lot.
Advantage: It seemed easy for beginners to learn how to do simple things, such as sequencing the operations and measurement in a lab experiment or instrument prototype. That's pretty cool.
Disadvantages: 1) For me, I happen to suffer from severe eyestrain and wrist / neck fatigue when dealing with tiny graphics and fine mouse work. I would not be able to program a graphical language all day.
2. My impression that it's hard to modify / refactor code because of the laborious manual effort needed to move graphics around. Programs tend to become unwieldy when they expand beyond one screen.
3. I think that text is the easiest and quickest way to prototype a new programming language idea, and there is rapid evolution and proliferation of both text based languages and programming tools like specialized editors and environments. It's also easier to port a text based language to a new machine. I think that evolution would be slower if people had to develop a graphical framework to try out a new language. It's also very easy to share source code, either full programs or snippets, on the Internet via text, even across different languages with a bit of manual translation.
1. Not all visual languages are the same, just as not all text-based languages are the same. The main problem is there aren't many in widespread use, and they tend to be quite specialized, so you might not find one which you're completely happy with.
2. Programs, or rather functions/procedures/subroutines should, with very few exceptions, be displayable on a single screen. If they are larger, they should be split up. This applies whether the language is textual or graphical. Moving graphics around should make no difference to how a dataflow program executes.
3. Yes, it's easier to develop a new text-based language, because so much research has been done on them, and you don't need to develop an editor along with the language. But there are hundreds in active use, which are constantly evolving. If you want a new set of features, you can add it to an existing language or create your own dialect. Visual code must have either a text or binary representation of the source which can be shared. It may not be human-readable but that's not the intention.
1) I think although LabView is quite useful, it's interaction design is terrible (that users play along only attests to it's utility!)
3) It's essentially a way of displaying code, so perhaps any new languages could reuse the same graph/flowchart environment. But inherently visual languages are designed either towards people who don't want to learn a language or who are performing specific tasks where the graphic flow improves their reasoning. I'd say for the vast majority of 'coding' those are not the case, since the "concept density" is very low (but visual UIs may help a lot of get started programming people anyway).
Having a graphical environment also helps remove a lot of cruft from languages that newcomers shouldn't really have to deal with.
For example, if I want to make a C program to computer the distance between tow points on a plane, I have in my head something like "d=sqrt((x1-x2)^2+(y1-y2)^2); output d", and actually programming I'm going to have to import a couple of libraries to take care of both floating point arithmetic and IO. The only way a novice can know that is looking at an online reference basically; while a decent UI could easily provide a searchable list of math/IO functions and include libraries automatically. Those are always taken care of in visual programming languages. The syntax itself of languages is arbitrary in many ways you have to learn on a case by case basis (in the example, how exactly do you use printf to "output d"?), while in an UI you are forced to use the correct syntax, because it's the only option.
When you are programming an operating system or low level application none of those really matter, but for a newbie making a simple Mobile app it's going to involve googling a lot and copious amounts of copy-pasting templates for getting trivial things done.
Those are valid points. My first language, BASIC, didn't require libraries. You could just enter those two statements and it would figure out the libraries and types required, from the context. It was my understanding that the additional "overhead" of C is to direct the compiler to make more efficient code, and to head off certain kinds of failures of larger programs.
But still, I think your point stands. The tools that beginners like to use, whether the underlying "language" is represented by text or graphics, tend to be fairly self contained with zero overhead and a built in lookup system for library functions and user interface design, and those systems tend to be implemented as graphical software.
Code completion evolved from a graphically structured language, AlicePascal, for this reason. We've been adding visual features into our text based lnaguages via tooling for quite some time.
I have some professional experience using a visual programming language on the same files with many coworkers. Here are the biggest pain points I experienced:
Diff, merge, search/replace, copying code directly from chat or websites into a REPL or file to try it out.
I have used a handful of other visual languages and when I see a new one I am on the lookout for use cases that involve more than one programmer, sometimes not even knowing each other; features that make it compatible with existing file and line oriented version control systems or provide an alternative(which is a project in itself, hard, and might not be as modular)
Learning about visual programming languages gave me a new appreciation for the simple elegance of text and IMHO the future of them will be those that easily map back and forth between text and graphics so you can have the best of both worlds and continue to stand on the shoulders of giants.
Does anyone konw of languages that translate to/from text well?
I'm in the same position with similar circumstances. You did what you had to do - instead of going back to school and learning the theory, you decided to focus on the problem and build practical solutions in the form of prototypes/mvps. There's no shame in that.
My approach will be to stay humble and eager to learn. I want to hire people smarter than me so that I can grow by working with them.
