Linked by Thom Holwerda on Thu 14th May 2009 09:43 UTC
General Development 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."
Thread beginning with comment 363644
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Ugly
by google_ninja on Thu 14th May 2009 14:33 UTC in reply to "Ugly"
google_ninja
Member since:
2006-02-05

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.


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.

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.


Examples? I think being able to declare a type to be late bound in a statically typed language to be exceedingly cool.

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.


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

Reply Parent Score: 2

RE[2]: Ugly
by tuttle on Thu 14th May 2009 16:21 in reply to "RE: Ugly"
tuttle Member since:
2006-03-01

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


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

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.

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


Examples? I think being able to declare a type to be late bound in a statically typed language to be exceedingly cool.
"

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.


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


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

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 :-)

Reply Parent Score: 2

RE[3]: Ugly
by google_ninja on Thu 14th May 2009 19:01 in reply to "RE[2]: Ugly"
google_ninja Member since:
2006-02-05

I think that dynamic is an atrocity


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

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.


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.

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


Dumb, I agree. This is fundamental language design though, not syntactical sugar.


-There are extension methods, yet no extension properties. Why?


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.


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


Maybe im misunderstanding you, but this

public void test()
{
var s = "hi";
test2(s);
}

private void test2(string s)
{
Console.WriteLine(s);
}
works fine.

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


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; }

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


That one is dumb too, but again, a core design decision rather then a language add on.

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 :-)


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

Reply Parent Score: 2