Visual Programming – Why It's a Bad Idea - <AUTHOR> http://mikehadlow.blogspot.com/2018/10/visual-programming-why-its-bad-idea.html <comment><USER2> Visual programming languages will only take you so far, but often that is far enough. What the author misses is that we as professional programmers miss the success stories, because we only get called in when the boundaries have been reached.

In my career I've often been asked to rewrite Access DBs, InfoPath forms, or SharePoint sites developed by amateurs into something more usable. My early reactions where along the lines of "what insane person tried to do this in Access." I realized at some point that was the wrong approach in my thinking. These systems are working software delivering value. I now say "wow, congrats on doing so much on your own. Let me help you take this further."

<comment><USER3> I think the broader, opposing point you bring out is that visual programming is perfectly suitable for specific scopes of computational modeling, and that's just because they're DSLs, and we already know DSLs are the right choice for a number of problems. I'd like to know who the author things they're engaging with on the points they're making.

<comment><USER4> I disagree that DSLs are the right choice unless it's an extension to the suitably flexible implementation language itself.

Actually, the perceived need for "dumb" DSLs is sprung from the same misconceptions as mentioned in the article and the end result is inevitably that simple problems are made somewhat simpler and complex problems turn into impossible problems.

A proper DSL extension in an unobtrusive host language is another thing but also hard to find. If a Lisp syntax is acceptable then that's the canonical example.

I don't want to get depressed overe all misconcieved excuses for test automation languages, process automation, configuration templating systems, etc, so I'll just stop here.

