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."
Now you know.
in your channel class then you can communicate with agent instances that implement that channel quite easily like:
If the data can't be sent over a channel you use (and this word should sound familiar to you web guys) a schema.
From there on out it gets a lot more complicated with state and domain communications/sharing. It looks better thought out than most of Microsoft's libraries I've been forced to use but--as always--new languages need many releases before they are production worthy. A noble effort to simplify concurrency. With some really slick operator coding and overloading, you could probably get a similar thing going in Java or C++.
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.
My work here is dung.
I already imagine job offer
- Minimum 5 years experience with Axum
Gesundheit!
The windows version works great, but Axum on Linux isn't ready for prime time, yet. However, Axum is powerful enough that you should probably change your platform to permit its use, so if you have a new app being developed, I'd force your engineers to use Axum and develop it on windows.
And I know what I'm talking about because I'm an IT manager at a Fortune 500 company.
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.)
Ok, so C# is a pretty good language. (Despite its severe limitations. Seriously, thank god for C# if you've had to work with VB at all. Ugh!) Of course most of it they stole from Java, with an attempt to add refinements here and there. (Possible nefarious motives aside...)
So from what language did this one come from? Erlang?
Or did Microsoft actually create something relatively unique this time?
The current version implements Vin Diesel and Paris Hilton.
Chortle.
>> Axum does not have capabilities to define classes, but as it runs on the .NET platform, Axum can use classes made with C#.
Why is it that Microsoft persist in vomiting up quick/crappy/hacky workarounds rather than solid solutions? and how is it that the people with the biggest blind-spot about technology and how bad Microsoft products are, are always in senior management of tech companies?
While I am actual surprised that C# caught on
It's Java without a number of the Java hassles. Why would you be surprised?
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
The c# syntax is a real advantage over vb.net.
Do you even lift?
These aren't the 'roids you're looking for.
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.
> I haven't seen may apps that properly use OO
True, but it's very nice for program libraries - boost, wxWidgets, Qt, etc (yes I'm a C++ programmer) - where people who know what they're doing have already done the difficult stuff for the rest of us.
Adventure, Romance, MAD SCIENCE!
previously known as Maestro and based on the actor model
Somebody has their performance arts mixed up
Wanted:
Senior Software Engineer
Windows Platforms
MFC C++ - 10 Years
C# - 5 years
Axum - 5 years
You *know* it's going to happen.
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.)
Concurrent programming is becoming increasingly important for any kind of high-performance project. This doesn't necessarily mean one needs a "concurrent programming language" to do it - but whatever the chosen mechanism, the goal is the same - write a program that uses all cores effectively. One way or another, professional programmers are going to need to 'get' concurrency in the coming years.
The benefit of a language that provides parallelization as a basic assumption is that the language itself can provide infrastructure (for message-passing, task-scheduling, and so on) useful to the task. Such a language encourages programmers to think about problems in terms of how they can be parallelized, but leaves the compiler or the runtime engine free to make decisions about how the parallelization is to occur.
Another benefit of such a language is that a language that takes certain ideas as base assumptions can help guide the programmer's approach to a solution. This can involve a significant learning curve for the programmer (see, for instance, Prolog or various functional languages...) but it can help programmers to achieve a new way of solving their problems: in this case, one that is rather well suited to the current needs of high-performance CPUs.
The challenge with synchronization in Axum, presumably, is that it's possible to write code that will run in the engine that won't conform to the rules for an "actor" - that it will perform some non-thread-safe access to a file, or that it will otherwise do something that won't be safe when run in parallel. From that perspective it's no different from (almost) any other language - as you say, it's still possible to screw up. What it does provide, however, are guidelines and framework to help keep you from screwing up.
Bow-ties are cool.
Every programming language has its downsides. Race conditions -are- preventable, especially with a system to slow down fast code blocks or speeding up slow code blocks.
The easiest way (in my experience, but I'm an amateur programmer) to program concurrently is to synchronize the agent's I/O, and where it becomes hardware dependent, either queue it or prioritize it.
I can see that this is going to be a popular programming language for 4+ processor systems... but they need the right development framework to make it successful.
An agent model makes sense (used appropriately); and it would go a long ways toward making a logical development system).
I would like to see the day when logical development is easily visual and self-adaptable (not the pencil and paper kind of visual), and this is a step in the right direction.
There are no perfect answers, only the right questions. More questions at http://foresightandhindsight.blogspot.com/
Seriously this looks an awful lot like Microsoft doing MPI. In which case they should just drive a railroad spike through both testicles, or ovaries.
Did Glenn Beck rape and kill a girl in 1990? gb1990.com
The thread control facilities available in the C# language are already quite extensive and include pretty much every known way to control concurrency presently used in software: mutexes, semaphores, locks, etc...they are all there. For example, the following paper (PDF link), written by Andrew Birrell of Microsoft Research, covers all the basics and explains the various options in C#. If they wanted more robust threading frameworks then why not simply add the relevant classes to the .NET Framework class library (i.e. in System.Threading)?
link : http://www.cs.umd.edu/projects/hpsl/ResearchAreas/DataCutter.htm .NET...
except data cutter does not rely on
While I am actual surprised that C# caught on
Really? Whenever I mention C# around programmers they can't stop telling me how much they love it. It's almost creepy, especially considering our company uses a completely open source production environment.
I haven't seen may apps that properly use OO as to do so requires management oversight, in which usually doen't know about OO anyways.
I've seen a lot of apps that properly use OO, but they were all written within the past 3 or so years. Anything older than that doesn't use OO or uses it badly. It seems like legacy code (the great bane of all programmers) keeps most projects from being strictly OO, and most programmers didn't master it until a few years ago anyway. Of course, I'm in web development, so YMMV.
Because you would whine and bitch about them "stealing" the language if they were to co-opt another concurrent programming language to run in their .NET environment.
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.
Now it is true that C# was taken lock, stock and barrel from Java when the Microsoft embrace and extend strategy was slapped down there (read the memos), but no-one ever complained about other languages being added in just as no-one accuses Java of "stealing" all the languages that VM supports now. So using an existing concurrent language would make a lot of sense and annoy no-one.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I don't have to make up reasons to not use this (which I usually would have to, because I hate Microsoft...)
what is it about object-orientation that microsoft doesn't get? read MSDN sourcecodes - it's like a trip to 1960...
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
There's a good chance that those older projects were "correctly" written with regards to OO principles. Unfortunately, we have yet to discover the programming methodology that corrects for the standard programmer response to a fix/addition on an aging project: "Ugh. I'll just hack this in. Nobody is going to know, and if they find out, they won't say anything for fear of being charged with doing all the work I'm avoiding."
feldicus
can it do Concurrent BSOD?
I don't think its C# they love as much as it is the .NET framework as combined with Visual Studio.
It is awesome to program with and for.... Thats all there is to it.
"His name was James Damore."
You're making the mistake that concurrency is the same thing as parallelism. It is not. Concurrency is when a program is written in such a way that the order of execution of tasks is highly underspecified; parallelism is the use of multiple execution units to execute concurrent code.
Concurrency isn't just for performance; concurrency is just as much for writing software that can do many things at once. For example, one needs concurrency to have client applications that respond to the user with very low latency while doing some other work in the background. In this case, in fact, the software isn't trying to perform its heavy computations in the absolute minimum time; it's OK to slow down the heavy computation somewhat in order to reduce user interface latency. Have you ever used one of those applications where the whole UI hangs (e.g., won't even draw) while the application does some action, like connecting to a server? That's a failure to provide concurrency.
Contrary to common wisom, the introduction of multicore processors didn't increase our need for good tools for concurrent programming, because we've needed such tools since way before for user interaction. The tools that conventional languages provide for threading and synchronization are too hard to use, leading programmers to introduce far less concurrency into the software than they otherwise could. Also, conventional threads are much too heavyweight for an application to create thousands of them.
Are you adequate?
and don't forget the good concurrent stuff - OpenMP for example:
#pragma parallel for
// do ten iterations in parallel.
for (i=0; i < 10; i++)
{
}
so easy! Add Intel's TBB and you have seriously easy and powerful concurrent programming. Without having to reengineer to MS-Java++.
Virtually every field of specialization has its own jargon. Usually, the idea is to use a specific word for a narrow definition to speed communication and reduce the chance of misinterpretation. Beyond specialty jargon, every software company has some unique jargon, but unless you work there, you're unlikely to see it. Microsoft is just higher profile.
Of course, sometimes the jargon goes wrong. You can see some appalling examples at Raymond Chen's blog. Just search for "Microspeak" posts.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Why don't they just add this stuff to C# like they do with everything else? Keep C# as the kitchen sink language.
Well it is a case with OO espectially for large projects you need to be sure that the wheel isn't reinvented. For large projects with hundreds of developers and thousands of classes it is really easy for a wheel to be reinvented where they could have just extended or just use an existing class. You need management layer (Who sees the big picture) to assure that the employees are not reinventing the wheel over and over again.
Even as a professional for a large projects (in which OO was suppose to build) you need a management layer to insure the rest of the people are just as professional and information is properly distributed.
Management doesn't always mean a pointy hair boss but a Sr. Developer who has a big picture view and enough authority to tell someone to stop doing it that way and do it differently.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You'd need a coherent architecture for a start. State models coming out yer ears. And preferably tool support. I think if you attempt to hack anything more than trivial in this then you're asking for trouble.
The synchronous Ada rendezvous model is looking more and more like a stroke of genius.
Sig pending!
Is the language named after Axum, Ethiopia and its famous obelisks?
There is OR concurrency where multiple independent evaluations provide alternatives. This is otherwise known as relational programming. This subsumes not only the obvious relational databases, but also exception handling.
There are no others.
Seastead this.
I have to agree, VS is the best IDE out there, hands down. MS sure knows where to put its effort, make the best IDE and programmers will follow. And that leads to market domination by software library size.
I'm surprised after reading the spec and blog that a bunch of this seems to be re-inventing Objective-C and bits of concurrent object oriented C. http://portal.acm.org/citation.cfm?id=157352.157356
Not only that, but extensions to a language don't really foster supporting a new paradigm. http://www.codinghorror.com/blog/archives/000169.html
/\/\icro/\/\uncher
It'll be ready when it's ready.
In other words, when the samba guys wrest the specifications from microsoft, figure out what's broken with it, and reimplement it all properly.
I have been searching for a simple code example, but haven't been able to find one that doesn't involve me having to install f***ing Silverlight. Anyone having better luck?
Axum!
I guess it was quicker to type than "Fireumall".
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Frankly, #pragmas are ugly, and what if you want to parallelize operations on STL containers? How about a library solution using C++0x lambdas instead:
But, of course, it would require you to embrace "MS-Java++", and therefore automatically evil, right?
The Borg icon actually fits: Axum, aka Five of Twelve.
We already have Haskell, OCaml, Erlang and tons of other well-hung languages, who can do this, and already have the good stuff in it (meaning libraries like OpenGL, and/or support for embedded devices).
Any sufficiently advanced intelligence is indistinguishable from stupidity.
The c# syntax is a real advantage over vb.net.
--
[citation needed]
Your sig is apropos to your comment. Please enlighten us with the real advantages of C#'s syntax over VB.Net's. And no, familiarity doesn't count.
Celebrity worship is a poor substitute for Deity worship and costs more to boot.
How can we know when it will be ready?
Its concurrent. Start using it now, you don't need to wait until its ready. Anything unavailable will simply block until its released.
Doesn't "embrace and extend" usually mean that Microsoft keeps the technology name?
No - or at least that's irrelevant to the complaint.
The problem people have with Microsoft regarding "Embrace And Extend" is that they take a technology, add some feature(s) on, and that becomes the de-facto standard - that now requires Microsoft patent licensing to comply with fully. The name has much less to do with things than does Microsoft strangling out all other versions.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You don't try to retain workers out of consideration for them, you do it for the good of your company.
Hiring people is very expensive, so terminating someone should be vetted as carefully as hiring them. Without a good policy in place, a bad manager can run amok in a company.