21–30 of 33 posts
Earlier quoted context omitted.
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.
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 averag…
The adequacy of the Haskell ecosystem really varies depending on the kind of application that you want to develop. If you're writing a compiler or a web service, Haskell is a pretty good choice.
This [1] is a nice overview of the state of the Haskell ecosystem.
Let me also plug two more links [2] [3] that explain why Haskell is actually a very good choice for (large) commercial projects.
[1] https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
[2] https://www.fpcomplete.com/blog/2016/12/software-project-mai...
[3] https://www.reddit.com/r/haskell/comments/54umkh/haskell_for...
Anyway, it's the wrong problem. I don't need help understanding x * 3 + y. I need help understanding what these 30kLOC in these 17 files do.
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…
Each kind of node is basically a class, and is distinguished by its color and interfaces - input nodes are blue with a button that triggers an action and one output, debug nodes are green with one input and a switch to toggle if output is being logged, function nodes are tan and have one input and three outputs (iirc, "normal" output - more on this later - stderr and return value).
Nodes are linked up output to input - no limit on the number of links a given interface can have - and transfer information as json objects. Often nodes expect a top level key named "payload" by default, though most node behavior can be customised.
So a hello world program would be something like: blue kickoff node with a button --> tan function node inside which you define a js function that takes an object named msg as an argument and sets msg.payload to "hello world!" --> green debug node set to log msg.payload and switched on. You click the button and "hello world!" appears in the log (and reappears as many times as you click).
The nice thing is that there are a lot of kinds of nodes that abstract away common tasks - very much like what ansible does with modules. One read/writes files, one executes shell commands, one listens/broadcasts to mqtt channels, one queries sql databases, etc. When the correct node is used for a task vs wrapping all the desired logic in a single function node (which you could do), the resulting graph or flow is very easy to understand or reason about.
Earlier quoted context omitted.
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 th…
Earlier quoted context omitted.
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…
What you are describing sounds a lot like what Node-RED does. https://nodered.org/ Each kind of node is basically a class, and is distinguished by its color and interfaces - input nodes are blue with a button that triggers an action and one output, debug nodes are green with one input and a switch to toggle if output is being logged, function nodes are tan and have one input and three outputs (iirc, "normal" output -…
What I had in mind was staying in the procedural/oop paradigm of e.g. Java, but without the requirement of a fixed syntax, way more flexible rendering options, and the possibily of more diverse input schemes than typing one character at a time.
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 averag…
So yes "why push deeper"? It's just what some developers feel they need to do in order not to just throw out their laptops and turn to full-time gardening, full-time redditting/4chaning/twittering, or cooking shows. Not that there's anything wrong with any of these..
I am very interested in program visualization, but I think trying to visualize things at this level is just nutballs. Anyway, it's the wrong problem. I don't need help understanding x * 3 + y. I need help understanding what these 30kLOC in these 17 files do.
As always.. not the silver bullet, just the perfect tool for a context and use-case only you can decide/suspect/discover =)
Edit: actually looked at the screens. Hmmm seems like a language/programming learner-aid tool mostly. Fair game for dem young'uns I guess!
I am very interested in program visualization, but I think trying to visualize things at this level is just nutballs. Anyway, it's the wrong problem. I don't need help understanding x * 3 + y. I need help understanding what these 30kLOC in these 17 files do.
If for some reason you actually need to understand 30kloc in 17 files in any meaningfully substantial fashion, I posit this will always require some time investment on your part. (Such as outcommenting most of `main` / a module, then progressively interactively proceeding to dive into the codebase via repl/compile trial+error etc.) I gather that such diagrams and visual aids etc help much more once one's basic unders…
I've tried implementing something very similar for Clojure, but I thought I was insane so I stopped :)
Notice how close to the lisp syntax these visualisations are, eg: (* 3 5) or (* (+ 8 7) 2)
Visual representation of code opens up a lot of possibilities, like being able to click on a block and visually debug it or write all kinds of unit tests on it's 'back'.
You can also 'visually' show how data passes from function to function or edit the constants in their slots and see how the changes propagate throughout the code..
Anyway, I'll check it out in more detail later, great work !