Microsoft Releases New Concurrent Programming Language 297
zokier writes "Microsoft has released a new programming language called Axum, previously known as Maestro and based on the actor model. It's meant to ease development of concurrent applications and thus making better use of multi-core processors. Axum does not have capabilities to define classes, but as it runs on the .NET platform, Axum can use classes made with C#. Microsoft has not committed to shipping Axum since it is still in an incubation phase of development so feedback from developers is certainly welcome."
This will be fun... (Score:5, Interesting)
Re:Focuses on Interfaces to Ease the Pain (Score:5, Interesting)
One last thing I'd like to bitch about is that this download is an MSI. Really? You really need to do that? For the love of christ, I'm a developer. Could you please just give me a standalone zipped up SDK directory that I could add to my path if I want to? I'm not even going to install this because it's going to get all up in my registry n' shit.
While I realize that bitching about MS products is a common hobby, you could just extract the files directly [tech-recipes.com] and avoid any installation.
msiexec ships with Vista (and possibly earlier versions of Windows, I haven't checked). There are a number of third party programs that could do it as well, just look around.
Re:So, where did they steal this idea from? (Score:5, Interesting)
Initial Failures (Score:3, Interesting)
public Program()
{
// Receive command line arguments from port CommandLine
String [] args = recieve(PrimaryChannel::CommandLine);
// Send a message to port ExitCode;
PrimaryChannel::ExitCode <-- 0; }
I can't help but think that their idea of "Channels" is really a message queue, which listeners pull messages from. This is easily implemented in around 30-40 lines of Python, Queues, Tasks and Listeners. And since Python supports these crazy things called CLASSES, it's really quite easy to implement new features or override base functionality.
In other words, this is an incredible waste of time. Put all these kids to work on IronPython and close this crap down.
Re:So, where did they steal this idea from? (Score:2, Interesting)
To me it looks more like they took XNA and adapted it to something a bit more agnostic to underlying architecture. Almost like a Blackboard [wikipedia.org]/XNA [xna.com] lovechild. They took the compartmentalized (class-driven) structure of XNA, gave a shared communication API in the same vein as Blackboard (think centralized communication system as opposed to shared discussion system... like the comm system in Quake 3 source), wrapped it up in a C# API, and called it a language.
Call me crazy... but in order for it to be truly a "language", it needs to have a compiler/interpretor, and not simply a few new keywords in an existing language (it's C# with some new datatypes).
Re:Not "Insightful", "Clueless" (Score:5, Interesting)
Come on, who ever complained about Microsoft "stealing" any of the existing languages supportted by .Net? That was not true for Eiffel or managed C++ or IronPython, or... you get the point.
Actually there have been many criticisms of IronPython and Managed C++ in the usual "embrace, extend" whining on this site and on other tech sites.
So using an existing concurrent language would make a lot of sense and annoy no-one.
Bullshit. People would whine no matter what because it's Microsoft.
Re:Focuses on Interfaces to Ease the Pain (Score:4, Interesting)
After scanning the guide as well, it reads a lot like Erlang as "improved" by a Java/C# lover. You get a lot of syntax to make strict specification, which is a win, but the result is that the language isn't very light on its feet or Lispy in the way Erlang is.
For example: Axum seems to have a pretty strict type system, which gives you the ability to catch compile-time errors more cleanly, but on the other hand, there doesn't seem to be a simple way of creating a Tuple or Array literal without using a function. And at that, while it uses concurrency like Haskel or Erlang, it doesn't appear to be at all pure-functional, or maybe it is but the design is already burping with an "isolated" keyword that warns the compiler to forbid modification of static vars within the function body.
Re:WTF is a "Concurrent Programming Language"? (Score:2, Interesting)
Because the business of computer languages has nothing to do with technical merit or academic proof. Languages today are nothing more than brands that are sold (and resold) to programmers.
The language to get most mindshare wins.
Re:WTF is a "Concurrent Programming Language"? (Score:4, Interesting)
Because the PHBs like a single vendor. Nothing confuses them more than saying, "We're getting the OS from Microsoft, the database from Oracle, the language from Sun and the hardware from Dell." The less companies in this list, the better, regardless of the merits of technology.
This is not true of every Fortune 500 shop I've ever worked in. Most PHBs never met a platform they didn't like. Hell, at my current gig, we have mainframe, AS/400, Solaris, HP-UX, AIX, Linux (2 distros!), Windows, Oracle, DB/2, Sybase, MySQL, JBoss, Websphere, Cisco, Foundry, etc.
Lots of big shops are heterogenous to the point of pathology.
Re:So, where did they steal this idea from? (Score:4, Interesting)
I'm not affiliated, but I do own their dev kit
Re:WTF is a "Concurrent Programming Language"? (Score:3, Interesting)
it's a programming language which splits up multiple threads of execution into different processes instead of threads.
That would be an incorrect definition of concurrent programming language. The actual implementation of executing multiple things isn't defined. There are many flaws in your "history lesson". OS/2 blew chunks when compared to NT at the time, and the SDK for OS/2 was a major pain to get anything working.
COM wasn't made after CORBA, it predated it, and it was developed by IBM. Much of CORBA was even based on COM, COM is mentioned all over the place in the original CORBA documentation. COM was licensed to Microsoft, which is why there was a sudden shift away from ActiveX controls and the like to the new .NET platform 8 years ago (license was expiring). I was never a huge fan of MFC, as it's design (document centric) didn't fit many of my needs. And as for the "nonstandard C" compilers, that's quite a joke as noone had a standard C compiler if it was worth anything. ANSI C was retarded and didn't support much of anything beyond hello world back then. Even your beloved OS/2's C compiler was mostly proprietary in nature. K&R C was even more popular and powerful and I would argue was a much better C standard than ANSI C at least at the time.
As for windows not supporting threads, I'm not sure where you got that from as most of my work back then all involved multi-threaded applications, and supported everything from NT 3.1 and up.
Re:WTF is a "Concurrent Programming Language"? (Score:3, Interesting)
Next question asked is WHY has Microsoft have to invent one when there are others available already?
As with most other Microsoft languages - because, while this is a research project currently, it may well become productized in 5 years, and at that point they'll want something that looks familiar, at least syntactically, to C# programmers, so as to not scare them away. It's not a new thing, either - Spec# [wikipedia.org] is a similar research language based on C#, but for Design by Contract (and bits of DbC based on it will be in .NET 4.0, though as library features, and not in the language proper). C-omega [wikipedia.org] was another project in the same vein that provided basis for LINQ.
On a side note, the major (and finally fully realized in the upcoming 4.0) benefit of using .NET in the first place is that you get first-class interop between very different languages. In 4.0, you can define an interface in C#, and implement it in IronPython. IronPython code can furthermore call some pure functional F# code, create some (Python, dynamic) object encapsulating the result, and return it to C# again, which will be able call some methods on that object using late binding / duck typing. It's one step above the traditional approach using FFI for C-style APIs that's common in Unix land for mixing C++/Java/ML/Python code, since your API boundaries use higher-level primitives (objects, typesafe collections, tuples etc - rather than structs and pointers).
However, this necessitates the "embrace and extend" for all languages involved, to provide that seamless interop. For example, you can still use plain Python code with IronPython, but if you want to use the language interop capabilities, you'll have to use some IronPython-specific stuff. On the other hand, F# is designed from ground up to have that interop built into the language, which is why it differs on many points from Objective CAML (from which it is derived).
Re:The good points of a concurrent language (Score:3, Interesting)
My understanding is that most functions in the .NET libraries are not reentrant.
Most functions in the .NET libraries are perfectly reentrant in the classic definition, if you consider the implicit receiver argument ('this') a proper argument. Most non-static functions in .NET classes are not thread-safe in a sense that two threads cannot call the same function on the same object concurrently (or, more often, any two functions on the same object concurrently) - this is generally the same as what you can see in Java or C++. I don't see this as a problem, since it's unlikely that you'll want to, say, concurrently draw several thousand buttons on a window and handle their input events, or concurrently write to the same file from several threads using a single handle. Even in a concurrent application, most often you'll use .NET objects in isolation of a single thread, to perform whatever task it needs to perform.
Can you identify specific scenarios where limitations of .NET class libraries with respect to concurrency block or hinder some specific concurrency scenario?
When it comes to your own .NET classes, they are, of course, as concurrent as you make them to be. If you code them in F#, you'll be dealing with immutable data structures by default (F# lists and maps are immutable, as is traditional in functional languages, even though they implement all the standard System.Collections.Generic interfaces such as IList and IDictionary for interop), and your own structures and classes will also be immutable by default - F# requires any mutable variables and fields to be explicitly declared using the "mutable" modifier.
Looking into the future, .NET 4.0, which will include a bunch of stuff specifically for parallel & concurrent computations [wikipedia.org], also comes with several new collection classes that are specifically designed for concurrent use, such as ConcurrentQueue and ConcurrentStack.