Hate to break it to you, but so-called "picosats" have already been launched. They are indeed in the 1kg mass range. You're also right that "femtosats" are on the cards. See here for one of the more popular mass classification schemes. I'm eagerly awaiting the appearance of the first "yoctosat"...
In most languages, you write your program in some complex surface syntax, which is then run through a complicated parser. The parser converts it into a tree (hey...wasn't there something about trees before?), and the compiler then performs all kinds of transformations on that tree. Transformations that are relatively easy to describe on trees, but not so much on the surface syntax of the programming language - that's why you generate the parse tree. Of course, this all happens behind the scenes. But not so in Lisp. In Lisp, your program already _is_ a tree the way you wrote it down.
In fact (you probably already know this, but for the benefit of other readers), Lisp's S-expression syntax -- the familiar parenthesis-heavy stuff that looks like an abstract syntax tree -- started as just that: an abstract syntax for Lisp. The plan was originally to have a more ALGOL-like syntax for writing Lisp programs, the so-called M-expression syntax. But writing programs directly in S-expressions proved to be much more popular than M-expressions, possibly for some of the reasons you mentioned above.
That's the point though, isn't it: using a message-passing approach with no shared state makes concurrency much more tractable to reason about. It's a much more scalable mental model for building concurrent code that actually works.
Indeed. A language built around highly-efficient message-passing concurrency (rather than shared state) was seen as the way forward the last time the computing world was getting excited about using large-scale parallelism to increase processing power. Bell Labs also implemented the same kind of model when they started taking concurrency seriously. It's an idea that's been percolating in the background for many years now, but has never quite seemed to hit the mainstream (too many programmers wedded to sequential programming and the "small" jump from there to shared-state concurrency). Hopefully this time around, the idea will stick. Erlang certainly seems well-placed to gain mainstream acceptance, especially with Joe Armstrong's new PragProg book out, and the growing popularity of ErlyWeb.
Indeed. Surrey's SNAP-1 weighed in at around 6.5 kg (yes, that decimal point is in the right place), cost around $1.5M, and was built in about 6 months. It included full 3-axis attitude control (via a momentum wheel and magnetic torquers), a butane-based propulsion system, and a nifty structural design based around stackable modular trays.
First of all, I wanted to question whether anybody knew if they had any customers for this satellite bus?
I suspect that NASA is unlikely to find customers for this bus - it's an immature design, and is more costly and massive than flight-proven offerings from the likes of Surrey Satellites. Even if you restricted yourself to only buying from US companies, I think you'd find that Microsat Systems Inc, AeroAstro, or one of the other US smallsat manufacturers could outdo this FASTSAT concept.
Second, does anyone know if a magnetic orientation system has been used on any satellites in the past? Obviously, the rotation rates that can can be achieved by such a system must be pretty low, especially if the satellite has no moving parts to extend booms, so I'm curious what sort of payloads this bus is useful for.
Yes, magnetic attitude control has been in use for several decades. Search for "magnetic torque rod" and you'll probably dig up a few vendors. A few spacecraft have used torque rods as the primary form of attitude control. However, they're much more commonly used in combination with a gravity gradient boom (for low-cost, low-precision attitude control), or with reaction wheels (where the torque rods are used to help dump excess spacecraft angular momentum, and thereby prevent the reaction wheels from getting spun up to too high a speed).
Python... actually has all of the tools required to do functional programming.
Much as I like Python (and I do like it), last I checked it doesn't support tail-call optimization, which is pretty much required for many of the recursive algorithms used when doing FP.
From personal experience, I appreciate learning in an applied engineering environment rather than the theory of academia.
From my own personal experience (having worked in several different fields of engineering, and having down a couple of stints in grad school), I've found that the learning you can do in an applied engineering environment and the theory you can get in academia are complementary. Both are valuable, and each enhances the other. I've found that the times when I've been in grad school have been much more fruitful (compared to undergrad) due to the practical insights and the context that my work experience provided. By the same token, my ability to create working solutions is enhanced by the breadth and depth of academic knowledge I can bring to bear on a problem. Undergrad gives you the engineering equivalent of a swiss-army knife - you can do a lot of stuff, and you can learn all sorts of practical tricks to make that knife do things you'd never expect it to be able to do, but it's not always the best tool for the job. Grad school allows you to add a few power tools and some precision instruments to your mental workshop. Granted, most days you can probably get by with just the swiss-army knife. But sometimes it's nice to be able to call on one of those more powerful tools for some particularly troublesome piece of work.
I'd wager a fair amount of money to say that numbers under 65535 are represented as 16 bit ints but anything over that number is changed on the backend to possibly a 32bit number. This allows faster calculations of smaller numbers (which happen quite a lot) while still allowing higher numbers to be used.
I don't really see the point of doing 16-bit arithmetic on a 32-bit machine. It's not likely to be any faster than doing straight 32-bit arithmetic, particularly since integral promotion may well boost the 16-bit value to a 32-bit value for arithmetic anyway. Besides, 65535 is at the top end of the unsigned 16-bit int range, which seems an odd type to be using for spreadsheet calculations (where negative values are as likely as positive). I agree that the value itself indicates some kind of 16-bit snafu. I just don't think it's caused by trying to perform unsigned 16-bit arithmetic.
Most people don't need mathematics beyond basic arithmetic and fractions. Outside of a classroom, the concepts taught in algebra and above are rarely, if ever, encountered by the day to day people.Most people don't need most of the stuff they get taught in school. Outside of a classroom, the bulk of a K-12 school curriculum is rarely, if ever, going to be encountered by day to day people. So why bother sending anyone to school for anything? Oh yeah... that whole "educated populace" thing...
IIRC, the Air Force did actual tests on suits of this sort in vacuum chambers several decades ago. I seem to remember Jerry Pournelle mentioning it in one of his essays (something in "A Step Farther Out" maybe?). Note that both Pournelle and Niven typically had their spacefarers wearing skintight suits.
Re:I like my privacy, so please, no email ID
on
The Internet Of Things
·
· Score: 2, Funny
People are sheep. They can be led around like cattle...
So some kind of hybrid mutant livestock then?
Re:I have to say this doesn't sound like a good bo
on
Linux Programmer's Toolbox
·
· Score: 2, Insightful
As for printing state, depending on the system, printing may not be possible (embedded), or may throw off timing (or whatever) enough to make the problem go away...
To be fair, running a debugger on an embedded systems can cause just as many problems as state printing. In same cases more, since it can sssslllooooowwwww code execution. Depending on the embedded system, "printing state" can be a better choice - easier to get in to the system, and able to be targeted to a specific part of the system. Of course "printing state" in that case may not mean printf statements everywhere. I've used short diagnostic codes drawn on an NTSC display, bytes fired out an RS232 port, and logging to EEPROM, depending on the system. I've used debuggers too, but they've usually been more trouble than they're worth (I find them to be far more useful when writing desktop software).
Well, yeah, that is a problem. FDR is free for academic use, IIRC. But they charge for commercial use. Although, as the Formal Systems Europe folks point out, exactly how much debugging time do they need to save to justify the cost of FDR.
If FDR is too pricey for you (perhaps you're an open source developer), there are a few other options. In the free category is LTSA. LTSA accepts a language called FSP, which is similar (but not identical) to CSP. The tool itself is not as powerful as FDR from what I can tell, can potentially still very useful. And there's an Eclipse plugin:-) In the open source category is SPIN. SPIN's process modeling language, Promela, is more C-like than CSP-like, but does have CSP-like semantics. The tool itself is free, open source, very powerful, and has an active community of users. Definitely worth a try if you're looking for something capable of industrial-strength model-checking.
Not directly. The tool support for the pi-calculus is (IMHO) a little lacking compared to what you can do with CSP. Mobility Workbench is nice, but no real competition for FDR when it comes to design analysis. Not to say that you couldn't use the pi-calculus. However, since it's relatively straightforward to model the mobile aspects of occam-pi within the CSP framework using channel datatype conventions, and CSP is already a reasonably good match for the non-mobile part of occam, I've just used CSP as my analytical framework.
I'm not sure if there's been any work on applying the pi-calculus to occam-pi. I gather Peter Welch has done some work on a pure-CSP semantics for occam-pi (using the aforementioned technique for modeling of mobility within CSP), and I've heard talk of developing techniques for working with occam-pi in the "Unifying Theories of Programming" (which is kind of a mix of Z and CSP), but have heard nothing about using the pi-calculus so far (which is not to say it isn't happening of course). I have seen a few papers that discuss using the pi-calculus to model Erlang programs. But I don't recall if the intent there was to actually provide analytical support.
Thanks! From a quick skim it looks quite interesting (although it'll obviously take me a while to digest the whole thing:-) The few examples of Finesse that I ran across are (to me) reminiscent of Wright - which I guess shouldn't be surprising, since I gather you spent some time with Garlan at CMU. It'll be interesting to see how those kind of ideas can be turned into an implementation instead of an analytical tool. Looking forward to working my way through your thesis.
...it appears we definitely need a better tools/methods to do this competently
We already have them. Not to say they couldn't be improved. But before asserting that we "need a better tools", it'd be nice to see the tools/methods we already have actually get tried. As it is, most developers are (as this entire thread demonstrates) largely unaware of the huge body of existing work that's already been done in this area. Why reinvent the wheel? Smarter minds than you or I have already spent considerable time thinking about these problems, and coming up with solutions. Why not give them a go!
Even with all the pencil-paper-uml exercises available, you can rarely "develop" a design without accidentally introducing races due to assumptions and then debugging to find and exorcise them from the design.
Who said anything about UML? Certainly not I. UML is hopeless for designing concurrent systems, precisely because it lacks a truly formal semantics, and therefore does allow assumptions and race conditions to slip in. I'm talking about modeling languages like CSP and Promela, that are formally defined, executable, and able to be exhaustively model-checked to uncover all those hidden assumptions and race conditions. There are even tools and techniques that will help you to refine code from an abstract model in correctness-preserving steps. Granted, none of this is perfect. But it's still (a) streets ahead of how most sequential software is developed, and (b) much better than trying to find and eliminate bugs in already-developed code.
Actually, all you are doing is decomposing the problem. What parts of the decomposed computations can be parallel?
The simple answer is: the parts you can't see:-) Process calculi generally only concern themselves with externally observable events (such as the start or finish of an internal computation). Two computations can be considered to overlap in time ("be parallel") if their "start"/"finish" intervals overlap. Of course, there will be no interaction between those parallel computations, since the computations themselves are internal to the processes in question. Any interaction requires the introduction of additional events between the start and finish events.
Yes, they don't blindly apply the operational semantics of CSP: they use implicit synchronisation to avoid conflicts introduced by parallelism.
I'm afraid that I may not be following you here. Just to clarify: are you referring to the fact that CSP includes a nondeterministic choice operator, which occam omits (and further restricts its equivalent of the CSP external choice operator such that it's not possible to ALT across output events)? Or is there some other aspect of the "implicit sychronization" that I'm missing?
Please note that I'm not disagreeing with your point. You are quite correct that languages which implement concurrency models based on process calculi (such as occam or Nomadic Pict) do make judicious choices about which constructs make sense froma practical perspective, and which are better suited to theoretical use. However, your original complaint was about interleaving semantics in general as a basis for execution models, which is a somewhat broader issue than the choice of which constructs within an interleaving model to use.
There is no easy answer, but I believe that asynchronous (event-driven) programming models are better.
We are in agreement there. I think that asynchronous messaging is a better default choice for distributed programming. Of course, there are process calculi based on asynchronous messaging...;-)
I've previously developed a language, execution semantics and implementation of the semantics that provides this. In my case, I was trying to build a language and execution engine that could be easily distributed. The result is a fully asynchronous, distributed, state machine. Works well but it is very much a research prototype.
Interesting. Is the implementation available anywhere online? I'd be interested in playing with it.
How do we chase and choke out race conditions and deadlocks in testing?
Using testing to iron out concurrency errors is a losing proposition. You're better off trying prevent race conditions and deadlocks getting into your design in the first place, and making the design robust to those errors that do slip through. A few ideas (by no means a complete solution):
Use interaction patterns which are known to be free of deadlock (Welch's IO-Seq and IO-Par patterns, client-server structures, E's event-loop concurrency).
Model your design in something like CSP or Promela, and then model-check it to detect and eliminate potential race conditions or deadlocks.
If it's too late to model the design, then use a model-checker like Java Pathfinder to actually model-check your code, or extract a model from your code and model-check it with SPIN.
Develop a design that is robust to the concurrency errors that slip through the modeling and analysis process - see Erlang's approach to supervised process networks for one example.
They all use an interleaved concurrency model as the basis for their semantics. This is OK as a way of defining semantics, but not for execution in a truly parallel environment. In essence, the semantic model says that running computation A in parallel with computation B is the same as executing "A" then "B" or "B" then "A". Notice that the parallelism has been removed to make the semantics easier to reason about.
To a certain extent, that's a matter of interpretation and/or abstraction. Simultaneity of events is a tricky concept: it's always possible that if you look closely enough, you'll find that two things which appear "simultaneous" really aren't, but are actually interleaved. That's effectively the stance that calculi like CSP and the pi-calculus take: as you rightly point out, they make a fundamental assumption that events are "instantaneous" and indivisible, and simply cannot occur "simultaneously". However, all is not lost, since if you need to represent something that has any real duration, you can model it as a pair of events ("start" and "finish", or something similar). As for whether the interleaving model makes an acceptable basis for execution in a "truly" parallel environment, I guess it depends on what you mean by "truly" parallel. The success of the occam programming language running on networks of transputers would seem to provide a proof-by-example that the interleaving model can work in practice. Erlang provides a similar, more modern proof-by-example. But I suppose those may not count as "truly" parallel, in that they do enforce some serialization of events at the interfaces of individual processes, even if most of the system is operating "in parallel".
Having said all of that, there's been some work done on providing a "true concurrency" semantics for CSP (not sure about the pi-calculus). See, for example, recent work in that area by Adrian Lawrence or Marc Smith. There has also been a bunch of work on other "true concurrency" process algebras. So to claim that "They all use an interleaved concurrency model..." is incorrect. rather, the interleaved concurrency model has so far proved adequate for the design problems to which the calculi in question have been applied (see my comments above about occam and the transputer).
In a truly parallel application, you need to be very sure that executing "A" in parallel with "B" is not actually going to break anything.
I can only really see that being an issue if A and B can both affect the same piece of state simultaneously (willing to be corrected on that count though - I just can't envision any other situation where it'd be an issue). Languages built on models like CSP enforce the interleaving of A and B if they are affecting the same state, as a byproduct of the share-nothing approach to state encapsulation. Note that that doesn't prevent A and B from occurring at the "same time" if they're not affecting the same piece of state.
Petri nets are truly parallel, but also introduce some synchronisation requirements. Models based on Winskel's event structures are somewhat better, but not that widely known or understood.
Both Petri nets and Winskel's event structures certainly have much to recommend them. However, in both cases, my impression is that they are better suited to use as tools for providing a semantics (much as traces provide a semantics to CSP, or labelled transition systems to the pi-calculus), rather than as something that one would actually want to use as the basis for developing a design or a programming language. Perhaps an event-structure-based semantics of something like CSP would be useful (I gather Winskel did some work on that kind of thing back in the early 80's, but I'm not sure if he's done much with it since - my quick skim of his work on HOPLA wasn't enough to determine if it provides "true" concurrency or not).
Concurrent Sequential Programs - CSP. This is the programming model behind Erlang
Technically speaking, Erlang has more in common with the Actor model than with CSP. The Actor model (like Erlang) is based on named actors (cf Erlang pids) that communicate via asynchronous passing of messages sent to specific names. CSP is based on anonymous processes that communicate via synchronized passing of messages sent through names channels. Granted, you can essentially simulate one model within the other. But it pays to be clear about which model we're discussing.
There is a whole new way of thinking that is pretty much mind bending.
It's really not that new. CSP has been around in the literature since at least 1978 (the date of Hoare's first paper on the topic). Hewitt's Actor model predates that by a number of years. Languages implementing both CSP and the Actor model have been around for at least 20 years. They just haven't seen widespread use so far.
Be warned, it's functional!
Not necessarily. Erlang is certainly implemented that way. But it's not a requirement. The 20-year old occam programming language, which was based pretty heavily on CSP, is basically an imperative language. The E programming language is OO to the core. The Oz language freely mixes functional, imperative, and OO constructs. All three permit message-passing concurrency in the Actor or CSP style.
The compiler can auto-parallelize a functional-map where each individual map-computation is not dependent on any other.
This can help to improve the performance of computational tasks. But it doesn't address the fact that (a) the world is fundamentally concurrent, and (b) most modern apps (web browsers, word processors, games) have a large interactive component that could really benefit from a concurrent design. Too much emphasis is being placed on pure computational speed in discussions like this one, when in most cases computation isn't the bottleneck - it's I/O and interactivity. As Joe Armstrong (the guy behind Erlang) has said, "In Concurrency Oriented Programming, the concurrent structure of the program should follow the concurrent structure of the application. It is particularly suited to programming applications which model or interact with the real world."
I ask because I've been following programming research, and the general consensus seems to be that it is too hard with the existing tools. I haven't done anything serious requiring multiple threads, but the experience I have had suggests that it can be a very tricky thing indeed to do correctly.
Yes, and then again no. Concurrency is hard. But it doesn't have too be as hard as most developers make it. Shared state and threads are horrible way to do concurrency, but it's all most developers are taught. We've had the tools to do concurrent programming in a much more manageable way for 15-20 years (Google for the occam programming language, or CSP - for a modern take, see Erlang or E). I've personally written software consisting of 1000+ interacting "threads" in a complex, dynamically changing communications topology. Concurrency bugs have generally not been a problem with that code (I spent more time debugging some of the sequential stuff) because of the design paradigm I used (occam and CSP). Granted, that toolset is not "mainstream", and there's more research dollars in selling stuff like Software Transactional Memory (which nominally lets programmers stay in their little sequential comfort zone) than there is in actually taking existing, proven solutions mainstream (again, Erlang is about the closest we've got right now).
MPI is a heavyweight solution resting on top of essentially sequential languages. What is need is languages that integrate share-nothing message-passing into the language itself, in a lightweight manner. Erlang and E are good examples of that kind of approach.
Slashdot Mirror
Hate to break it to you, but so-called "picosats" have already been launched. They are indeed in the 1kg mass range. You're also right that "femtosats" are on the cards. See here for one of the more popular mass classification schemes. I'm eagerly awaiting the appearance of the first "yoctosat"...
That's the point though, isn't it: using a message-passing approach with no shared state makes concurrency much more tractable to reason about. It's a much more scalable mental model for building concurrent code that actually works.
Indeed. A language built around highly-efficient message-passing concurrency (rather than shared state) was seen as the way forward the last time the computing world was getting excited about using large-scale parallelism to increase processing power. Bell Labs also implemented the same kind of model when they started taking concurrency seriously. It's an idea that's been percolating in the background for many years now, but has never quite seemed to hit the mainstream (too many programmers wedded to sequential programming and the "small" jump from there to shared-state concurrency). Hopefully this time around, the idea will stick. Erlang certainly seems well-placed to gain mainstream acceptance, especially with Joe Armstrong's new PragProg book out, and the growing popularity of ErlyWeb.
Indeed. Surrey's SNAP-1 weighed in at around 6.5 kg (yes, that decimal point is in the right place), cost around $1.5M, and was built in about 6 months. It included full 3-axis attitude control (via a momentum wheel and magnetic torquers), a butane-based propulsion system, and a nifty structural design based around stackable modular trays.
Most people don't need mathematics beyond basic arithmetic and fractions. Outside of a classroom, the concepts taught in algebra and above are rarely, if ever, encountered by the day to day people.Most people don't need most of the stuff they get taught in school. Outside of a classroom, the bulk of a K-12 school curriculum is rarely, if ever, going to be encountered by day to day people. So why bother sending anyone to school for anything? Oh yeah... that whole "educated populace" thing...
IIRC, the Air Force did actual tests on suits of this sort in vacuum chambers several decades ago. I seem to remember Jerry Pournelle mentioning it in one of his essays (something in "A Step Farther Out" maybe?). Note that both Pournelle and Niven typically had their spacefarers wearing skintight suits.
Well, yeah, that is a problem. FDR is free for academic use, IIRC. But they charge for commercial use. Although, as the Formal Systems Europe folks point out, exactly how much debugging time do they need to save to justify the cost of FDR.
If FDR is too pricey for you (perhaps you're an open source developer), there are a few other options. In the free category is LTSA. LTSA accepts a language called FSP, which is similar (but not identical) to CSP. The tool itself is not as powerful as FDR from what I can tell, can potentially still very useful. And there's an Eclipse plugin :-) In the open source category is SPIN. SPIN's process modeling language, Promela, is more C-like than CSP-like, but does have CSP-like semantics. The tool itself is free, open source, very powerful, and has an active community of users. Definitely worth a try if you're looking for something capable of industrial-strength model-checking.
Not directly. The tool support for the pi-calculus is (IMHO) a little lacking compared to what you can do with CSP. Mobility Workbench is nice, but no real competition for FDR when it comes to design analysis. Not to say that you couldn't use the pi-calculus. However, since it's relatively straightforward to model the mobile aspects of occam-pi within the CSP framework using channel datatype conventions, and CSP is already a reasonably good match for the non-mobile part of occam, I've just used CSP as my analytical framework.
I'm not sure if there's been any work on applying the pi-calculus to occam-pi. I gather Peter Welch has done some work on a pure-CSP semantics for occam-pi (using the aforementioned technique for modeling of mobility within CSP), and I've heard talk of developing techniques for working with occam-pi in the "Unifying Theories of Programming" (which is kind of a mix of Z and CSP), but have heard nothing about using the pi-calculus so far (which is not to say it isn't happening of course). I have seen a few papers that discuss using the pi-calculus to model Erlang programs. But I don't recall if the intent there was to actually provide analytical support.
I'm afraid that I may not be following you here. Just to clarify: are you referring to the fact that CSP includes a nondeterministic choice operator, which occam omits (and further restricts its equivalent of the CSP external choice operator such that it's not possible to ALT across output events)? Or is there some other aspect of the "implicit sychronization" that I'm missing?
Please note that I'm not disagreeing with your point. You are quite correct that languages which implement concurrency models based on process calculi (such as occam or Nomadic Pict) do make judicious choices about which constructs make sense froma practical perspective, and which are better suited to theoretical use. However, your original complaint was about interleaving semantics in general as a basis for execution models, which is a somewhat broader issue than the choice of which constructs within an interleaving model to use.
We are in agreement there. I think that asynchronous messaging is a better default choice for distributed programming. Of course, there are process calculi based on asynchronous messaging...To a certain extent, that's a matter of interpretation and/or abstraction. Simultaneity of events is a tricky concept: it's always possible that if you look closely enough, you'll find that two things which appear "simultaneous" really aren't, but are actually interleaved. That's effectively the stance that calculi like CSP and the pi-calculus take: as you rightly point out, they make a fundamental assumption that events are "instantaneous" and indivisible, and simply cannot occur "simultaneously". However, all is not lost, since if you need to represent something that has any real duration, you can model it as a pair of events ("start" and "finish", or something similar). As for whether the interleaving model makes an acceptable basis for execution in a "truly" parallel environment, I guess it depends on what you mean by "truly" parallel. The success of the occam programming language running on networks of transputers would seem to provide a proof-by-example that the interleaving model can work in practice. Erlang provides a similar, more modern proof-by-example. But I suppose those may not count as "truly" parallel, in that they do enforce some serialization of events at the interfaces of individual processes, even if most of the system is operating "in parallel".
Having said all of that, there's been some work done on providing a "true concurrency" semantics for CSP (not sure about the pi-calculus). See, for example, recent work in that area by Adrian Lawrence or Marc Smith. There has also been a bunch of work on other "true concurrency" process algebras. So to claim that "They all use an interleaved concurrency model..." is incorrect. rather, the interleaved concurrency model has so far proved adequate for the design problems to which the calculi in question have been applied (see my comments above about occam and the transputer).
I can only really see that being an issue if A and B can both affect the same piece of state simultaneously (willing to be corrected on that count though - I just can't envision any other situation where it'd be an issue). Languages built on models like CSP enforce the interleaving of A and B if they are affecting the same state, as a byproduct of the share-nothing approach to state encapsulation. Note that that doesn't prevent A and B from occurring at the "same time" if they're not affecting the same piece of state.Both Petri nets and Winskel's event structures certainly have much to recommend them. However, in both cases, my impression is that they are better suited to use as tools for providing a semantics (much as traces provide a semantics to CSP, or labelled transition systems to the pi-calculus), rather than as something that one would actually want to use as the basis for developing a design or a programming language. Perhaps an event-structure-based semantics of something like CSP would be useful (I gather Winskel did some work on that kind of thing back in the early 80's, but I'm not sure if he's done much with it since - my quick skim of his work on HOPLA wasn't enough to determine if it provides "true" concurrency or not).MPI is a heavyweight solution resting on top of essentially sequential languages. What is need is languages that integrate share-nothing message-passing into the language itself, in a lightweight manner. Erlang and E are good examples of that kind of approach.