Viskell: Visual programming meets Haskell
github.com
github.com
A simple program (with equivalent Haskell and Racket code): http://i.imgur.com/dsNJYyx.png
List of strings, with element insertion GUI: 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
Fold using a lambda, with equivalent Haskell code: http://i.imgur.com/avQNHXS.png
Complex signatures, polymorphism and typeclasses: http://i.imgur.com/cZ4KMzt.png
What we have now as actual working code is a visual editor that allows to connect nodes together, a typechecker that prevent connections between different types (and invalidates / blackens existing connections if they somehow go wrong), and multi-input / variadic nodes such as lists and tuples.
It's not yet executable - you can't run the program in our visual environment yet, you can only construct / typecheck them. Also, we have a metric ton of unsolved problems: function definition and signatures, deconstruction of ADT values, definition of ADTs, preview of intermediate values for each node etc.)
Based on what I see right now, it will take at least a year before we have anything resembling a proper language. Also, I predict that the runtime performance will be awful.
It is likely that it is because I spend more time parsing text, so I am more experienced at that than at parsing relevant information from flowcharts.
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.
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
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.
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.)
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.
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".
(It was buried at the bottom of the comments here, not many people will see this)
FWIW, "Latest commit ... 4 days ago," so it's not dead, which is nice. (And 4 days certainly gives lots of hope!)
I can easily imagine some graphical tool similar to digital circuits design, where the basic build modulus are the lambda calculus basis.
https://youtu.be/PDrALvAqsaI?t=254
The possibilities of this 'paradigm' are pretty unbouded and not tied to the usual programming 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.
http://www.pawfal.org/dave/index.cgi?Projects/Scheme%20Brick...