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

Glance, a visualizer for Haskell code

github.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Glance, a visualizer for Haskell code

#11

Post by nacc »

westoncb wrote: post #9
nacc wrote: post #4

If anyone like me thinks all these visualizations just make the code more confusing, I want to point out it might be a personal (although it can be very strong) preference. I always firmly believe programs are universally clearer represented as line of texts with indentations, and any attempt to visualize it doesn't help except for simple toy programs. Then I met some architects who design buildings with code using G…

I think the question of whether 'visual' code is good/useful should be broken down a little more: which specific aspects of a programming language could usefully draw from a larger visual vocabulary? It's clear that text is useful for some aspects: it allows you to easily define and incorporate a very large number of distinct symbols for naming things—and in code we need to name lots of things. What about sequences o…

I think you nailed an important point here: text is great in representing code because text is sequential, and so does a lot of the code we write, and the computer it runs on. Maybe if the code have different structure, some 'visual' code would serve better. Idk, maybe coding for an FPGA/GPU would benefit from a visual representation?

Re: Glance, a visualizer for Haskell code

#12

Post by _Robbie »

tunesmith wrote: post #10
_Robbie wrote: post #2

Creator of Glance here, happy to answer any questions.

I didn't realize graphviz could do graphs of that quality. I'm used to graphviz's examples of DAGs and badly formatted text. Can you tell us more of how you're using graphviz? Wouldn't you need to move away from it as you move towards an interactive editor, in favor of other more javascript-based layout algorithms? What path do you think you'd follow for that?

Graphviz is only used to find the positions for the nodes using Graphviz's Neato algorithm. The nodes and the lines themselves are all rendered using the Haskell library Diagrams [0].

The next step for the project is to improve graph layout (see Glance issue here [1]), which likely means moving away from Graphviz.

What tools to use for interactivity or an editor is still up in the air.

[0] http://projects.haskell.org/diagrams/

[1] https://github.com/rgleichman/glance/issues/1

Re: Glance, a visualizer for Haskell code

#13

Post by davesque »

The question of how concepts and algorithms are represented is interesting. While this is a neat project, a lot of people including myself might say that a "visual" representation of code is actually more confusing. Perhaps it's because textual representations are 1-dimensional i.e. the representation of code as text can only grow in one direction. This makes it inherently simple in some sense.

Re: Glance, a visualizer for Haskell code

#14

Post by n00b101 »

_Robbie wrote: post #12
tunesmith wrote: post #10

Earlier quoted context omitted.

I didn't realize graphviz could do graphs of that quality. I'm used to graphviz's examples of DAGs and badly formatted text. Can you tell us more of how you're using graphviz? Wouldn't you need to move away from it as you move towards an interactive editor, in favor of other more javascript-based layout algorithms? What path do you think you'd follow for that?

Graphviz is only used to find the positions for the nodes using Graphviz's Neato algorithm. The nodes and the lines themselves are all rendered using the Haskell library Diagrams [0]. The next step for the project is to improve graph layout (see Glance issue here [1]), which likely means moving away from Graphviz. What tools to use for interactivity or an editor is still up in the air. [0] http://projects.haskell.org…

Why are the nodes rotated like that? It seems very distracting, and I think that might also be partly causing your "layout is too spread out" issue? [1] It could also be exacerbating your second issue of crossing edges - you are getting crossing edges in even the simplest graphs (e.g. your "f1" function example, with 5 nodes).

GraphViz's "dot" algorithm (i.e., Sugiyama-style graph drawing algorithm) [2] should give a fairly compact representation that is organized into layers, and avoids crossing edges in at least simple cases, but rotating the nodes would again "spread out" the layout by forcing increasing height of each layer.

Under "Possible solutions" you mention "create a better graph layout algorithm" - that sounds quite ambitious, wouldn't this be a PhD-thesis-level research task in itself?

The only graph drawing library I'm aware of that might be competitive with GraphViz's algorithms is MSAGL [3] but that's a .NET library.

[1] https://github.com/rgleichman/glance/issues/1

[2] https://en.wikipedia.org/wiki/Layered_graph_drawing

[3] https://www.microsoft.com/en-us/research/project/microsoft-a...

Re: Glance, a visualizer for Haskell code

#15

Post by chewxy »

davesque wrote: post #13

The question of how concepts and algorithms are represented is interesting. While this is a neat project, a lot of people including myself might say that a "visual" representation of code is actually more confusing. Perhaps it's because textual representations are 1-dimensional i.e. the representation of code as text can only grow in one direction. This makes it inherently simple in some sense.

I have found in my time teaching people about deep learning that proper visualizations of algorithms can help people grok things better[0]. Granted backprop and neural networks are really simple one dimensional algorithms.

[0]: http://blog.chewxy.com/2016/12/06/a-direct-way-of-understand...

Re: Glance, a visualizer for Haskell code

#16

Post by blunte »

I admire the Haskell folks, much in the way I admire theoretical mathematicians... which is to say, I'm sure the work they are doing/did has some value, somewhere (in the past).

But the Haskell proponents that I have known have admitted that the reason they don't use Haskell more is because the libraries and ecosystem aren't adequate. That's not to mention that maybe Haskell is just too much for even the above average dev to grok.

So why push deeper? Is this just academia stroking itself? Why not invest this energy in something slightly more commercial?

Re: Glance, a visualizer for Haskell code

#17

Post by nikofeyn »

