The problem I think with visual programming tools is people get stuck. I watched my dad's career die stuck in Visual Basic. It's because people get stuck in thinking the way those tools force you to think. Code in text has a magnificent universality.
Folk wisdom on visual programming
41–50 of 168 posts
Re: Folk wisdom on visual programming
#42I think what the author did here hits hard on why hacker news is such a great resource. To quote: > Most fields have a problem with ‘ghost knowledge’, hard-won practical understanding that is mostly passed on verbally between practitioners and not written down anywhere public. At least in programming some chunk of it makes it into forum posts. I'd be incredibly interested in seeing a series of posts like this, where…
As for what HN could be mined for, a big topic is software languages. There are ways to subdivide that: by language, by optimization aspect (e.g., comparative performance). Geographic topics like cost of living and quality of life. Remote work pros and cons.
Another way of identifying topics worth mining would be identify posts where @dang provides a link to previous posts and those previous posts have a sufficient number of comments.
Re: Folk wisdom on visual programming
#43Btw, you can run still run arbitrary Java (1.7) in UCCX scripts too, which is kinda cool. Used that to make email alerts in case of certain situations in the call queue
Re: Folk wisdom on visual programming
#44> IDEs for text-based languages normally have features like code folding and call hierarchies for moving between levels, but these conventions are less developed in node-based tools. This may be just because these tools are more niche and have had less development time, or it may genuinely be a more difficult problem for a 2D layout — I don’t know enough about the details to tell.
NI demoed a system to function zoom in/out feature at one point but never fully developed it.
LabVIEW does have a call hierarchy. Like with Doxygen, my problem with these is they show everything rather than finding ways to highlight important relationships (e.g. you don't want to show every array append).
> Input
I suffered from RSI when using LabVIEW. Maybe I hadn't mastered enough but there is a lot more than just dropping that needs to be improved, but the wiring.
> Formatting
I think LabVIEW suffers from giving people so much pixel-perfect control, it encourages people to waste time on it because its "so close".
At one point, they demoed dynamic formatting (reflows the diagram as you add/move nodes without any manual management). This really needs to be made the default.
> Version control and code review
LabVIEW NXG has a text-based GVI format. It is not easily reviewable, mergeable, etc because it has all of the graphical minutia in it.
My proposal would be
- Remove block diagram formatting (see above)
- Separate top-level hand-designed UI from VI auto-placed front panel
- Reduce reliance on icons
- Encourage naming wires
At that point, a text-based VI format would be simple enough to be manageable within existing tools.
Re: Folk wisdom on visual programming
#45Wow! This is so awesome! Would you please write a page like this for every Hacker News post?
Re: Folk wisdom on visual programming
#46Earlier quoted context omitted.
That falls on is face at scale. There is a reason not every bullet in a gun is a tracer bullet.
Flow paradigm doesn’t claim scale though. It’s about being a DSL for specific environments, often visually-oriented software like CAD or interactive art, which doesn’t have heavy 10K person team requirements.
If you are programming a singular thing, this probably has good legs. As soon as you are programming many things, though?
This is why cad systems can be seen as visual programming of parts, but are never considered for this debate.
Re: Folk wisdom on visual programming
#47Re: Folk wisdom on visual programming
#48I think what the author did here hits hard on why hacker news is such a great resource. To quote: > Most fields have a problem with ‘ghost knowledge’, hard-won practical understanding that is mostly passed on verbally between practitioners and not written down anywhere public. At least in programming some chunk of it makes it into forum posts. I'd be incredibly interested in seeing a series of posts like this, where…
Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom.
On the other hand, a point that's still a mystery to me is "programming language choice". I've learned useful heuristics like you can do web backend in pretty much anything, if you have no libraries for something that needs them like an AWS SDK you're going to suffer, what helps in the long run slows you down at first, but that's about it. I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find.
Re: Folk wisdom on visual programming
#49Earlier quoted context omitted.
> But you can only go so far with Scratch vs other programming languages. A friend has built some pretty amazing stuff in Scratch, including a BBC Micro emulator (runs 60+ games), a few arcade game ports, and lots more [1]. As a developer myself, I find it quite surprising how far one can go with Scratch. (FWIW I've never coded with it myself) [1] https://scratch.mit.edu/users/RokCoder/
Were there advantages? Or was it an exercise in determination?
IMO, for these kinds of projects, I suspect Scratch doesn't offer many advantages (if any at all). He likes a challenge :)
— More details, including an interview, can be found here:
https://www.coderkids.com/blog/who-is-rokcoder
He's pretty responsive to comments on his Scratch homepage — and can also be found under the same name on Twitter/FB/etc. He's always been happy to help others. Give him a shout if you have any specific questions.
(FWIW: I worked with him — Cliff — for a short while, back in the 90s)
Re: Folk wisdom on visual programming
#50One thing missing here and in most of the visual programming discussions since it sits in a somewhat adjacent SCADA industry is Ladder Logic[1]. It was pretty illuminating how many parallels ladder has with the visual and scripting solutions I'd worked with in GameDev. Hot-reload under running processes, visual debugging very reminiscent of node based visual editors. I ended up automating our greenhouse with a P100[2…
Special functions are implemented in boxes, like delays, counters, etc.
My task back then was to feed the entire I/O state into a ring buffer, and when a "crash" of the steel mill happened, a host PC could then download the entire buffer, giving access to information about what happened in the seconds BEFORE the crash.
It would be fairly easy to port to the Arduino, if someone hasn't done it already. Yep - it's been done https://cq.cx/ladder.pl
Because Ladders are text based, you could use Teco/EDT/Vi/Emacs/WordStar macros on them.