
Show HN: DeepUI Programming Studio – A different approach to programming - Naeron
https://deepui.io
======
dmvaldman
There is a deeper question undercutting this project (and Bret Victor's
Drawing Dead Fish talk and related approaches). That question is: how can we
represent computation in an intuitive and scalable way?

Conventional programming languages is one answer. They associate programs with
text. Some believe there is another way, by associating programs with
diagrams. A more abstract example: machine learning associates programs with
parameters and weights.

In some weird way, I feel these are all skeuomorphisms. We choose text because
that's how we comprehend literature. We choose diagrams because we are visual.
We choose ML because we mimic how our brains work.

We don't, however, try to understand what "thought" is, and work backwards to
form a representation of it.

For example, take thinking of programming textually. Text assumes a beginning,
an end, and an ordered sequence between them. But in this small programming
example, is there a well-defined ordering?

a = 0; b = 1; c = a + b;

Since the first and second lines can be switched, in some sense Text itself
does not do Thought justice.

Visual representations like the one in this video also have their
shortcomings. The most obvious being, a monitor is 2D. Thought is not 2D.
Going to 3D won't help either. Thought also not only spatial and temporal. For
example, how would you represent concatenating strings visually?

I think the more interesting question is how we can accurately represent
thought?

~~~
dustingetz
> is there a well-defined ordering? > a = 0; b = 1; c = a + b;

In pure functional languages, these expressions form a dependency graph and
the interpreter or compiler may choose an ordering and may cache intermediate
results

We may even represent the program itself as a graph, just like you suggest
with ML programs, but this is a general purpose program

Obviously we can't do this in imperative languages.

I think pure functional programming enables this future of thinking about
programs as graphs and not as text.

~~~
zackmorris
Back in the late 80s/early 90s after I learned C, I remember wondering in awe
how in the world compiler optimizations worked. But they do the same thing,
they build (often intricate) dependency graphs. In the end, if a human can
translate between imperative and functional programming, then there's no
reason a machine can't.

I think the move towards functional programming, and putting the onus on
developers to do the mental elbow grease of converting what are largely macro-
style tasks (do this, do that) into functional code (feed this transform into
this one) has done a great disservice to software engineering, especially with
respect to productivity.

For a specific example: I use map() frequently with a use() clause or some
other means of passing immutable variables to the inner scope. I have done the
work of building that dependency graph by hand. But I should be able to use a
mundane foreach() or even a dreaded for() loop, have the compiler examine my
scope and see that I'm using my variables in an immutable fashion, and
generate functional code from my imperative code.

What I am getting at is that in the olden days we used synchronous macros do a
series of tasks and even though it was mediocre at best, it gave tremendous
leverage to the developer. Today the amount of overhead required to map-reduce
things or chain promises and carry the mental baggage of every timeout and
failure mode is simply untenable for the human brain beyond a certain
complexity. What we really need is to be able to read and write code
imperatively but have it executed functionally, with every side effect
presented for us.

I realize there is a lot of contradiction in what I just said but as far as I
can tell, complexity has only increased in my lifetime while productivity has
largely slipped. Shifting more and more of the burden to developer proficiency
is just exactly the wrong thing to do. I want more from a typical computer
today that is 1000 times faster than the ones I grew up on.

~~~
brianberns
> I think the move towards functional programming, and putting the onus on
> developers to do the mental elbow grease of converting what are largely
> macro-style tasks (do this, do that) into functional code (feed this
> transform into this one) has done a great disservice to software
> engineering, especially with respect to productivity.

I think you've got this exactly backwards. Functional programming lets you
think at a higher level of abstraction (data flow) than imperative programming
(control flow). The compiler then applies elbow grease to translate your high-
level data flow transformations into low-level control flow constructs.

Let's translate your statement back a generation and see how it sounds: "I
think the move towards structured programming, and putting the onus on
developers to do the mental elbow grease of converting what are largely
assembly-level tasks (branch, copy, add a value to a register) into structured
code (if, while, for) has done a great disservice to software engineering,
especially with respect to productivity."

