18 ms·

Funciton – A graphical programming language

165 points by minxomat 9y ago

taneq 9y ago
Marvellous, they've reinvented Function Block Diagram programming. https://en.wikipedia.org/wiki/Function_block_diagram https://en.wikipedia.org/wiki/Function_block_diagram
- tathougies 9y ago
  Um.. no they haven't. Function block diagrams do not support recursion. Unlimited recursion basically means a graphs ability to modify itself at runtime -- i.e., change the wiring.
  - fdsfsafasfdas 9y ago
    > Function block diagrams do not support recursion. As someone not familiar with this, why not? Can't you just draw a line from output to input?
    - taneq 9y ago
      Generally not. PLCs are designed to be as reliable and fault tolerant as possible, so they don't allow recursion (along with a bunch of other things, like direct memory access with pointers[1]) since it's so easy to accidentally make something either take a really long time, or fail to terminate. You can fake it by piping an output into a variable which is also used as an input, but this makes it explicit that the last value is used then the next value stored, rather than multiple steps of recursion happening in one scan. Generally the kind of software you develop in structured text doesn't need recursion anyway.
- javra 9y ago
  Did you actually read the description of the language?
donquichotte 9y ago
I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well. Simple visual programs are arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks. The deal breaker for me (having worked on a large LabView program that controls machinery for a wind energy system) is the lack of reasonable source control systems and the fact that it is very hard to structure a large program in a comprehensive manner.
- avaer 9y ago
  Actually I'd say the visual languages do a much better job representing what the computer circuit is doing. But that's exactly the problem. Handling that complexity is the reason we invented textual programming languages.
  - hatmatrix 9y ago
    I think textual programming languages predates visual languages on account of the hardware available at the time...
  - TuringTest 9y ago
    We have better abstractions for textual programming because there has been much more research poured into them, but there's nothing preventing visual languages from being used at higher abstraction levels - they don't necessarily represent the computer circuit level. The typical strongest point of visual languages is that you can represent relations by proximity. This way, you can directly indicate the connection between a caller and its calles with an anonymous connector line, whereas in text you would need to declare a variable name, pass it as a parameter and assign it to a local variable. This makes moving data between components much more verbose in text than in graphs. Textual programs try to approximate this relations-by-proximity with indentation levels, but the expressive possibilities in a visual language are stronger. This makes them also more difficult to lay out and organize, though. But I foresee than in the future, better support in IDEs will make it easier to mix visual and textual languages.
amelius 9y ago
Can a statement be made about the size of these diagrams w.r.t. the size of an implementation in e.g. Haskell? For example, can these diagrams "blow up exponentially" like deterministic finite automata do w.r.t. their source regular expressions?
minxomat 9y ago
Guys, I hope you keep in mind that this is an esolang, it's intention is not to be practical, but interesting. And I think in that it succeeded. I also recommend a look into the repo which contains the parser, which could be interesting. For me it was, because I never really thought about how to parse diagrams.
- TuringTest 9y ago
  I get that a submission like this is not intended as a suggestion for a practical tool, but as a curiosity and invitation to explore. It's great as a first attempt to delve into the strengths and shortcomings; you can't learn what won't work until you try. The author should explain the motivations after this design, and could get hints from other similar languages to improve the language. IMHO the notation has several shortcomings that would make it very hard to use in practice, and not the best strategy for working with functions. Maybe it's my fault for not seeing the purpose of this approach; but in my experience, free-form graph-based language work best when they emphasize working on collections and data streams, rather than on scalar function parameters. For the kind of example problems expressed in the article, a tree-based notation would work better.
  - minxomat 9y ago
    Not really to explore, the intention is nothing but to be esoteric. Suggesting things to make this lang easier to use (i.e. less esoteric) is akin to suggesting adding names to brainfuck commands to make it more readable. Timwi does have some other useful projects though (take a look at his github), all of which are basically centered around parsing. (an IL debugger, a C# parser, generic regular expressions...)
    - TuringTest 9y ago
      You're right, I didn't get that this is was intended as esoteric. Actually the parser for the language, if it works right from the Ascii art and not an intermediate representation, must be awesome. This also explains why the visual syntax is much better suited for a computer than human readers though. :-)
