Are higher-level proprietary programming languages bad for developing programming skills?

I wouldn't say KRL is like Java -- it's far more like 1980s PASCAL, if anything.

The whole robot-programming space is a strange place ATM. Most robot languages (Fanuc KAREL/TP, ABB RAPID, KUKA KRL, Kawasaki AS, etc) predate modern "IT"-domain languages. And haven't evolved as fast, b/c the use cases and requirements are so different.

Robot programming, as compared to "computer" programming, is so dominated by the motion/path planning that other features like string handling, array manipulation, object-oriented programming, and so on gets low priority (or has), often not getting much past "minimum viable feature" status. Or becomes a paid option, like basic Trig functions on Fanuc. This has helped prevent any consolidation in robot languages across brands, or the creation of a 3rd-party common language/transpiler, because how each brand handles motion is unique and proprietary. The safety-critical nature of robot systems contributes to this.

Instead, robots have (so far) followed a path similar to CNC machines -- proprietary (more or less) language on the machine, with 3rd-party software using brand-specific postprocessors to convert from the 3rd-party "common" language into something executable by the robot. But this often leaves some degree of optimization to the programmer to perform on the post-processor output (or a programmer who knows how to get exactly what they want from the post-processor).

There have been some recent moves, like the "timeline programming" interface on Fanuc CRXs, which tries to give a drag&drop Blockly-like programming experience. But even here (so far), this is just a translation layer atop the existing language, and the "Blockly experience" gives up utility to achieve ease of use. Which leaves most experienced programmers feeling handcuffed, and switching back to the "classic" mode.

KUKA was doing some interesting things with the Sunrise OS a few years ago, where the controller was just a "normal" computer running "normal" Java, with the robot "abstracted" away to being essentially a Java library. This... ended up being quite a bit more complex than anyone anticipated, but it sounds like it's going to be available as an option on the KRC 6(?) going forward. I'll be interested to see what that looks like. The big advantage there was that non-robot-specific operations like string handling, TCP/IP ports, matrix algebra, etc, could be handled using "normal" Java and libraries, reducing the KUKA-specific programing know-how required to motion and I/O control. This goes hand-in-hand with the controller hardware becoming more and more commodity-PC (albeit with industrial-grade components and realtime OS cores) and the virtualization of items that used to be brand-specific, function-specific (and very $$$) hardware.

Fanuc is advertising the ability to run some manner of Python on their upcoming R-50(?) controllers, but no word yet on what that will look like or how it will interact with the existing control software elements. I imagine they have an interest in leveraging open-source tools while retiring the tech debt of maintaining their own language suit. Similarly, AIUI KUKA has to pay Siemens a license fee for every KRC sold with KSS/KRL (dating back to the original KSS/KRL in the 1980s), so a situation where their controller runs Java (maintained by 3rd parties with lots of testing) and only have to maintain their in-house elements that are directly tied to robot motion

Quote from IsaacMaw1

In general, how transferable do you think robot programming experience is between brands? I assume that things like planning a process, identifying bottlenecks, understanding safety, maintenance and troubleshooting are more valuable, and the new language is somewhat trivial. Do you agree?