<comment><USER5> Obviously these are sweeping statements, but the problem with this generalization is that successful DSLs become invisible because we take them for granted. Regular expressions are a DSL. SQL is a DSL. LaTeX is a DSL. The Wikipedia page on domain-specific languages even lists HTML as an example: [https://en.wikipedia.org/wiki/Domain- specific_language#Examp...](https://en.wikipedia.org/wiki/Domain- specific_language#Examples)

With regard to LaTeX or HTML, you could even argue that their goals could be better accomplished with some sort of graphical interface, which sounds a lot like… visual programming!

<comment><USER6> Geometric constraint solvers are essentially graphical, declarative domain- specific languages for mechanical/physical design. As an example: [http://solvespace.com/index.pl](http://solvespace.com/index.pl)

</comment></comment></comment></comment></comment><comment><USER7> There is more to visual programming than simple wire diagrams and "code- blocks-as-visual-blocks":

[https://www.youtube.com/watch?v=6orsmFndx_o](https://www.youtube.com/watch?v=6orsmFndx_o)

[https://www.youtube.com/watch?v=I9LZ6TnSP40](https://www.youtube.com/watch?v=I9LZ6TnSP40)

[https://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.h...](https://alumni.media.mit.edu/~mt/thesis/mt-thesis- Contents.html)

[http://worrydream.com/](http://worrydream.com/)

And yes, this: [http://www.fantasticcontraption.com/](http://www.fantasticcontraption.com/) This is not 100% real programming, because it does not include sensors, but you do create constructs that interact with the environment and accomplish goals. It's close enough to show what's possible with certain interfaces.

Long-term: [https://dynamicland.org/](https://dynamicland.org/)

There have been much fewer resources allocated to the development of these concepts. Mostly for historic reasons.

The sad reality is that both critics and proponents of visual programming are often uninformed about prior work, user studies and related research rooted in cognitive and developmental psychology.

<comment><USER8> There's so much interesting prior work!

I really enjoyed this paper "A Taxonomy of Simulation Software: A work in progress" from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems.

[http://donhopkins.com/home/documents/taxonomy.pdf](http://donhopkins.com/home/documents/taxonomy.pdf)

It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favorites, Rockey's Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I'd never seen before:

[http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S...](http://chaim.io/download/Gingold%20\(2017\)%20Gadget%20\(1\)%20Survey.pdf)

I've also been greatly inspired by the systems described in the classic books "Visual Programming" by Nan C Shu, and "Watch What I Do: Programming by Demonstration" edited by Alan Cypher.

[https://archive.org/details/visualprogrammin00shu_2pf](https://archive.org/details/visualprogrammin00shu_2pf)

[https://archive.org/details/watchwhatido00alle](https://archive.org/details/watchwhatido00alle)

Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32:

C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion

[http://www.cs.cmu.edu/~bam/acronyms.html](http://www.cs.cmu.edu/~bam/acronyms.html)

Also, here's an interesting paper about Fabrik:

[https://donhopkins.com/home/Fabrik%20PE%20paper.pdf](https://donhopkins.com/home/Fabrik%20PE%20paper.pdf)

Danny Ingalls, one of the developers of Fabrik at Apple, explains:

"Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might 'tick' many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"

<comment><USER9> We could go back farther with Sutherland's SketchPad (early 60s) and Smith's Pygmalion (mid 70s).

There are also a lot of disparate visual programming paradigms that are all classed under "visual", I guess in the same way that both Haskell and Java are "textual". It makes for a weird debate when one party in a conversation is thinking about patch/wire dataflow languages as the primary VPLs (e.g. QuartzComposer) and the other one is thinking about procedural block languages (e.g. Scratch) as the primary VPLs.

<comment><USER8> Absolutely, their important work foreshadowed and inspired so much great stuff. Also Douglas Engelbart's NLS pioneered many of the ideas of visual programming.

I think spreadsheets also qualify as visual programming languages, because they're two-dimensional and grid based in a way that one-dimensional textual programming languages aren't.

The grid enables them to use relative and absolute 2D addressing, so you can copy and paste formulae between cells, so they're reusable and relocatable. And you can enter addresses and operands by pointing and clicking and dragging, instead of (or as well as) typing text.

Some people mistakenly assume visual programming languages necessarily don't use text, or that they must use icons and wires, so they don't consider spreadsheets to be visual programming languages.

Spreadsheets are a wildly successful (and extremely popular) example of a visual programming language that doesn't forsake all the advantages of text based languages, but builds on top of them instead.

And their widespread use and success disproves the theory that visual programming languages are esoteric or obscure or not as powerful as text based languages.

Other more esoteric, graphical, grid-based visual programming languages include cellular automata (which von Neumann explored), and more recently "robust first computing" architectures like the Moveable Feast Machine.

[https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton](https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton)

[https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...](https://en.wikipedia.org/wiki/Von_Neumann_universal_constructor)

Robust-first Computing: Distributed City Generation (Moveable Feast)

[https://www.youtube.com/watch?v=XkSXERxucPc](https://www.youtube.com/watch?v=XkSXERxucPc)

>A rough video demo of Trent R. Small's procedural city generation dynamics in the Movable Feast Machine simulator. See [http://nm8.us/q](http://nm8.us/q) for more information. Apologies for the poor audio!

Programming the Movable Feast Machine with λ-Codons

[https://www.youtube.com/watch?v=DauJ51CTIq8](https://www.youtube.com/watch?v=DauJ51CTIq8)

>λ-Codons provide a mechanism for describing arbitrary computations in the Movable Feast Machine (MFM). A collection of λ-Codon molecules describe the computation by a series of primitive functions. Evaluator particles carry along a stack of memory (which initially contains the input to the program) and visit the λ-Codons, which they interpret as functions and apply to their stacks. When the program completes, they transmute into output particles and carry the answer to the output terminals (left).

</comment></comment></comment></comment><comment><USER5> Various links related to this have come up in the past few days, and I think they mostly betray a lack of understanding of the weaknesses of text-based programming, and a lack of imagination as to how visual programming could actually work.

One person who's done a lot of thinking about this is Bret Victor, and I encourage anyone interested to watch his videos: [http://worrydream.com/](http://worrydream.com/)

Here's a project that's trying to split the difference between visual programming and text-based programming: [https://luna-lang.org/](https://luna- lang.org/)

<comment><USER10> Thank you jakelazaroff for mentioning Luna <3 ! We, at Luna, are trying to blend the difference between text and visual programming, allowing people to choose the best tool for their use case – visual representation for high-level system modeling and textual representation for low-level components.

Personally, I've been creating visual programming languages for years for such domains as visual effects, allowing artists (people with very limited / none programming skills) to create outstanding physics simulations systems or automated geometry processing by their own. Seeing people being able to create something that was so far not accessible for them is amazing.

Readers of this topic might also be interested in reading our blog post about why visual languages are actually very useful here: [https://medium.com/@luna_language/luna-the-visual-way-to- cre...](https://medium.com/@luna_language/luna-the-visual-way-to-create- software-c4db520d6d1e)

</comment></comment><comment><USER11> Tools for visual programming have seen massively less effort spent on them than text-based tools. This is why text-based tools have much more conveniences, and better integration, than visual-oriented tools.

Another important aspect is that humans use words to communicate, so some amount of text is inevitable (and welcome) in visual programming tools.

Also, text-based tools use the most common and open format of all, a stream of ASCII (UTF-8) characters. This allows to mix and match text-based tools (editors, compilers, formatters, linters, etc). Visual languages were (and are) dominated by proprietary formats. This keeps visual programming tools in silos, profitable for the vendor but preventing the wild expansion that text- based programming languages periodically enjoy.

</comment><comment><USER12> I'm not a visual programming proponent, but I don't think this article does a very good job of supporting its thesis. It exclusively makes claims about current VP implementations and tries to extrapolate them to VP in the abstract, but I think these are all non-sequiturs. I specifically think the article fails to distinguish between the dual problems of _modeling a program_ (hard) and representing that model visually vs textually.

For example, the article claims that the idea behind scratch is that programming is fundamentally easy but text makes it hard. I don't think that's the idea at all, but rather that programming (i.e., modeling a program) is fundamentally hard, but the difficulty is compounded because text is not a natural way for the current crop of humans to think about a program.

Another example is his criticism of the failure of enterprise UML tools-- presumably the problem with these is that UML is just not a very good way of _modeling a computer program_, regardless of whether the interface to UML is visual or textual.

Another example is the criticism that the current crop of VP tools are procedural. Why can't a visual programming language be functional?

Another is the claim that VP is bad because the current crop of tools combines visual and textual programming (I'm not sure this is even true; I don't recall LabVIEW requiring text, for example). Is there any fundamental reason a programming model can't be purely visual? Why can't you represent a whole programming model (all the way down to primitives) visually?

I think most of these would be solved with more trial and error and more investment; none of these support the thesis that VP is fundamentally a bad idea.

To be clear, I think this article has a lot to offer people who are trying to solve visual programming issues, but it doesn't make the case that it sets out to do--that visual programming is fundamentally a waste of time.

<comment><USER13> "Why can't a visual programming language be functional?" \- there is one: [https://luna-lang.org/](https://luna-lang.org/) and it also has a dual textual/visual representation.

</comment></comment><comment><USER8> Years ago I developed a visual interface to an existing non-visual language, the multi threaded object oriented dialect of PostScript in the NeWS window system. Since PostScript is homoiconic, the data viewers and editors could also be applied to code!

It didn't try to replace text based PostScript programming, just augment it: there was an interactive shell window you could type expressions to, which had a stack "spike" sticking out of it representing the PostScript stack, which would update in response to the commands you typed, or you could drag and drop objects to manipulate the stack and the state of the system.

You could perform "direct stack manipulation" by dragging objects up and down or on and off the stack, open up nested objects and functions in an outliner, adjust the point size and formatting style, open up special editors on data and code, drag and drop objects and code around, etc. It was like a live Smalltalk system, in that you could explore (and vandalize) the entire state of the window system, and use it as a debugger to inspect and modify and debug processes of other NeWS clients (including itself).

[https://medium.com/@donhopkins/the-shape-of-psiber-space- oct...](https://medium.com/@donhopkins/the-shape-of-psiber-space- october-1989-19e2dfa4d91e)

</comment><comment><USER14> In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

<comment><USER15> LabVIEW is a... toy for children.

<comment><USER16> Don't be rude.

LabVIEW is used in production in a lot of serious environments.

<comment><USER15> I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code.

LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.

<comment><USER17> I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it _just works_ and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from.

Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff _built in_ getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.

<comment><USER15> I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.

<comment><USER17> Well, enlighten us then. What is the right way according to you? In case of my example: what is a better way than getting things done in a few hours, with no bugs whatsoever, with all functionality needed, and just working? I'm actually truly curious as to what would be better and more right.

<comment><USER15> To begin with, the labview run time is riddled with bugs. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason.

Yes, drawing out some things in a visual IDE and having it work is nice. The problem is that eventually LabVIEW is going to update their runtime and it won't work anymore. Now what?

Take the time and do it right up front, and then when it needs to be updated people aren't cursing "whoever decided to do this in LabVIEW years ago" as they often do in these situations.

<comment><USER17> _do it right up front,_

Ok, but again what do you suggest is 'right' then, any example? Because as laid out, for me, it is right, since we have zero problems.

 _Every application I 've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason._

Hmm, strange. Sounds to me like those creators must be doing something wrong. I mean, we've been running a couple of Labview applications for +10 years and I honestly think none of them _ever_ crashed (where 'crash' means suddenly stops working without apparent reason because of a bug in Labview itself, not come to a halt due to programmer error). Also wen to, I don't know, 3 or 4 updates, without much problems. Again I think it just comes down to hwat I said first: the hard part might be fuguring out how to do Labview right, I guess.

<comment><USER15> Or the labview runtime is absymal and broken and you simply haven't tripped over any of its thousands of broken cases in the minimal use of it you've done.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Hi! I'm Wojciech Danilo, one of the founders behind Luna language ( [http://luna-lang.org](http://luna-lang.org) ). I'd love to share with you our blog post about why actually visual programming languages could be very useful: [https://medium.com/@luna_language/luna-the-visual-way-to- cre...](https://medium.com/@luna_language/luna-the-visual-way-to-create- software-c4db520d6d1e)

We've been building visual languages in the past for people in different industries, including Visual Effects one. Watching people with limited programming skills to create outstanding things on their own is truly amazing.

</comment><comment><USER18> _Pros_

The author well formulates the limitations of VPLs (Visual programming languages).

 _Cons_

The rant seems to jumble in VPLs for general purpose programming with VPLs for domain-specific usecases. So although VPLs may be "a bad idea" for general purpose computing and does a good job of explaining its downsides, it is a little reckless in saying VPLs are a bad idea overall.

The author also offers two straw man arguments to make their point, though I don't believe that these things are common misconceptions at all:

1) Abstraction and decoupling play a small and peripheral part in programming.

2) The tools that have been developed to support programming are unimportant.

Lastly, the author uses Scratch as its representative VPL example, even though it is probably the most far removed from "Visual Programming" and more in line with something I'd call "Block-Based Programming". These are far from equivalent and a poor choice to use for talking about general purpose VPLs (though the author does admit that it may have been a poor choice later).

<comment><USER19> Arrays and Objects and trees and everything else in an AST (including the AST itself) are shapes.

Shapes are better built with our hands. They're often filled with text, which is more easily said than written.

Someone can already use a visual programming language to simulate the _ocean_ in UE4 in 2018, in 20 years we'll have a mainstream general purpose visual programming language. More people might be using a visual programming language to make their AST than a keyboard, which is as comparatively cumbersome to gestures/talking as punchcards are to keyboards.

<comment><USER18> UE4 blueprints are an example of a domain-specific VPL that I've mentioned above (a good example of where VPLs can work great). They however do not solve the problem of working with abstractions well- UE4 blueprints are akin to, how the author put it, "property dialogue programming".

So far, any attempts to model abstractions for general purpose VPLs have ended up more difficult to parse and read than textual code (that argument can also be made for UE4 Blueprints[0]).

Talking about "shapes are better built with our hands" isn't a solid argument for why general purpose VPLs are bound to happen. Note, too, that I would love for them to.

[0] [https://blueprintsfromhell.tumblr.com/](https://blueprintsfromhell.tumblr.com/))

<comment><USER19> Sorry, why isn't it a solid argument? I'm imagining building an AST representation that looks like our current one, since there's less abstraction, but using our hands and voice. Optimising the appearance can come later.

</comment></comment></comment></comment><comment><USER20> > The lack of good source control is another major disadvantage of most visual > programming tools.

I think this is underselling the point.

Lack of good source control is a _non-starter_ for any programming paradigm. If you want to do visual programming or any other kind of programming that doesn't dovetail with directory tree of text files, you are not going to get anybody serious to work with you until you fix that problem.

The first problem you should solve is not how to compile the code, nor how to debug the code, but how to store it.

<comment><USER21> Jupyter notebooks is a counterexample. Its annoyingly unfriendly to source control, but is still quite popular (and growing).

<comment><USER20> There are a lot of very complicated documents and visual displays that can be built by a collaboration of 2 or 3 people where word of mouth suffices to deal with problems of simultaneous edit. Effectively it's ad-hoc optimistic locking with a coordination phase.

None of these models scale to teams of 10, 20, 100 people. Even at 4 they begin to become tedious.

The biggest problem with software developers is confusing "successful" with "applicable to everybody", and this is a prime example. It doesn't matter if it's successful. It's not applicable to my work. Excepting, perhaps, for Wiki- like workflows, which are less than 10% of my duties.

</comment></comment></comment><comment><USER22> Matrix/EA used a visual language for Spore. [http://puredata.info/exhibition](http://puredata.info/exhibition)

Pure Data (Pd) is a visual programming language developed by Miller Puckette in the 1990s for creating interactive computer music and multimedia works

[https://en.wikipedia.org/wiki/Pure_Data](https://en.wikipedia.org/wiki/Pure_Data)

This is the one shinning example where a visual language actually accomplishes something that a general language can't not. Make programming accessible to creative people.

This is the only visual language that I felt was worth learning.

<comment><USER8> Also, Cycling '74's Max is a commercial visual programming language that shares a lot of concepts and designs with PD (which you could think of as a free implementation of Max, but ideas have flowed both ways).

[https://cycling74.com/](https://cycling74.com/)

On the topic of procedural sound, you might enjoy this talk about Generative Systems with Will Wright and Brian Eno:

[https://www.youtube.com/watch?v=UqzVSvqXJYg](https://www.youtube.com/watch?v=UqzVSvqXJYg)

At Maxis, we also developed a bespoke visual programming language for The Sims (first used in SimCopter), called "SimAntics".

We never officially released "Edith", the version of The Sims with the object editing and visual programming tools built in, but users have reversed engineered the byte code, and developed text based tools for programming custom objects with SimAntics.

[http://simantics.wikidot.com/wiki:introduction-to- simantics](http://simantics.wikidot.com/wiki:introduction-to-simantics)

[http://modthesims.info/wiki.php?title=SimAntics](http://modthesims.info/wiki.php?title=SimAntics)

Here's a transcript and video demonstrating it:

The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo

This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that Don Hopkins developed for The Sims with Will Wright at Maxis and Electronic Arts.

Link to "Edith Sims Programming Tool" section:

[https://medium.com/@donhopkins/the-sims-pie- menus-49ca02a74d...](https://medium.com/@donhopkins/the-sims-pie- menus-49ca02a74da3#719c)

</comment></comment><comment><USER23> I personally think node based programming is suitable for DSL, high level plumbing, data visualization (imagine Jupyter cells but having branches). The best visual programming language is UE4 Blueprint: prototype quickly, great debugging experience (great tooling in general), communicate with C++ easily, intellisense... It's really productive to glue stuff together but not that helpful for "drawing" all the core logic. VSP is good but not for every use- cases.

<comment><USER24> Exactly this. The best example here is NodeRed, Javascript underneath and a dataflow UI on top.

You can get connectors for pretty much anything eg. Raspberry pi robot/ home automation, twitter, http, email, mqtt, SQL, openCV, parallel processing.

The dashboard allows you to create UIs visually, and I've ported it to run on Android + IOS:

[https://github.com/alexisread/noreml](https://github.com/alexisread/noreml)

<comment><USER24> EDIT: Ran out of time to finish the comment:

Allowing this to run on mobile means that you can develop/monitor systems on mobile, cluster the systemsphone with other nodered instances, and develop mobile apps (the package is basically nodeJs, nodered and a cordova webview which can be hooked up to display the nodered dashboard).

The important things to note here are that the underlying language to the visual DSL is flexible enough to do everything, and standard ways of building visual extensions (aka nodes) exist.

The main thing missing on the Dashboard is a table node, which would allow a much more flexible layout of data (sorting, trees etc).

</comment></comment></comment><comment><USER25> > The final misconception is that visual programmers can do without all the > tools that have been developed over the decades to support programming. > Consider the long evolution of code editors and IDEs. Visual Studio, for > example, supports efficient intellisense allowing the look-up of thousands > of APIs available in the base class library alone.

I think this point the author makes is an interesting one because I see it form a different perspective. I think the biggest issue is that we mix presentation with representation.

> The lack of good source control is another major disadvantage of most visual > programming tools. Even if they persist their layout to a textual format, > the diffs make little or no sense.

At the same time tabs vs spaces is still a thing. In languages which aren't whitespace sensitive, the diffs similarly don't make any real sense in my opinion.

I believe (and have no idea how to implement) that the representation of a programming language should be modified more directly and the rendered presentation (textual, visual, interpretive dance) should be irrelevant to the tooling.

</comment><comment><USER26> seems from the bottom of the post, since he posted a picture of scratch (which is a fantastic tool!) that the author really just has an opinion about this and actually hasn't done really solid research and measured anything by actual outcomes.

The block based visual programming embraced by scratch and things like the BBS micro:bit are really good, my 7 year old son can do really cool things with these systems (also check out the new beta [https://beta.scratch.mit.edu/](https://beta.scratch.mit.edu/) which is done with React for anyone interested )

You can even add this kind of visual block based coding into your own systems using something like [https://developers.google.com/blockly/](https://developers.google.com/blockly/)

I think it's a little shortsighted to think just because there's been tools that didn't really work out too well that the idea is bad

<comment><USER8> One of the coolest ways to learn programming I've ever seen is the Snap! visual programming language, which is written in JavaScript and runs in the browser.

Snap! is a visual "blocks" programming language like Scratch, but with the full power of Scheme: First class functions.

It's the culmination of years of work by Brian Harvey and Jens Mönig and other Smalltalk and education experts. It benefits from their experience and expert understanding about constructionist education, Smalltalk, Scratch, E-Toys, Lisp, Logo, Star Logo, and many other excellent systems.

Snap! takes the best ideas, then freshly and coherently synthesizes them into a visual programming language that kids can use, but is also satisfying to professional programmers, with all the power of Scheme (lexical closures, special forms, macros, continuations, user defined functions and control structures), but deeply integrating and leveraging the web browser and the internet (JavaScript primitives, everything is a first class object, dynamically loaded extensions, etc).

Visual lexical closures.

User defined blocks including control structures.

Macros and special forms.

Call with current continuation!

Written in JavaScript and easy to integrate with JavaScript libraries.

[https://snap.berkeley.edu](https://snap.berkeley.edu)

Adding Machine Learning Blocks to Snap!

[https://s4scoding.com/adding-machine-learning-blocks-to- snap...](https://s4scoding.com/adding-machine-learning-blocks-to-snap/)

[https://project.ecraft2learn.eu/](https://project.ecraft2learn.eu/)

[https://github.com/ecraft2learn/ai](https://github.com/ecraft2learn/ai)

[https://ecraft2learn.github.io/ai/](https://ecraft2learn.github.io/ai/)

ProgKids is a Russian site that integrates Snap! (and Python) with Minecraft, so kids can visually program 3d turtles that move around in the world and build things!

[https://progkids.ru](https://progkids.ru)

ProgKids. Строим дом, а потом ещё пару (Building a house, then another couple)

[https://www.youtube.com/watch?v=muNpsk4UH7c](https://www.youtube.com/watch?v=muNpsk4UH7c)

ProgKids. Куда же без зверей? (Why do you not have animals?)

[https://www.youtube.com/watch?v=1iBFwaUSDYI](https://www.youtube.com/watch?v=1iBFwaUSDYI)

ProgKids. Как работает Snap? (How does Snap work?)

[https://www.youtube.com/watch?v=lh0mrqxFImQ](https://www.youtube.com/watch?v=lh0mrqxFImQ)

More links and stuff I've written about it on HN:

[https://news.ycombinator.com/item?id=17594403](https://news.ycombinator.com/item?id=17594403)

<comment><USER26> cool... what strikes me about a number of these block based programming tools is they are quite approachable and complex functionality is not that hard to look at and know what's going on

</comment></comment></comment><comment><USER27> [https://www.mendix.com/](https://www.mendix.com/) Seems to be cleaning up on the concept. I've seen two start-ups now using it and the turn-around times for features were definitely impressive. The problems with such solutions are always long term maintenance, scalability and lock-in.

</comment><comment><USER28> Going from text to visual programming only takes you from (sort of) one dimension up to two dimensions. That isn't much of an advantage for complex code where the "dimensionality" (for lack of a better term) is much higher than 2D.

Perhaps the growth of VR and other 3D interfaces will breathe new life into visual programming?

<comment><USER8> David Ackley, who developed the two-dimensional CA-like "Moveable Feast Machine" architecture for "Robust First Computing", touched on moving from 2D to 3D in his retirement talk:

[https://youtu.be/YtzKgTxtVH8?t=3780](https://youtu.be/YtzKgTxtVH8?t=3780)

"Well 3D is the number one question. And my answer is, depending on what mood I'm in, we need to crawl before we fly."

"Or I say, I need to actually preserve one dimension to build the thing and fix it. Imagine if you had a three-dimensional computer, how you can actually fix something in the middle of it? It's going to be a bit of a challenge."

"So fundamentally, I'm just keeping the third dimension in my back pocket, to do other engineering. I think it would be relatively easy to imaging taking a 2D model like this, and having a finite number of layers of it, sort of a 2.1D model, where there would be a little local communication up and down, and then it was indefinitely scalable in two dimensions."

"And I think that might in fact be quite powerful. Beyond that you think about things like what about wrap-around torus connectivity rooowaaah, non-euclidian dwooraaah, aaah uuh, they say you can do that if you want, but you have to respect indefinite scalability. Our world is 3D, and you can make little tricks to make toruses embedded in a thing, but it has other consequences."

Here's more stuff about the Moveable Feast Machine:

[https://news.ycombinator.com/item?id=15560845](https://news.ycombinator.com/item?id=15560845)

[https://news.ycombinator.com/item?id=14236973](https://news.ycombinator.com/item?id=14236973)

The most amazing mind blowing demo is Robust-first Computing: Distributed City Generation:

[https://www.youtube.com/watch?v=XkSXERxucPc](https://www.youtube.com/watch?v=XkSXERxucPc)

And a paper about how that works:

[https://www.cs.unm.edu/~ackley/papers/paper_tsmall1_11_24.pd...](https://www.cs.unm.edu/~ackley/papers/paper_tsmall1_11_24.pdf)

Plus there's a lot more here:

[https://movablefeastmachine.org/](https://movablefeastmachine.org/)

Now he's working on a hardware implementation of indefinitely scalable robust first computing:

[https://www.youtube.com/channel/UC1M91QuLZfCzHjBMEKvIc-A](https://www.youtube.com/channel/UC1M91QuLZfCzHjBMEKvIc-A)

<comment><USER29> Thanks for sharing these links. I first came across David Ackley watching the Artificial Life II Video proceedings from 1992, where he was demoing an agent- based simulator. So it's interesting (and quite amazing) to see how far his research has expanded in the past 26 years.

</comment></comment></comment><comment> d--b What does visual mean? A text file is a 2D set of characters, so if you consider it that way everything is visual. What are brackets, if not visual markers of blocks that start and end? What is code coloring if not visual aid to help with typing?

Programming is visual, full-stop. The main reason why "visual programming didn't catch on" is because there can't be a semantic equivalent to placing programming elements on a 2D grid. A program executed things On sequence, so it's convenient to program top to bottom. That's why text is better suited to represent it.

Dataflow programming is not generally executing in sequence. And that's where visual programming shines.

</comment><comment><USER8> Spreadsheets are visual programming languages, and they seem pretty popular.

The economy would collapse if you took them away, so I think that's a pretty good measure of how important and widely used they are.

</comment><comment><USER30> A preface before you read this- it's just a long joke :)

I wonder if instead of new programming languages or VPLs aren't the problem, but lack of meta data structures (going beyond a class or interface) that tie together data with expected structure and their implicit validations (including relateable data) to code that performs business rules (booking airplane tickets) and code that draws a UI (ticketing screen).

I know about 10-15 years back this was called "4GL" (fourth generation languages) but instead of that taking off, a sludge of just new procedural programming languages took hold (rust go ts etc..). I think VPL tries to fill that same niche space where the goal is to think meta-like, not procedurally about each input box. If the system understands and records data in similar ways, we can eventually get to a place where data is ubiquitously stored in the structure the system defines, not the programmer defined way.

So while right now we may not have the correct primitives for 4GL or VPL, maybe one day and that's why these ideas won't die - because it is likely going to be the way that software is designed in the far (or near?) future. Especially in the wake of AI where we might have a chance to let the system write the UI/business logic.

In other words, instead of thinking of AI as writing code in C/C++/Rust, etc.. AI will be in charge of moving data - at first in human defined chunks (likely spec'd out in VPL or 4GL structures), but eventually for AI to define its own objects of related structures. Eventually getting to the point where us mere humans ask AI to build things that fit human process.

The last step is that humans would no longer define the process, and AI be able to incrementally add processes with the data it has, by defining the most optimal path for humanity whether it be tax rates or human production or smoothing out effects of electricity futures based on incoming solar mass ejection predictions. Eventually in the final stages of humanity, defining the work output each human needs to make during a day. By this point enough people will have opted out and the giant war between the owners of AI and the people will start. Killing off most people, but at the same time many of the oligarchs will have been assassinated by members of the public that were willing to rip out their tracking chips in the left eye.

Enough of the planetary population will be gone and totally untrusting of anyone, but we'll have finally visioned our AI future. Won't it be grand!

Oh sorry off topic again yeah we probably should stay away from Visual Programming.

</comment><comment><USER31> The auther of this poor article, is extremely blinkered and lacking in imagination. Just 5 minutes watching a demo of the incredible power of modern games engine, such as Unreal, blows to smithereens, the whole premise of this article. Has he never wondered into an accounting department? Not seen an Excel workbook running a business? Or seen designers and their viusal tools. A shame though, that Microsoft can't be bothered to update the ancient appalling VB editor that ships with Excel.

</comment><comment><USER32> This sounds analogous to the argument that mathematicians used to have: whether abstraction trumps intuition, especially in geometry.

For instance, you can't really plot a 25-dimensional object, but the same object is trivial to manipulate with equations.

It's clear to most people that both approaches have their place. In geometry, the visual component is very important to develop important intuitions about how objects behave in low dimensional space. On the other hand, if one were to insist on the visual, one would be stuck with purely intuitionist ideas and never be able to move into more complicated realms where you cannot visualize objects graphically (e.g. high-dimensional space).

The Bourbaki group was a group of mathematician who aimed to put mathematics on a rigorous foundation by developing the abstractions that shaped modern math, and by moving mathematics past its intuitionist foundations. Some argue that this caused modern "geometers" to lose their feel for geometry because everything became about symbols. But without this development, a lot of modern discoveries might not have been possible.

</comment><comment><USER33> Our company develops a software for alarm receiving centers. In our software our customers can use a visual code editor [http://pfau.de/images/beispiel002.gif](http://pfau.de/images/beispiel002.gif) to program their own processes for alarm reactions. That is actually our main selling point. They can control the user interaction (what to do, who to call, etc) in reaction to an alarm, access all the data to change process outcomes in response to data or user interaction and automate a lot of processes (filling forms, mailing reports and even automated invoices). They can even call external programs (on other computers) and fill and read databases to interact with other systems. That generally works well as long as people use simple flows and standardise a lot. But as soon as people start to program complex flows you can really see who is a "programmer in disguise" and who is "just a user thrown in way over his head".

<comment><USER34> It feels like it's easier to understand a complete process flow like this visually; sure a developer could probably implement individual steps for a complicated workflow faster as code, but only if they already understand how the process needs to flow in the first place. The visual paradigm almost acts to shortcut the need for a developer to "get in the zone" and load up a mental model of decision tree, but at the cost of a more rigid implementation model (you have to work within the framework of the UX that you're provided, and pretty much any GUI will fail to keep up with the speed the most advanced users "could" work at). On the other hand, I can't imagine implementing something like your example graphic in code without at least whiteboarding it out ahead of time, which is effectively just an analog way of doing visual programming.

</comment></comment><comment><USER35> source control is the biggest problem with visual programming. i remember doing something we eclipse modelling tools which actually supported merging of models but you just lose so much going from languages that are supported by the existing text based eco-system to languages that are not.

<comment><USER36> Is this an inherent difference, though, or "just" due to current source control systems being built with text in mind?

<comment><USER37> It's also an issue with the final output of these tools being text, instead of reified computer models.

</comment></comment></comment><comment><USER38> I remember the first programming languages I used (when I was very young) were visual. I think Flowol at primary (elementary) school was the first. They gave me a pretty much instant understanding of how imperative programming worked. Admittedly, I never created anything practically useful in it, but what's important is that I could imagine, from early in my life, what programming could do / was for, and put it on my cognitive radar.

As a child I was more inspired by seeing the inner workings of something than being told X was possible if you learn to code. Visual languages can better expose the guts of the working automaton.

That said, I agree that [current] visual programming languages have shortcomings that limit them to simple / educational scenarios.

</comment><comment><USER39> To this day, I'm amazed at the things that were done with Access, and horrified by the things I've seen in Lotus Notes.

It really just depends. What visual systems provide is accessibility for novices to create value. That sometimes means planning to replace them, or enhance them with skilled developers. In my mind, it creates jobs. Not always great jobs, but at least security in that Software Development will always be a viable career, with lots of opportunities.

</comment><comment><USER40> There's no one-size-fits-all for programming. FWIW, I can recall a project where one piece was built visually (SSIS) and I enjoyed working with it.

<comment><USER41> I've not been a fan of visual programming in the past (and I'm not a huge fan of SSIS) but I did a project recently that included both Microsoft Flow and Azure Logic Apps and was pleasantly surprised at how quickly you can build something rather powerful.

The key as far as I can see is not to allow things to get too complex and call out to "real" code components over a certain level of complexity.

</comment></comment><comment><USER42> For me personally, I can see a theoretical benefit to visual programming languages - because I already think of code mostly in terms of shapes created be the flow of data. I've just never seen one that really matches my mental model, and trying to see myself using one of them seems like it would end more as a fight with the language than any actual benefit.

</comment><comment><USER43> Well I always liked Authorware [1]. Maybe it was very media (CD/DVD) orientated but I really liked how you could see the flow of the program.

[1] [https://en.m.wikipedia.org/wiki/Adobe_Authorware](https://en.m.wikipedia.org/wiki/Adobe_Authorware)

</comment><comment><USER44> This article is poorly researched (the only "visual" tool it mentions is scratch???) and pretty lazy in considering the merits of extratextual programming. It's worrying that something of this quality resonates with people.

<comment><USER45> _> It's worrying that something of this quality resonates with people._

I wouldn't be worried about that. Just because people are reading it doesn't mean they are agreeing with the conclusion. It's all just stuff to think about.

Where it becomes worrying is when people _vote_ for something of that quality.

</comment></comment><comment><USER46> In the early days of KloudTrader, we attempted to use Visual Programming too.

[https://web.archive.org/web/20171006072839/http://www.kloudt...](https://web.archive.org/web/20171006072839/http://www.kloudtrader.com:80/)

The main difficulty was scale and tradeoffs between power vs ease-of-use. We spent a lot of time creating "subroutine blocks" for the most commonly used functions and optimizing for UI/ease of use that we weren't doing much else. Furthermore, pretty much every integration, library etc. had to be converted into its visual equivalents for the language to be of any use and all the linear algebra/candlestick libraries were taking up so much time that the rest of the product was suffering. Stuff that often makes sense to a professional programmer had to be "simplified" so the UX is more optimal. E.g. data structures.

If you look at VPLs in production, there's a reason most of them tend to be "imperative commands only" i.e. a glue language that mainly strings together other subroutines. The concept of objects, or even structs is completely eliminated in the VPL.

[http://www.ni.com/getting-started/labview-basics/data- struct...](http://www.ni.com/getting-started/labview-basics/data-structures)

There are exceptions to this however, the Unreal Engine's Blueprints is a lot more flexible than most.

If you want to get started building your own version of Google's Blockly, here's a good guide:

[http://www.aosabook.org/en/500L/blockcode-a-visual- programmi...](http://www.aosabook.org/en/500L/blockcode-a-visual-programming- toolkit.html)

Throw in an immediate-mode UI library like React and you might even scale up indefinitely with plain HTML (most browser VPLs stick with SVG/Canvas).

For prettier node-based types of languages, try these libraries:

[https://github.com/retejs/rete](https://github.com/retejs/rete)

[https://github.com/slothking-online/diagram](https://github.com/slothking- online/diagram)

[https://github.com/jagenjo/litegraph.js](https://github.com/jagenjo/litegraph.js)

Bonus tip for anyone looking to implement any: use code generators. AST -> Visual programming component conversion may save you lots of time (assuming that the language has mature enough tooling and labour is extremely expensive)

<comment><USER47> Was "CloudTrader" taken?

<comment><USER46> The domain yes, check us out:

[https://KloudTrader.com/narwhal](https://KloudTrader.com/narwhal)

</comment></comment></comment><comment><USER48> once again, someone has a strong opinion on something they have never used or don't know much about.

in my personal opinion, scratch and blockly have very little to do with visual programming. they are nice little experiments but just repeat what's bad about text-based programming into visual blocks, which just compounds the issue. i honestly am surprised mit and the media lab have dumped so much time into scratch.

i have said this before, but the most productive visual programming language and environment is labview. it certainly has its problems, and i am a big critic of it, but its visual programming style and dataflow paradigm are more powerful than people realize. it has some seriously good ideas that aren't found in many other languages, and it had many innovative features well before other languages. for example, doing concurrent programming in labview is a breeze.

on the other side, you see that modern IDEs are starting to add a lot of visual content to help the programmer out. the languages remain text-based, but the environments are adding visual features. i think that there is a lot of untouched ground regarding hybrid environments and languages that merge the ideas of text-based programming with visual-based programming. in addition, the dataflow paradigm is also underused.

there's also other computation targets other than CPUs such as FPGAs. it's silly in verilog and vhdl how you often have to manually label up wires where in labview, the tool and language do that for you. you simply draw your circuit out as you would in a diagram.

common complaints against visual programming have almost no weight. for example, "oh, you can't diff visual programs like text programs". yes you can. it's not like computers were gifted by god text-based diff programs. these things were developed and iterated on. labview has a diff mechanism. it isn't great, but my point is that people view text as some sort of innate trait of programming and all the tools are "natural" and already exist as if they just poofed into being once programs started being written. but if we put some thought and work into the tools for visual programming, similarly to how it has been done with text programming, it's possible to create really powerful environments and languages.

where visual programming languages often have a ceiling is abstraction. for example, labview has object-oriented features, but it doesn't go far. i program on the side in f# and racket, which have an amazingly high ceiling for abstraction, but interacting with these languages is often frustrating coming from labview. there are many things that are simply easier in labview. some of that is tooling. some of that is the visual language and dataflow paradigm.

</comment><comment><USER49> There are a lot of things to respond to in this.

The purpose of Scratch is not to have all programming done in an environment like Scratch. It's to ease students into precisely what the author wants (textual programming environments).

Scratch eliminates several categories of errors for students.

Students in younger grades often lack an understanding of grammar and its utility or applicability. Consequently, the novel (to the student) syntax of programming languages can be vexing: Why is "while if x > 3" not allowed? The rules of the languages proscribe it. So now they're learning language rules and the concepts of programmatic/computational thinking.

They can no longer make typos when writing out keywords and variables. Keywords are typically available as draggable icons that they can then "fill- in-the-blanks" for. Variables become draggable icons or can be filled in with a simple drop down or text field that filters a drop down. Try explaining to an 8-year-old who still Writes Like this and SomeTimes tHis that there's an actual meaningful difference between "name" and "Name".

Scope is made explicit. Variables and logic exist within certain scopes so scoping errors (trying to use a variable outside the appropriate scope) becomes impossible as well.

Are all these constraints great for pedagogy? I don't know. But after teaching a number of high schoolers (now years ago), I'll say it would have been awesome to have had Scratch. They got along well enough with Dr. Scheme (now Racket), but a lot of time was spent fighting with the language that could have been abbreviated or eliminated with a different environment.

In the case of block-based editors, you can actually get version control. Usually, they're just a constraint-based, visual editor over a textual representation. So the underlying source files can be version controlled and compared quite easily (if the implementors considered this in their implementation).

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>==

Other thoughts:

This reminds me of an ex-girlfriend who legitimately thought it would be better if _all_ math were written as:

      To calculate the average of the population sum up
      each of the members and divide by the count.

That is a _precise_ definition of average (arithmetic mean), but it is impractical to use language like this in place of pages of algebraic expressions.

                      Ʃ pop
      average(pop) = </comment><comment>-
                      |pop|

is a better method of expression once you have more than one equation in play.

Graphical representations of processes can, similarly, be more useful than their textual counterparts (though not in all cases, I wouldn't argue that).

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>==

But here's a fun one:

Problem: Identify binary strings (read left-to-right, last digit read is the least significant) that are multiples of 3. So 11 = 3, 1010 = 10, etc.

Do this with just regular expressions. No tables, no diagrams, nothing.

Ok, now do the same thing but with a standard DFA diagram or state transition table.

Much easier, right? Now, once you have those last two you can write out the textual regular expression and embed it in your program with relative ease. And maybe that's how you want to store it in your code. Or if you don't want to use a regex engine you could encode the table form into your program easily enough, and still retain its visual characteristics.

Are visual programming environments going to replace most of our programming languages and work? Probably not. But it's foolish to discard them based on the complaints in this blog post without considering the reasons _why_ they have value.

</comment><comment><USER50> text-based representation is visual.

</comment><comment><USER51> Last I heard text is visual... so then what is text but a form of visual programming?

In essence text is visual programming limited to set of symbols and tokens parsed in left to right order.

Who said that this arbitrary set of rules is the best way to represent programming logic? The number of concepts for abstraction encompass many things in the visual realm. Graphs, procedures, arrows and even 3D space can be used to represent logic... Obviously with a space this big, text is unlikely to be the best way.

Text based programming is simply a local minima that is seemingly the optimal minimum. The problem is we're so deep in this minimum that it's hard to climb out.

<comment><USER52> > _Last I heard text is visual... so then what is text but a form of visual > programming?_

But the author of TFA defines what he means: "A visual programming language is one that allows the programmer to create programs by manipulating graphical elements rather than typing textual commands."

<comment><USER8> The mistake in that definition is saying "rather than" rather than "as well as".

<comment><USER52> I think that's splitting hairs.

We all understand the difference between "texual" and "manipulating colored boxes, drawing arrows and generally using a non-textual interface". I'd rather we addressed this rather than the accuracy of the author's wording...

I partially agree with the author in that programming is inherently complex, and that "visual" UIs are inadequate once the program reaches a sufficient complexity level. Also, textual manipulation tools tend to be ubiquitous and more importantly, non-propietary; I'm naturally wary of other tools.

I disagree with the author in that I think there's still room for exploring graphical UIs.</comment></comment></comment></comment>


Is Google glass too far ahead of it's time? - <AUTHOR> https://medium.com/we-live-in-the-future/98e07b1c3fe8

<comment><USER2> This is definitely a good critique. I remember when I got an iPhone in 2007, people always wanted to talk about how I had an iPhone (they were still very uncommon, I think I was the only one at my school to have one for a time). I can't imagine how awful this would be with something that wasn't meant to be in my pocket for most of the day.

</comment><comment><USER3> Correct, technology like Glass has to be socially acceptable before there can be adopted by the masses. It's a chicken and egg problem but then again I've never used a Bluetooth headpiece.</comment>


Solving the Dating Problem with the SENPAI Protocol [pdf] - <AUTHOR> http://sigtbd.csail.mit.edu/pubs/veryconference-paper10.pdf <comment><USER2> This already exists, it is called flirting.

Given two socially well adjusted participants it allows either party to back down without hurting the other parties feelings and allows everyone to save face. The person escalating the flirtation doesn't feel bad because they aren't outright denied and the respondee isn't put in the awkward situation of having to deny someone.

It also has the added benefit of allowing each person to get to know each other better and figure out if they actually have real 'chemistry' to begin with. Furthermore, attraction isn't binary, you might initially start chatting with someone with the intention of escalating the flirting process but figure out, hey, I just want to be friends with this person! With the SENPAI protocol you might just end up in an ill fated relationship with your would be friend

<comment><USER3> Flirting has a high signal to noise ratio.

There are also many issues with unintentional signalling.

<comment><USER4> Seems like the sort of problem a deep neural network would be great for. I've already got some good hardware for it, but I'm a little apprehensive about acquiring enough training examples.

<comment><USER5> Just put together a research pool so you can generate a solid baseline. I'm sure you could use Amazon Mechanical Turk to get a large number of able participants at minimal cost to your wallet and pride.

</comment></comment></comment></comment><comment><USER6> > In his presentation of the original protocol, Aaronson suggests that zero- > knowledge proofs can be used to prevent cheating. However, we find this > approach unsatisfying, partly because zero-knowledge proofs would make the > protocol much more unwieldy and time-consuming, and partly because we have > no clue how to actually implement ZKP in this context

I am in love with the honesty in this.

<comment><USER7> ZKP is also useless in this case because there's no way to enforce dating if the ZKP finds a match. Anybody who wants to detect a crush can simply lie about having one themself.

<comment><USER8> Except the presented protocol already does not prevent this attack (which they acknowledge in the paper).

ZKP still provides the property that cheating will be detected, which is all that is required to satisfy the papers security definition.

</comment></comment></comment><comment><USER9> For those not getting the reference, "senpai" is a Japanese honorific used to address one's upper classman in school.

A common trope in Japanese medium is that a character will have a crush on a senpai (equivalent to a prefect or hall monitor in that context), only for them to be utterly oblivious to it.

[http://tvtropes.org/pmwiki/pmwiki.php/Main/SempaiKohai](http://tvtropes.org/pmwiki/pmwiki.php/Main/SempaiKohai)

This is a witty paper, as other commenters are noting.

<comment><USER10> I think you see that trope mainly in hentais and very rarely in regular romcoms, as far as animes go.

<comment><USER11> That's not true. I've stopped watching seasonal anime but the last time I did (2014), every single comedy/romance anime had that trope. Sometimes it's just admiration and not romance but it seems to always be there.

<comment><USER10> It's _most of the times_ admiration and not romance, and is most of the times a comedy element and not part of the main plot. That's very different from what OP stated.

</comment></comment></comment></comment><comment><USER12> > Unfortunately, this protocol is completely dependent on the trustworthiness > of Trent, as they receive all of Alice and Bob's information and are > entirely free to manipulate the results of the protocol. If Trent has been > compromised, perhaps by a nation-state adversary, Alice and Bob's love life > will be completely in the hands of a malicious attacker

Beautifully done.

<comment><USER13> "nation-state adversary" and "logical AND" both cracked me up. It is surprising to see common themes with my own research on this topic: "thinking too much".

</comment></comment><comment><USER14> This whole paper was great. It starts heavy on the humor but then also delivers just enough actual cryptographic protocol to make the lead-up worth it. This bit at the end was my favorite:

      As is noted in [1], if Alice simply suggests to Bob that
      they carry out a SENPAI exchange, this in and of itself is
      indicative of interest on Alice's part. Thus, the only nonawkward
      way to actually use the SENPAI protocol is to
      assemble large groups of people, and have every pair of
      people carry out the protocol.

<comment><USER15> I'm interested in the consequences of, instead of "everyone" carrying out SENPAI, having a more efficient STB Matching System (Spin The Bottle).

Sure, it could backfire: interested parties may fall victims of the universe's Random Number Generator, but it makes for some interesting Game Theory dynamics, which I call the Tinder Card Stack Dilemma.

Any one party could be more willing to express interest in any of the other parties (assigned by STB), if they believe there is a low chance of them being matched with someone else they are more interested in.

On the other hand, they could become more picky, and only express interest in parties they are very interested in, rejecting others because they believe there is a high chance of them being matched with greater interests.

There is a definite trade off between efficiency and overall population happiness when choosing between STB and the solution described in the paper. Because STB is more efficient, it ends up being way more scale-able. But bigger populations greatly intensify the TCSD.

</comment></comment><comment><USER16> TLDR; (fta)

        Alice and Bob should each
        learn the logical AND of their
        responses, and nobody should
        learn any other information

The SENPAI protocol is proposing a way to do this with cryptography. There's a historical review of other proposed protocols (AMP, JMAP, MFP, SOAP, YGMP, SLP) along with their deficiencies. A SENPAI-MTT protocol is also considered that allows for non-binary interest (MTT=More Than Two). They propose foiling protocol cracking by quantum factoring by basing future SENPAI protocols on lattice based cryptographic methods.

</comment><comment><USER17> The entire site hosting this is hilarious - it appears to be an April Fools parody of an academic tech conference and it's very well executed.

"Submissions are double blind and author names must be removed. On the published copy, authors must be ordered by descending number of vowels."

<comment><USER18> Thanks- I initially thought this was hosted on arxiv (it's on a MIT server).

This paper from the same conference also looks good:

[http://sigtbd.csail.mit.edu/pubs/veryconference- paper5.pdf](http://sigtbd.csail.mit.edu/pubs/veryconference-paper5.pdf)

"Locally Bijective, Non-Noetherian, Ultra-Liouville Random Variables and Parabolic Lie Theory"

"Good" as in "it was probably generated by an LSTM RNN".

Full papers listing here:

[http://sigtbd.csail.mit.edu/pubs/](http://sigtbd.csail.mit.edu/pubs/)

And main conference page:

[http://sigtbd.csail.mit.edu/](http://sigtbd.csail.mit.edu/)

For the benefit of other July fools like me :0

P.S.

This one is of special interest to me: Evident Logic, a logic programming language based on a new logic, made special by "not the rules that it has, but the rules it lacks, so we wish the reader good luck in figuring that out":

[http://sigtbd.csail.mit.edu/pubs/veryconference- paper8.pdf](http://sigtbd.csail.mit.edu/pubs/veryconference-paper8.pdf)

</comment></comment><comment><USER19> Tangential: can somebody explain to me how same-sex speed-dating is sequenced? Two-sex is easy as one sex remains static while the other rotates around, but I can't figure out a solution for single-sex.

Update: a solution that satisfies being practical to organise and that lets you talk to all participants

Update2: [http://math.stackexchange.com/questions/55439/gay-speed- dati...](http://math.stackexchange.com/questions/55439/gay-speed-dating- problem)

<comment><USER20> I don't know how they actually do it, but this would work: [https://en.wikipedia.org/wiki/Graph_factorization#Complete_g...](https://en.wikipedia.org/wiki/Graph_factorization#Complete_graphs)

<comment><USER19> This way you see everyone, but have a logistical nightmare.

<comment><USER21> All you need to do is set it to music, so that at the end of the set each 1-factor of the factorization has been represented for a verse. You'd probably need a distinct song and pattern for each group size.

If your dancers are some mixture of male/female/het/homo/bi such that you don't have a complete graph or other easy problem then you may need to have a computer-augmented dance caller.

</comment></comment></comment></comment><comment><USER22> > The Just Man Up And Ask Protocol (JMAP) is often proposed as a naive > solution to the Dating Problem...

Man, this paper is golden!

</comment><comment><USER23> Super fun paper.

It seems like their modification to Aaronson's algorithm would also work for Yao's garbled circuits, i.e.

1\. Alice generates a long random bitstring s, and publishes hash(s)

2\. Alice crafts a garbled circuit with just one AND gate, where the false output is 0+s, and the true output is 1. Alice sends the circuit and her input to Bob.

3\. Bob gets his input from Alice using oblivious transfer. He evaluates the circuit, publishing the result.

4\. If the result starts with 0, Bob verifies that hash of the rest of the string matches the hash published by Alice. Alice also checks to make sure the rest of the string matches her original s.

</comment><comment> Ar-Curunir If you want to use heavy handed crypto you can utilise multiparty computation protocols that are secure against malicious parties.

For the 2PC case this problem was solved way back in the 1980s Andrew Yao.

</comment><comment><USER13> The paper is very helpful for the arbitration of a "simple, binary phenomenon". Section 4.1 correctly investigates ternary responses.

However, logic may only be used if a common GND is accepted. If Alice does not believe in absolute truth, there is no way that trust can be established. Analogue systems may not approach 1, only digital logic can provide "TRUE" love.

Moral relativism is commonly professed. However, I theorise that an absolute 0 point can be readily established.

"Is cheating in relationships always wrong?"

If a common GND cannot be established this way, then the crush may be ended without wasting more time running the simulation.

</comment><comment><USER24> This has already existed for ages using trusted third parties. A while ago on Facebook there were things were you could say which of your friends you fancy, and if you match it sends you both a message.

The problem is there's no real disincentive just to say 'yes' to everyone, just to see who said yes back. Kind of like always swiping right on Tinder (although I'm sure they punish you for that in some way).

</comment><comment><USER25> While reading i had to scratch my head and ask myself, is this serious or is someone pulling my leg.

<comment><AUTHOR> The paper was submitted to SIGTBD 2016. From the website ([http://sigtbd.csail.mit.edu/](http://sigtbd.csail.mit.edu/)):

SIGTBD's emphases includes innovative, elegant (to the point of simplicity) and creative approaches for solving problems that are not traditionally served by the academic community. These problem spaces may be obsolete or unrealistic even by academic standards and are often of debatable research taste.

<comment><USER25> dlgeek 7 hours ago [-]

The entire site hosting this is hilarious - it appears to be an April Fools parody of an academic tech conference and it's very well executed. "Submissions are double blind and author names must be removed. On the published copy, authors must be ordered by descending number of vowels." reply

</comment></comment></comment><comment><USER26> Uhm, how do one compute the cubic root of x^3 modulo N?

</comment><comment><USER27> Is the protocol described in Aaronson's algorithm actually sound? I can't seem to make sense of it myself. An example sequence would help.

</comment><comment><USER28> I'm curious what happened to paper number 6

<comment><USER29> "There is no paper number six!"

</comment></comment><comment><USER30> Who is the Author of the paper? Usually people put that at the top.

<comment><USER31> This is a preprint from a conference with a double blind submission process, which is why the author names are not present. According to the agenda the authors are S. Dukhovni, J. Weisblat, and I. Chung.

<comment><USER30> I can't find these people using google.

<comment><USER32> They are undergraduates at the EECS department.

</comment></comment></comment></comment><comment><USER33> First the underwear sorting hat, and now this.

MIT, never change.

</comment><comment><USER34> [10] is the best

</comment><comment><USER35> 先輩のが多きくて硬い。 カッコいい!

<comment><USER36> Use 大きくて, not 多きくて

the former is 'big', the latter is 'many'

<comment><USER35> You have to watch that Windows IME like a hawk.

</comment></comment></comment><comment><USER37> "Notice me SENPAI!"

</comment><comment><USER38> There is a dating problem?

<comment><USER39> I thought Tinder had it solved...

<comment><USER40> Tinder is Trent in this protocol. As long as both Alice and Bob trust Trent, that works. But Trent can cheat.

<comment><USER6> And then the Russians might control our love lives!

<comment><USER3> I'm prepared to give them a go at this point, they can't do a worse job of it than me.</comment></comment></comment></comment></comment>


Ask HN: Any hardware startups? - <AUTHOR>

I'd like to hear about hardware startups and your troubles and problem solving. Particularly if there are any IC manufacturers or fabless startups.
This is an area (EE and ICs especially) I was always fascinated by, but I have no practical knowledge about. Yet, I have several ideas which I would like to develop into a HW product (one of million ideas we all write down), but I have no one to talk about since I don't know any people that are experts in. My exposure to the area comes mostly through occasional scouring through IC manufacturers news/prs/blogs, eetimes and wiki (so it's nothing basically).
Is it possible at all for a small yc-like startup to break into an IC field at all (fabless like Nvidia or manufacturer area). Costs associated seem to be astronomical. <comment><USER2> I'm currently working on an FPGA-related startup, not manufacturing hardware but developing an online FPGA development platform (<http://www.plunify.com>).

Octopart is a YC-funded search engine for electronic parts.

One reason why I'm listing these indirectly-related examples is that hardware for me seems to involve an ecosystem of different companies, each painting part of the overall picture. To me it's a very inter-connected industry: from the hardware manufacturers to the design houses to the software tool providers to the customers, etc.

As you said, manufacturing and selling a hardware product requires a sizable capital investment, not to mention challenges of maintaining a logistical operation. If the product design is not too complex, one can get it manufactured for cheap in Taiwan or in China... startups based somewhere else will just have to find the nearest board house to do the first prototypes.

Fabless is of course a good way to go as it eliminates a lot of the costs. That also brings with it business-model-related questions: do you sell the IP or do you actually want to make something in the end? Are you thinking about opensourcing your IP? Etc...

There are hardware-as-a-service startups, opensource hardware startups like Arduino(<http://www.arduino.cc/>), and many such companies coming into the market in recent years. It's definitely a rich playground with decent barriers to entry(hardware expertise, market knowledge, connections) and I feel that there isn't a "killer" business model out there yet for smaller players to capitalize on.

Would be interested to know what other hardware-related startups are doing!

<comment><USER3> I love the idea of Plunify. I tried to find pricing information (for future use) on the website, to no avail. But if this cuts down the cost for CAD tools as an independent developer, it will be huge for me!

<comment><USER2> Thank you!

We're in beta and are still figuring out the pricing as we go along. Absolutely agree that cost, among other things, stands in the way of many independent developers.

</comment></comment></comment><comment><USER4> I'm interested in hardware startups but at a higher level than chip design.

Some semi-random pointers which might be of interest:

* OGP is an open source hardware project to create open source video graphics hardware which currently uses a FPGA: <http://wiki.opengraphics.org/tiki-index.php>

* Bunnie is one of the people behind the Chumby and has documented his manufacturing experiences on his blog but that seems to be at a higher level than what you're looking for: <http://www.bunniestudios.com/blog/>

* ARM is an example of something that started out with a small development team: <http://en.wikipedia.org/wiki/ARM_architecture>

For prototyping purposes my limited understanding is that software simulation and FPGAs can be used initially. If you're interested in FPGAs this site of open source FPGA code might be of interest: <http://opencores.org/>

<comment><AUTHOR> Excellent sources. For what I would like to do, FPGA with a custom PCB seems to be a right choice anyways. I would like to do something what AJA ( <http://www.aja.com> ) and BlackMagic Design do ( <http://www.blackmagic- design.com/> ) - basically broadcast equipment. AJA uses FPGA for their IO (I know because when I boot it it says initializing FPGA :) ). I also have an interest in SSDs. Thanks!

</comment></comment><comment><USER5> Just want to make an important distinction. OP is talking about hardware startups. Someone below mentioned WakeMate, and I want to clarify that's not what we should call a hardware startup - it's a very very different beast from a company that designs ICs.

I've heard Brad Feld use the term "software enabled hardware" and I think that's as good as anything else to talk about companies like WakeMate.

</comment><comment><USER6> I'm working on a very early stage hobby startup based around preexisting open source hardware / software.

It's going very slowly due to my lack of knowledge with regards to hardware development and manufacturing.

The only YC company I know of that does hardware is WakeMate and they have been plagues by numerous manufacturing and licensing problems.

<comment><AUTHOR> Can you provide more info about what are you trying to do? Looks like post got no traction, which is a shame - I really wanted to hear about HW manufacturing issues from a startup perspective, especially IC.

<comment><USER6> Sorry, I'm intentionally being vague at this point.

If it ever amounts to anything, I will let you know.

<comment><USER4> As I'm interested in open source hardware and hardware startups I'd be interested in learning more too when you're ready to do so. :)

</comment></comment></comment></comment><comment><USER7> You'll want to check out Mosis for getting ICs fabbed on the cheap. <http://www.mosis.com/>

</comment><comment><USER8> You should check out Kogan. I don't know the guys personally but they have successfully built a hardware brand in Australia.

<comment><AUTHOR> Thanks. From a glance ( <http://www.kogan.com.au/profile/> ) it seems more like a trading company that slapped brand on hardware deals they got through alibaba.

</comment></comment><comment><USER9> I'm not sure what you're trying to do, but was wondering if you could use FPGAs or microcontrollers.</comment>


Mange and scale your infrastructure with Scalr.  - <AUTHOR> https://www.scalr.net/

<comment><USER2> Unfortunate typo in title but I can vouch for scalr.

Used it since the early paid beta. Compared to the likes of rightscale it's a bargain. Alongside all the expected things like ami creation and cluster (aka farm) configuration the scripting features and automatic DNS management make life much easier. Their quality control used to be a bit hit and miss and it sometime felt like we were testing their functionality for them. I also had the impression their European DNS performance was poor (never validated). For the money though they were still a cost effective way of managing large ec2 clusters.

The open source version used to be a real pain to setup. Given the relative cost of setting up and running your own install I'd go with the paid version.</comment>


My Family Came to This Country Legally, but Were Almost Deported - <AUTHOR> https://medium.com/@benhuh/my-family-came-to-this-country-legally-but-we-were-almost-deported-9c7de6e80083#.pxudvbnif <comment><USER2> Meh, they started proceedings to deport me over a year _after_ I got my citizenship. tl;dr I moved a few months after getting my citizenship and the INS didn't realize I had become a citizen and got irritated that I didn't notify them of the move.

The INS/DHS is hopeless.

<comment><USER3> How did they know you moved?

I moved a couple times and forgot to submit the change of address form. I did it retroactively, but nothing came of it.

<comment><USER2> I'm guessing it was when I filed my taxes the following year since that included my updated address.

</comment></comment></comment><comment><USER4> I don't understand how people like my roommate got into the US with minimal funds and no degree. He's from a village in Russia and just came here on his own, and works as a barista about 30 hrs/week. No lawyers or anything. He's been here for eight years. He said he worked at a national park first, but overall said the process of getting here (and staying) was pretty easy.

<comment><USER5> Perhaps he came here through the Diversity Immigrant Visa program (aka the green card lottery)? If you're a resident of one of the eligible countries it's just a matter of filling out a form and getting lucky.

</comment></comment><comment><USER6> Disgusting. I had to deal with the INS myself to get a visa, and later a green card. Thank God I didn't experience a tenth of what the author describes and I can still say that this "machinery" is incredibly dysfunctional.

</comment><comment><USER7> The INS is what the IRS would look like if taxpayers couldn't vote.

</comment><comment><USER8> I don't understand the $45K for the 3 green cards. Right now it costs maybe $1500 to process one green card application with the complexity of tax form. You can definitely do it yourself though a lawyer may add another $2000 to help you out. Back 10-20 years ago everything was probably half the amount. Also as I understand, H1B based green cards are sponsored by the employer?

<comment><USER9> If you read between the lines, it appears the author's father was bribing an INS official, albeit he claims his father did it unknowingly.

<comment><USER10> Since when does "if you read between the lines" mean "infer the exact opposite of what the author stated"? The author wrote that his father ended up being a key witness to convict Daniel Lee.

The story clearly states that the green cards were legally obtained through the father's work (see fourth paragraph).

<comment><USER9> Sounds like his father had a lot of interaction with Daniel Lee.

"Everyone in here is innocent, you know that?" \- Red, The Shawshank Redemption

EDIT: Can't reply to the child comment. But we only have one side of the story here. At best it seems his father was a fool and it's hard to trust the word of a fool.

<comment><USER11> New immigrants who don't know how to navigate a complex and hostile legal system are a pretty ripe customer base for fraudsters.

Just because a scheme seems to a knowledgeable observer to be too good to be true doesn't make it okay to blame the victims of such frauds.

<comment><USER9> Victim of fraud or not, how should the INS have handled it differently? If someone at your company is found trading job offers to unqualified people for money, should those unqualified people keep the jobs? Of course not. What if those unqualified people used an intermediary to proffer the bribe? Doesn't change anything. Sad story all around for the victim of fraud. That's why they are called a victim. Being a victim sucks and is nothing to be proud of.

</comment></comment></comment></comment></comment></comment><comment><USER9> I take issue with the title. His father bribed an INS official. __Maybe __unknowingly, but the author 's excuses for his father don't completely wash. $45k for an "expedited" green card, in 1995? Come on, you know something shady is happening at that point. That's $70k+ in today's dollars.

IANAL, but I think immigration generally operates under strict liability, not mens rea. So regardless of whether his father knew he fucked up, his father was at fault. Same way a chemical plant has to pay damages if it poisons the community, whether or not they intended to hurt anyone.

<comment><USER12> > His father bribed an INS official

Did you even read the article mate?

> To get our green cards expedited, we paid $45,000 for legal services, fees, > and documentation for the three of us to an immigration brokerage service. > It was a herculean sum of money for poor immigrants like us, but the > American immigration system was hopelessly complicated and confusing. This > was my first experience with how expensive lawyers could be.

His _broker_ may have bribed the official, but his father most certainly did not.

> 45k for an "expedited" green card, in 1995?

3 expedited green cards.

> Come on, you know something shady is happening at that point.

Based on what, his extensive experience of the US immigration system that he obtained in South Korea?

<comment><USER9> > Did you even read the article mate?

Do you take everything at face value?

> His broker may have bribed the official, but his father most certainly did > not.

Immigration is strict liability, so from the perspective of liability, his father did.

> 45k for an "expedited" green card, in 1995?

Good catch. I missed that. Makes me somewhat believe his father was just a fuck-up and not outright bribing.

> Based on what, his extensive experience of the US immigration system that he > obtained in South Korea?

I don't know, based on maybe getting a second opinion before spending $45,000. Maybe based on the fact he'd spent years in Hong Kong and on H1-B. You don't need to know much about stereos to know you shouldn't buy them out of the back of a van. The author is quick to label his father an imbecile rather than a in-cahoots. The apple doesn't fall far from the tree.

</comment></comment></comment><comment><USER13> My family came here legally as well, I was 10. Got stuck on I829, been renewing my permanent residency status every year for almost 18 years. Based on my home country's government records I'm not its citizen. I applied for U.S. military some time ago, but got denied due to depression I went through in college years. I'm a citizen of no country, and yet I love the U.S., I would die for no other country.

<comment><USER14> That is a very interesting situation to be in, do you have any concerns should your resident status get changed? What would you do if you were required to leave the US?

<comment><USER13> Every year we visit USCIS to get our status renewed for another year, and it worries us every time we do so. There are times when inexperienced USCIS agents (who don't understand our status) refuse to renew our status, in such circumstances we have to make another appointment and simply hope to run into one who've seen us for years.

After the disappearance of our lawyer (over a decade ago), we had no way of getting our hands on any case files, I wouldn't know how to fight it in court if we were required to leave the US.

After my father's real-estate developer business went bankrupt in the early 2000s we were in a financial downward slope, pretty much to the point where we had to beg our family friends for money. Nothing was left after my father's passing, well by that time my brother and I had jobs, which was fortunate, although the school loans do hurt, I may have to save up some for the lawyer costs if it ever comes to that.

<comment><USER14> Wow, that is indeed very precarious, my best wishes and i really do hope it never comes to you needing a lawyer. That sounds incredibly stressful especially when going to uni/college while dealing with it.

<comment><USER13> Thanks. It hit me pretty hard, but I'm just glad I had the opportunity to study at the university (Physics) and get a job. Although I may not have joined the military, I'd like to believe even as a software engineer at a small company, I'm contributing for ever more brighter future of this country. I revere the people who are working in US digital services agencies.

</comment></comment></comment></comment></comment><comment><USER15> Perhaps I'm overly critical but, if

> ... [T]he stench of stale coffee and rancid soda cans that I collected from > office trash cans to help make ends meet.

was the worst he had to deal with in a cleaning job, he had a very nice office to clean. I've cleaned up much worse in my office, and I do IT for a living.

</comment><comment><USER16> Wouldn't it cost more to go through with deportation (and risk people going into hiding instead), rather than just process them with priority again? Then again, maybe it's too reasonable for strictly applied law?

</comment><comment><USER17> He believed that by "doing the right thing" to help the Department of Justice.

Very common mistake Asians (and non Americans) make to mistake government officials/agencies for the good guy. From little experience I have with USA, law enforcement and tax people are just another scums on the contrary they might be worse than someone who tries to bribe you in a dark alley.

</comment><comment><USER18> To some degree of people who have fought through this and came out alive. In a competitive situation with someone who got through that a lazy normal person like me would have no chance of survival.</comment>


Binny Bansal is Flipkart's new CEO; Sachin Bansal is executive chairman - <AUTHOR> http://stories.flipkart.com/flipkart-management-structure/ <comment><USER2> nice to see one company growing whose leadership is invested and growing in light of the last few weeks and the recent jumping ship or complete tone reversals :)</comment>


The Big Growth Opportunity That Netflix is Missing - <AUTHOR> https://medium.com/startup-growth/b3e82ce23c87

<comment><USER2> While the author does have an interesting point about how Netflix could be a bigger hub for information, is it really a "big growth opportunity"?

To create (good) content for solely information consumption would require a lot of leg work on Netflix's end, and would it really help their return? They would have to hire content creators, change dev infostructure to be both in/out of a paywall, manage the content, etc. Netflix is basically a household name already (even my grandma uses it), I don't know if ranking higher on SEO is really going to be cause of a large growth spurt.

> _" Netflix needs to put all of this valuable content outside of the paywall > in order to provide value..."_

Netflix already provides a magnificent amount of value to customers without doing this. "Needs" is a very strong word to use in that sentence. Yes, it _may_ help, but it doesn't "need" to happen for them to provide value. Also, maybe not doing this is the value. By making people sign up to see content, reviews, trailers, etc. it actually gives them more value. Yes you can find that information on other sites, but why give it away for free if people are already willing to pay for it?

Netflix could use the money saved from a project like this to get more and more shows/movies on their network. A bigger library of content is what will make them have more and more growth, not awareness via SEO. Awareness is something I think they already have that down pretty well.

However, I think this could come into play and be a more helpful strategy when more and more competition comes around (other than just Hulu and Amazon) against Netflix. Or when they have a more significant amount of original shows in their library.</comment>


Apple must make Macintosh a standard-Letter from the past - <AUTHOR> http://www.lettersofnote.com/2012/02/apple-must-make-macintosh-standard.html

<comment><USER2> Blah blah. Trotting out this tired old chestnut again? Yes, things might have been very different. If they'd done it early enough, Apple could have been a tired, clueless license-humper like Microsoft. They could have won the market share wars and never produced another great product. Or, since Microsoft would have done their copycat anyway, they might have lost the market share wars and still never produced a great product. Not an alternative history I want to live in.

<comment><USER3> "Blah blah. Trotting out this tired old chestnut again?"

Well excuse me for featuring something you've apparently read far too often. Believe it or not, some people haven't seen it all.

<comment><USER4> The title is misleading, phrased as if present-tense, when this is a letter from 1985.</comment></comment></comment>