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."
Permalink for comment 363686
To read all comments associated with this story, please click here.
RE[3]: Ugly
by google_ninja on Thu 14th May 2009 19:01 UTC 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