If HN believes creative thinking is a waste of time I’ll get downvoted for this but I fancy just letting my imagination go wild so here goes...
Video gamers can supposedly differentiate between tones more similar to one another than non-gamers. Perhaps, if you made a theme of very similar colors, you could achieve the same benefit from programming. Although I suspect it might not work because the difference in the colors has to have significance for your brain to really start paying attention to it. So you could have a color-sensitive language. Or maybe color could be the only significant thing, then you could just bind each character to a color in your text editor and use a normal language.
While walking in the wood today and looking at the detail on the ground and searching for ripe fruit in the trees I was thinking about how our brains are really good at picking out specific visual things from noise and how more complex visual things are sometimes easier to recognize than simpler things. Also its possible to get really good at picking out subtle clues from very complex input: think about a native American Indian’s ability to track moving animals over long distances.
So I think what would be really cool is to have a way of representing each function of a program as a visual form, ideally a 3-dimensional one. You could then look at these form and over time you would start to be able to see certain things about the function just by looking at the forms. I wonder if that might be a much faster way of searching for specific things within a large body of code such as you might do in a security audit than actually reading through all the code because it taps into the innate concurrency of the right-hemisphere.
There would be some difficulty would be in generating appropriate visual forms. The form has to be meaningful. The ideal would be if it were meaningful to the point where somebody well used to them could write the code a form represented just by looking at the form or, at least, infer the gist of it. Of course you don’t have to limit yourself to one form per function, you could have 10 different forms per function, each representing different properties, or forms generated from by dividing the code in lots of different ways (not just functions). Or maybe you could simplify everything I’m saying here and just have a lot more statistical static analysis of code then displayed with charts and infographics.
I tried explaining a similar concept to a designer recently - When I use Sublime Text 2 I use the minimap to visually identify sections of code based on their rough shape, and get to learn bits of code or sections of a file purely on its indentation / minimap pattern.
Thats exactly what I do with sublime as well, except i do it for log files. similar exceptions/errors in log files tends to have similar shapes thoughout, and you can scan a log file to find probable problems due to the patterns of errors without having to read each individually
"Wires" that carry values are color-coded according to their contents (integers are blue, floating point values are orange, booleans are green, etc.). Loops like FOR and WHILE are actual "loops" that encircle the repeated code. The flow of information along the wires determines the order of execution for the code, and you can debug your code by turning on a special mode that actually shows the information moving down the wires.
LabView IS fun, I've written a couple of drivers and a (physical device) testing GUI with it. As I've been thinking about it more I see two hurdles to overcome with LabView though:
- Layout: Spaghetti code becomes a very tangible issue if you don't follow guides on routing religiously. Intro courses only touch on this and LabView code in the wild are rarely clean. These visual routing guides are ORTHOGONAL to good code design practices which you also have to follow to make maintainable and understandable code.
- Navigation: There is no VIM or Emacs for LabView code as far as I know. Navigating a codebase and following function references deeper and deeper down the rabbit hole becomes tedious pretty quickly. Visual breakpoints help here but there's no substitute for quick navigation, I never found a Ctags equivalent for this language.
True enough, LabView visual 'code' doesn't scale cleanly. One of the reasons for this 'spaghetti' is that the language combines control-flow and data-flow constructs in the same schema level. However, LabView remains the most successful graphical language to date, leaving MUCH room for future language innovations for those who dare to journey out of the scripting realm for software expression to deal with the scaling and many other engineering issues for a new paradigm.
I'm not a LabView fan for various reasons, but something neat they've added as of V8.0 (I think) is an auto-format tool which will take a mess of wires and organize it. Vastly improves readability, and works really well.
You're right, the auto-wire-organizer tool is fantastic. Every time I use it I wonder what algorithm LabVIEW is using to rearrange things - not an easy problem computationally I'm sure. I use it for small sub-VIs but I find that if I use it on a large project I can't find anything after using it - I was relying on spatial layout of the VI which was lost after auto-formatting.
I guess this is analogous to algorithmically reformatting code in a normal text-based programming language...
6.1 was running on an even more ancient PC from 2001. This was at a former employer so I have no influence over this system any more. The funny thing was that we had ample budget for this project, I think we spent about $10k on a very nice rack-mount SCXI DAQ and about $60k on other equipment but upgrading the computer system driving the whole thing was out of the question due to color-of-money issues and dysfunctional inter-departmental politics.
I like your assessment of LabVIEW. I find that if your code is turning to spaghetti, you're not using enough sub-VIs. Try to find blocks of code that accomplish one thing and put that code in its own VI. As a bonus you get to design a little icon for your new sub-VI. :)
Your "rabbit hole" analogy is spot-on and I'm not sure how NI can address some of those problems. Some things like Ctags that are so valuable in text-based languages just seem to have no obvious analogy in a graphical programming language... it's fun to imagine though.
I'm sure part of the issue was that I was trying to teach myself Labview under a deadline as a fresh college grad with zero oversight from anyone with experience with it.
A professor of mine and I were discussing this as we were poring over some freshman 1st semester programming projects done by primarily artistic students in Max/MSP, which is extremely similar.
Looking at a program from the scope of functions, it looks pretty unremarkable, but when you scope out to view the scale of functions you can start to make out the flow of control, etc. Even farther out, you can visually see separations of concerns that the student has implicitly created by the arrangement of the code. It was really remarkable viewing the architecture from 10,000 feet like that.
I'm not sure how to do all of that, but the bit about reducing the dynamic range resonates. I think syntax highlighting should exist to highlight three categories of syntax:
a) comments. What is never run?
b) literals. What is just plain data?
c) punctuation -- mostly so it can be deemphasized.
You might try naming your functions in Chinese. There's evidence showing that people take advantage of the face recognition machinery of their brains to read Chinese[1].
Coincidentally, native speakers of tonal languages (Chinese being one of them) also seem to have a higher chance of being pitch-perfect [2].
[2] Deutsch, D., Henthorn, T., Marvin, E., & Xu H-S (2006). "Absolute pitch among American and Chinese conservatory students: Prevalence differences, and evidence for a speech-related critical period". Journal of the Acoustical Society of America 119 (2): 719–722.
Video gamers can supposedly differentiate between tones more similar to one another than non-gamers. Perhaps, if you made a theme of very similar colors, you could achieve the same benefit from programming. Although I suspect it might not work because the difference in the colors has to have significance for your brain to really start paying attention to it. So you could have a color-sensitive language. Or maybe color could be the only significant thing, then you could just bind each character to a color in your text editor and use a normal language.
While walking in the wood today and looking at the detail on the ground and searching for ripe fruit in the trees I was thinking about how our brains are really good at picking out specific visual things from noise and how more complex visual things are sometimes easier to recognize than simpler things. Also its possible to get really good at picking out subtle clues from very complex input: think about a native American Indian’s ability to track moving animals over long distances.
So I think what would be really cool is to have a way of representing each function of a program as a visual form, ideally a 3-dimensional one. You could then look at these form and over time you would start to be able to see certain things about the function just by looking at the forms. I wonder if that might be a much faster way of searching for specific things within a large body of code such as you might do in a security audit than actually reading through all the code because it taps into the innate concurrency of the right-hemisphere.
There would be some difficulty would be in generating appropriate visual forms. The form has to be meaningful. The ideal would be if it were meaningful to the point where somebody well used to them could write the code a form represented just by looking at the form or, at least, infer the gist of it. Of course you don’t have to limit yourself to one form per function, you could have 10 different forms per function, each representing different properties, or forms generated from by dividing the code in lots of different ways (not just functions). Or maybe you could simplify everything I’m saying here and just have a lot more statistical static analysis of code then displayed with charts and infographics.