Hopefully you can understand how silly that seems to a modern programmer.

~~~
taneq
I don't think that data flow is a higher level of abstraction to control flow.
They're just different types of abstraction, and each has its strengths and
weaknesses.

If you only ever work on things that map well to functional programming then
you'll naturally think it's superior to imperative programming. Likewise, if
you only ever work on things that map well to imperative programming, then the
functional programming approach seems a bit silly.

~~~
TuringTest
Functional code can represent an imperative program (using temporal logic or
state monads), so it can be used for domains where you would use imperative
code.

It will not always be easier, but it certainly provides more control over the
execution flow.

------
TheAceOfHearts
Some feedback on the website: IMO, it's obnoxious and disrespectful to play
full screen video like you're doing. That just made me close it immediately
and leave after reading through the text.

Considering the complexity involved in developing a an advanced IDE or
similar, have you considered publishing an open source community version?
Similar to JetBrain with IntelliJ. They seem to be doing great.

Since we're on the subject of experimental UI concepts, I'll plug Bret
Victor's Inventing on Principle [0] talk. For me it was an instant classic.

[0] [https://vimeo.com/36579366](https://vimeo.com/36579366)

~~~
immigrantsheep
Why does EVERYTHING have to be opensource these days to be considered
acceptable?

~~~
TuringTest
Because with open source software:

\- You can run the program as you wish, for any purpose.

\- You can study how the program works, and change it so it does what you
want.

\- You can redistribute unmodified copies without fear of the publiher suing
you.

\- You can distribute copies of your modified versions to others without fear
of the publiher suing you.

Who _wouldn 't_ want to have all that in a tool that will be the basis for
your own projects?

~~~
immigrantsheep
I understand when we're talking about crypto or security. You want your data
to be safe. You want to know that it is what they're selling. But this? A guy
is building something that might be cool one day. One should he make his
engine/IDE opensource? He can but doesn't have to. I don't see people
screaming why SublimeText, AbletonLive, Photoshop or many other tools aren't
open source. There is still that thing called commercial software and some
people make a living out of it.

~~~
TuringTest
SublimeText, AbletonLive or Photoshops are not platforms where you create an
automated software artifact that runs on top of the tool. On top of a
programming language, however, you depend on the tool being always available
without major changes for as long as you need it to remain stable. This is not
guaranteed on a privative development platform. They are simply not in the
same class of products at all.

In all your three examples, the product they create is detached from the
creation platform before release, and that product (text, music, images) is
compiled/played/displayed on a different application; an also there are many
alternative tools where the product could be processed if the original tool
ceased to exist.

So there's no fear with those that, if the tool creator begins imposing more
and more restrictions, you'll be locked-in. But a unique programming language
for which your code can't possibly be ported to a competing platform? One
would be stupid to develop for it anything requiring ongoing commercial
support, beyond some cool tech demos.

~~~
immigrantsheep
Stupid as all those people building games with Unity? Or all those people who
used to use Unreal/UDK before v4 while there was no source code available?

Anyway not here looking to start a flame war. My point was that the product
can be good or bad and it doesn't have anything to do with it's source code
being available or not.

My 5c. Everyone feel free to disagree.

~~~
shakna
Both Unity and UDK recognised the benefits of open source, and have OS
components.

A product can be good or bad without OS. So long as you can deploy what you
make with it effectively.

Sometimes that means mindshare, like UDK and Source.

Sometimes that means complete decoupling tooling from code like Sublime and
Atom.

Sometimes it is more about the deployment, like Visual Studio and Unity.

However, to stand out, this product needs one of the above.

It's new, and doesn't seem to be backed by a big name, so no mindshare yet.

So they need to somehow make devs want to use it for their code. A nice
experience is usually not enough.

An OS community, or a fantastic cross-compilation strategy are the only two
things that I, personally, have seen work.

OS seems to be the easiest of the two.

~~~
jasonm23
> So they need to somehow make devs want to use it for their code. A nice
> experience is usually not enough.

While I side with your central argument, there are numerous cases where the
above is absolutely enough.

------
cocktailpeanuts
Is it just me? Or does this look 10 times geekier than writing actual code?

I think the project is trying to be a user friendly way of writing programs,
and I think that's an awesome idea, but the actual product looks otherwise.

I finished the video and still have no idea what the hell was going on through
out the entire video.

~~~
Naeron
There is a plan for a lengthier explanation video. The intention of the video
was to show that it can be done. Of course, some kind of explanation and
training is needed for everything, I don't dispute that.

~~~
dkersten
My problem with the video is that it doesn't show me what can be done. It
shows me that the ball can follow the line and with some magical symbols and
lines "other logic" can be "somehow" added. It didn't do anything to tell me
what other logic is possible, nor did it explain what the symbols and lines
mean. So I still don't really know _what_ can be done (besides a pong game)
and I've no idea what most of the on screen stuff even is or means.

------
vashington
The video was trying to do two things at once: explain the goals and high
level ideas as well as demonstrate "syntax" (the clicks and drag and drops).
Since these are both new to people coming to your site, it's hard to digest at
the same time. I'd love a video of just explaining what the demo is doing,
since I didn't really understand how to program in the new approach you
described.

~~~
Naeron
The exact method is not that important but the goal itself. But of course, you
have a point. The explanation is planned but had no time for it yet.

------
buzzybee
As soon as I saw a logic gate implemented for a single keypress I was "noping"
out of there. Visual methods, to a one, break down quickly when they reproduce
low-level digital logic. At that point, you have a software circuit board, and
this is a thing that your CPU can represent just fine by coding in assembly
and possibly adding an abstraction on top for a dataflow representation.

Graphics are absolutely wonderful, in contrast, when they are able to stick to
a domain abstraction, which is why we have a notion of application software at
all. I have, in fact, aimed towards discovering what a "Pong synthesizer"
would look like, so I have the domain knowledge to know that it does tend to
lead to the digital logic breakdown if you aim to surface every possibility as
a configurable patch point. As a result I started looking more deeply into
software modularity ideas and rediscovered hierarchical structures(Unix, IP
addressing, etc.) as the model to follow. I'm gradually incorporating those
ideas into a functioning game engine, i.e. I'm shipping the game first and
building the engine as I find time, and I do have designs for making a higher
level editor of this sort at some point.

However, I also intend to have obvious cutoff points. There are certain things
that are powerful about visual systems, but pressuring them to expose
everything at the top level is more obscuring than illuminating. So my
strategy is to instead have editors that compile down to the formats of the
modular lower-level system, smoothing the "ladder of abstraction" and allowing
people to work at the abstraction level that suits them.

~~~
johnp_
The logic gate's primary function seemed to be in limiting the paddle to not
move outside of the playing field.

Otoh, in a visual programming language it'd feel more natural to make the
upper and lower edges of the playing field collidable (I'm sure there's a
better word for that), so that moving the paddle is inherently limited by
collision with the edges.

------
pttrsmrt
Like so many projects on the internet: Lots of big words and ideas, but no
content. Show us some actual tech and code and I might throw my money your
way. Or better: Release your code under an open license and I might even throw
my time your way!

~~~
Naeron
I need the money to develop it fully. If it was usable at this point, I would
release it, no doubt. I want something out of the door ASAP, that's why it is
focusing on 2D games first. That is feasible but still hard. This is really
not a technology in the traditional sense. The runtime itself is nothing new.
The real thing is the UX, that is how programming can be made more efficient
to do. I believe if someone supports this, he/she supports the goal of this
project, not the concrete implementation.

~~~
MattRix
I love the idea of it... but the video makes it very hard to see how it works.
I believe it's possible to show how this works without it actually working
right now. I think you might be focusing too much on making it look good and
polished, you need to just make it work, bare bones!

~~~
dkersten
_I believe it 's possible to show how this works without it actually working
right now._

Exactly! A short tutorial using screenshots to explain what stuff means, for
example, would go a long way and doesn't actually require anything to be
implemented as the screenshots could be mocked up.

------
cafebabbe
There is this old idea that programs are somehow "limited" by their textual
representation, and that a 2D graphical syntax would unleash more
possibilities. Never worked very well so far, unfortunately, except for a
bunch of very specific niches.

~~~
ipnon
Isn't this just UML for a generation that wasn't programming during Dot Com?

------
relics443
From what I understand after watching true video, I think this abstraction
could work for extremely simple implementation details, but once the
implementation gets even slightly complex, the scale of complexity of coding
it with this system balloons.

~~~
Thrillington
That's the exact problem I encountered when I worked on a similar product for
microcontrollers.

Having to use a mouse to interact with your programming ide graphically
doesn't scale. It does make for a decent tool for hobby projects or
prototyping though.

------
delegate
I like it and I think this is the general direction that creating applications
will look like in the future.

But don't throw away text-based programming yet; the wiser move would be to
_combine_ the two.

Find use-cases were visual DeepUI style programming shines and is vastly
superior to text-based programming, but let me polish the details with old-
school text source code.

There are apps which already do a lot of this, for example Unity - you can
assemble your scenes and animations visually and tune it up with code.

------
marknadal
I worked on Accelsor which is a tactile-spatial programming language, and I
think the ideas here are actually really good (so don't let HN haters get you
down).

Ultimately work like this though leads to needing to reinvent all of
programming (unfortunately) for instance, I'm now having to build a graph
database to handle Turing Complete systems that are being collaborated on in
realtime (see [http://gun.js.org](http://gun.js.org)). So prepare for a long
haul of work ahead of you. Get to know people in the space, like me and the
Eve team, etc.

If you persist long enough (don't let money or lack of money stop you) you'll
make a dent. :)

~~~
Naeron
I still have to eat though :)

------
jdiez17
This seems quite similar to LabView. So I imagine it'll have similar pros and
cons: LabView is great for putting together quick prototypes for e.g data
collection or visualization, but it quickly becomes unmanageable as the
complexity increases; you need to 'tidy up' the placement of the various
operators or it ends up being a rat's nest.

~~~
DonaldFisk
No, they explain that LabVIEW and other visual languages are just different
ways of representing the code. The idea here, I think, is that there's far
greater coupling between the output of the program and the program itself.
It's similar to some of Bret Victor's ideas:
[https://www.youtube.com/watch?v=PUv66718DII](https://www.youtube.com/watch?v=PUv66718DII)

I'd like to incorporate this coupling idea into my own visual dataflow
language
([http://web.onetel.com/~hibou/fmj/FMJ.html](http://web.onetel.com/~hibou/fmj/FMJ.html)),
but haven't yet decided how to implement it. My approach has been to design
the language from the bottom-up, so that simple programs can be simply drawn,
and there are higher level programming constructs which simplify more complex
code, avoiding the complexity problem (the Deutsch limit) you've seen with
LabVIEW.

------
swalsh
That auto full screen thing is infuriating.

~~~
vvanders
Just came here to say the same thing, sounds interesting but I bounced soon as
I couldn't view outside of fullscreen.

~~~
haskman
Agreed, that was very strange. Right click "Copy video link". Leads me to -
[https://www.youtube.com/watch?v=Gy5m091fOTU](https://www.youtube.com/watch?v=Gy5m091fOTU)

~~~
Naeron
As a quick fix, I've put there a direct link to that video.

~~~
wingerlang
I think you should just turn off the forced full screen. No reason to have it
at all.

------
alunaryak
I like the idea of a physical analog to game logic, e.g. tripping a certain
condition based on collision mechanics. This could be useful for something
akin to Game Maker, and I'd be curious to see how it would translate to other
mediums. I could imagine front end programming would be well suited for this
style, especially when creating interactive prototypes.

~~~
Naeron
Yes, those would work too.

------
dkersten
I found the video quite confusing.

It seems like its great for things that have an on-screen spatial meaning like
the pong example game[1]. But what if I want to represent something abstract?

Like a tree (lets say a quad-tree since this is for (2d?) games for now)? Or
what if I want to implement AI logic (lets say I want some kind of decision-
tree planner and path finding)? I'm having trouble visualising (I guess
because the video didn't really go to explain) how any of this can be done, as
opposed to "moving something around on the screen".

I assume this has been thought about. I just couldn't figure out any of the
details from the video.

[1] although even in that case, I couldn't figure out what the symbols and
lines in the video meant. The symbols especially seem cryptic. A mix between
logic gates and something else?

------
petterfaiknavn
Looks very similar to blueprints in UE4, with more visual integration of what
actually happens.

~~~
Naeron
Actually, that presents the code in a visual way while this allows you to work
on the thing itself. Similar to Stop Drawing Dead Fish by Bret Victor:
[https://vimeo.com/64895205](https://vimeo.com/64895205)

------
seanmcdirmid
Looks interesting. I would like a more detailed look at the visual language
being used here. How is logic projected out into the physical world, is it
simply making variables into nodes?

------
big_paps
Looks like completely detached from reality. Its like a digital revival of
electronics ?

------
blueprint
This looks like a complete scam.

~~~
Naeron
Why do you say that?

~~~
azeirah
To be fair, your site looks like one of those weird overly ambitious
overpromising products like

* [http://madmaniak.github.io/pro/](http://madmaniak.github.io/pro/) * [https://thegrid.io/](https://thegrid.io/) (seems like their site is having some difficulties)

Before yours, there have been many products that promise to enable programming
for everyone, many of these have been scams, utter failures or were just
overly marketed mediocre software packages.

The things is, the way your video seems voiced to "sell" rather than "explain"
what is going on, as well as the odd, or at least "unique" hacker aesthetic of
the website makes it look very dubious.

I have no idea how to showcase a product like this the "right" way, maybe
there is no "right" way, but I can certainly say that the aesthetic, big
claims, confusing video and ambitious future plans give the project a bad
smell.

------
aylmao
Can't watch the video right now. Anyone can summarize it? What is this / how
does it work (from a user standpoint)?

(Pro-tip for the site; screenshots and concrete descriptions on how things
work)

------
godmodus
Cute idea. Why No Linux?

~~~
pjmlp
Maybe because GNU/Linux users are allergic to money for desktop software.

~~~
greyman
Out of respect for Linus, it should be called Linux, and not by some made-up
name.

~~~
dgellow
Linux is a made-up name.

~~~
greyman
No, Linus created a piece of software and called it Linux. It is his creation
and he named it.

~~~
icebraining
Funnily enough, he didn't :)

 _Initially, Torvalds wanted to call the kernel he developed Freax (a
combination of "free", "freak", and the letter X to indicate that it is a
Unix-like system), but his friend Ari Lemmke, who administered the FTP server
where the kernel was first hosted for download, named Torvalds's directory
linux._

------
ungzd
A mashup of flowcharts and FRP with Hollywood aesthetics?

~~~
Naeron
FRP seems about right and I wanted it to look cool :). But no flowcharts,
those represent steps. If you are talking about the logical symbols, they are
not step based at all. Rather more similar to physically implemented logical
circuits.

------
Vandash
Very promising, the site doesn't talk about Unity 3D, did you consider
building a plugin for it?

~~~
Naeron
No, I haven't considered it yet. To be frank, my plate is full right now.

------
Naeron
Many people did not understand the video so I am going to create a detailed
explanation.

------
Naeron
Fullscreen issue has been fixed but the old version of the website is still
cached.

------
UhUhUhUh
Is it a sort of Wolfram's approach? Candidly asking.

------
org3432
I watched the video but have no idea what I'm looking at, it's supposed to be
a pong game of some sort?

------
revelation
So they've reinvented Matlab Simulink or LabVIEW with a dorky interface and
.5% of the functionality.

~~~
IshKebab
I feel like 90% of the problem with Labview is the interface, so I wouldn't
discount interface improvements.

Even if this wasn't spaghetti code, most of the Labview icons are totally
unreadable:

[http://www.ni.com/cms/images/devzone/pub/nrjsxmfm91216399872...](http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg)

------
triptych
The misspelled purpose.

~~~
Naeron
fixed, the old one is still cached though

------
asow92
Good luck.

