Hacker News Reader

I've been using LabVIEW 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.

As 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.

Good 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.

Source control is fine in NoFlo's JSON graph format or DSL.

So, are you saying when I diff I am looking at textual representations of the graphs?

Which is fine, that is what I'd expect. It's how I'd implement it. But isn't that a huge clue about the fundamental weakness of graphical representation - as soon as you try to do anything nontrivial it's back to text. And back to text for a very good reason, not because the right git plugin hasn't been written yet.

One could write a real 2D graph diffing system, it is not inconceivable, at least. However, you won't get this for free by diffing a textual representation of the graph.

One simple hack is to take each version, set transparency to 50%, and then overlay them.

In 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 :)

Its 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.

One 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.

My 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.

"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.

Imagine 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.

We 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.

To be fair, an awful lot more people know how to read and write now than even 50 years ago, and I think the internet is bringing that number even higher.

I'm astounded at how much better the spelling and grammar of the commentariat has gotten since the early days of ubiquitous internet. Most people seem to be reading something every day (even if it's about Beyonce) and that means that their ability to read about what they want to know more about has gotten better. The effect of this newly capable public on entrenched power structures can't help but to ultimately be positive.

I understand how the same case for computing could be made.

>Not everyone has the same interests, and barring an apocalypse, no one needs to know it all at once. Programming is no different.

knowing everything at once != knowing how to program

We're not that smart, people. The same case could be made for not teaching people how to cook, or drive a car. What makes something a "base skill"?

> We already live in that world, and it's been that way for centuries.

I assume you mean a world where some people know more than others. Fair enough, but in a democracy, that chasm cannot grow too large before a citizen's right to choose becomes meaningless.

> ... not everyone should be pushed to learn computer science any more than they should be pushed to learn quantum mechanics.

Not the topic. We've accepted that the ability to read and write are basic to a functioning modern life. It's now true that the ability to compute has the same status. That doesn't mean everyone needs to know how to write a computer program, but print literacy never meant that a person should be able to write a novel.

>I assume you mean a world where some people know more than others.

No, not exactly. I'm referring to the tendency for most people to be experts in one or two fields and mostly ignorant in others that are not related to their core competency.

>We've accepted that the ability to read and write are basic to a functioning modern life. It's now true that the ability to compute has the same status. That doesn't mean everyone needs to know how to write a computer program, but print literacy never meant that a person should be able to write a novel.

That's exactly my point. People should know how to use computers effectively, but that doesn't translate to "should know how to program" just like knowing how to read and write does not translate to "being a novelist", nor does learning math translate to "being a calculus professor."

> That's exactly my point. People should know how to use computers effectively, but that doesn't translate to "should know how to program" just like knowing how to read and write does not translate to "being a novelist"

No, people should know how to use computers which does translate to "know how to program" but not "be a professional software developer", just like knowing how to effectively function in a world with written language does translate into "knowing how to read and write" but not "be a novelist".

The vast majority of the computer-using population, on a daily basis, has zero need for programming in order to use a computer. The same cannot be said for reading and writing.

They do, however, need to know how to use a computer. This is an argument for computer literacy, not computer programming literacy.

If you can't make the computer do work for you, you're not really using it effectively. If you can only use programs others have written, you aren't really computer literate, you're just a monkey pushing a button. Computer programming literacy is the new reading. The vast majority of people who use computers now do need programming, they just don't realize it because they don't know they could be automating what they currently do manually.

Oh, and everyone who uses a computer should learn some basic shell scripting, it will make them vastly more productive regardless of their field of expertise.

The base level of computer literacy should be deeper than "how to use Word" to some level of algorithmic literacy.

Why? 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.

> Most people can't even use a word processor or spreadsheet right now, let alone comprehend algorithms and programming.

If you can comprehend written procedures for a task, you can comprehend programming (you might not be able to understand algorithmic analysis, but that's a different issue.)

People (especially people that are otherwise knowledge workers) that "can't" do that largely can't because they've been taught that computers are deep magic accessible only to an elite priesthood.

I don't think we are at the point where truly universal programming literacy is necessary or practical in the very short term, but just as with writing before it became something universally expected, I think we are at least at the point where we should start to see it as part of the basic repertoire of knowledge workers, even those whose primary job isn't producing computer code.

You might notice that the historical solution to this problem was "teach people to read and write (program)" not "express all ideas in pictographs so that the illiterate masses can understand them".

We improved classical literacy by turning people into readers and writers. We improve computer literacy by teaching people to become programmers, not by trying to dumb down programming to something that the plebes can understand. I'm all for turning more non-programmers into programmers. The issue isn't that as much as it is the issue of this fantasy that if it wasn't for those dastardly geeks who want to be lazy and charge a ton of money for it, everybody could program with no real work, which is just pure bull puck.

The appropriate analogue here is not literacy, it's carpentry. That everyone makes use of furniture does not imply that everyone would benefit from taking the time to learn to build furniture themselves. It would be a good thing if furniture were made more durable and less expensive(although perhaps not such a good thing for furniture makers) but the solution to that is improving tools and methods used by professional carpenters.

But just as you wouldn't want to read a novel written by someone who is merely literate in English, you wouldn't want your bank to use software written by someone who didn't have professional-level skills in programming.

> ... you wouldn't want your bank to use software written by someone who didn't have professional-level skills in programming.

That's the first step toward creating a programming priesthood, a very bad idea. Software is as software does. Good software can be identified without requiring its creator to have some credential attesting to his ability to craft "professional-level" code, no more than a writer needs a certificate attesting to his ability to write a readable novel.

For proof of this thesis, one need only look at Microsoft -- until recently the top of the programming profession, highest salaries, copious certificates and assertions of competence, and the worst software.

http://www.vexite.com/2005/ending-microsofts-cowboy-spaghett...

Sure - 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

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.

I 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.

Because 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.

I 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.

"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.

If 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/