Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flood: Geometric visual programming, driven by a Scheme interpreter

floodlang.com.s3-website-us-west-2.amazonaws.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#21

Post by seanmcdirmid »

pjackson5 wrote: post #14
seanmcdirmid wrote: post #11

Earlier quoted context omitted.

Can you communicate in graphs? Can they be used to express metaphors or abstractions? You've just written a wall of text in your post that someone who doesn't understand English will find messy and incomprehensible. Visual formats are great at some things, especially in expressing concrete concepts that are perceptible. They are just not great at abstraction, which forms the basis for most of our non-trivial programm…

I might be out of my depth and not truly understand what is meant by abstractions, but I think the answer is yes? Lets look at the example on the website, theres a node called cube. Isnt that little node an abstraction of a whole lot of other things? A more advanced visual programming language would allow you to access and modify what a "cube" is. You would be able to double click on that and be taken to another grap…

Abstraction != encapsulation. The point is about the node, not its contents. What does the node mean as a metaphor? What is it's idea?

Language is a very powerful technology that nature evolved for us. We could not have this conversation with graphs or paintings...we need words! Many programming problems are also best solved with words, though you could definitely wire something up the old fashioned way.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#22

Post by seanmcdirmid »

peetle wrote: post #17
pjackson5 wrote: post #14

Earlier quoted context omitted.

I might be out of my depth and not truly understand what is meant by abstractions, but I think the answer is yes? Lets look at the example on the website, theres a node called cube. Isnt that little node an abstraction of a whole lot of other things? A more advanced visual programming language would allow you to access and modify what a "cube" is. You would be able to double click on that and be taken to another grap…

Exactly. The node is just a lambda - no reason it can't be expressed in exactly the same way.

Lambdas are formal, not linguistic constructs.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#23

Post by jonnybgood »

peetle wrote: post #12
TheZenPsycho wrote: post #7

am I missing something? using safari. All I see is a blank white screen, with a few things that might be "buttons", none of which do anything. It doesn't respond to keypresses. No messages appear saying that my browser might not be compatible. what am I expected to do here?

I apologize - the site is only tested on Chrome. At this point it's mostly an experiment, so I haven't put in the time to ensure a consistent experience across browsers.

I'm using Chrome on Debian and I'm getting the same thing.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#24

Post by shotwell »

seanmcdirmid wrote: post #11
pjackson5 wrote: post #8

Earlier quoted context omitted.

Hold on a sec, I stare at graphs like this all day! If you work in visual effects your whole world is nodes and connections - and that is not a complicated graph ;) For someone whos not used to programming a big wall of text is going to look messy and incomprehensible too. Just like there are best practices with code there are best practices with how you organise this kind of graph. you can usually save a subnetwork…

Can you communicate in graphs? Can they be used to express metaphors or abstractions? You've just written a wall of text in your post that someone who doesn't understand English will find messy and incomprehensible. Visual formats are great at some things, especially in expressing concrete concepts that are perceptible. They are just not great at abstraction, which forms the basis for most of our non-trivial programm…

Then so much for graph based programming?

[1] http://www.slideshare.net/slidarko/gremlin-a-graphbased-prog...

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#25

Post by tunesmith »

seanmcdirmid wrote: post #21
pjackson5 wrote: post #14

Earlier quoted context omitted.

I might be out of my depth and not truly understand what is meant by abstractions, but I think the answer is yes? Lets look at the example on the website, theres a node called cube. Isnt that little node an abstraction of a whole lot of other things? A more advanced visual programming language would allow you to access and modify what a "cube" is. You would be able to double click on that and be taken to another grap…

Abstraction != encapsulation. The point is about the node, not its contents. What does the node mean as a metaphor? What is it's idea? Language is a very powerful technology that nature evolved for us. We could not have this conversation with graphs or paintings...we need words! Many programming problems are also best solved with words, though you could definitely wire something up the old fashioned way.

Can't this same criticism be made about (word-based) programming languages? Programming languages communicate the what or the how pretty well, but not the why.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#26

Post by sparkie »

seanmcdirmid wrote: post #22
peetle wrote: post #17

Earlier quoted context omitted.

Exactly. The node is just a lambda - no reason it can't be expressed in exactly the same way.

Lambdas are formal, not linguistic constructs.

I think you're making a distinction that doesn't exist: lambdas are a (written) language - the have symbols, morphemes, phrasing, syntax, semantics, pretty much all the elements to define a language. Just an incredibly small and concise one.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#27

Post by seanmcdirmid »

sparkie wrote: post #26
seanmcdirmid wrote: post #22

Earlier quoted context omitted.

Lambdas are formal, not linguistic constructs.

I think you're making a distinction that doesn't exist: lambdas are a (written) language - the have symbols, morphemes, phrasing, syntax, semantics, pretty much all the elements to define a language. Just an incredibly small and concise one.

Lambdas have definitions, but they have no communicative meaning to human beings. They have to be bound to words to provide us with a humane way of using them.

The lambda calculus is great at describing computation formally, but says nothing at all about programmer ergonomics. What we really care about is the abstraction capability of "node" or "word", the implementation is encapsulated.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#28

Post by seanmcdirmid »

tunesmith wrote: post #25
seanmcdirmid wrote: post #21

Earlier quoted context omitted.

Abstraction != encapsulation. The point is about the node, not its contents. What does the node mean as a metaphor? What is it's idea? Language is a very powerful technology that nature evolved for us. We could not have this conversation with graphs or paintings...we need words! Many programming problems are also best solved with words, though you could definitely wire something up the old fashioned way.

Can't this same criticism be made about (word-based) programming languages? Programming languages communicate the what or the how pretty well, but not the why.

I never said anything about why. Even if you are just instructing, do you care to see a wordless video or read an instruction manual? Actually it's not even that...which one is easier to write? The descriptive power of language is great when issuing imperatives; it must have been very hard to organize before language was developed 50-100 kya.

You can still communicate spatial concepts better with pictures, and maybe a hybrid approach might work, structured edited languages are very popular as vpls, but think about code with interspersed diagrams.

Re: Flood: Geometric visual programming, driven by a Scheme interpreter

#29

Post by nabla9 »

columbo wrote: post #18
trothoun wrote: post #5

Demos like this are cool, but they make me think that we'll never see a non-toy visual programming tool. Even a fairly simple bit of logic quickly becomes an incomprehensible soup of interconnections. edit: Thinking about it a bit more, whats lacking in all the examples of visual programming I've seen is a clean way to build abstractions. It would take a while to learn to efficently read and style visual code just li…

I think to really get visual coding to work it would need to start from circuit design; Vin, Vout, ICs, logic gates etc. That doesn't really get you towards end-users writing code but I'd find it pretty useful when trying to look at a complicated process.

Many circuit design tools have the ability to use either visual circuit diagrams or VHDL. Visual diagrams are useful in many cases, just like UML diagrams, but using only them would be pain in the ass.
Post reply on HN