4 ms·

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 m

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_ 11y ago
> 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 11y ago
  > 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.

i336_ 11y ago

> 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 11y ago
> 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.