
Viskell: Visual programming meets Haskell - bojo
https://github.com/wandernauta/viskell
======
VladimirGolovin
Cool! I'm also working on a visual functional language conceptually similar
Haskell. I'm a founder of
[http://www.filterforge.com](http://www.filterforge.com), and I want to
develop a proper (i.e. Turing-complete, strongly typed with type inference,
pure, lazily-evaluated) visual language for the next major rewrite of Filter
Forge. Here's what I've been able to achieve so far:

A simple program (with equivalent Haskell and Racket code):
[http://i.imgur.com/dsNJYyx.png](http://i.imgur.com/dsNJYyx.png)

List of strings, with element insertion GUI:
[http://i.imgur.com/Re64IJE.png](http://i.imgur.com/Re64IJE.png)

A more complex program, a function definition, and some sugar for infix math:
[http://i.imgur.com/KoxjoOM.png](http://i.imgur.com/KoxjoOM.png)

Fold using a lambda, with equivalent Haskell code:
[http://i.imgur.com/avQNHXS.png](http://i.imgur.com/avQNHXS.png)

Complex signatures, polymorphism and typeclasses:
[http://i.imgur.com/cZ4KMzt.png](http://i.imgur.com/cZ4KMzt.png)

~~~
i336_
Congratulations, you're now a member of the elite club of people who've
(possibly accidentally? :P) made a subfeature so cool it needs to be a first-
order thing in its own right.

I'm sure you've seen all the back-and-forth on here about open-source vs.
closed-source in programming languages and taken note of current trends. :D

What I _will_ say is that this looks very, very complete, and it would be a
tiny shame to limit its awesomeness and usefulness just to Filter Forge.

An as-is officially-alpha build of whatever produced those shiny screenshots
would certainly go down very well.

~~~
VladimirGolovin
Thank you, that's very encouraging!

The feature was not accidental. I always wanted to expand the possibilities of
Filter Forge's nodal language, but until I met Haskell I didn't know how to do
that. And now, after trying Haskell, it's simply impossible for me to think in
terms of non-general, domain specific visual languages. The Haskell paradigm
lends itself very well to a visual syntax, but there's a lot of problems to be
solved, and that will be an excellent challenge for me in the coming years.

Despite looking complete, it's really, really far from that. There are serious
conceptual problems that remain unresolved yet. We do have a visual tool for
constructing and typechecking programs, but it’s not yet ready for any
release, even an as-is alpha. Actually, the screenshots I posted are my Excel
mockups: [http://i.imgur.com/WYeLJJr.png](http://i.imgur.com/WYeLJJr.png)

As for the open-source / closed source, I spent some time thinking about that,
and discussed the idea with the team, but we’re not ready to make the decision
yet.

On one hand, I'd be immensely pleased if our research on visual syntax for
functional languages could be useful to the wide world. Functional programming
really deserves wider adoption, and if our research can help that, I’d be very
proud. Also, open-sourcing this may bring a lot of benefits to our commercial
product, because it will allow us to access the global talent pool of
functional programmers, who, collectively, have vastly more expertise than all
our developers combined. I also think that many of these programmers are in
academia, and would welcome a visual tool that could help them teach
functional programming to their students.

On the other hand, we, as a company, have absolutely no experience in starting
and maintaining open-source projects, and we have no idea how to do that
properly, and what resources will it require from us. I’ll have to read up on
that.

~~~
i336_
> the screenshots I posted are my Excel mockups

 _ba-dum-tss_

...I see :P. Well, you've definitely got a really nice visual design so far,
at the very least. I say keep it; the aesthetic (Excel-ness and all) looks
good. (That said, now I know that it's Excel, I do strongly associate the
visual style with Excel... so there is that. Could be me though.)

To open or not to open is certainly not a decision that can be made lightly,
so careful consideration FTW.

On the one hand, this is a fairly unique, original idea, and not something
that's been explored all that much, so there isn't that much competition. It
would make for a very special product (if you made it standalone) or component
(if you just used it in FF) and put you in a very unique position.

But if you stay closed, development and evolution would be driven soley by the
experience level (and available time) of the development team behind FF.

On the other hand, language design is incredibly nuanced because of all the
offerings that are available out there, and it takes a lot to make a language
succeed, both design-wise and implementation-effort-wise. There's also a lot
of technical competition - people will flock to whatever's easier to use, less
buggy, more developed - and, lately, what's more active.

On top of that, visual languages are a very special case scenario. Considering
there's so little out there in terms of visual languages, in a field where
academics and tinkerers are constantly trying every possible combination, it's
clear that for systems like this to make it, they must provide just the right
amount of flexibility/functionality: too little and they'll be frustrating too
use, too much and they'll lose design coherence. I suspect the sweet-spot for
this level is less generalized than that of common programming languages.

There are people out there that _really_ know language design, know the
pitfalls, have made the mistakes, etc, and it would be ideal to be able to get
anchoring design/implementation advice for the core system from this hivemind,
especially considering the experimental direction you're trying to go in.
(This would logistically be significantly trickier, if not absolutely
impossible, in a commercial context.)

A few open-source models I can think of off the top of my head, which I've
observed and taken vague mental notes on over the years (I feel like I'm
forgetting the important ones):

\- Fully open, code released as-is; no support, patches/PRs only - popular
among burnt-out developers (possibly with soul-crushing jobs)

\- Periodic (weekly to biyearly) code-dumps released as-is; full commercial
support - the codebase is open so people can tinker with it, but everyone
knows the party's where the private repo's at, and the open code dumps are so
badly far behind in the dust, there isn't much activity on the open codebase

\- Open-source version as-is but supported; commercial version has added magic
unicorn pixie dust - interact and make the open-source version feel like it
has a nice big community/hub atmosphere around it and you'll eventually
attract contributors. (Proceed to spend 90% of your time breaking up catfights
among said contributors.)

\- Fully open-source; random company decides it's the perfect thing to base
their internal stack on - development track must be well-defined in order to
to compartmentalize personal goals while prioritizing contracted feature
requests

\- All program source and related assets placed into the public domain -
developer is insane

I write the above as a more-or-less-non-developer with no real-world practical
experience. I'm still collecting ideas and methodologies and working out which
ones to use where.

One thing I've seen reiterated various different ways is having clearly
defined limits. Without this, I've heard you can can wind up having to deal
with types who'll send in the support request equivalent of leaving a 10lb
dumbbell on the accelerator and walking away... yes, open source can
occasionally _look_ like a perpetual motion machine, but that's largely an
optical illusion, there _are_ real people behind the support buttons and
algorithmic magic.

Something that will be incredibly useful in my case is cultivating
consistency: I'm currently figuring out how much public-facing interaction
(commit frequency, reply latency, general visibility) I can handle on a really
bad day/week/month, so I can then stick to that level regardless of where I'm
at. On a good day keeping up everything will only require very little of me,
on a bad day I'll still be able to poke stuff without getting too badly
bitten. I expect you've already established this with FF, but this type of
thing needs to be more explicitly defined in an open-source context (where
there's a lot more interaction).

Another useful thing that I think might be relevant here is the idea of closed
betas: the code is _technically_ open source, but everyone agrees to keep the
lid on it until some specific point in the future. This is ideal both for
solidifying project design and incubating an initial userbase who will not be
able to help but share it when it goes open :D (I will mention, however, that
I'm aware of projects out there that have been invite-only for years (due to
licensing issues, looks like) and it's driven me crazy that I have to commit
to signing up to the (free) project's beta in order to take it for a 30sec
spin. The ideal solution to this, I think, would be keeping it predominantly
private and only doing limited publicity; with good ideas, this won't be
damaging.)

~~~
VladimirGolovin
> _a really nice visual design so far, at the very least. I say keep it_

Thanks :) This is basically Material Design / Flat design, and I consider it
to be perfectly good-enough for an MVP, so yep, I'm keeping it :)

> _To open or not to open is certainly not a decision that can be made
> lightly_

Absolutely. Thank you for your write-up on open source models - you just saved
me a lot of work. I'm bookmarking your comment for reference.

A concern I have about the entire open-source thing is that it will put a lot
of maintenance burden on us, while not providing enough benefits in the
'breakthroughs departnemt'. For example, I'm sure the contributors can
optimize performance or implement relatively minor inprovements, but I doubt
that the community will be able to implement big systems (for example visual
support for higher-kinded types). Is this generally the case, or I'm being too
skeptical due to my lack of experience with open source?

> _On top of that, visual languages are a very special case scenario.
> Considering there 's so little out there in terms of visual languages, in a
> field where academics and tinkerers are constantly trying every possible
> combination, it's clear that for systems like this to make it, they must
> provide just the right amount of flexibility/functionality: too little and
> they'll be frustrating too use, too much and they'll lose design coherence.
> I suspect the sweet-spot for this level is less generalized than that of
> common programming languages._

These days, there are two kinds of visual functional languages in use by
general (non-programmer) public:

1\. Node-based image / video processing systems. Examples: material / shader
editors in any modern 3D modeling app (3DS Max, Modo, Maya, Houdini etc.) and
compositing apps (Shake, Nuke etc). Node-based (i.e. functional) workflow is
nowadays a standard in these apps. Language-wise, these are simple funcional
languages without higher-order functions, recursion and flexible type systems
(they do offer strict typing, but you cannot construct custom types).

2\. Excel. Yes, Excel. Basically, it's a tree of formulas, which are mostly
pure (except for certain functions that access time, random numbers etc.). The
evaluation order depends on the functional dependency, not row/column order,
just like in a pure lazy functional language. No recursion, no reusable
functions (though Simon Peyton-Jones proposed adding spreadsheet-defined
reusable functions to Excel). Weak typing, no custom types, no recursion, no
turing-completeness.

What I'm aiming for with my language is not full generality. It will be
somewhere in between Haskell and Excel. It will be fully turing-complete like
Haskell, but in terms of 'side-effectness' it will be more similar to Excel
and Filter Forge: the program is entirely pure, and the only elements that
access or produce side effects are the inputs and outputs of the program. The
program is executed momentarily, just like in Excel and Filter Forge, and
there's no notion of time or waiting.

------
windlep
This is cool, but not really the problem I have, nor many I've talked to have
when actually doing something 'real' in Haskell. (Granted we're a rare breed,
actually trying to _use_ Haskell for real-world use outside academia)

Show me how much memory a program will actually use. If it uses a lot, show me
_why_ it did, and _where_ it did.

This is a solved problem for most mature languages, and the lack of tooling
making it even remotely possible to figure this out in Haskell speaks volumes
about how ready it is for "real world use".

~~~
i336_
It might be worth starting a discussion on this subject (here or elsewhere) to
make more people aware of this problem.

(It was buried at the bottom of the comments here, not many people will see
this)

------
justinmk
Has anyone been following Lamdu[1] and can comment on its status? I had
expected to hear about it more often when it was announced 2 years ago...

[http://www.lamdu.org/](http://www.lamdu.org/)

~~~
i336_
TIL about this, this is very cool.

FWIW, "Latest commit ... 4 days ago," so it's not dead, which is nice. (And 4
days certainly gives lots of hope!)

------
melloclello
Unison bears linking in this thread I think.

\- [http://unisonweb.org](http://unisonweb.org)

\- [http://unisonweb.org/2015-05-07/about.html#post-
start](http://unisonweb.org/2015-05-07/about.html#post-start)

------
pjmlp
For me visual programming adapts quite nicely to many FP concepts.

I can easily imagine some graphical tool similar to digital circuits design,
where the basic build modulus are the lambda calculus basis.

------
agumonkey
It might not be clear, but here's an application to generate cities
'procedurally' using data flow operators

[https://youtu.be/PDrALvAqsaI?t=254](https://youtu.be/PDrALvAqsaI?t=254)

The possibilities of this 'paradigm' are pretty unbouded and not tied to the
usual programming data types.

~~~
VladimirGolovin
That's not just an application for procedural cities, that's Houdini
([http://www.sidefx.com/](http://www.sidefx.com/)), a relatively well-known 3D
modeling, animation and rendering tool based on the node-based (a.k.a.
functional) approach. I investigated them, and while I found the tool itself
very powerful, its language is not a proper general-purpose functional
language, and I don't think it's turing-complete (if you exclude their
integrated Python scripting).

~~~
agumonkey
Yeah, I didn't imply it was a tool dedicated to this task, it's just a non-
traditional example of dataflow (most of the time I see signal, maybe image
composition, very regular data types).

You're right that the node-based part is not a proper GPFP. I just wanted to
link a 'complex' application of the visual ~functional (if piping is function
composition is correct) kind.

------
discohead
Visual programming is always well-suited to audio synthesis, would be cool to
see something like the Synthesizer library in there:
[https://wiki.haskell.org/Synthesizer](https://wiki.haskell.org/Synthesizer)

------
vmorgulis
I can add Scheme Bricks:

[http://www.pawfal.org/dave/index.cgi?Projects/Scheme%20Brick...](http://www.pawfal.org/dave/index.cgi?Projects/Scheme%20Bricks)

