This idea will eventually work and be huge I think (I know visual programming languages already exist but a commonly used one to emerge). As someone who believes in metaprogramming and flexibility though I'm hoping for something dynamic, not a heavy mandatory type system that compiles to Haskell.
I have this crazy idea in the back of my mind to write a visual programming language based on Haskell, where shape and colour convey kind and type information. Still cooking that one.
This is awesome! I know lots of people would love the type safety of a Haskell or OCaml combined with the metaprogramming and AST manipulation capabilities of a Lisp - and that seems to be the eventual goal of this project.
Cool! I'm also working on a visual functional language conceptually similar Haskell. I'm a founder of 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:
I was thinking Ruby actually, although Haskell could probably be close too. In any case is sounds like the suggestion is to move away from imperative, procedural programming, which has been talked about a lot in various ways.
Exactly! I've been drooling over this kind of language in my dreams for quite a while now. Though I'd also like to see fully dependent types in there as 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.
Hmm, interesting. I've been thinking about a Haskell-based shell, but the flow of concatenative programming might be a better fit. Maybe I'll have to play with this idea this summer as well...
Heh, I find it the next step in evolution after lisp. All the same flexibility, but with a new language that lets you delineate and work with the meaning of your data alongside the data itself.
I don't think it's anything resembling practical in its current state, but I think it's absolutely the way of the (possibly deep) future. I want to spend more of my time programming with types than programming with values since that's where my brain honestly is (despite the type languages of today being a bit obtuse) and since the compiler is often able to program the value-level stuff for you.
As Haskell begins to get more and more dependently typed features this could definitely be an exciting possibility (I think there are folks already working on this).
reply