Mostly, yes. Knowing the language is important to be able to execute the process you've planned, especially when you're pushing the margins. For example, handling precisely timed on-the-fly output signals is possible in most brands, but the techniques and syntax are very different. And knowing the fine details of how those commands work on Robot X is really important when you're struggling to squeeze out the last few 0.1sec from your cycle time.
Also, each brand's language has its own features (or lack thereof) that can become critical, especially if you assume that Standard Feature A exists on every robot, then discover the hard way that Robot X doesn't support it (I'm looking at you, Fanuc, and your (lack of) Trig functions!)

OTOH, while it's not a matter of "if you've programmed one brand, you've programmed them all", the bulk of the most critical skills do carry over, as you said above. Generally, I would say that if you're pretty good with one robot brand, you can climb the learning curve for another pretty quickly, as long as you have access to good manuals and tech support. In this case, it helps to be an integrator who bounces between brands regularly (ask me how I know this ), because "agility" itself turns out to be a separate skill of its own that needs exercising. I've known far too many programmers who were absolute wizards in one brand, or one specific application, who were completely lost the moment an OOC problem hit them.

Hello,

Just to share my experience with programming languages and robots: When I started working with robots six years ago, I had no programming experience at all. I was a mechanical technician at a machinery maker and system integrator. I learned the basics on a Yaskawa robot, then a Fanuc. I could tell my programming conceptual ideas and signal/IO concepts were lacking, so I started to learn C++, Python, and Arduino for fun in my spare time.

The robot programs I write at work benefit from the larger concepts and basic programming fundamentals I have picked up using those more standard programming languages, even if the usual robot languages I use (Yaskawa INFORM, MelfaBasic, Yamaha Robot Programming Language, Fanuc) have a different or more rigid structure. Like others have mentioned, moving to the newer Fanuc drag-and-drop blocky style programming wasn't for me. When I am faced with a touchscreen-type pendant, I usually try to get the older overlay on it so I can use the commands the way I am used to.

Please post a link to the article when you are finished

the basics of all programming languages are the same. that includes concepts of memory, logic operations, loops, passing parameters etc. this is why such topics are covered in any introductory programming course. how far you go from here is up to you. when it comes to transferring knowledge from one language to another, it is the basics that transfer well. the higher you go the less transferability exists. an example of this is code dealing with hardware layer, proprietary features, abstraction layers etc.

for example any language will support branching and loops but not every language will support objects (this is something found in higher level languages) or direct hardware access such as DMA, IRQ, port access etc. (something normally found in low level languages).

also most languages are created to be application specific, not general purpose. ladder logic, function block diagrams, sequential logic etc are meant for controls. even though they look completely different, underlying basics are still there is you know how to look.

no language is bad but people can use any language badly. for example not understanding underlying principles and architecture can and generally does have severe impact on results. performance is one of obvious measures used to compare results.

many years ago we were given task to write program that writes text file on a floppy disc and content of the file should be 100 lines of text containing numbers 1-100. this could be done differently. the naïve approach worked too but it was incredibly slow. see in those days, operating system did not have the smarts of modern OS, there was no cashing of writes. so to make this faster, smart programmers would create image of what is to be written in memory then write the entire thing once.

so trying same exercise on modern computer would produce different results because OS is helping along and programmer would likely not even learn the difference until trying to do the same on a different platform. and then frustration would kick in "but i did this before and was fine".

the point is that learning outcome can have vary greatly based on course and instructor. self learning is one option but this has obvious disadvantage that without guidance, it is much slower and you get to pick what you like instead of what is important or good to know.

here is a great example of optimization

Quote from panic mode

no language is bad but people can use any language badly.

I had been meaning to give my input on your question, and I will start with this quote from Panic mode. I absolutely agree.

Many years ago I was going to try learning C/C++ on my Commodore Amiga 500. I had a book, and a compiler that kind of worked like the book said it would. That didn't work out so great

Fast forward a decade, decade and a half, to where I began learning the Rapid language of ABB robots. I was fortunate enough to be able to write some of the programs we used, instead of being just a teach monkey. I was also fortunate enough to have a mentor or two early on. I also studied the variety of programs from one company to the next as I went from job site to job site. I saw some clever programming, which I usually copied and used, and I saw some not so clever programming.

I have seen programmers write out the entire expression for calculating the distance between two points-I give them an A for their math skills but a C for ABB programming. Just use the built-in function. I have seen other programmers, not dumb guys, that break down a pos or pose into the atomic level when all they had to do was stop at the pos level and evaluate it as it is.

Rapid is a great language, in my opinion. If one has the knowledge and imagination, one could write a program to do income tax returns.

Other ways of programming, like TP programming of Fanuc and Yaskawa/Motoman are dumbed down versions, IMO. They are often referred to as being "user friendly". OK, if the user is not quite the sophisticated type. Many times these user friendly TP programs become spaghetti code, with jumps and labels everywhere. That can be quite difficult at times to follow. Don't get me wrong or on a high horse about Rapid, I have seen such programming in Rapid, too.

Now back to your original question, I have to ask clarification on this part:

Quote from IsaacMaw1

However, if the programming for my robot is a super polished user interface and I never see the code, I don't really learn any programming skills.

Which do you think is the higher level proprietary one? The super polished drag and drop type interface? Or languages Like Karel and Rapid?

The drag and drop is most likely higher level, but at the user interface level it is dumbed down and certainly doesn't provide much valuable skills for real programming.

I never really programmed Karel but I have seen some code and followed along. That and Rapid are really old school, but still evolving some.

In the end, I think that there are far less of us that actually care enough to excel in programming, seeking out knowledge, studying code, following along in order to better ourselves. Let the teach monkeys and drag and droppers do their thing, and we can do ours.

Some people are satisfied knowing just enough to get by while others are maybe never satisfied; always seeking better, more efficient, smarter ways to do new things, or even old ones.

Quote from IsaacMaw1

But in short I would think that the more "user friendly" an interface is, the more translation the computer/PLC is doing to get it down to the binary instructions that the controller actually follows.

At the end of the day, it's all layers of abstraction. And you're correct, the more abstraction, the less fine the level of available control. That's why people writing Python code still dip down into C when they need extremely fast or precisely-timed code (and Python itself is, at the end of the day, an abstraction layer on top of a huge library of C). And there's still the absolute madlads who write assembler on the regular.

The definition of "high-level" language is... slippery. And it's a continuum, not a discrete definition. Most computer programmers these days would look at most current robot languages and sneer at them for being so primitive ("No OOP? No CD/CI? The '80s called, they want their languages back!"). But compared to what we started with on robots in the 1960s, it's downright next-century.