In *n?x the C calling convention reigns supreme. The C calling convention allows libraries and programs to be written in different languages - to a certain extent. OpenVMS extends the idea of a calling convention with its calling standard[1]. The OpenVMS approach provides more detail than the C one, allowing better interoperability between languages.
Another issue, that might be related is that of bindings. Many libraries are written in compiled languages, and must have bindings made to be used from a scripting language. This strikes me as less than satisfactory - I would like to get access to a new library for free, no need for bindings. Unfortunately, I think that there is a problem with this idea - namely, scripting languages generally have higher level constructs available than the lower level language the libraries are written in. This means, to provide an interface appropriate for the scripting language, taking advantage of its idioms and syntax, additional information is needed. The alternative is for a standard for libraries to follow which recognizes, and encodes information for all desired idioms. This strikes me as absurd, since it requires an update to the system in the case that a language introduces an idiom that isn't yet recognized, and coded for.
What I think I want is a system where a common set of functionality is available to any language on the system, and any language can be used to add functionality to that set. Perhaps the executable or process provide this ideal in *n?x.
[1] OpenVMS Calling Standard
Tuesday, June 15, 2010
Taking Out The Trash
Most (all?) dynamic programming languages these days use a garbage collector. Even some static languages use a garbage collector. This is generally considered a good thing. Google can help convince you of the benefit.
Unfortunately garbage collectors have a couple downsides. One downside is that they tend to conflict with parallelism, a growing problem with today's abundance of multicore processors. The main disadvantage, however, is the pause in processing when the garbage collector pauses processing to clean the heap. This means that real-time processing (audio, video, games) can't be done in today's high-level languages. The typical solution is to rely on an external library written in a language without garbage collection, typically C or C++.
Perhaps all we need is better garbage collectors. What I think, however, is that we need some means of designating which portions of code a garbage collector may interfere with. Honestly I have no idea what I'm proposing, but I like dynamic languages like Ruby and Javascript far too much to decide that I have to simply rely on a different language for real-time code.
Unfortunately garbage collectors have a couple downsides. One downside is that they tend to conflict with parallelism, a growing problem with today's abundance of multicore processors. The main disadvantage, however, is the pause in processing when the garbage collector pauses processing to clean the heap. This means that real-time processing (audio, video, games) can't be done in today's high-level languages. The typical solution is to rely on an external library written in a language without garbage collection, typically C or C++.
Perhaps all we need is better garbage collectors. What I think, however, is that we need some means of designating which portions of code a garbage collector may interfere with. Honestly I have no idea what I'm proposing, but I like dynamic languages like Ruby and Javascript far too much to decide that I have to simply rely on a different language for real-time code.
Subscribe to:
Posts (Atom)