Comment by robomartin
13 years ago
For years I've been bothered by the fact that we still use ASCII text-based documents to program. Having spent a good deal of time programing in APL, a language that uses symbols extensively, I'd like to think that I saw just how different things could be.
Having said that, every time I've looked into graphical programming paradigms they almost always seem to fall apart or get in the way of translating ideas and thoughts into machine instructions.
In the end, at least for me, it's about having an environment and a language that gets out of the way and let's me program the way you'd play the piano: The music just flows and the technical bits that make it happen are invisible.
Oh wow. I've never used APL but this demo of it always blows me away http://www.youtube.com/watch?v=a9xAKttWgP4&feature=youtu...
If APL looks good to you, it may be worth checking out its descendent J: http://www.jsoftware.com/
I'd be interested to hear your thoughts on LabVIEW, if you've ever used it: http://www.ni.com/labview/.
It's a graphical programming language with an emphasis on system design (for scientists and engineers) that uses a dataflow paradigm (amongst other things) and has a unique UI creation system.
(Disclaimer: I work for National Instruments and my comments here in no way reflect the views of National Instruments and yadda yadda.)
My experience with LabVIEW, for the brief amount of time I worked with it for our high school robotics team, was slightly frustrating. I liked the dataflow paradigm, and to some degree the dashboard system, but connecting and managing the "wires" was a pain. Especially since I'm more comfortable/faster with a keyboard than I am with a mouse.
It also seemed to be harder to read and understand the flow of the code, which made debugging a pain sometimes. I remember struggling to figure out why my code wasn't working, only to find out I had used 1 instead 1.0 as a constant. The only indicator of the data type was a thin colored border around the box.
LabVIEW seems to do a great job as a kind of Visual Basic for scientists and engineers, but I'd probably find it frustrating to spend any substantial amount of time programming with it.
I understand the frustration. I've run into from a few of my students on the FTC teams that I mentor in my neighborhood. I think that this can be attributed to a lack of really great educational material (there is good stuff out there, but it can be hard to find when the build season really picks up), but on the flip side, I've seen kids in elementary school pick up the basics of dataflow programming, especially when working with the NXT-G software that comes with the Mindstorms NXT.
It's definitely a tool and one should always use the best tool for the job. Sometimes the best tool is not necessarily the one with the most suited features, but the one that you're most adept at using. Either way, thanks for the input, really. It helps a lot to understand what people walk away with when they use a product you've been a part of, and I love that HN users are honest and gracious in their feedback. Cheers.
The whole time I was using LabVIEW (for a class) I kept dreaming of the days when I'd be done with it and back to a typed language.
That's the sentiment that's been conveyed to me when visiting a few university classes that make use of LabVIEW. I think that a great number of programmers that come from textual programming languages (I'm one of them) find the environment jarring as we try to force LabVIEW to fit norms we've built through out experiences in other languages. I think this is a combination of poor educational material catered towards dispelling projected similarities between graphical and textual programming languages and less than great communication beyond the scientific engineering user base of what LabVIEW is really great at.
In any case, thank you for the feedback, it's always great to hear back from fellow programmers that have had experiences with LabVIEW.
Text is still the best way too tell a story and programs are just that: stories. I would say that any language requiring a fancy IDE is doomed.
Comics and movies are pretty good ways to tell stories too. Some stories are better suited to text. Some are not. I'm in the middle of making a comic that makes deep use of color and the relative position of panels on the page to tell its story, for instance.
What kind of programs are we missing out on by limiting ourselves to text? What kind of programmers?
Upvoted but I don't know the answers to your questions. Maybe getting more programmers is a good thing. For me, right now the issue is to get better ones, and I doubt having box drawing languages should bring better programmers on the boat.
I'm not sure if you can say that text is the best way. It's certainly one way to tell a story, and even a fundamental way to tell a story, but there have been many interesting advancements in storytelling in the last few millennia. I also enjoy pictures and, especially, talking pictures.