Hacker News Reader

Comment by a-dub | Hacker News Reader

So every time I've seen something like this (ETL tools, LabView, Scratch, pd/max, etc) I've noticed a common problem. They're dead simple to create simple things in, but often times simple things grow into complex things over time and once things become complex things implemented in graphical programming languages they become nightmarish to maintain. Subtle logic ends up buried... Simple processes like a full search of a project or diffing between two versions become impossible or clunky and you end up with the one person who knows how to maintain X.

Is there anything here that addresses this problem?

View on HN

Check out my note on visual programming. [1]

The short answer is we have lots of tools in mind that will help with this, but programming this way just creates a very different kind of system. We've built some complex things and they've remained fairly flat and we made sure that it is both readily apparent what is contributing to your current query and easy to navigate into it if you want to see more. For the most part these problems boil down to navigation and debugging issues, both of which we have really powerful ideas for. For example, we want our debugging story to be what's called a "why? debugger" where you can click on any value in the system and Eve will show all the data that went into calculating it and every query it went through to get to here.

There's assuredly going to be lots more experimentation needed here, but we have every intention of making this handle more complex things. We're bootstrapping the compiler and eventually the editor, we've built clones of websites, and we'll continue to push the edges of what we can do with it :)

[1]: https://github.com/witheve/Eve/blob/master/design/visualProg...

Well, I guess this is as good a comment as any here to say this... I feel morally obligated, as someone who has been frequently skeptical about visual programming on HN, to point out that what I personally really meant is that...

"Along the way to version 0, we tried everything from a Mathematica-like notebook built on functional programming to a purely spreadsheet-like model. We built dataflow languages and madlib based editors and read through papers from the foundations of computing. One thing that ran through all of this, however, was to make sure we never drank our own kool-aid too much. We dug through research and created postmortems and landscape summaries of all the projects that have come before us. We tested our ideas with actual people and against real projects. That meant that we "threw away" most of what we did to get here. It was the best way to keep ourselves honest."

... that is the minimum effort required. I have long advocated that people picking this problem up hit up what's already been done and hit the research to make sure they're not going down a known failure path.

If anyone's going to get to stick my skepticism about visual programming back in my face, it's someone who's doing the stuff in that paragraph, not someone who goes (basically) "Programming sucks, by extension you all suck, visual programming is obviously the solution because, visual! And look, guys, here's my 2-week solution that proves it out!".

I won't lie to you, I remain skeptical, but, well, I'm just generally skeptical about things that don't exist yet. I wish you all the best, and I promise you that if you do succeed I won't do that thing where I pick nits to claim it's a failure anyhow. And I also promise you that I'm happy to say you've been successful in some niche, not set the bar at "REPLACES ALL PROGRAMMING, EVERYWHERE!" or something equally silly.

It depends also very much on the individual psychology and experience of the human in question that is using the tool to develop, and the kind of thing that is being developed. For example, to lay out the gui in a gui tool, you'd rather locate it visually, while to specify the logic, you do it now textually. The reason the second is textual is because previous experiences made it so that specifying logic textually is easy for you (the experience here being practicing programming).

The question is, when someone is thinking "this is what my app should do," what is the model of the "this" inside their mind? What form does it have, and can we make computers be able to read something closer to that form, rather than having the human have to add more layers on that form before handing it to the computer.

If development becomes a conversation between the computer and the human, it might be more interesting, satisfying, fun and spawn some directions that the human would not have come to so quickly with earlier forms of development tools. Thus, this whole thing being about a search for something 'cool and fun' rather than being like 'X is bad, Y is a solution,' like a kid walking out in his/her backyard and looking for cool things with not much preconceived notion of what to look for. Exploration. Not replacing programming everywhere or things like, that, but "hey, here's a thing we made, why don't you try it and see if you like it."

Do you have any thoughts on how automated tests would work in this world? You mentioned email filters and responders in the OP, and I remember that everytime I start creating filters I quickly hit a point at which debugging or changing them becomes fraught.

We do! One neat thing about our architecture is that literally everything is just data and side-effects happen outside of the system itself. This means if you disconnect the "watchers" that do things like send email based on the presence of rows in the email table, you can safely do anything you want. This resolves a bunch of issues around testing for us.

The overall plan is to provide a bunch of really interesting generative testing facilities. For example, we can generate data based on your integrity constraints that tries to sneak values into the system that would break them. Being a live language also helps a lot here - you're inherently testing as you build things. We want to make it easy to just capture that while you're doing it.

That resonates. I've been trying to teach programming by teaching testing first: http://akkartik.name/post/mu. My basic idea is that the hardest thing about programming is learning to consider all the different situations your program might be thrown in. Static code gets 'uncoiled' into many different dynamic 'traces' at runtime. I try to focus on that hard thing right from the start.

I have to ask: are you familiar with Blizzard's GUI script programming? It introduced me to programming and allowed 10 year old me, terrible at logic (and never before programmed!), to make games without reading much external references (it is completely self-explanatory).

For example, by reading those I think you get immediately an ideal of what it does:

http://i221.photobucket.com/albums/dd195/thehelper-andrewgos...

You can build those from a predetermined set of Events (if you're advanced you can create custom events), so just by reading from a list of events/actions you an figure out how to do whatever you want. I think it's similar to Scratch but it does away with the clutter -- it's not exactly trying to make programming "visual", it's more just merging documentation and code, so you have all the building blocks needed to build any application right in from of you.

I think this kind of rethinking you're doing can truly change how programming is like for beginners or people who want to make specific tools/application (and not learn a plethora of things they'll never use)!

Yep, I've had some good experiences with the old StarCraft editor. It had a surprisingly good first user experience because it was immediately useful (terrain editing was very intuitive, and stock games could be played on custom maps) and had a gentle learning curve (new game features could be added in progressively to the base game).

One of our past examples worked on a similar principle to the SC trigger system [1] but we unfortunately found that it didn't scale as well to larger systems. While it was very easy to write in, it was hard for a stranger to read and intuit the implied data flow. We've had a lot of fun experimenting with different query editors, and I hope to find the time soon to do a more in depth write up on our research.

[1] https://camo.githubusercontent.com/f24714bf6429fa21ca91e4987...

Yes but have you had a marketing and a sales person and a business exec throw random logic and rules into the mix? That's the hardest part; integrating seemingly random or subtle business rules into the reporting or applications.

On this note it seems incredibly important to make sure the medium has something analogous to refactoring in code: ways to tranform the system into a better form in discrete, safe steps that do not change the behavior.

Version control, refactoring, code reuse, etc. are big items on the roadmap for the next release. We have some interesting ideas, including the realization that refactoring in this sort of system can take the form of graph rewrites.

Here's a post on our dev diary about version control: http://incidentalcomplexity.com/2015/04/22/version-control/

Yeah that would be nice ...

... but unfortunately impossible, as you are solving the halting problem.

Reply on news.ycombinator.com