jlebrech 9y ago
ascii makes it ugly, why not use file and directory names? or even store nodes in a special file format?
- Aardwolf 9y ago
  It's actually unicode instead of ascii. It's full of special characters for boxes, and more for the function library. But I get your point, you probably meant "fixed width text characters" instead of ascii. I'm just being pedantic :)
  - jlebrech 9y ago
    just use ncurses, have a gui to "add new class", etc. and a box == class. I often thought that languages shouldn't need any OO keywords if those features are visual, ie. boxes and arrows.
imron 9y ago
dum de dum won't you take me to dum de dum a func-i-ton
- dwringer 9y ago
  I know this type of comment is often frowned on here, but let's be honest - this is the reason EVERYONE came to the comment section.
  - imron 9y ago
    I knew it would bring downvotes but the pun was just too irresistible.
TuringTest 9y ago
Your language advocates a [X] Boxes and arrows [ ] Spreadsheet-like [ ] Control flow block primitives [ ] Grid world simulation approach to visual programming. Your approach won't work because it gets poor scores in the following cognitive dimensions (https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...): [ ] Abstraction gradient [x] Closeness of mapping [ ] Consistency [x] Terseness [x] Error-proneness [x] Hard mental operations [ ] Hidden dependencies [ ] Juxtaposability [x] Premature commitment [ ] Progressive evaluation [x] Role-expressiveness [ ] Secondary notation and escape from formalism [x] Viscosity [ ] Visibility and the following philosophical objections may also apply: [ ] Any schema based on undeclared program state is unacceptable [x] Complex dependencies will get intermingled and make a mess [ ] You can't have more than 50 visual primitives on the screen at the same time [x] Function application is the wrong abstraction for flow graphs [x] Similar proposals have been tried in the past, and failed [x] It requires seeing the whole thing at once [ ] It doesn't allow for in-place comments [x] Evaluating program state is hard Furthermore, this is what I think about your solution: [x] Sorry dude, but I don't think it would work. [ ] This is a stupid idea, and you're a stupid person for suggesting it. [ ] Nice try, assh0le! I'm going to find out where you live and burn your house down!
- TuringTest 9y ago
  Obligatory self-deprecating criticism: https://it.slashdot.org/comments.pl?sid=4366081&cid=45208069 https://it.slashdot.org/comments.pl?sid=4366081&cid=45208069
- GuiA 9y ago
  These copy pastas (whether for visual programming languages or approaches to solving spam or whatever else), while witty the first time one sees them, get irrelevant very fast as they only provide generic, blanket criticisms of a design with no consideration for the tradeoffs involved or why they are made. In other words, you could post such a takedown for plenty of visual programming languages that have very satisfied users who are made very productive by their use. Does that mean they “won’t work”? Clearly not. These text templates are very easy to post - all it required of you was to skim the page, add an X to the lines where it felt like there was sort of a match even if you don’t really know, and click “post” - but they provide little to no value.
josetzamora 9y ago
Every time I see the word Funciton, it makes want to swap the letters t and i!
- drabiega 9y ago
  It just get the song Funkytown stuck in my head.
- ferdterguson 9y ago
  I read it as function and probably wouldn't have noticed without this comment. Whimsical software names are the bane of my existence.
mannykannot 9y ago
This is almost timely, following the recent 'Why Does Visual Programming Suck' post [1]. Funciton did not get mentioned in the ensuing discussion. My first impression, from the factorial function example, is disappointment - it does not seem to promise any improvement in clarity, though that may be due to its unfamiliarity. [1] https://news.ycombinator.com/item?id=14482988 https://news.ycombinator.com/item?id=14482988
mrkgnao 9y ago
Someone hacked together something very similar with Haskell arrows. http://scrambledeggsontoast.github.io/2014/09/28/needle-announce/ http://scrambledeggsontoast.github.io/2014/09/28/needle-anno...
fdsfsafasfdas 9y ago
Unrelated, but you should really pronounce this "funky-town"; you're never gonna get a name that fun in this field again.
mentos 9y ago
https://docs.unrealengine.com/latest/INT/Engine/Blueprints/ https://docs.unrealengine.com/latest/INT/Engine/Blueprints/
minxomat 9y ago
Since the title was changed to "Show HN:", I want to clarify that this is a language created by Timwi, not me.
- sctb 9y ago
  Thanks! We've just removed "Show HN" to avoid confusion.
- dang 9y ago
  Whoops sorry! That was me misreading your comments. We detached this subthread from https://news.ycombinator.com/item?id=14498855 https://news.ycombinator.com/item?id=14498855 and marked it off-topic.
