Slashdot Mirror
Microsoft Releases New Concurrent Programming Language
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."
I see Microsoft is doing its best to help developers all over the world create race conditions. I wonder how many programmers there are who never really 'got' concurrency. Hopefully I'm not one of them. (And no, there is no programming language that can prevent you from screwing it up.)
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 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.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
The "channel" technique makes me think of Occam.
Goddamn, PDFs for language specification and programmer's guide? Thanks guys, I'll probably never need to search this stuff, or link to a specific section. Also, what the hell do you call this bracket style:
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.
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.
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.
Don't blame me, I voted for Baltar.
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.
Advice: on VPS providers
I think most concurrent languages have been derived at least in part from CSP, so they'll probably all 'feel' like occam; it's just occam got there first. Incidentally, if you already knew about occam, you might want to check out David May's (the guy behind Occam) new startup XMOS. :-)
I'm not affiliated, but I do own their dev kit
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.