6 ms·
>> What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,” says
by jliechti1 13y ago
>> What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,” says Kenneth Kan, CTO of a company called Pixbi and a recent convert to flow-based programming.
I disagree with this. This might work fine for small programs, but will quickly fall apart for anything of significant size. National Instrument's LabVIEW [0] offers a graphical programming language called "G". G makes it easier for non-programmers (usually other types of engineers) to create the software they need. However, as their programs grow, they can easily get out of hand and become a dangled mess if they don't understand good program design. I am all for getting more non-programmers programming, but this method does not solve the need to understand programming fundamentals.
In my experience with LabVIEW, it was really great for making things like concurrency easy, and it was really great for quickly building GUIs to control hardware. I like to think that graphical programming makes some "hard" things easy, and some "easy" things hard (it's a bit manually intensive to make complex mathematical equations - though there are blocks you can use that let you drop in C code into the interface).
Like anything else, the methodology has its advantages and disadvantages.
[0]: http://en.wikipedia.org/wiki/LabVIEW http://en.wikipedia.org/wiki/LabVIEW
- bergie 13y agoIf LabVIEW was perfect we might not have to build all this. Execution matters :-) I've written about this in http://bergie.iki.fi/blog/noflo-kickstarter-launch/ http://bergie.iki.fi/blog/noflo-kickstarter-launch/
- albeec13 13y ago"I am all for getting more non-programmers programming..." May I ask why? I completely disagree with that statement and all the initiatives pushing that agenda.
- jliechti1 13y agoSure - let me answer that with my post for the "Everyone does not need to learn to code" thread. When I say getting more non-programmers programming, I mean it from more of a practical standpoint. My previous post: "From a practical standpoint, I really wish everyone was taught enough programming to know how to automate basic manipulation of text data. I see way too many people editing long lists of data by hand, when there are much better ways to go about it (even Excel works great for this kind of stuff). Just knowing this setup below can let you do some really power automation of manual tasks and can save you a lot of time. Example template in Python: import csv with open('mydata.csv', 'r') as csvfile: reader = csv.reader(csvfile, delimiter=',', quotechar='"') for row in reader: # Data manipulation here " Link: https://news.ycombinator.com/item?id=6237430 https://news.ycombinator.com/item?id=6237430 I'd also recommend looking at Jach's post (the child post of my post in the link) - I thought he made some really good points/critiques about 'tool-based' vs 'concept-based' teaching.
- albeec13 13y agoI agree with you to a point. Yes, I think computer literacy is very important, and far too many people think of computers/tablets/phones as magic boxes that show pretty pictures when you click/touch things. Your Excel example, to me, falls into that category. Learning to use a word processor or spreadsheet application is something that is increasingly necessary in today's world, and I am often surprised by how few people (including, shockingly, many software developers) know how to effectively use them. I just don't feel like taking it all the way to "everyone must learn to program" is a good idea, any more than "everyone must learn to perform open-heart surgery" is. Based on your comments, I think we actually agree.
- lutusp 13y agoImagine a world in which most of the important ideas are in printed form, and only a priestly elite can read or write. Wouldn't you want to increase the base of literate citizens? Today, most of the important ideas -- their genesis and dissemination -- are in computer form. I would argue that making everyone a programmer is not the goal, but widespread computer literacy, a familiarity and comfort with computer use, database searches, research skills, is the modern parallel to encouraging print literacy in years past.
- albeec13 13y agoWe already live in that world, and it's been that way for centuries. If all the automobile designers and mechanical engineers were to vanish today, do you think lay people would be able to hop into the driver's seat and take over the job? The same is true for nearly every industry, and always has been. The only reason we've come this far as a civilization is because we record what we learn and pass the knowledge on to future generations of people who are interested in that knowledge. Not everyone has the same interests, and barring an apocalypse, no one needs to know it all at once. Programming is no different. Sure, things like reading, computer literacy, math, biology, basic problem solving, etc. are important base skills for everyone to know. Once those foundations are in place, delving further is a matter of preference, and not everyone should be pushed to learn computer science any more than they should be pushed to learn quantum mechanics.
- meemoo 13y agoThe base level of computer literacy should be deeper than "how to use Word" to some level of algorithmic literacy.
- albeec13 13y agoWhy? Most people can't even use a word processor or spreadsheet right now, let alone comprehend algorithms and programming. Besides, we all drive cars and we all use refrigerators and air conditioners daily. Not everyone knows how those work or is able to fix them. If they did, we'd be a world of "jacks of all trades and experts in none." That's not what got us to this point as a technologically advanced civilization. It's far more important for everyone to know how to drive properly and safely than it is for them to know how to perform maintenance on their cars. In fact, having everyone do their own car maintenance would probably be just as dangerous as putting programming into the hands of people who don't know how to avoid phishing attacks and computer viruses.
- dagw 13y agoBecause it will free up them to focus on what they're good at and free up 'real' programmers to work on harder problems more appropriate to their background. At work I see many people struggling with 'simple' programming problems in all kinds of strange ways (often involving abusing excel) that could so easily be done in a dozen lines of python. Occasionally they end up coming to me to ask for help. Now they have to spend their time teaching me the intricacies of their domain, and then I have to spend my time coding up a solution, which might be wrong because of some subtle detail they felt was too obvious to mention. And now we're both stuck in a situation where every time something changes instead of just fixing it, they have to come to me and first explain exactly what they need to change and then wait for me to have time to fix it. At the end of the day this isn't productive use of anybodies time.
- meemoo 13y agoI agree about making some easy things hard in my experience with Pure Data. NoFlo's UI design makes it frictionless to drop in to edit any component's JS, or build a new component.
- bnejad 13y agoI've been using LabVIEW at my current internship for the past 4 months and I agree with you. LabVIEW has great hardware support which makes it really easy to get up and running collecting data. But like you said, I've looked over some previous LV projects that have multiple copy and pasted sections, terrible design, etc. As a software engineer, LV holds you back in my opinion. I don't doubt for a second that some really amazing things can be created with LV but ultimately it is extremely tiring/annoying to reinvent the wheel to accomplish things that would be extremely simple in almost any other programming language. This seems to come into play when you move past the simple act of collecting data and doing primitive processing. Edit: The other thing I forgot to touch on was the presentation of the "code". With wires running all over the place and ambiguous function blocks you quickly find yourself wishing you could cozy up with a text editor instead. The main reason I don't think data flow programming will "take over" all programming is because ultimately I think its a inferior presentation for professionals.
- rprospero 13y agoAs someone who has fallen into the unfortunate position of being the local LabView expert, there's a little tricky you might want to know. Pretty much all of the awesome hardware support is contained in the daqmx library. The C api for this library can be connected to through nicaiu.dll (or the corresponding dynamic library format for your OS). By linking in here, you get all the wonderful hardware support while being able to write code in your favorite language with your favorite editor and commit it to your favorite source control. I've been slowly translating all of our LabView code out of G and it's both made my life vastly simpler and has also allowed other coders to work on it without learning G.
- bnejad 13y agoGood tip! I was aware there were some options along this line but unfortunately using LV(more specifically, "G") was a project requirement. You briefly touch on another point that is worth repeating. Source control with LV is terrible.
- 13y ago
- Serow225 13y agoIn a similar vein to LabVIEW, I've used MathWorks' Simulink and its Stateflow FSM environment quite a bit over the years and I've found that the most effective way to use it is to have your functions written in standard textual code, with the control flow (reactive/parallel/etc) connecting the function using the graphical wiring environment. That looks similar to what NoFlo is proposing, which is a promising sign for IMHO :)
- Serow225 13y agoOne advantage I've found of this approach is that the graphical overview of the wiring makes spotting architectural 'code smells' easier, which makes it easier to refactor as you go instead of realizing the poor structure farther down the line (ie too late) when the thing is released and you start running into issues caused by the architecture.
- JPKab 13y agoIts nice to see other people who are bothering to understand the benefits of this rather than snarking away. I once fell into the unfortunate position of having to program proprietary building control systems made by a company called Crestron. Its terrible, overpriced shit, but at the core is a neat little Flow Base Programming tool that is based on some proprietary C derived language. What amazed me about it was how quickly we could teach people with little to no programming experience how to reuse existing functions for new projects just be altering the flow between components and editing parameters in functions. It was crazy. Naturally, every now and then custom code had to be written, but then you would just create a new function, and add it to the pile of other functions that could be wired together. I'm very interested in NoFlo, and can't wait for this tool to come out.
- zwieback 13y agoMy experience also. I've been working in various test and manufacturing automation roles at HP and I've seen some complex stuff done in LabVIEW that's very hard to read and practically impossible to hand off to a different engineer. The typical LabVIEW user here is an experienced EE with limited SW engineering skills so I can see how a different "paradigm" might be appealing. As we all know, though, maintenance cost and sometimes performance also counts. Also, I'm not sure why representing a program as data structures flowing between reusable components is described as something different or new. I think the major contribution of FBP, if such a thing really exists, is the GUI used to create these programs. Surely the fundamental building blocks have been programmed in a more traditional way.
- lbenes 13y ago"In my experience with LabVIEW, it was really great for making things like concurrency easy" Absolutely. Ever since my stint with G, I've longed for a general purpose solution for handling flow control in concurrent code. If NoFlow avoids some of G's pitfalls, it could make an excellent addition to my programming toolbox.