Programming without programming discussion

So wally I didn’t want to step all over Jason’s post by discussing this further, there. Also keep in mind that this is just a discussion. There is not right or wrong, only right or wrong for individuals. Or personal beliefs if you will.

I won’t disagree with what you say, but it ignores a few simple truths.

Programming is hard work and requires absurd amounts of arcane knowledge that can quickly become obsolete.

This is somewhat right in concept, but mostly wrong in practical application. Let me pick a single language to help illustrate. C for instance, the language specification changes only once every so many years. But even then the past concepts mostly stay in place. So you only need to learn a little at a time which can take place as a given programmer “needs to know”. This is easier for experienced programmers. Passed that, all the libraries out there, one does not need to retain that information, as it is really easy to freshen up on most Linux API calls in real time once you’re working on code. Again, this is much easier for experienced programmers, and this technique makes it much easier to use new( to the programmer ) libraries as well.

So this “arcane knowledge” is only really arcane to those who are really not programmers. Truism ?

These graphical or visual programming languages you denigrate really do help scientists, engineers, and other “domain experts” who aren’t, and don’t want to become, “programmers” implement an idea for which there is not, and will never be until the idea is proven sound, a budget for “hiring real programmers”.

I have a friend who is a scientist, who has picked up programming pretty easily. He might use Python, which I particularly do not care for, but he is able to write code that is mostly competent. Just not as easily or quickly as someone who is more experienced. Passed that, I’ve read many white papers written by scientist’s and if they’re serious, they will learn how to program, and indeed many have. One white paper particular where a scientist blew my mind discussing the use of abstract generic templates in C++ . . . a very complex concept.

I wont deny that these types of programs are good for prototyping concepts for a proof of concept. The problem is, passed that you have many who want to use these applications to write production code, and I honestly do not think the technology is there yet. And won’t be there for a long time.


Also, in addition to the above. Your friend for example, and the Nodejs / node red discussion you’ve been having lately. If you friend is an Engineer, then learning the quick basic of javascript would take far less time than you’ve been discussing the problems you’ve been having on this google group.

So as an example of what I mean. A couple weeks ago someone asked on this group what to use with Java to twiddle a GPIO or two. I told him he needed to learn how the GPIO is presented to user space through sysfs, and then just use a good file system object for Java. To illustrate my point on that post, someone came back a few minute later with exact code needed to twiddle a single GPIO . . .

Anyway, yes, it’s not very easy when you’re new, but it’s pretty simple and a concept everyone needs to understand if they want to learn how to use the hardware properly. Plus once you learn how to do various things in Javascript through Nodejs, you do not forget that usually. So that information can be applied to other similar, or perhaps not quite to similar situations.

These graphical or visual programming languages you denigrate really do

help scientists, engineers, and other "domain experts" who aren't, and
don't want to become, "programmers" implement an idea for which there is
not, and will never be until the idea is proven sound, a budget for "hiring
real programmers".

In principle, yes, they are useful and enabling. In practice, however, they
have been underwhelming, and I can think of several reasons:

   - fragmentation: they usually are designed for some domain-specific
   programming (e.g. LabView for data acquisition, GNUradio for signal
   processing, Simulink for control systems, SGI AVS/Explorer for data
   flow/processing, etc). This, however, means that their audience is limited
   to that particular domain.
   - closeness: most of graphical programming systems are commercial and
   closely held by their owners
   - lack of scaling: easy tasks are very easy, but as the program size
   grows, they become unmanageable. It's difficult to determine whether two
   visualized data flow graphs are equivalent: the program representation and
   semantics are mixed up. My favorite dis of graphical programming:

   - Finally, we can have spaghetti code that looks like spaghetti!

Someday, someone will probably come up with visual system that's general,
open source and amenable to maintaining in git---but that day hasn't
arrived yet.

Someday, someone will probably come up with visual system that’s general, open source and amenable to maintaining in git—but that day hasn’t arrived yet.

I think that right now, probably the toold that are closest are the better UML apps out there. Rational Rose, and Microsoft Visio. Where you diagram your program flow, and the app builds your app skeleton for you. Functions, classes, and all it can based on the data you’ve given it. For me personally though, this is not my own style of coding. I prefer to write small bits at a time and test as I go. This way, I do not spend large amounts of time debugging code . . .

toold == tools

we know your Too old so don't deny it. :stuck_out_tongue:

I have had the pleasure of introducing a few scientists to things like Matlab, but they were motivated to be “self-sufficient”, I’ve known a few others who purchased something like Delphi (Pascal) and just jumped right into it with good success. But most have a full plate keeping up with their specialty and really don’t want to be “programmers” – if they had the budgets they’s just hire one to do it. Its when there is a good idea and insufficient budget to develop it that these “visual or graphical” systems can help get things going.

As to production code, depends on what the product is, and the volume produced – I’ve been involved in several labs where they run on Labview with no “real programmers” – the product is publishing a research paper and the volume is one instance to accomplish the research goals.

As to the the friend I’m helping which got me playing with node-red in the first place, the fundamental trade-off is he just wants to accomplish something to make his life easier. He sees the virtues of using a micro-controller like PIC or Arduino, or a small computer like the Beaglebone or Raspberry Pi, but its not his life’s ambition, its just a task to get done. Throwing a computer into the mix has a pretty steep entry fee in terms of the time and effort he needs to put into “learning” to use it vs. simply accomplishing his task by just wiring up relays, timers, bang-bang or PID controller modules etc. the way he’s always done in the past. Once he succeeds with a computerized project, he might very well see dramatically more possibilities and then be motivated to learn Python or Javascript etc., but until then the entry fee is just too steep. Its in lowering the barrier to entry that these visual/graphical programming systems offer promise. The developers see the need, or they would be developing these systems. In fact node-red with its function nodes and rode-red-node-beaglebone (unfortunately broken for the two newest images I’ve tried) lets one ease into learning Javascript in the context of a doing something the stock modules can’t quite get right instead of starting with a blank page.

Unfortunately, at present, node-red and bonescript just plain aren’t ready for a newbie to just buy one and get started. The Raspberry Pi Raspbian Jessie images are much closer, the 2016-05-01 testing image would be about caught up to the Pi except for yet another kernel change that broke the bonescript PWM.

Unless other folks jump in, its pretty pointless for the two of us to banter back and forth about this.