exoteric said:

kaveh.shahbazian@gmail.com said:

*snip*

Scala was designed from the ground up with an object-functional theory in mind; C# is evolving towards functional style (with LINQ in particular) but even if we want C# to evolve I don't see C# ever becomming as smooth as Scala in this regard; it simply wasn't designed from the outset with this philosophy in mind.

 

On the other hand it's probably not completely unreasonable to say that Microsoft wanted the equivalent of Java, fixing its inherent mistakes and improving it in various ways and then grew the idea further into an infrastructure for "poly-linguistic execution" although essentially founded on C# semantics (feel free to correct me.)

 

This "Parameter-Level Interface Implementation" sounds to me like structural typing. That is indeed very desirable in some cases although you can emulate it with C# 4.0 dynamics - but I imagine loosing a lot of efficiency along the way.

 

It would probably be more desirable to have a higher-kinded type system a la Haskell (higher-order generics or higher-order parametric polymorphism?)

 

http://en.wikipedia.org/wiki/Type_polymorphism

 

There has been some rumours that Microsoft is working on one more language. I believe Joe Duffy has been involved in this and maybe Erik Meijer as well. It's probably going to be pretty hard to beat Scala in generality and elegance but I remember a video with Joe Duffy and Erik Meijer discussing Linear Type Systems as a means to control effects within a concurrent world - or something to that effect. Maybe we can get an update some time on the current thinking within the company of what features are being thought of next.

 

And of course we still have C# 5.0 on the horizon (and C# 4.0 is still not quite out of its eggshell yet.) I'm surprised you are disappointed at the C# roadmap because I haven't seen any roadmap so maybe you can point me to it - please!

 

Still, functional programming has arrived in C# and its best realized in LINQ which is still evolving, at least on the library level. Rx is the latest and greatest example. So its power and impact is still unfolding.

 

@exoteric  
Thanks for your time and your informative and precise reply.

i.
First on my disappointment about C# roadmap: I always look into ways not only to separate subsystems; but also abstracting bunch of aspects among all layers. First tool I like it here is syntactic extension mechanism and meta-programming and the second one - which I enjoy it's presence at XAML (especially WPF) - is a neat and clean (I am not sure if this name is descriptive enough) "aspect oriented" programming model. In XAML you can think of providers, services that are presented through providers, (I did not see this anywhere else, so maybe I am wrong) a very well tailored and tailor-able implementation of prototype-based OO model, templating every “thing/aspect” even up to the sky, binding/plumbing/validating state and much more; and why I think it should be more than handy in a programming language? An example could be a common task: Logging! A huge noise scattered all around our code just to serve at different conceptual level (can you turn it off and on easily, safely, or remove it easily?)! After these long years no one stood up to tackle this and see this problem at language level (for sure there a Lisper out there who does not share my point of view). This is my first of first (!) and very valuable (conceptually at least) to me: C# as an abstraction layer "on .NET"; C# as a XSLT for aspects "into .NET" (90:00':00"). I thought .NET team and C# team bring us more of it (and if anybody listens hear: we need more in-depth essays of WPF and the "reason/philosophy" behind each bit of it to learn it more deeply).
Second (to be honest this second still has more deeply affected me than that first; maybe because it happens recently) reason of my disappointment is Scala. I melted down when I saw it: How is this possible? Even possible? I though these are elegant dreams! They should not exist in the real world! The second reason was: I "believed" something like Scala is "impossible"! Of-course your description of Scala way and "logical/rational" (political?) decisions about C#; are complete. Yet Scala provides a neat and clean statically typed meta-programming and even syntax manipulating environment.

Again XAML is a source of well landed ideas! I like it! (OK, OK!)

ii.
A long time ago I thought about this "Parameter-Level Interface Implementation" thing in a different way. It was like some sort of "something mimics something" one-liner. Exactly as you mentioned, this idea changed in my mind when I was playing with C# 4.0 dynamic to this "Parameter-Level Interface Implementation". It's cool (and maybe exceptionally really immediately useful!).

iii.
I have played a little with Haskell and have a (maybe not so exact) clue of higher-kinded type-system; yet I think that's hard to achieve in C# semantics. But at interface level we can do more compiler tricks easily (correct me please if I am wrong).

iv.
It would be very nice to have some sources about that language you have spoke of. Thanks

v.
I have not looked into Rx so maybe I am wrong but it seems Rx should co-exists with some immutability facilities (like even an attribute, bundled with a compiler trick) in the language itself. Without that many problems (troubles) will still continue to exist in our code (is it possible for us to have uniqueness typing in C# or even in .NET?). And what about continuations? Does Rx provide a facility to use that seamlessly in our code? I have read some essays (maybe) which described that a language with exceptions can provide a richer model for dispatching that languages with continuations (in simple that idea is using different exceptions to reach different places in code - as I remember). So theorically we have a good bit of it. But do we have it built-in (not blotted-on) the language?

Regards

1 - Parameter-Level Interface Implementation; For example:

class Person
{
    public string Name { get; set; }
    public int Age { get; }
}
interface IPersonata
{
    string Name { get; }
    int Age { get; }
}
class SomeTasks
{
    // ...
    void Function(static IPersonata p) { /* ... */ }
    // ...
    void AnotherFunction(Person p)
    {
        // ...
        Function(p);
        // ...
    }
}

Should work; since Person satisfies IPersonata "statically". This is something like Google Go languages does. If we use dynamic instead of static; then it should generate necessary parts at runtime.

2 - Mixins (like Scala's Mixins); which in turn could lead to some statically typed meta-programming (well; It "could"; yet I am not sure how viable are these things in C#'s type system *).

3 - Templating generics themselves; at least as type parameters, in interfaces:

interface ITemplateBuilder<T><a>
{
     T<a> CreateInstance(a arg);
}

4 - Stronger type inferance (*).

5 - XAML everywhere! Yes! XAML could be a perfect replacement for macros in C#; and it's legal even for macro-hater C# folks (and some designers which I have not their eagle-eye view for sure; yet I like statically syntatic extension tools)! XAML provides a proper blending of aspects, services and data manipulation facilities.

I have successfully implemented a kd tree (in fact a 2d tree!) for solving a GIS nearest neighbor finding algorithm and enjoyed it a lot; and it is really performant.

But; the point that language designers should have in calculation more and more (as our problems get more complex and need quicker reactions):

A programming language for sure consums time to bend the programmer's mind to it's concept. At one point this "bending time" will be costy enough for being abandoned by industry.

One good job that Microsoft did; is releasing F#. Because if they intend to keep C# the way it is; they should leverage abstraction levels as new languages. F# is a wonderful language; yet a Scala blend (Maybe G# since G has one more angle than C!) could help more; since this "syntax" thing - and { } - really matters.