问题
It seems that the software language skills most sought for embedded devices and robots are C, C++, and LISP. Why haven't more recent languages made inroads into these applications?
For example, Erlang would seem particularly well-suited to robotic applications, since it makes concurrent programming easier and allows hot swapping of code. Python would seem to be useful, if for no other reason than its support of multiple programming paradigms. I'm even surprised that Java hasn't made a foray into general robotic programming.
I'm sure one argument would be, "Some newer languages are interpreted, not compiled" - implying that compiled languages are quicker and use fewer computational resources. Is this still the case, in a time when we can put a Java Virtual Machine on a cell phone or a SunSpot? (and isn't LISP interpreted anyway?)
回答1:
I once built a robot based on Java. It garbage collected right into a wall.
If you're going to have processes running that you can't micromanage (eg, a Linux based system) then they must know to yield to certain high priority processes like motion control. So either you do it yourself in a low level language like C, or you use an RTOS.
回答2:
As others have pointed out already, C and C++ are used because they are low-level. Another reason for C's popularity is that just about every architecture gets a C compiler targeted for it. This is good enough for a lot of people, so extra effort isn't often put into other languages. This is sort of like saying C is popular because C is popular, but hey, that's how things work.
LISP variants are popular in robotics in part because LISP variants have historically been popular in AI research. AI is a major focus in robotics, so a lot of stuff gets carried over from that field.
LISP has been around for a long time -- 1958 according to Wikipedia. It has more history than most other high-level languages, and this has two significant implications: 1) LISP is more firmly established (in the areas it is commonly used) than other high-level languages and 2) LISP interpreters have already been made to run on all manner of resource-limited hardware (see the next bullet point).
Interpreters are easier to implement for LISP variants than for many other high-level languages, and they can be made reasonably efficient. Scheme, for example, is a really easy language to parse, both conceptually and in CPU exertion.
To see why other languages do not have a strong foothold in embedded programming, just take the converse of the reasons that C, C++, and LISP do have a strong foothold.
They are not already popular in this field, so effort is not put into supporting them.
They were not used by previous generations, so newbies are not taught to use them.
They don't have much history (in this field). They represent the unknown. The unknown is scary (and hard).
They are taxing on limited hardware.
NOTE: When I talk about limited hardware, this is what I mean: a lot of embedded work still involves systems with between 256 bytes and 32 kiB of RAM. A smart phone that has 128 MiB of RAM is not a limited system.
回答3:
Because embedded devices mostly have limited resources where it is not welcome to have luxury such as automatic garbage collector. C/C++ allows you to work on quite low levels and program close to machine so that you get effective code as very much needed on those devices.
One more area where high-level languages like Java and .NET don't play well is real-time operation. You can't afford to get suddenly stalled because the garbage collector just kicked in at the worst possible moment.
回答4:
In 20 years in embedded systems (including 8 years on a commercial robotics project), I have never seen Lisp used anywhere and would not regard it as 'prevalent'. I seen far more Ada for example. I would say that it is a niche, but if you happen to be working in that niche, it might look prevalent to you.
C and C++ are used because they are systems level capable languages that require minimal run-time support. For example they can run without an OS - and indeed commonly used to implement Operating Systems.
When a new processor architecture or device is developed, C and C++ are typically the first 'high-level' language tools available for the platform (and often remain the only ones available) - usually from day one, and increasingly often GNU GCC based. Availability of other languages is patchy or non-existant. C and C++ skills are the ones pretty much guaranteed to be reusable across projects and architectures.
回答5:
You can do robotics with Java on the Mindstorm robots and MS has a push for doing robotics, but to a large extent C/C++ is used due to limited resources, and LISP is used for AI because for a long time this was an area of research and researchers were the main users of LISP, so they used the language they knew.
This is the same reason why FORTRAN is so prevalent in physics, for example, people use the language they know and when the project becomes commercial, unless you want to rewrite it from scratch, you keep the original code.
回答6:
I once fell over this interesting snippet on using Lisp at NASA: http://www.flownet.com/gat/jpl-lisp.html
In 1994 JPL started working on the Remote Agent (RA), an autonomous spacecraft control system. RA was written entirely in Common Lisp despite unrelenting political pressure to move to C++. At one point an attempt was made to port one part of the system (the planner) to C++. This attempt had to be abandoned after a year. Based on this experience I think it's safe to say that if not for Lisp the Remote Agent would have failed.
回答7:
My guess is that C/C++ are used because they are closer to the hardware and allow for resource-aware programming. This is generally true for all embedded projects, not just robotics.
Then I guess that LISP is often chosen, because it still seems the predominant language in artificial intelligence research. LISP is probably used for the higher level workings of the robot, I suppose.
回答8:
The main reason for the prevalence of C and C++ is that the runtime is deterministic for both due to the lack of garbage collection requirements. This makes it a good choice when you have to provide runtime guarantees. Not too mention that C has been considered the "higher level assembly language" of choice for many years.
Another interesting observation is that most embedded devices do not need or even have access to a complex GUI layer -- cellphones are an obvious exception. Most of the embedded work that I have done professionally has been in the cable set-top box arena so I may have a slanted view of things. And "No", I don't consider the set-top box to be a hard embedded environment. We grew up from having nothing more than a raw memory map of what is "on screen" and very little in the way of resources. To make a long story short, on screen graphics are an exercise in bit-twiddling with fixed bit widths - this is another place that pointers in C really shine.
I'm really not too surprised that Java hasn't made headway into the more "bare bones" market yet. The interpreter is just too heavy even though the Java ME was supposed to solve this. It is pretty prevalent in cell phones (e.g., BREW) and is slowly making its way into the set-top and TV markets (e.g., <tru2way> and GEM) but it isn't there yet and I'm really not sure that it will ever be.
As others have mentioned, FORTH is an "interpreted" language that has been used in a number of embedded environments as well as in quite a few bootloaders. Interpreted languages can definitely be used in realtime environments. Not all implementations of FORTH are interpreted though. LISP has been embedded as well.
I think that the main criteria for an embedable language are:
- deterministic memory management
- access to well-defined bit sizes (still not sure how LISP fits in here)
- simple execution environment
- entirely functional or general purpose
- flat memory model
The last point is the most interesting in my opinion - this is also why I believe that many languages will have trouble in the embedded market. Pure functional languages are a natural fit for concurrency and usually work in a flat memory model. General purpose languages work well because they don't usually proscribe any particular threading model which gives a lot of flexibility to the RTOS runtime implementers. Virtual memory environments are damned near impossible to implement so that they are deterministic and fast. This makes it very difficult for languages that require virtual memory support to really function correctly.
回答9:
Lisp is/was used in some research and some commercial robots. iRobot for example uses it. Here is an older article about their Common Lisp variant called L (<- Link).
Lisp is used when there is need for special higher level libraries, for example for complex planning operations. There are lots of libraries written over time for various planning operations, including planning of actions and movements of autonomous systems.
回答10:
It seems that the software language skills most sought for embedded devices and robots are C, C++, and LISP. Why haven't more recent languages made inroads into these applications?
I presume it's about space requirements, performance and reliability.
For example, Erlang would seem particularly well-suited to robotic applications, since it makes concurrent programming easier and allows hot swapping of code. Python would seem to be useful, if for no other reason than its support of multiple programming paradigms. I'm even surprised that Java hasn't made a foray into general robotic programming.
Probably much more languages could be used on those platforms if implementors undertook the effort of taking care of runtime constraints. Which is not often the case. There is always a tendency to soak up the resources you have at hand, if you do not deliberately strive for less.
I'm sure one argument would be, "Some newer languages are interpreted, not compiled" - implying that compiled languages are quicker and use fewer computational resources.
Forth has a reputation for being interpreted, but small and fast, and was therefore often used on embedded devices. Follow-ups like Factor would probably be good candidates too, but I havent' heard of any effort in this direction - see above.
Is this still the case, in a time when we can put a Java Virtual Machine on a cell phone or a SunSpot?
I'm not an embedded person, but a cell phone is a rather luxurious platform, compared to controllers in cars, speklets asf. But Java always had embedded devices in mind, so their embedded implementation might even reach further down the power spectrum.
(and isn't LISP interpreted anyway?)
Nope, professional implementations compile, AFAIKT.
回答11:
I just read some introductory Erlang materials and one of the first things they said was that Erlang was suitable for "Soft" real-time control. This is not something that I would want in any robot near me.
In addition I would say that robots (as in industrial) currently have no real need for hot swapped code. They are working on a piece basis and there will always be scheduled downtime to reload code at an appropriate moment - which of course is well tested in an offline unit.
回答12:
C and C++ are languages with very effective compilers (what leads to efficiency very important in Embedded systems with low resources).
Regarding Lisp, some misunderstanding has been spawned. Common Lisp (something what is mostly used right now - descendent of LISP 1.5) is compiled (not interpreted) and very efficient with a wide range of implementations and FFI (i.e your Common Lisp application may interoperate with C libraries) and some very nice high-level constructs. Live coding via REPL makes it even more convenient for checking out things on working robot.
Moreover there is Embeddable Common-Lisp, which allows embedding Common Lisp application in C binary – it is implementation compiled to shared library.
回答13:
Most commercial and industrial robots are programmed in C or C++. There maybe another language that the user interacts with. For example The industrial robot company I work for uses C running in a VxWork OS, but the applications programmers like me work with a proprietary language for commanding the robot. Both C and C++ give you a great deal of access and control over the hardware. You don't find too many commercial drivers for high power servo control motors. While complex these robots just follow basic routines.
LISP is mainly used in research robots like those that competed in the DARPA challenge. These types of robots need more "intelligence" then industrial or commercial robots.
回答14:
Having worked with robotics, my answer is efficiency. Yes, you can run a Java Virtual Machine on cell phones. But how efficient will it be? I was on a team that wanted to run a Java Virtual Machine on a full Windows XP machine on a robot, running multiple realtime monitoring applications in Matlab. Needless to say, we were dropping frames like it was no one's business. Moral of the story, override people who don't understand computing even if you need to override your supervisors if it's going to sink your operation.
Yes, you could run Python, and I've seen it done to manage multiple C processes. But at the end of the day, running C allows you to do some direct manipulation of connections so much easier and reliably than some of the higher level codes, and therefore is preferred.
回答15:
Embedded system needs a bare minimum OS and simple (not always) Application, since most OS-es are "C" its a natural choice
Scarcity of Processing/Memory resource force optimization from very low-level. C (edge over C++) has a great scope of Optimization
回答16:
Java made another milestone this year when it became a programming option for the FIRST Robotics Competition. FRC is an impressive competition involving over 77,000 high-school students, mentors, and volunteers from around the world building 120 pound robots in six weeks. I just posted some results about this on my blog.
By strange coincidence (or not), it uses the same Java VM as the Sun SPOTs mentioned in the original question.
来源：https://stackoverflow.com/questions/1601893/why-are-c-c-and-lisp-so-prevalent-in-embedded-devices-and-robots