deavmi 9y ago
Me when defining a function. Comes up with that name.

165 points by minxomat 9y ago

Marvellous, they've reinvented Function Block Diagram programming. https://en.wikipedia.org/wiki/Function_block_diagram https://en.wikipedia.org/wiki/Function_block_diagram

tathougies 9y ago
Um.. no they haven't. Function block diagrams do not support recursion. Unlimited recursion basically means a graphs ability to modify itself at runtime -- i.e., change the wiring.
- fdsfsafasfdas 9y ago
  > Function block diagrams do not support recursion. As someone not familiar with this, why not? Can't you just draw a line from output to input?
  - taneq 9y ago
    Generally not. PLCs are designed to be as reliable and fault tolerant as possible, so they don't allow recursion (along with a bunch of other things, like direct memory access with pointers[1]) since it's so easy to accidentally make something either take a really long time, or fail to terminate. You can fake it by piping an output into a variable which is also used as an input, but this makes it explicit that the last value is used then the next value stored, rather than multiple steps of recursion happening in one scan. Generally the kind of software you develop in structured text doesn't need recursion anyway.
javra 9y ago
Did you actually read the description of the language?

donquichotte 9y ago

I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well. Simple visual programs are arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks. The deal breaker for me (having worked on a large LabView program that controls machinery for a wind energy system) is the lack of reasonable source control systems and the fact that it is very hard to structure a large program in a comprehensive manner.

avaer 9y ago
Actually I'd say the visual languages do a much better job representing what the computer circuit is doing. But that's exactly the problem. Handling that complexity is the reason we invented textual programming languages.
- hatmatrix 9y ago
  I think textual programming languages predates visual languages on account of the hardware available at the time...
- TuringTest 9y ago
  We have better abstractions for textual programming because there has been much more research poured into them, but there's nothing preventing visual languages from being used at higher abstraction levels - they don't necessarily represent the computer circuit level. The typical strongest point of visual languages is that you can represent relations by proximity. This way, you can directly indicate the connection between a caller and its calles with an anonymous connector line, whereas in text you would need to declare a variable name, pass it as a parameter and assign it to a local variable. This makes moving data between components much more verbose in text than in graphs. Textual programs try to approximate this relations-by-proximity with indentation levels, but the expressive possibilities in a visual language are stronger. This makes them also more difficult to lay out and organize, though. But I foresee than in the future, better support in IDEs will make it easier to mix visual and textual languages.

amelius 9y ago

Can a statement be made about the size of these diagrams w.r.t. the size of an implementation in e.g. Haskell? For example, can these diagrams "blow up exponentially" like deterministic finite automata do w.r.t. their source regular expressions?

minxomat 9y ago

Guys, I hope you keep in mind that this is an esolang, it's intention is not to be practical, but interesting. And I think in that it succeeded. I also recommend a look into the repo which contains the parser, which could be interesting. For me it was, because I never really thought about how to parse diagrams.

TuringTest 9y ago
I get that a submission like this is not intended as a suggestion for a practical tool, but as a curiosity and invitation to explore. It's great as a first attempt to delve into the strengths and shortcomings; you can't learn what won't work until you try. The author should explain the motivations after this design, and could get hints from other similar languages to improve the language. IMHO the notation has several shortcomings that would make it very hard to use in practice, and not the best strategy for working with functions. Maybe it's my fault for not seeing the purpose of this approach; but in my experience, free-form graph-based language work best when they emphasize working on collections and data streams, rather than on scalar function parameters. For the kind of example problems expressed in the article, a tree-based notation would work better.
- minxomat 9y ago
  Not really to explore, the intention is nothing but to be esoteric. Suggesting things to make this lang easier to use (i.e. less esoteric) is akin to suggesting adding names to brainfuck commands to make it more readable. Timwi does have some other useful projects though (take a look at his github), all of which are basically centered around parsing. (an IL debugger, a C# parser, generic regular expressions...)
  - TuringTest 9y ago
    You're right, I didn't get that this is was intended as esoteric. Actually the parser for the language, if it works right from the Ascii art and not an intermediate representation, must be awesome. This also explains why the visual syntax is much better suited for a computer than human readers though. :-)

jlebrech 9y ago

ascii makes it ugly, why not use file and directory names? or even store nodes in a special file format?