marcosdumay wrote: post #5
nacc wrote: post #4

If anyone like me thinks all these visualizations just make the code more confusing, I want to point out it might be a personal (although it can be very strong) preference. I always firmly believe programs are universally clearer represented as line of texts with indentations, and any attempt to visualize it doesn't help except for simple toy programs. Then I met some architects who design buildings with code using G…

LabViz is another well used graphic programming enviroment. It's also the base of the LEGO uses on their toys. I'll have to disagree. It's not a matter of personal preference. Those tools scale only into a few hundred blocks, and even for naturally visual things (like logic circuits designing) people can only grasp more complex constructions when they are text. Even if you make the same abstracction blocks available…

How can you accurately comment on something that you don't even know the name of? You are almost certainly referring to LabVIEW, which is a graphical programming language commonly used in instrumentation applications and also serves as the foundation of the LEGO MINDSTORMS software.

I have built many large applications in LabVIEW (>1,000 VIs), and I can easily state there is no inherent fault in being to build large systems with a graphical language vs a text-based one. Why? Because I have actually done it, resulting in extensible and maintainable code. The dataflow nature of the language makes it easy to understand how data flows through your system. It even has by-value OOP and an actor framework.

Physicists complaining about it have no merit because they have zero idea about software development, architectures, design patterns, etc. They love Python for whatever reason and don't complain about it, yet it's still terrible code. I have seen LabVIEW sworn off by top of the line physicists only to be shown their Python program that was a single file with about 15,000 lines of code and such atrocities as functions with greater than 20 arguments spread over 10 lines. It was an atrocity.

I have written multithreaded applications in Python, and the equivalent LabVIEW application would be far simpler because you get multithreaded behavior for free.

Many software engineers swear graphical languages are only for toy applications, but yet they've never actually built anything of note themselves in one. So it's a poor argument to listen to (as in the person you replied to) when it's purely speculation based on no real data. They somehow forget that they spent four years in college getting it drilled into their head that linear, text-based files are the only way to program a computer. It's interesting to note than any high level thought (e.g. mathematics) bears more resemblance to graphical notation than pure text-based notation.

Re: Glance, a visualizer for Haskell code

#18

Post by _Robbie »

n00b101 wrote: post #14
_Robbie wrote: post #12

Earlier quoted context omitted.

Graphviz is only used to find the positions for the nodes using Graphviz's Neato algorithm. The nodes and the lines themselves are all rendered using the Haskell library Diagrams [0]. The next step for the project is to improve graph layout (see Glance issue here [1]), which likely means moving away from Graphviz. What tools to use for interactivity or an editor is still up in the air. [0] http://projects.haskell.org…

Why are the nodes rotated like that? It seems very distracting, and I think that might also be partly causing your "layout is too spread out" issue? [1] It could also be exacerbating your second issue of crossing edges - you are getting crossing edges in even the simplest graphs (e.g. your "f1" function example, with 5 nodes). GraphViz's "dot" algorithm (i.e., Sugiyama-style graph drawing algorithm) [2] should give a…

Rotating nodes is an easy way to reduce line crossings. Here's a comparison [0].

However, it does seem that vertical and angled text is harder to read than horizontal text, so there is room to improve here.

[0] https://gist.github.com/rgleichman/f812150151b549ca9f634832c...

Re: Glance, a visualizer for Haskell code

#19

Post by _Robbie »

chewxy wrote: post #15
davesque wrote: post #13

The question of how concepts and algorithms are represented is interesting. While this is a neat project, a lot of people including myself might say that a "visual" representation of code is actually more confusing. Perhaps it's because textual representations are 1-dimensional i.e. the representation of code as text can only grow in one direction. This makes it inherently simple in some sense.

I have found in my time teaching people about deep learning that proper visualizations of algorithms can help people grok things better[0]. Granted backprop and neural networks are really simple one dimensional algorithms. [0]: http://blog.chewxy.com/2016/12/06/a-direct-way-of-understand...

The link is a blank page for me.

Re: Glance, a visualizer for Haskell code

#20

Post by westoncb »

nikofeyn wrote: post #17
marcosdumay wrote: post #5

Earlier quoted context omitted.

LabViz is another well used graphic programming enviroment. It's also the base of the LEGO uses on their toys. I'll have to disagree. It's not a matter of personal preference. Those tools scale only into a few hundred blocks, and even for naturally visual things (like logic circuits designing) people can only grasp more complex constructions when they are text. Even if you make the same abstracction blocks available…

How can you accurately comment on something that you don't even know the name of? You are almost certainly referring to LabVIEW, which is a graphical programming language commonly used in instrumentation applications and also serves as the foundation of the LEGO MINDSTORMS software. I have built many large applications in LabVIEW (>1,000 VIs), and I can easily state there is no inherent fault in being to build large…

> It's interesting to note than any high level thought (e.g. mathematics) bears more resemblance to graphical notation than pure text-based notation.

Exactly! The more general the structures you're thinking about, the more visual approaches seem to become effective. That's my experience and Hadamard has some good discussion and data on it being a widespread trend in mathematical thinking.

Maybe a good approach for thinking about (at least partially) visual languages is considering which approaches are effective in thought for which types of subject matter. It definitely seems like the more general/abstract/high-level thought-categories make better use of relationship-focused visuals.

Also: that's why 'LabViz' yielded no seemingly relevant results on image search...

Post reply on HN