为什么 C、C++ 和 LISP 在嵌入式设备和机器人中如此流行？
嵌入式设备和机器人最需要的软件语言技能似乎是 C、C++ 和 LISP。为什么最近的语言没有进入这些应用程序？
例如，Erlang 似乎特别适合机器人应用程序，因为它使并发编程更容易并且允许热交换的代码。 Python 似乎很有用，如果没有其他原因，除了它支持多种编程范例之外。我什至感到惊讶的是，Java 还没有涉足通用机器人编程。
我确信一个论点是，“一些较新的语言是解释性的，而不是编译性的”——这意味着编译性语言更快并且使用更少的计算资源。当我们可以将 Java 虚拟机放在手机或 SunSpot 上时，情况仍然如此吗？ （LISP 不是被解释了吗？）
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?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（17）
我曾经搭建过一个基于Java的机器人。它把垃圾直接收集到墙上。
如果您要运行无法进行微观管理的进程（例如，基于 Linux 的系统），那么它们必须知道要让位于某些高优先级进程，例如运动控制。因此，您要么使用 C 等低级语言自行完成，要么使用 RTOS。
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.
正如其他人已经指出的那样，使用 C 和 C++ 是因为它们是低级的。 C 流行的另一个原因是几乎每个体系结构都有一个针对它的 C 编译器。这对于很多人来说已经足够了，因此通常不会在其他语言上投入额外的精力。这有点像说 C 很流行，因为 C 很流行，但是，嘿，事情就是这样工作的。
LISP 变体在机器人领域很受欢迎，部分原因是 LISP 变体历来在人工智能研究中很受欢迎。人工智能是机器人技术的一个主要焦点，因此很多东西都是从该领域继承下来的。
LISP 已经存在很长时间了——根据 Wikipedia 的说法，LISP 已经存在很长时间了。它比大多数其他高级语言拥有更悠久的历史，这有两个重要意义：1）LISP 比其他高级语言更牢固（在常用领域）；2）LISP 解释器已经出现可以在各种资源有限的硬件上运行（请参阅下一个要点）。
与许多其他高级语言相比，LISP 变体的解释器更容易实现，并且可以变得相当高效。例如，Scheme 是一种非常容易解析的语言，无论是在概念上还是在 CPU 消耗方面。
要了解为什么其他语言在嵌入式编程领域没有站稳脚跟，只要与 C、C++ 和 LISP 确实站稳脚跟的原因相反即可。
他们在这个领域还没有流行，所以没有花精力去支持他们。
前几代没有使用过它们，所以不教新手使用它们。
他们（在这个领域）没有太多历史。他们代表着未知。未知是可怕的（而且很难）。
他们对有限的硬件征税。
注意：当我谈论有限的硬件时，我的意思是：许多嵌入式工作仍然涉及 RAM 介于 256 字节到 32 kiB 之间的系统。拥有 128 MiB RAM 的智能手机并不是一个有限的系统。
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.
因为嵌入式设备大多资源有限，不欢迎自动垃圾收集器等奢侈品。 C/C++ 允许您在相当低的级别上工作并在机器附近进行编程，以便您获得这些设备上非常需要的有效代码。
Java 和 .NET 等高级语言表现不佳的另一个领域是实时操作。您不能因为垃圾收集器在最糟糕的时刻启动而突然陷入停滞。
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.
在嵌入式系统领域的 20 年（包括商业机器人项目的 8 年）中，我从未见过 Lisp 在任何地方使用过，也不认为它“流行”。例如，我见过更多的艾达。我想说这是一个利基市场，但如果你碰巧在这个利基市场工作，它可能看起来对你来说很普遍。
使用 C 和 C++ 是因为它们是系统级语言，需要最少的运行时支持。例如，它们可以在没有操作系统的情况下运行 - 并且实际上通常用于实现操作系统。
当开发新的处理器架构或设备时，C 和 C++ 通常是该平台可用的第一个“高级”语言工具（并且通常仍然是唯一可用的工具）——通常从第一天开始，并且越来越多地基于 GNU GCC。其他语言的可用性是零散的或不存在的。 C 和 C++ 技能几乎可以保证在项目和架构中可重用。
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.
我曾经在 NASA 使用 Lisp 时遇到过这个有趣的片段：http://www.flownet。 com/gat/jpl-lisp.html
I once fell over this interesting snippet on using Lisp at NASA: http://www.flownet.com/gat/jpl-lisp.html
你可以在 Mindstorm 机器人上用 Java 做机器人，MS 也推动做机器人，但由于资源有限，很大程度上使用 C/C++，而 LISP 用于 AI，因为很长一段时间这是一个领域。研究人员和研究人员是 LISP 的主要用户，因此他们使用他们知道的语言。
这也是 FORTRAN 在物理学中如此流行的原因，例如，人们使用他们知道的语言，当项目商业化时，除非你想从头开始重写，否则你会保留原始代码。
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.
我的猜测是使用 C/C++ 是因为它们更接近硬件并且允许资源感知编程。这对于所有嵌入式项目来说通常都是如此，而不仅仅是机器人。
然后我猜LISP经常被选择，因为它似乎仍然是人工智能研究中的主导语言。我想，LISP 可能用于机器人的更高级别的工作。
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.
C 和 C++ 流行的主要原因是，由于缺乏垃圾收集要求，两者的运行时都是确定性的。当您必须提供运行时保证时，这使其成为一个不错的选择。更不用说 C 多年来一直被认为是首选的“高级汇编语言”。
另一个有趣的观察是，大多数嵌入式设备不需要甚至无法访问复杂的 GUI 层——手机是一个明显的例外。我专业完成的大部分嵌入式工作都是在有线电视机顶盒领域，所以我对事物的看法可能有偏见。 “不”，我不认为机顶盒是一个硬嵌入式环境。我们的成长过程中，除了“屏幕上”的原始内存映射之外什么都没有，而资源却很少。长话短说，屏幕上的图形是固定位宽度的位调整练习——这是 C 中指针真正发光的另一个地方。
对于 Java 尚未在更“简单的”市场取得进展，我真的不太感到惊讶。尽管 Java ME 应该可以解决这个问题，但解释器还是太重了。它在手机中非常流行（例如，BREW），并且正在慢慢进入机顶盒和电视市场（例如，
正如其他人提到的，FORTH 是一个“解释” 语言已在许多嵌入式环境以及相当多的引导加载程序中使用。解释型语言绝对可以在实时环境中使用。但并非 FORTH 的所有实现都被解释。 LISP 也已被嵌入。
我认为可嵌入语言的主要标准是：
最后一点是我认为最有趣的——这也是为什么我相信很多语言会在嵌入式市场遇到麻烦。纯函数式语言非常适合并发，并且通常在平面内存模型中工作。通用语言工作得很好，因为它们通常不禁止任何特定的线程模型，这为 RTOS 运行时实现者提供了很大的灵活性。虚拟内存环境几乎不可能实现，因此它们具有确定性和快速性。这使得需要虚拟内存支持的语言很难真正正常运行。
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:
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.
Lisp 被用于一些研究和一些商业机器人。例如 iRobot 就使用它。这是一篇关于 Common Lisp 变体的旧文章，名为 L（<-链接）。
当需要特殊的高级库时，例如复杂的规划操作，可以使用 Lisp。随着时间的推移，有许多用于各种规划操作的库，包括自治系统的行动和运动的规划。
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.
C 和 C++ 是具有非常有效的编译器的语言（这使得效率在资源匮乏的嵌入式系统中非常重要）。
关于Lisp，人们产生了一些误解。 Common Lisp（现在最常用的东西 - LISP 1.5 的后代）经过编译（未解释）并且非常高效，具有广泛的实现和 FFI（即您的 Common Lisp 应用程序可以与 C 库进行互操作）和一些非常好的高级构造。通过 REPL 进行实时编码使得检查工作机器人上的东西变得更加方便。
此外，还有 Embeddable Common-Lisp，它允许在 C 二进制文件中嵌入 Common Lisp 应用程序 - 它是编译为共享库的实现。
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.
我认为这与空间要求、性能和可靠性有关。
如果实现者努力处理运行时约束，那么这些平台上可能可以使用更多的语言。但这种情况并不常见。如果你不刻意争取更少的资源，那么总是有一种倾向会耗尽你手头的资源。
Forth 因可解释而闻名，但体积小且速度快，因此经常在嵌入式设备上使用。像 Factor 这样的后续产品可能也是不错的候选者，但我还没有听说在这个方向上有任何努力 - 见上文。
我不是嵌入式人员，但与汽车、speklets asf 中的控制器相比，手机是一个相当豪华的平台。但 Java 始终考虑嵌入式设备，因此它们的嵌入式实现甚至可能会进一步降低功率谱。
不，专业实现编译，AFAIKT。
I presume it's about space requirements, performance and reliability.
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.
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.
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.
Nope, professional implementations compile, AFAIKT.
我刚刚读了一些介绍性的 Erlang 材料，他们说的第一件事就是 Erlang 适合“软”实时控制。这不是我希望我附近的任何机器人都能做到的。
此外，我想说机器人（如工业机器人）目前并不真正需要热插拔代码。他们按件工作，并且总是会安排停机时间以在适当的时刻重新加载代码——当然，这在离线单元中经过了充分的测试。
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.
大多数商业和工业机器人都是用 C 或 C++ 编程的。用户可能会使用另一种语言进行交互。例如，我工作的工业机器人公司使用在 VxWork 操作系统中运行的 C，但像我这样的应用程序程序员则使用专有语言来命令机器人。 C 和 C++ 都为您提供了对硬件的大量访问和控制。您找不到太多用于高功率伺服控制电机的商业驱动器。虽然这些机器人很复杂，但它们只是遵循基本的惯例。
LISP 主要用于研究机器人，例如参加 DARPA 挑战赛的机器人。这些类型的机器人比工业或商业机器人需要更多的“智能”。
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.
在从事机器人技术工作后，我的答案是效率。是的，您可以在手机上运行 Java 虚拟机。但它的效率有多高呢？我所在的团队希望在机器人的完整 Windows XP 机器上运行 Java 虚拟机，在 Matlab 中运行多个实时监控应用程序。不用说，我们丢帧就像这与任何人无关一样。这个故事的寓意是，即使你需要推翻你的主管（如果这会导致你的运营陷入困境），也要推翻那些不懂计算的人。
是的，您可以运行 Python，而且我已经看到它是用来管理多个 C 进程的。但归根结底，运行 C 允许您对连接进行一些直接操作，比某些更高级别的代码更容易、更可靠，因此是首选。
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.
嵌入式系统需要一个最低限度的操作系统和简单（并不总是）应用程序，因为大多数操作系统是“C”，它是一个自然的选择
处理/内存资源的稀缺迫使从非常低的级别进行优化。 C（优于 C++）具有很大的优化范围
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
Java 今年取得了另一个里程碑，它成为 FIRST Robotics 的编程选项竞争。 FRC 是一项令人印象深刻的竞赛，来自世界各地的 77,000 多名高中生、导师和志愿者参与其中，在六周内建造了 120 磅的机器人。我刚刚在我的博客上发布了一些关于此的结果。
奇怪的是（或不是），它使用与原始问题中提到的 Sun SPOT 相同的 Java VM。
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.
与其他程序相比，C、汇编、lisp 在使用较小的内存空间方面效率更高，并且需要较少的电力资源。而且，C 在 AI / ML 方面比其他程序更容易训练
C, assembly, lisp are more efficient in using small memory space and need small power resources compare to other programs. And also, C are far better easy trainable in AI / ML than other programs