Aardwolf 9y ago
It's actually unicode instead of ascii. It's full of special characters for boxes, and more for the function library. But I get your point, you probably meant "fixed width text characters" instead of ascii. I'm just being pedantic :)
- jlebrech 9y ago
  just use ncurses, have a gui to "add new class", etc. and a box == class. I often thought that languages shouldn't need any OO keywords if those features are visual, ie. boxes and arrows.

imron 9y ago

dum de dum won't you take me to dum de dum a func-i-ton

dwringer 9y ago
I know this type of comment is often frowned on here, but let's be honest - this is the reason EVERYONE came to the comment section.
- imron 9y ago
  I knew it would bring downvotes but the pun was just too irresistible.

TuringTest 9y ago

Your language advocates a [X] Boxes and arrows [ ] Spreadsheet-like [ ] Control flow block primitives [ ] Grid world simulation approach to visual programming. Your approach won't work because it gets poor scores in the following cognitive dimensions (https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...): [ ] Abstraction gradient [x] Closeness of mapping [ ] Consistency [x] Terseness [x] Error-proneness [x] Hard mental operations [ ] Hidden dependencies [ ] Juxtaposability [x] Premature commitment [ ] Progressive evaluation [x] Role-expressiveness [ ] Secondary notation and escape from formalism [x] Viscosity [ ] Visibility and the following philosophical objections may also apply: [ ] Any schema based on undeclared program state is unacceptable [x] Complex dependencies will get intermingled and make a mess [ ] You can't have more than 50 visual primitives on the screen at the same time [x] Function application is the wrong abstraction for flow graphs [x] Similar proposals have been tried in the past, and failed [x] It requires seeing the whole thing at once [ ] It doesn't allow for in-place comments [x] Evaluating program state is hard Furthermore, this is what I think about your solution: [x] Sorry dude, but I don't think it would work. [ ] This is a stupid idea, and you're a stupid person for suggesting it. [ ] Nice try, assh0le! I'm going to find out where you live and burn your house down!

TuringTest 9y ago
Obligatory self-deprecating criticism: https://it.slashdot.org/comments.pl?sid=4366081&cid=45208069 https://it.slashdot.org/comments.pl?sid=4366081&cid=45208069
GuiA 9y ago
These copy pastas (whether for visual programming languages or approaches to solving spam or whatever else), while witty the first time one sees them, get irrelevant very fast as they only provide generic, blanket criticisms of a design with no consideration for the tradeoffs involved or why they are made. In other words, you could post such a takedown for plenty of visual programming languages that have very satisfied users who are made very productive by their use. Does that mean they “won’t work”? Clearly not. These text templates are very easy to post - all it required of you was to skim the page, add an X to the lines where it felt like there was sort of a match even if you don’t really know, and click “post” - but they provide little to no value.

josetzamora 9y ago

Every time I see the word Funciton, it makes want to swap the letters t and i!

drabiega 9y ago
It just get the song Funkytown stuck in my head.
ferdterguson 9y ago
I read it as function and probably wouldn't have noticed without this comment. Whimsical software names are the bane of my existence.

mannykannot 9y ago

This is almost timely, following the recent 'Why Does Visual Programming Suck' post [1]. Funciton did not get mentioned in the ensuing discussion. My first impression, from the factorial function example, is disappointment - it does not seem to promise any improvement in clarity, though that may be due to its unfamiliarity. [1] https://news.ycombinator.com/item?id=14482988 https://news.ycombinator.com/item?id=14482988

mrkgnao 9y ago

Someone hacked together something very similar with Haskell arrows. http://scrambledeggsontoast.github.io/2014/09/28/needle-announce/ http://scrambledeggsontoast.github.io/2014/09/28/needle-anno...

fdsfsafasfdas 9y ago

Unrelated, but you should really pronounce this "funky-town"; you're never gonna get a name that fun in this field again.

mentos 9y ago

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/ https://docs.unrealengine.com/latest/INT/Engine/Blueprints/

minxomat 9y ago

Since the title was changed to "Show HN:", I want to clarify that this is a language created by Timwi, not me.

sctb 9y ago
Thanks! We've just removed "Show HN" to avoid confusion.
dang 9y ago
Whoops sorry! That was me misreading your comments. We detached this subthread from https://news.ycombinator.com/item?id=14498855 https://news.ycombinator.com/item?id=14498855 and marked it off-topic.

deavmi 9y ago

Me when defining a function. Comes up with that name.