In my experience (which is extensive, but not universal), almost no robots support "common languages" from the "IT world." The URs are the only ones I can think of offhand that do (Python). Although the latest KUKA controllers with the Sunrise OS option are supposed to be programmable in Java, from what I've heard.
Offline programming tends to be limited to very large, complex systems that have to be built and tested virtually before starting hardware build, and even then, it's not unusual for the Sim team to only provide certain critical data (Tool/Base frame coordinates, special process points, etc), and still leave the detailed programming to the shop-floor programmers. Systems programmed 100% offline are pretty rare.
The Ready Robotics-type 3rd-party pendants (they're honestly more like an extra control system duct-taped on top of the robot's existing OS) have been pretty rare in my experience. When I tried using it, I came away feeling like I was trying to swim with both hands handcuffed behind my back. It might provide a more iPad-like user-friendly experience for non-programmers, but in trying to be all things to all people, I think it gives up a lot of utility.
Brand-specific languages and pendants are pretty much inseparable. It's possible to write KAREL code for Fanucs offline, but loading it into the robot generally requires operations on the pendant, as does testing. And most KAREL programs interact with "pendant" programs in some ways -- in fact, "pendant" programs are just programs optimized for creation/editing/testing from the pendant. The distinction between KAREL and TP on Fanucs is pretty arbitrary, and is pretty much a Fanuc-only thing. Most other brands either only have one programming language (KUKA, ABB), separate languages that have equal "standing" (UR), or even mix multiple languages in one program (Kawasaki).
You're right that it's not natively offered but many at least offer a socket messaging interface that you could use from any programming language. The ROS industrial project also provides a way to interface with many robots from Python and C++.
Yyyyeeeees, but: almost all of those rely heavily on a "TP"-level program running in the robot as "middleware". ROS, for example, is not highjacking the control down to the raw servo-control level. Instead, a fairly complex program in the robot is accepting motion commands from ROS, executing them, then reporting back. Safety, accel/decel, inertia, low-level motor management, etc, are still mostly being handled by the robot controller.
There are different degrees of this, but generally, ROS and its equivalents are acting from one abstraction level higher than the "TP" program.
There is motion in the direction you're thinking, but it's not a simple jump to make.
Most of my experience is with ABB robots and, consequently, the Rapid programming language. One may use the editor in robotstudio, even loading programs into the virtual controller to get syntax checking and such. Other than that, one may use any ascii based text editor. I have used Ultraedit for many years, but even notepad will work. Additionally, one may connect to the controller with Robotstudio to directly edit the rapid program loaded into the controller. Teach pendant programming is a good skill to have as well. I have known many programmers who could do one or the other well, but not both. My take is that what would you do if you were on the road and your laptop broke? Better be able to use the pendant!
I use a combination of TP Programming on the pendant and using the same TP programming language in a text editor.
I agree with Lemster68, first and foremost you need to be able to work on the pendant. Then if you do offline, it's best if it's the same language as the pendant so you don't have to context switch.
When an assembly line is down, operations doesn't care if you know ROS or c++, they care how quickly you can get the machine running again. The fastest way to troubleshoot a down robot is through the pendant.
