Microsoft has come one step closer to delivering a parallel programming language to developers. On May 8, Microsoft made Axum, the company’s foray into parallel programming, available on its MSDN DevLabs portal. Axum is a .NET language for building parallel applications. According to a Microsoft description, Axum “is a language that builds upon the architecture of the Web and principles of isolation, actors and message-passing to increase application safety, responsiveness, scalability and developer productivity.”
Can’t click on the link?
Or you did that on purpose? :o.
Axum, F, C# … when will Microsoft get over their NIH mindset and learn to cooperate ?
The world does not need more programming languages. The tower of Babel has already been built.
I disagree. Choice is always a good thing.
For me C# is the most beautiful language out there. It would be a shame if Microsoft just went along with Java. (I like Java less than C#, but I still like it. I really do not like the Java framework and runtime, though.)
Of course, that’s just my opinion, but the point is, if it’s out there someone will like it and use it. That’s why Microsoft should continue developing its own technologies. Those technologies people like will be adopted even outside of MS ecosystem. Remember Mono?
If Axum encapsulate the concurrency principals in an elegant, easy to understand and productive manner, the ideas will jump over to other languages over time. Thus, everyone will benefit from it.
If it fails, only Microsoft loses.
Hi,
Hehe – “many eyes make bugs shallow” (but only if those eyes aren’t glazed over in a haze of utter confusion).
Let’s invent 1 million languages, so that the chance of one programmer being able to maintain code written by another programmer is almost zero.
If choice is a good thing, then let’s also invent 1 million different web standards, 1 million different alternatives to TCP/IP, 1 million different keyboard layouts and 1 million different “optic disk” formats.
-Brendan
Without new languages (or standards) there is no innovation.
No language is perfect. Ultimately, industry selects the best (or the best promoted) ones. Others become noise, but they were not created in vain, because if they introduced noteworthy ideas and concepts their legacy remains.
Who really knows Ada? Very few I guess, but does that mean that Ada should have never been created? Of course, not!
Edited 2009-05-17 16:00 UTC
While I do see your point, I also don’t see the harm either.
As this language is a .net language, one would assume that it compiles to byte code like C# does. so there’s no additional installs / libraries needed for the customers machin thus the only person affected by the differences would be teh developer which choses which language to develop in.
as for the examples given, I can’t speak for F, but C# had a definite perpose that stands out enough to warrent it’s own language. If anything, I see Visual Basic.net as the pointless addition. If I wanted to enter that much syntax then I’d code in C++. But that’s just me personally – others might sware by VB.net.
I disagree! The world does need new programming languages to deal with massively parallel systems.
But microsoft apparently does not have what it takes to provide these languages. Except for haskell, which is developed by simon peyton jones at microsoft research.
But apparently there is some kind of internal firewall that prevents stuff that is being developed in microsoft research to be used productively… 🙁
Sorry for responding to each of your posts with disagreements like this, but this is the sort of thing I love to talk about 😉
Funny, I consider haskell to be a pretty academic language. I would say Erlang is the first language that is both appropriate for massive concurrence, and also practical.
F# came from MSR, and it is going to ship with the next version of visual studio. Basically OCaml for the CLR.
No problem. I love discussions about computer languages. This is the kind of stuff I would like to see on the main page of OSNews. But at least it is on page 2.
F# is a bastardized version of OCaml, just like C++/CLR is a bastardized version of C++ for the CLR.
If the CLR is as language-agnostic as microsoft claims, why can’t they just do a straight port of OCaml to the CLR?
What a biased view!
One of the greatest things about .NET is language independency.
Whatever language you like to use, it will compile into MSIL and work seamlessly with stuff from other people. That’s a terrific improvement, expecially in eco-systems where people might come from different experiences and workplaces.
So I can happen to prefer VB.NET and be able to use that without:
1) any need to know what others will use to interface with my code;
2) consider that using an old-style language like VB could affect my performance.
Multiply this by all languages we have and think if that’s not useful. And if you think that letting developers use whatever language they prefer is a bad thing, consider how productive you could be using your language of choice when compared to forcing people to uniform into one language only.
Plus, compiling from different sources to MSIL is great for OSS and distributed developers.
And about Axum: ask people developing games if they wouldn’t worship anyone providing an easy way to build concurrent code…
Why? I think it is wonderful and I hope that maybe Microsoft will relinquish any claims of royalties on .NET implementations – I can understand the need for defensive patents but it would be great if Microsoft worked with the open source community thus leaving the ‘value’ being derived not from the framework but the implementation of developer tools which make it easier to implement.
Haven’t gotten that deep into it yet, but axum is basically Erlang with a c-like syntax rather then a prolog-like syntax. I like the look of the code, definately going to play with it a bit more.
Don’t do it. If you want to play with erlang-style concurrency in a general purpose language, take a look at scala actors.
I am a language geek, I enjoy learning languages if I find them interesting. If I wanted to do message passing with an actor model for something serious, i would probably just do it in erlang.
Erlang is not really a general purpose language. It is a special purpose language designed for high availability.
If you want to do some (single-threaded) calculations it can be quite slow.
Nope. Sadly, they didn’t even look at Erlang before they started. This means that they’ve actually implemented all the things that the Erlang guys looked at – then threw away!
It’s garbage.
Microsoft does not have any hygiene when it comes to introducing new language features. Whenever they think some syntax candy is a good idea, they just add it to the language.
Just look at the mess that is C# 4.0. C# started as a decent programming language with some advantages over java. Nowadays it is just a grab bag of unorthogonal syntax features that do not work seamlessly with each other.
After less than 10 years, it contains more cruft than C++. And don’t get me started about the libraries.
If you want to see how to do message-passing based concurrency beautifully without having to introduce a dozen new language constructs, take a look at scala actors. They are implemented as a library, yet they are very concise to use.
Most language features are around bringing down the verbosity of the language, which IMO is the only way a static language can hope to compete in the long run with dynamic languages.
Examples? I think being able to declare a type to be late bound in a statically typed language to be exceedingly cool.
I find it odd that you criticize c# for being a “grab bag of language features”, but you like scala. Its not that I dont like scala or anything (because I do, a lot), but if you were to say something bad about it, it is that the complexity is too high due to the amount of language features it has.
Also, C# is Anders baby, and designed for general purpose, real world development. Axum is coming out of MSR, and is designed for a much smaller domain of problems, by a group of very different people.
Edited 2009-05-14 14:43 UTC
There are areas where statically typed code will always be superior. But in general I agree that verbosity should be reduced. Static typing does not have to mean lots of boilerplate code.
But it has to be done right. Adding language features that have only a limited application domain is dangerous for a general purpose language like C#. I think making the syntax of the language extensible like lisp, scala, boo, nemerle and various other languages do is the better, more scalable approach.
I think that dynamic is an atrocity. But that is just one example. My biggest complaint is that most recent (since 2.0) extensions are non-orthogonal.
-For example, generics do work with only a small subset of the language features. You can not use static methods, operators or constructors with parameters from generics. This makes generics basically useless for more complex applications than collections.
-There are various things that behave like a function and are implemented as functions on a MSIL level: static methods, instance methods, constructors, property getters, property setters. But only two of those (static and instance methods) are compatible with delegates. To create a delegate pointing to one of the other quasi-functions (constructors, properties), you have to create an adapter.
-There are extension methods, yet no extension properties. Why?
-Various new language features discourage factoring repetitive code into methods. For example the result of an implicitly generated type can not be passed to a method other than as an object since its type does not have a type name.
-The new property and collection initializer syntax encourages writing mutable classes. As do many other new language features. And we all know that the single most important thing when doing multithreaded programming is to use immutable objects as much as possible.
-Scala and other modern languages generate equality and hashcode functions for immutable objects. In C# you have to do all this yourself. And not even the collection classes override equality and hashcode.
But most language features of scala are based on a very small core. And the type system is much more refined. Just leaving out static methods makes everything so much nicer. (I hope that they will remove constructors next 🙂
Why? It makes duck typing easy in a static language. I don’t think it is something you would want to use all the time, but there are certain types of situations where you end up basically emulating it with tons of reflection code. Being able to say “this is late bound” makes that a lot less messy.
Also, it allows for interop with dynamic languages. (AFAIK) JVM languages that interop only goes one way. Dynamic will allow you to consume ruby and python libraries from c#.
I use generics all the time. My problem with them has to do with the generic invariance. (If you instantiate a Foo<T> as Foo<string>, but try to use it as Foo<object>, you cant in C# 3) Probably my favorite feature of 4.0 is giving syntax to explicitly declare covariance or contravariance for generics.
Dumb, I agree. This is fundamental language design though, not syntactical sugar.
Because MS wanted to be as conservative as possible with the whole monkey patching thing. Even with all the restrictions, people were still freaking out about the potentials for abuse.
Maybe im misunderstanding you, but this
public void test()
{
var s = “hi”;
test2(s);
}
private void test2(string s)
{
Console.WriteLine(s);
}
works fine.
That is a very functional way of looking at things.
string prop { get; set; }
is just shorthand for
string _prop;
string prop {
get { return _prop; }
set { _prop = value; }
}
also, there is nothing stopping you from doing this
string prop { get; private set; }
That one is dumb too, but again, a core design decision rather then a language add on.
Honestly, I like scala more then c# too. I don’t think C# is a bad language though, and I am not sure that there really is a need for one language to do all things in anymore. What we need is a good interop story, and languages that focus on certain types of problem domains. A good example would be something like erlang (for massive concurrence), or something like JavaFX (which is only appropriate for UIs).
But I don’t think that x.Y(1,2) is so vastly superior to x.Invoke(“Y”,1,2) to deserve its own syntax. And you know that it will be abused all over the place for completely different stuff. As an example, see this ugly and slow hack to use operators for generic types:
http://blogs.msdn.com/lucabol/archive/2009/02/05/simulating-inumeri…
This was linked from the visual studio start page! The correct way to handle this is to extend the constraint syntax for generics:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp…
or introduce appropriate interfaces:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp…
But now that you can do this kludge, they will never fix the fundamental problem!
If you see C# as a “glue” language, interop is extremely important. But if you see it as a core language for implementing algorithms, there are about a thousand things that are more important than dynamic.
Don’t get your hopes up. AFAIK variance annotations will only work for interfaces. Another halfbaked extension. There is no reason whatsoever not to allow covariant return types for all classes. java does it, c++ does it etc. And it does not violate the inheritance contract.
If you are writing large class hierarchies, this lack of covariance can be a large PITA. This is another example of a fundamental problem that microsoft ignores while adding fluff.
Generics are still very limited when trying to do calculations on generic types. Try to write a generic function that calculates the average and standard deviation of an enumerable of numeric types to see what I mean.
There are some kludges like calculator classes to work around the problems, but they had 4 years to come up with a proper solution and did nothing at all!
You could provide syntax to solve this problem. For example you could allow casting from a constructor for type T to a Func returning a T.
Another very dumb thing: why can a struct not have a default constructor? That is a CLR limitation that makes implementing proper C++ on the CLR almost impossible.
Then they should not have done extension anything in the first place. Extension methods have a huge potential for abuse. The real reason there are no extension properties is probably that you do not need them to implement LINQ. But I vastly prefer for expressions in scala to linq.
No, I meant something like
var x=new { Name=”John”, Age=12 };
Try to write a method that prints the name of x without using reflection.
The same is true for the type of most complex LINQ expressions. You do not know it at compile time, so you have to process it in place.
It is also a very correct way of looking at things. I think there is a consensus in the industry that shared mutable state is absolutely evil when doing concurrent programming. That is why erlang is so powerful: shared nothing concurrency! Yet microsoft adds more and more language features that encourage creating mutable objects for no reason at all. Combine mutable objects with PLINQ, and you are almost guaranteed to get lots of extremely hard to find race conditions and concurrency bugs.
But then I can not use initializer expressions like
new Bla() { prop=”blub” };
For a supposed multiparadigm language, C# always pushes you in the direction of “mutable everything”.
That one is dumb too, but again, a core design decision rather then a language add on.
[/q]
Having some mechanism (attribute or something) to automatically generate the fundamental functions such as Equals, GetHashCode and ToString would be a) easy and b) orders of magnitude more useful than every new language feature in C# 4.0.
It used to be a decent language. That is why what they are doing with it is so sad…
But what if you need both massive concurrency and high performance? You need a general purpose language. There is a reason all games and large applications are written in C++. It is ugly as hell, but it is multiparadigm and fast.
C# could in theory be used for this despite all the weaknesses I mentioned. But there are some very fundamental limitations of the CLR that prevent this:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp…
and yet dozens of new programming languages continue to pop up and small clicks clap their hands ins devotion.
God forbid that one actually develop skill and insight in software development before leaping onto a language bandwagon …
Perhaps the world would be using Lisp/Dylan, SmallTalk and (Obj-)C instead of Visual Basic, Java and C(++) …
Ada has support for concurrency programming through its task mechanism since its birth on the 1980s. With the latest Ada 2005 standard and free compiler from GCC, you don’t need to wait for Microsoft.