3 ms·

Introducing Sifflet: a visual functional programming language

6 points by dons 16y ago

gruseom 16y ago
It's amazing how regularly people reinvent this. Truly the perennial failed paradigm. I once worked with a programmer who had a bee in his bonnet about visual modeling languages. Every week or so he would arrive for another hour-long harangue on the topic. Nothing I said could convince him of anything, until one day it occurred to me to suggest that he take a moderately complex real-world model (from one of our clients) and mock it up in his visual language. He disappeared for three months, then showed up at my office, said "You are right! Can't be done," and left. That was the end of that. I was lucky, though, because this guy was smart. Had he come back with visual spaghetti instead I would have been done for. I should add, though, that people have told me that visual programming languages have found a niche in industrial process control. I have yet to hear a good answer as to what it is about this domain that makes visual programming actually work, since it's so infamous for being useless in pretty much every other area of computing.
- deleted 16y ago
  [deleted]
- starkfist 16y ago
  It's a decent paradigm for anything that has to do with signal processing. It mirrors almost exactly how you would do it in real life. I.e. connecting cables to boxes which do a filter or an amplifier or an oscillator or whatnot. The best examples are systems like Labview, Max/MSP and Quartz Composer.
  - gruseom 16y ago
    Ah, that may explain it: the programs are constrained by the physical things that they're modeling.
- theBobMcCormick 16y ago
  I gotta agree with you there. I think visual programming environments can be very useful in certain limited domains where you're mostly just "wiring" up a set of pre-existing components into a fairly small "script". Apple Automator in OSX is IMHO a great example of this. But the idea of building any reasonably large program in a visual environment is fundamentally unworkable.
TrevorBurnham 16y ago
Love the idea. I find the UI itself rather inelegant, but I'd be happy to see more experimentation in this direction.
ihumanable 16y ago
The mental model doesn't seem consistent to me. Within a function diagram the boxes (which seem to just be functions) have input and output nodes, but the function that you are working on contains it's arguments. Taking a look at the first example from the tutorial, it would make more sense to remove the salesA and salesB boxes and instead have nodes on the outside of the function. Then you could have external nodes (one for salesA and one for salesB) feed into the grossProfit function. This would solve the problem of the fairly inelegant "Input Values" dialog. Ultimately I agree with gruseom on this one, any real world program would be sufficiently complex to make this not very useful. But as a teaching tool I think it could be wonderful to take abstract concepts and turn them into concrete objects that a student could play with and inspect. It's also nice to see all the intermediate values.

6 points by dons 16y ago

It's amazing how regularly people reinvent this. Truly the perennial failed paradigm. I once worked with a programmer who had a bee in his bonnet about visual modeling languages. Every week or so he would arrive for another hour-long harangue on the topic. Nothing I said could convince him of anything, until one day it occurred to me to suggest that he take a moderately complex real-world model (from one of our clients) and mock it up in his visual language. He disappeared for three months, then showed up at my office, said "You are right! Can't be done," and left. That was the end of that. I was lucky, though, because this guy was smart. Had he come back with visual spaghetti instead I would have been done for. I should add, though, that people have told me that visual programming languages have found a niche in industrial process control. I have yet to hear a good answer as to what it is about this domain that makes visual programming actually work, since it's so infamous for being useless in pretty much every other area of computing.

deleted 16y ago
[deleted]
starkfist 16y ago
It's a decent paradigm for anything that has to do with signal processing. It mirrors almost exactly how you would do it in real life. I.e. connecting cables to boxes which do a filter or an amplifier or an oscillator or whatnot. The best examples are systems like Labview, Max/MSP and Quartz Composer.
- gruseom 16y ago
  Ah, that may explain it: the programs are constrained by the physical things that they're modeling.
theBobMcCormick 16y ago
I gotta agree with you there. I think visual programming environments can be very useful in certain limited domains where you're mostly just "wiring" up a set of pre-existing components into a fairly small "script". Apple Automator in OSX is IMHO a great example of this. But the idea of building any reasonably large program in a visual environment is fundamentally unworkable.

TrevorBurnham 16y ago

Love the idea. I find the UI itself rather inelegant, but I'd be happy to see more experimentation in this direction.

ihumanable 16y ago

The mental model doesn't seem consistent to me. Within a function diagram the boxes (which seem to just be functions) have input and output nodes, but the function that you are working on contains it's arguments. Taking a look at the first example from the tutorial, it would make more sense to remove the salesA and salesB boxes and instead have nodes on the outside of the function. Then you could have external nodes (one for salesA and one for salesB) feed into the grossProfit function. This would solve the problem of the fairly inelegant "Input Values" dialog. Ultimately I agree with gruseom on this one, any real world program would be sufficiently complex to make this not very useful. But as a teaching tool I think it could be wonderful to take abstract concepts and turn them into concrete objects that a student could play with and inspect. It's also nice to see all the intermediate values.