In Sonja Keene's book Object-Oriented Programming in Common Lisp, section 12.4, she mentions that support for protocols was considered by the CLOS working group, but that implementations were too immature at the time to consider for standardization.
Does any know of any papers or documents on this topic that the working group might have considered? Dylan seems to have the idea of protocols and I want to explore similar ideas for Common Lisp.
Related
After reading through Scala SIP-21, a proposal to add a new construct to increase the safety of closures in concurrent and distributed environments, I am curious as to why the authors chose the name Spores in particular for this concept. I haven't found any other references to this name in other Computer Science literature, so it appears novel to this SIP.
I can loosely see the how the dispersal of many small, simple structures and perhaps the capability for dormancy could be evocative of distributed closures. But is there some stronger connection here, a more involved metaphor?
Assuming I model a complete system correctly, according to the Modelica syntax, are the compilers 'mature' enough to handle it?
I need to model a system with at least 15 connected components, each components is relatively simple, mathematically speaking, only algebric equations. Modelica is very appealing to me but I am a complete beginner and this project is important to me so I'm a little bit afraid to commit to Modelica.
I understand that compilers can't fully simulate all of the standard library examples and models, how can I know what are the exact limitations?
Thanks.
Well, it depends quite a bit on what tool you choose of course. I can tell you from personal experience that over 10 years ago I used Dymola in a project at Ford Motor Company where we modeled an engine (combustion), transmission (mechanisms and hydraulics) and chassis (multi-body representation). The resulting system had 250,000 equations and certainly hundreds if not thousands of components and connections. You can find more information about the project in a paper I wrote.
Of course, it depends on other things besides the size of your models. Most Modelica tools do not really support variable structure (DAEs with variable index) and others have limitations with respect to some of the language constructs that they fully support (which therefore means some libraries are not fully supported).
Unfortunately, at the moment there is not a comprehensive way to qualify the support from different tools but this is something that the Modelica Association recognizes is a problem and they are working on it.
But overall, Modelica is quite mature and is used in many, many industrial projects. You can find the proceedings from the previous 8 Modelica Conferences at http://www.modelica.org/ and you will see that many big name companies (Ford, BMW, GM, Toyota, Airbus, etc) have published material there.
I was reading an interesting blog post about Erlang/OTP and the actor model. I also hear that Scala supports the actor model. From the little I gathered so far, the actor model breaks down processing into components that communicate with each other by passing messages. Typically, those processes are immutable.
Are those features language-specific though or more at the architecture level? more specifically, can't you just implement the same actor model in almost any language, and just use some form of message-queue to pass messages between worker processes? (for example, use something like celery). Or is it that those languages like Erlang and Scala simply do this transparently and much faster?
Certainly you can define an "Actor Library" in virtually any language, but in Erlang the model is baked-in to the language, and is really the only concurrency model available.
While Scala's actors system is well implemented, at the end of the day, it still vulnerable to some hazards that Erlang is immune from. I'll draw your attention to this paper.
This would be the case for any Actor library implemented in any imperative language that supports shared mutable state.
An interesting exception to this is Nodes.js. Some work is being done with actors between Nodes that probably exhibit the same isolation properties as Erlang, simply because there is no shared mutable state.
Actor model is not limited to any specific platform or programming language, it's just a model after all.
Erlang and Scala have really good and useful implementations of this model, which fits nicely in typical technology stack of these platforms and helps to effectively solve certain kinds of tasks.
To add to the points mentioned above, the fact that in Erlang actor model is the only way you can program, makes your code scalable from the get-go. Erlang processes are lightweight, and you can spawn 10-100K on one machine (I don't think you can do it with python), this changes the way you approach problems. For example, in our product we parse web server logs with Erlang and spawn an Erlang process to handle each line. That way, if one log line is corrupted, or the process that handles it crashes, nothing happens to the other ones.
Another difference is when you start using OTP you get processes supervisors and you can make processes connected so if one terminates all the others do.
Other than that, Erlang has some other nice feature (which can be found in other languages through libraries, but again here it's baked in) like pattern matching and hot deploy.
No, there is nothing language-specific about the Actor Model. In fact, you already mention Scala in your question, where actors are not part of the language but are instead implemented as a library. (Three competing libraries, actually.)
However, just like Functional Programming or Object-Oriented Programming, having direct support for Actor Programming, or at least support for some abstractions that make it easier to implement, in the language will lead to a very different programming experience. Anyone who has ever done Functional Programming or Object-Oriented Programming in C will probably understand this.
Learning Clips, while I don't mind the syntax I'm finding it difficult to derive rules from facts. Is there a tip on how to structure rules given a knowledge base?
A non trivial example would be nice, thanks.
Basically this is the entire field of "knowledge engineering;" it's really as broad a question as "given a domain, how do I architect application software for that domain?" Whole books have been written on this topic. Here are three that treat this topic well IMO: Peter Norvig's "Artificial Intelligence, A Modern Approach", Giarratano and Riley's "Expert Systems: Principles and Programming", and my "Jess In Action".
This has baffled me for a long time.
Given basic atomic primitives like compare & swap, I can see how to implement a spin lock (from which I can build mutexes).
However, I don't see how I can build condition variables out of this. How is this done?
It's not particularly simple. The following is a link to a paper by Douglas Schmidt (who is also largely responsible for the ACE libraries) that details several approaches for implementing condition variables on Windows using the synchronization primitives available in Win32 (pre-Vista). The approaches include using only the basic, generally available on any OS primitives, and discusses the various limitations of the approaches:
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
The bottom line (concluding remarks):
This article illustrates why developing condition variables on Win32 platforms is tricky and error-prone. There are several subtle design forces that must be addressed by developers. In general, the different implementations we've examined vary according to their correctness, efficiency, fairness, and portability. No one solution provides all these qualities optimally.
The SignalObjectsAndWait solution in Section 3.4 is a good approach if fairness is paramount. However, this approach is not as efficient as other solutions, nor is it as portable. Therefore, if efficiency or portability are more important than fairness, the SetEvent approach described in Section 3.2 may be more suitable. Naturally, the easiest solution would be for Microsoft to simply provide condition variables in the Win32 API.
Note that starting in Vista, Windows supports condition variables using native APIs:
http://msdn.microsoft.com/en-us/library/ms686903.aspx