Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Microsoft Programming IT Technology

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 discussion has been archived. No new comments can be posted.

Microsoft Releases New Concurrent Programming Language

Comments Filter:
  • by Z00L00K ( 682162 ) on Monday May 11, 2009 @12:31PM (#27908623) Homepage Journal

    Next question asked is WHY has Microsoft have to invent one when there are others available already?

    Probably the answer is "Because they can" and they see a business in locking in people into their environment.

  • by Alethes ( 533985 ) on Monday May 11, 2009 @12:36PM (#27908703)

    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.

  • by theArtificial ( 613980 ) on Monday May 11, 2009 @12:46PM (#27908879)
    Synergy. "With our development suite you have tools that specialise in X Y Z allowing you to do A B C. Give us your money."

    I thought the general consensus on this site especially with regards to open source software was that choice is a good thing? I'm sure if they used an existing language Microsoft would employ an embrace and extend strategy that would have developers/purists up in arms.
  • by Anonymous Coward on Monday May 11, 2009 @12:50PM (#27908955)

    I think part of the answer is here. . .

    "Microsoft has not committed to shipping Axum since it is still in an incubation phase of development so feedback from developers is certainly welcome."

    In other words - Microsoft wants other people, who are not being payed by MS, to suggest improvements and ideas, which MS can then patent and incorporate into their proprietary product, which they can lock people into.

    I mean, to be fair, there could potentially be room for a 'better' concurrent programming language than any of the existing ones currently available. I just don't like the idea of 'open' proprietary software development - give us your ideas for free so we can profit from them and prevent anyone else from using them.

  • by molarmass192 ( 608071 ) on Monday May 11, 2009 @12:51PM (#27908973) Homepage Journal
    Oh, you mean like C, C++, and BASIC? The reality is the most popular languages for MS platforms were not MS inventions.
  • by chthon ( 580889 ) on Monday May 11, 2009 @12:52PM (#27909001) Journal

    The Actors Model is around 40 years old. Scheme was based upon it. Lisp have already shown in the eighties to be good at concurrent programming. Just NIH syndrome.

  • by mmkkbb ( 816035 ) on Monday May 11, 2009 @12:55PM (#27909039) Homepage Journal

    Well, it does use the same concurrency model as Erlang, but Erlang has no concept of classes. Perhaps Scala, which I know little about except that it runs on the JVM and is supposedly better at concurrency.

  • Re:R&D (Score:4, Insightful)

    by odourpreventer ( 898853 ) on Monday May 11, 2009 @01:02PM (#27909181)

    > 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.

  • by ClosedSource ( 238333 ) on Monday May 11, 2009 @01:03PM (#27909195)

    I don't know about "devlopers", but real developers use whatever OS they need to get the job done.

  • by Burkin ( 1534829 ) on Monday May 11, 2009 @01:04PM (#27909233)

    Next question asked is WHY has Microsoft have to invent one when there are others available already?

    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.

  • Wanted:
    Senior Software Engineer
    Windows Platforms
    MFC C++ - 10 Years
    C# - 5 years
    Axum - 5 years

    You *know* it's going to happen.

  • by Tetsujin ( 103070 ) on Monday May 11, 2009 @01:09PM (#27909301) Homepage Journal

    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.

  • Was C# Not Enough? (Score:4, Insightful)

    by CodeBuster ( 516420 ) on Monday May 11, 2009 @01:18PM (#27909433)
    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) [microsoft.com], 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)?
  • by moderatorrater ( 1095745 ) on Monday May 11, 2009 @01:26PM (#27909557)

    Probably the answer is "Because they can" and they see a business in locking in people into their environment.

    Because they want to add to the .NET suite with a forward-thinking language. Like it or not, .NET is big for Microsoft, and giving people who use it more tools will only help their position. How you feel about that, of course, depends on how you feel about .NET and Microsoft.

  • by elnyka ( 803306 ) on Monday May 11, 2009 @01:35PM (#27909711)
    And you know this because your vast professional experience tells you so? Or are you still in school, or programming in some obscure niche?

    Last time I checked real developers get paid to solve real-world problems for real-world customers, not to use some company's computing facilities as dogmatic playing grounds.

    Be it for writing a web page for a company or doing some complicated shit, you use the tools that get the job done, and to program against the platform that is being used by the customer whose paying your fucking paycheck.

    I use a Windows XP workstation to do my coding, design and use tools like Rose, Clearcase and a requirement tracking tool, with JBuilder on one monitor, and VI (and cygwin) in another monitor.

    Then I used it to compile the stuff that is going to be deployed in a heterogeneous, distributed environment that runs mostly in Linux.

    At the end of the day, what we care for is the technical challenge and the HUMAN development environment, and most important of all, the knowledge that you are producing something as requested by our employers.

    That is, we are earning the bread instead of being uselessly dogmatic.

    Thank God that I grew up the naive college student, anti-M$ stage long time ago. I suggest you do, too.

    Real professionals use what they need to do to get the job done at a customer's behest.

    Little punks in geek niches use whatever platform they like best to feel good at themselves while pointing the finger at others (while not producing anything.)

  • by OrangeTide ( 124937 ) on Monday May 11, 2009 @01:53PM (#27910017) Homepage Journal

    "but Erlang has no concept of classes."

    One of Erlang's strengths.

  • by Estanislao Martínez ( 203477 ) on Monday May 11, 2009 @02:00PM (#27910125) Homepage

    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.

  • by mmkkbb ( 816035 ) on Monday May 11, 2009 @02:01PM (#27910157) Homepage Journal

    Well, I wouldn't say that classes are bad in and of themselves, but trying to bolt classes onto Erlang certainly wouldn't make sense.

  • Next question asked is WHY has Microsoft have to invent one when there are others available already?

    I'd suggest several major reasons:
    1. Integration with the .NET Environment.
    2. Integration with the Visual Studio IDE.
    3. Maximise control of the style of the language, featureset and its future direction.

    If you check the wikipedia page the parent linked to, there are already stacks of concurrent programming languages available, it's not like there's some universal standard concurrency language out there Microsoft is trying to displace. That, and the above points, particularly with respect to .NET, does give it a unique feature that distinguishes it from other concurrent languages (even if you loathe .NET, it still separates it from the rest).

    Probably the answer is "Because they can" and they see a business in locking in people into their environment.

    Yes and no. You can take the whole lock-in argument (not entirely unreasonably), but you can also take the argument that for those who don't actually have a need to develop something for multiple platforms, a language fundamentally focused on a Windows-centric design with related tools is probably a huge positive. Why code in a language with a crap toolset/IDE (assuming there is one) and various other potential problems when MS offers one that plugs into .NET, VS, and is guaranteed to work great on Windows out of the box? That, and if you're already familiar with the above, the migration path I suspect is quite easy.

    Of course, this being .NET based, Mono may or may not support some of this stuff. No idea.

  • by Grishnakh ( 216268 ) on Monday May 11, 2009 @03:20PM (#27911377)

    Visual BASIC is so unlike the BASICs I learned in the 80s on the Commodore, Apple, and other small computers that it might as well be a different language.

    Also, MS isn't pushing developers to use C or C++ any more, they're pushing them to use C# and .NET, which are MS inventions.

  • by BasharTeg ( 71923 ) on Monday May 11, 2009 @06:58PM (#27914921) Homepage

    Next question asked is WHY has Microsoft have to invent one when there are others available already?

    Yes, clearly the concurrent programming language problem is all wrapped up and doesn't need any further innovations or development.

    It's ridiculous how hostile people are to what happen to be really cool Microsoft research projects. I know it doesn't mesh well with the idea that Microsoft steals everything and invents nothing but if you're more interested in Computer Science rather than pushing an anti-Microsoft agenda, you'd see that some of their ideas are really cool and tend to spawn related ideas that help advance the industry as a whole.

    Microsoft has put *significant* efforts into developing *multiple* concurrent programming languages and libraries because it is an area that definitely needs new development and new innovations to meet the challenge of development in the manycore era.

    Funny I didn't see all this negativity when Apple started talking about "Grand Central". As if that system is going to be useful on any platform other than OSX.

  • by zuperduperman ( 1206922 ) on Monday May 11, 2009 @07:56PM (#27915655)

    It's not about threading - all the features you describe relate to dealing with concurrency in a small scale. New concurrent languages are targeted at algorithms that use concurrency as a fundamental building block - a language construct, if you like - which let you use completely different algorithms to what you would use otherwise.

    Totally contrived example: imagine you want to count the number of upper case characters in a large string. You could zip through it in a loop in a single thread. But that would only use a single CPU on a single node. Instead, break it into a thousand parts and create concurrent jobs to compute the number of upper case characters in each one, then sum them all together at the end. Doing that would take some serious thought to do correctly using threads, and it would be very inefficient. These new concurrent languages are built with primitives that allow you to do this kind of thing quickly and safely and in a scalable way to boot.

  • by Anpheus ( 908711 ) on Monday May 11, 2009 @08:42PM (#27916067)

    If you subscribe to certain philosophies, all ideas always existed, we simply discovered them.

    Regardless of your adherence to such a philosophy, you have to admit that it doesn't really matter who created the idea, but who first successfully implemented it.

    It's not like the people at Microsoft are somehow less capable because 100% of their ideas are 100% original, rather, they still had to have the intelligence to code it, document it, test it, etc.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...