Scala comes to .Net(scala-lang.org)
scala-lang.org
Scala comes to .Net
http://www.scala-lang.org/node/10299
11 comments
And C# programmers have F# to go to if they want to sample ML.
I do not primarily program in C#, and I have done decent amount of Java. As far as languages are concerned, I find C# 4.0 a superior language to Java 6.
I took a look at both Scala and F# - F# seemed simpler and more concise to me.
One of my grudges is absence of a standard package manager for .net - Java has maven, ruby has gem, python has pip, C# has ?
I do not primarily program in C#, and I have done decent amount of Java. As far as languages are concerned, I find C# 4.0 a superior language to Java 6.
I took a look at both Scala and F# - F# seemed simpler and more concise to me.
One of my grudges is absence of a standard package manager for .net - Java has maven, ruby has gem, python has pip, C# has ?
C# now has one called NuGet.
Edit* Just wanted to clarify it is not specifically for C# but the .NET platform in general.
Edit* Just wanted to clarify it is not specifically for C# but the .NET platform in general.
In typical MS style though it is incredibly over engineered while not quite doing the job.
I vehemently disagree - it's actually quite brilliant and easy to use imo. Can you describe how you came to this conclusion?
In what ways does it not "do the job"? How is it over-engineered?
Could you elaborate? (true interest, I didn't downvote)
When you first come across it it looks like they're console commands. Yay! You go, the light has been seen at MS! After mucking round with cmd and then power shell for a few minutes you realize, well, no, they're not. There's yet another window added to visual studio to run the commands and it installs a new directory and a crapton of pointless files in your project directory to boot. Woo. Like we needed more of them. And just to be extra useful it puts yet another option in the already vastly overcrowded and poorly organised right-click menu of projects.
I love visual studio and C#. But NuGet's pretty pants, it just feels like you're being treated like a child.
To me this just smacks of the overkill of the asp.net membership system to me. Vastly overcomplicated to do a simple job. Maybe I'm just getting cynical in my old age and it's time to switch to linux. There's lots of little things that bug me in .Net though so it's probably just one of my pet peeves. For example I've always detested the obsession asp.net has with ~ that for the most part is totally and utterly pointless.
With a lot of things MS seem to approach the problem with the most complicated use case in mind rather than the simplest.
I love visual studio and C#. But NuGet's pretty pants, it just feels like you're being treated like a child.
To me this just smacks of the overkill of the asp.net membership system to me. Vastly overcomplicated to do a simple job. Maybe I'm just getting cynical in my old age and it's time to switch to linux. There's lots of little things that bug me in .Net though so it's probably just one of my pet peeves. For example I've always detested the obsession asp.net has with ~ that for the most part is totally and utterly pointless.
With a lot of things MS seem to approach the problem with the most complicated use case in mind rather than the simplest.
You mention the complexity of the ASP.NET membership system. I've always found it to be quite straightforward (unless you write your own providers I guess). Where are the pain points for you?
It was quite difficult for me when I first tried to pick up ASP.net. In retrospect, I don't think the problem is how difficult ASP.net provider system is, but the absence of assertiveness in the voice in tutorials. They tend to say, you an do it this using Forms Authentication, or Windows or Passport. Which is all true, but presents too many options to someone trying to find their way around a new system.
Thanks.
Sounds much like a matter of taste then, though. I much prefer clicking a button over typing a command (f.ex. tortoisegit over git, explorer over bash mv/cp/etc).
Sounds much like a matter of taste then, though. I much prefer clicking a button over typing a command (f.ex. tortoisegit over git, explorer over bash mv/cp/etc).
.NET's definitely got the weakness that there's less of an Open Source community around it. There certainly are some good things out there, but nothing like Java.
I spent a lot of time in the last week implementing an internal DSL in Java which in turn got me meditating on Scala.
I'm not sure that the increased fluency of Scala syntax is really a win for internal DSLs. My fear is that the fluent syntax depends a lot on fine details of the language; you could make some beautiful examples for the DSL's documentation, but take one step away from that and the user of the DSL has to deeply understand Scala's corner cases.
One thing that could be good about Scala, like ML derivatives is pattern matching.
Somebody with a lot of OO experience who's used to building things in an OO way might have a negative impression of pattern matching for polymorphism as opposed to conventional polymorphism. However, if you're building out an AST and you might want to process it in different ways, the pattern matching paradigm could be much better. For instance, if you've got something like a C# expression tree, you might want to 'interpret' it in the obvious way, or compile it to Java bytecodes, or compile it to a SQL query string, or do any of a number of different things. Pattern matching would provide a lovely way to do this.
I spent a lot of time in the last week implementing an internal DSL in Java which in turn got me meditating on Scala.
I'm not sure that the increased fluency of Scala syntax is really a win for internal DSLs. My fear is that the fluent syntax depends a lot on fine details of the language; you could make some beautiful examples for the DSL's documentation, but take one step away from that and the user of the DSL has to deeply understand Scala's corner cases.
One thing that could be good about Scala, like ML derivatives is pattern matching.
Somebody with a lot of OO experience who's used to building things in an OO way might have a negative impression of pattern matching for polymorphism as opposed to conventional polymorphism. However, if you're building out an AST and you might want to process it in different ways, the pattern matching paradigm could be much better. For instance, if you've got something like a C# expression tree, you might want to 'interpret' it in the obvious way, or compile it to Java bytecodes, or compile it to a SQL query string, or do any of a number of different things. Pattern matching would provide a lovely way to do this.
C# has copy/paste or zip files from http://www.codeproject.com/
Edit: this is a joke
Edit: this is a joke
Very true.
I used Scala on a project a year or so ago. I needed/wanted to target the JVM. However, after looking at Java the language, I realized how far it was behind C# now. (I hadn't used Java in several years after going to work for a Microsoft shop).
Scala was fairly easy to learn, the new features of C# really coalesced nicely with the Scala language, so I didn't feel like I had to learn much.
There are some nice features of Scala (var/val immutability, etc) that would be nice to see in C#.
I think Scala adoption in the .NET community may be hampered by 1) continual improvements in the c# language and 2) the F# language.
The F# language in particular because it has full IDE support.
The Achilles heel of Scala was lack of really good IDE support. Coming from C#/Visual Studio, working with Netbeans and the Scala plugin was somewhat frustrating...it wasn't quite ready for prime time. (Considering it was the work of one person, it worked very well but had a few issues).
I used Scala on a project a year or so ago. I needed/wanted to target the JVM. However, after looking at Java the language, I realized how far it was behind C# now. (I hadn't used Java in several years after going to work for a Microsoft shop).
Scala was fairly easy to learn, the new features of C# really coalesced nicely with the Scala language, so I didn't feel like I had to learn much.
There are some nice features of Scala (var/val immutability, etc) that would be nice to see in C#.
I think Scala adoption in the .NET community may be hampered by 1) continual improvements in the c# language and 2) the F# language.
The F# language in particular because it has full IDE support.
The Achilles heel of Scala was lack of really good IDE support. Coming from C#/Visual Studio, working with Netbeans and the Scala plugin was somewhat frustrating...it wasn't quite ready for prime time. (Considering it was the work of one person, it worked very well but had a few issues).
The state of IDE support has pretty much changed since a year ago.
IntelliJ pretty much rocks, Eclipse is done by the Scala team itself (no idea about Netbeans, though). While Scala IDEs haven't reached the level of maturity or the wealth of features of Java IDEs, they have useful features even Java IDEs lack.
I guess the .NET port is mainly for people wanting to keep writing Scala regardless if they are targeting the JVM, the CLR, browsers with JavaScript/GWT or the LLVM.
IntelliJ pretty much rocks, Eclipse is done by the Scala team itself (no idea about Netbeans, though). While Scala IDEs haven't reached the level of maturity or the wealth of features of Java IDEs, they have useful features even Java IDEs lack.
I guess the .NET port is mainly for people wanting to keep writing Scala regardless if they are targeting the JVM, the CLR, browsers with JavaScript/GWT or the LLVM.
...and when Larry Ellison is done having his way with Java and has alienated the entire community, the .Net community is going to start looking almost ... appealing.
Well, some might actually want co-variant return types and "real" variance instead of the interface/delegate as well as non-broken array variance, real type inference, higher-kinded types (to not loose the collection type like in LINQ) and many things more. That said, yes, C# looks a bit more familiar to Java developers although it is more or less a C++ descendant.
Additionally, most Java developers want to stay on the JVM, because it guarantees high performance, stability and maturity and has a wealth of well-known third party libraries.
Additionally, most Java developers want to stay on the JVM, because it guarantees high performance, stability and maturity and has a wealth of well-known third party libraries.
If "most Java developers want to stay on the JVM, because X, Y, Z," then doesn't that support the OP reasoning that Scala on .NET is a solution looking for a problem?
To me, the obvious use case is not bringing the .Net platform to Scala developers, but bringing Scala to .Net developers.
At my company, we do a large majority of our work in .Net languages, mostly C#. Being able to incrementally mix some Scala code into this for additional productivity, especially in the areas where Scala rocks (such as distributed / parallel processing, or in-language DSLs such as Scala's parsing library), sounds like a big win.
Support for C# generics is a must for that, though; you need to be able to pass List<Banana>s around.
Like other commenters said, the only danger is if the Scala guys would decide to stop supporting the CLR in the future again.
At my company, we do a large majority of our work in .Net languages, mostly C#. Being able to incrementally mix some Scala code into this for additional productivity, especially in the areas where Scala rocks (such as distributed / parallel processing, or in-language DSLs such as Scala's parsing library), sounds like a big win.
Support for C# generics is a must for that, though; you need to be able to pass List<Banana>s around.
Like other commenters said, the only danger is if the Scala guys would decide to stop supporting the CLR in the future again.
How does parallel processing in Scala "rock"? Can you point me to studies where Actors outperform, say OpenMP or Task Parallel Library? Does parallel processing on Scala compensate the overhead that Scala generally has over Java, C++, or in this case C#?
I'd seriously like to know. I know that actors are good in some situations (distributed computing where you would normally use message passing), but statements such as the above can often be heard, but seem far to broad.
I'd seriously like to know. I know that actors are good in some situations (distributed computing where you would normally use message passing), but statements such as the above can often be heard, but seem far to broad.
> How does parallel processing in Scala "rock"?
Actually, in this case I was mostly referring to the parallel and distributed collections. And stuff like coding a for comprehension that can be transparently spread over multiple cores or even boxes.
I don't know enough about the actors stuff to make a good statement about it.
Actually, in this case I was mostly referring to the parallel and distributed collections. And stuff like coding a for comprehension that can be transparently spread over multiple cores or even boxes.
I don't know enough about the actors stuff to make a good statement about it.
Why and how should actors outperform OpenMP or TPL? They serve completely different goals.
Scala ships by default with sequential, lazy and parallel collections and actors.
Akka (akka.io) provides a different implementation of actors (which will replace the one in the standard library in the future), as well as Agents, STM, Transactors, ... for all your concurrency needs. Akka actors can actually outperform Erlang actors in core areas.
Spark (spark-project.org) provides a (Hadoop-like) framework for distributed collections.
Work is being done to make Scala collections run on GPUs, too.
I would argue that Scala's toolbox is pretty diverse and complete when dealing with parallel and/or concurrent problems.
Without facts I wouldn't claim that Scala is slower than Java/C++/C#.
Scala beats the shit out of Java in situations where Java has to work with boxed types instead of primitives like in ArrayList<Integer>, enables people to write fully generic algorithms supporting any number type without speed penalty.
Scala is certainly nicer than C++ because it just works and has far less weird corners or surprises. It lets you write code faster and gives you more time to actually optimize those places where it matters.
C# is pretty much a kitchen-sink language with many features bolted on in a non-othogonal way, unlike Scala. The unreliable VM doesn't help, although value types and the thing Mono did with SIMD is certainly nice.
Scala ships by default with sequential, lazy and parallel collections and actors.
Akka (akka.io) provides a different implementation of actors (which will replace the one in the standard library in the future), as well as Agents, STM, Transactors, ... for all your concurrency needs. Akka actors can actually outperform Erlang actors in core areas.
Spark (spark-project.org) provides a (Hadoop-like) framework for distributed collections.
Work is being done to make Scala collections run on GPUs, too.
I would argue that Scala's toolbox is pretty diverse and complete when dealing with parallel and/or concurrent problems.
Without facts I wouldn't claim that Scala is slower than Java/C++/C#.
Scala beats the shit out of Java in situations where Java has to work with boxed types instead of primitives like in ArrayList<Integer>, enables people to write fully generic algorithms supporting any number type without speed penalty.
Scala is certainly nicer than C++ because it just works and has far less weird corners or surprises. It lets you write code faster and gives you more time to actually optimize those places where it matters.
C# is pretty much a kitchen-sink language with many features bolted on in a non-othogonal way, unlike Scala. The unreliable VM doesn't help, although value types and the thing Mono did with SIMD is certainly nice.
"Without facts I wouldn't claim that Scala is slower than Java/C++/C#."
If I may be so bold, without facts I wouldn't claim the C# VM is unreliable or that features are added without thought.
If I may be so bold, without facts I wouldn't claim the C# VM is unreliable or that features are added without thought.
Why and how should actors outperform OpenMP or TPL? They serve completely different goals.
Show us numbers. That was the main request of my comment, and you come with a list of libraries? We hear all the time how great Scala is with respect to parallel computing. Show me some good examples, where it beats C++ or C# with TPL, say doing number crunching.
It's all to easy to repeat a mantra (parallel programming in Scala rocks), but it has been proven correct rarely. Given such statements, I would either expect it to be much easier to parallelize programs in Scala (as opposed to, say, adding OpenMP pragmas) or would expect parallelized programs to be much faster. Neither seem to be true.
Show us numbers. That was the main request of my comment, and you come with a list of libraries? We hear all the time how great Scala is with respect to parallel computing. Show me some good examples, where it beats C++ or C# with TPL, say doing number crunching.
It's all to easy to repeat a mantra (parallel programming in Scala rocks), but it has been proven correct rarely. Given such statements, I would either expect it to be much easier to parallelize programs in Scala (as opposed to, say, adding OpenMP pragmas) or would expect parallelized programs to be much faster. Neither seem to be true.
>>> Is driving a car better than eating a banana?
>> They serve completely different goals.
> Show us numbers.
That makes sense, doesn't it?
> That was the main request of my comment, and you come with a list of libraries?
Well, after you failed to even tell concurrent and parallel computing apart, I assumed giving you an overview first would be beneficial.
Maybe you could use the links I already gave you or use Google. For instance, here is an additional link I found pretty easily: http://www.azavea.com/blogs/labs/2011/06/scalas-numeric-type...
>> They serve completely different goals.
> Show us numbers.
That makes sense, doesn't it?
> That was the main request of my comment, and you come with a list of libraries?
Well, after you failed to even tell concurrent and parallel computing apart, I assumed giving you an overview first would be beneficial.
Maybe you could use the links I already gave you or use Google. For instance, here is an additional link I found pretty easily: http://www.azavea.com/blogs/labs/2011/06/scalas-numeric-type...
First, I am reacting to the original commenter, and pointing out that your post does not answer my question to the original commenter.
Second, I do know the difference between concurrency and parallelism (since I use the latter a lot, and the former in the rare occasion of writing GUI programs). Anyway, your ad hominems do not serve the discussion.
Third, mentioning 'actors' and OpenMP is one sentence was poking a bit of fun at the overly broad statements often made by fans of Scala (and Erlang) about what Actors will do. But the next time I will leave my sardonicism at the door.
Second, I do know the difference between concurrency and parallelism (since I use the latter a lot, and the former in the rare occasion of writing GUI programs). Anyway, your ad hominems do not serve the discussion.
Third, mentioning 'actors' and OpenMP is one sentence was poking a bit of fun at the overly broad statements often made by fans of Scala (and Erlang) about what Actors will do. But the next time I will leave my sardonicism at the door.
Since most serious Scala programs will use Java classes or class libraries, I still have to see how portable most Scala code will be between JVM and .NET/CLR, besides the lack of ABI compatibility. It will add complexity to a language that is already fairly complex.
Some commenters have already suggested that Scala has the C++ syndrome, but at least C++ is easily wrapped in C, making binding to anything else fairly easy.
I wonder if it would not be better to stick to the JVM, and tell people that that's the platform. You cannot be everything to everyone without collapsing under the weight.
Some commenters have already suggested that Scala has the C++ syndrome, but at least C++ is easily wrapped in C, making binding to anything else fairly easy.
I wonder if it would not be better to stick to the JVM, and tell people that that's the platform. You cannot be everything to everyone without collapsing under the weight.
Well, Scala is not the simplest language, but I'm not sure why having separate .Net backend will make the language more complex. After all, .Net and JVM are pretty similar at its core so that difference between the two shouldn't affect Scala the language, only Scala the compiler.
As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
As for portability between Scala.Net and Scala.JVM programs, it was never the goal of the programs. Of cource, programs using only Scala API should be source portable, but if one ues Java or .Net classes it will not be.
Right, you are paraphrasing my worry: there will be .Net and Java flavors Scala. Sure, the syntax will be portable, but programs do not only consist of syntax.
C# in the .Net 1.0 era was very similar to Java. However, most of the domain-specific knowledge is not in the language, but in the associated class library and runtime. Usage patterns evolve with them.
So, under the assumption that Scala.Net will get traction, in three years, people will be hiring Scala.Net and Scala(JVM) programmers. Educational programs will teaching two different flavors. Books will describe two different flavors.
How does this help Scala or the Scala programmer?
(Then there are more questions, such as: what does Scala.Net offer over C# (which is incorporating functional constructs) and F#?)
C# in the .Net 1.0 era was very similar to Java. However, most of the domain-specific knowledge is not in the language, but in the associated class library and runtime. Usage patterns evolve with them.
So, under the assumption that Scala.Net will get traction, in three years, people will be hiring Scala.Net and Scala(JVM) programmers. Educational programs will teaching two different flavors. Books will describe two different flavors.
How does this help Scala or the Scala programmer?
(Then there are more questions, such as: what does Scala.Net offer over C# (which is incorporating functional constructs) and F#?)
While we both agree what would happen, I don't see that as a bad thing. With core language being the same, lots of the skill will be portable.
We have the same situation right now with C/C++, where people are hiring Windows C++ programmers and Linux C++ programmers. It doesn't seem to hurt that much C++ as a language. And C++ has even smaller "standard library" than Scala.
We have the same situation right now with C/C++, where people are hiring Windows C++ programmers and Linux C++ programmers. It doesn't seem to hurt that much C++ as a language. And C++ has even smaller "standard library" than Scala.
C++ has a smaller standard library, but has easier interoperability with other languages.
I see your point, but I do think it hurts C++ and C++ programmers. Programming C++ in Windows or programming C++ in a gtkmm context are very different. Even the most basic things are not standardized (unicode string handling, etc.). Middle ground does exist (Qt), but it does replace most of the STL and has some very basic weaknesses, like vectors that are limited to 2^31 − 1 elements on common platforms.
So, again, I am seriously interested in what fragmentation buys you when porting to a platform that already has 1 1/2 functional languages, supported by its developer?
I see your point, but I do think it hurts C++ and C++ programmers. Programming C++ in Windows or programming C++ in a gtkmm context are very different. Even the most basic things are not standardized (unicode string handling, etc.). Middle ground does exist (Qt), but it does replace most of the STL and has some very basic weaknesses, like vectors that are limited to 2^31 − 1 elements on common platforms.
So, again, I am seriously interested in what fragmentation buys you when porting to a platform that already has 1 1/2 functional languages, supported by its developer?
IIRC 'Programming in Scala' doesn't talk much about the JVM.
Well, there is also a JavaScript compiler in the works and a LLVM backend. Who cares? Adding more supported platforms makes the language and its libraries more stable and mature, because less things are taken for granted.
Things in the Java standard library will work on .NET. Scala, too. If Scala uses .NET classes, this will also work. What's the problem?
Things in the Java standard library will work on .NET. Scala, too. If Scala uses .NET classes, this will also work. What's the problem?
This is basically the same reason that ClojureCLR has no traction.
One of the reasons. In general, I can see a low rate of acceptance of .NET among the crowd which has a high rate of interest in Clojure. I guess it is a case of avoiding Microsoft-dominated technologies by the open-source crowd.
As someone who uses both, I'll gladly be a supporting data point for this hypothesis.
And the Microsoft crowd is sometimes reluctant to embrace non-Microsoft technologies.
This is true, but I think the reasons are different. There has been a lot of usage knowledge created around the Microsoft platform(s), some supported by the community, but a lot still supported by the company. Moving in the open-source realm means losing a company's support, and I can see how those who are not used to it are uncomfortable with it.
I don't see how that's too different than if a dedicated open source user was to move to using MS products. Replace 'Microsoft' with OSS and 'company' with 'community', and the statement is still true.
They should give it a more dot netty name, by picking a letter (maybe F, as it's a functional language) and putting a sharp on the end.
S# :)
Yes. Pretty sure that hasn't been done before! :D
The danger with this is, how long will it be supported? Can the Scala team ensure that it will not be deprecated in the future? With JVM, one is confident of future.
I remember Microsoft letting go of the IronRuby developers, for example, has IronRuby's development stagnated as well? (I'm aware that the work is done by the Scala team in this case, though)
I remember Microsoft letting go of the IronRuby developers, for example, has IronRuby's development stagnated as well? (I'm aware that the work is done by the Scala team in this case, though)
This uses IKVM heavily, and it sounds like other people have tried running scala classfiles through IKVM
http://groups.google.com/group/scala-user/browse_frm/thread/...
and a LLVM backend project is also brewing
http://news.ycombinator.com/item?id=2625405
http://groups.google.com/group/scala-user/browse_frm/thread/...
and a LLVM backend project is also brewing
http://news.ycombinator.com/item?id=2625405
How many companies that do both .Net and Java development and use Scala there are? Or how many will start developing in Scala if they're already proficient in .net? Definitely there will be some, but to base the compiler of such complexity around these few ... well, I just don't think it's worth the effort.
I've always looked at Scala as a great language to go to if you don't want to be on the .Net stack. But if you're happy with the .Net ecosystem, the combination of C# and F# are very tough to beat. The tooling is great, and the languages are really well thought out.
I don't really know what benefits there are to gain from using Scala on .Net other than the fact that it's cool that it could be done.
I don't really know what benefits there are to gain from using Scala on .Net other than the fact that it's cool that it could be done.
Well, the Scala developers are currently moving their build system to Scala. This means they can fully bootstrap their language/compiler, library and build system from one source language.
The .NET port has only added some minor changes to the compiler (which have actually uncovered a bug in the compiler implementation!) and most of the .NET backend works as a compiler plugin, just like the JVM backend or the LLVM backend.
The .NET port has only added some minor changes to the compiler (which have actually uncovered a bug in the compiler implementation!) and most of the .NET backend works as a compiler plugin, just like the JVM backend or the LLVM backend.
As someone who has recently learned C# and known Scala for a while, I am very impressed with what C# has to offer as a language. However, it is not nearly as well-designed as Scala. Microsoft has piled on feature after feature to the point where many C# are features either mostly deprecated and replaced by newer features or else do not mix well with new language features. Some examples include:
-generic vs non-generic types. For instance, when using the Process class, you have to use StringDictionary.
- Actions and delegates vs lambdas. This is made more painful by the fact that C# handles the void return type specially, so that there is no way to create a Func<void>. Also, it means that if you want to support higher order functions that support both a void and a generic return type you have to write two different functions.
- ref and out parameters with lambdas. They just... don't mix!
- out parameters vs 4.0 tuples. Really C# needed syntactic sugar for multiple return types long ago, but the idiomatic way to do this in C# is with a feature that simply does not play well with functional programming.
There are other things that make Scala nicer as well.
-In Scala every statement is also an expression and Scala has the bottom type, which again makes writing functional code much simpler.
-Scala's collection's library is superior. It has functional collections and it's design enables overriding methods to have much more sensible static return types.
-Scala's way of extending class functionality with implicits is more powerful and object-oriented than C#'s extension methods. In fact, Scala in general feels much more OO than C#.
-Scala has a form of controlled multiple implementation inheritance (traits) that I really miss in C#.
These are just the practical things I can think of on top of my head that I miss in C# versus Scala. On the other hand, I get the impression that C# was originally designed to be a more performant Java by hybridizing it with C++. It's richer value type system, the fact that class methods are non-virtual by deafult, and the ease by which one can drop into unsafe code mean that one can port a lot more performant C-style code to C# than on any JVM-originating language, which I think is C#'s greatest strength compared to Scala.
Still, I think if people gave Scala a chance they would find it to be a very clean, productive, and well-designed language compared to C#. That alone may not be enough to convince people to switch to Scala in droves, but enough so that people who want to target both platforms will be willing to consider Scala as a solution rather than to use something like Mono.
-generic vs non-generic types. For instance, when using the Process class, you have to use StringDictionary.
- Actions and delegates vs lambdas. This is made more painful by the fact that C# handles the void return type specially, so that there is no way to create a Func<void>. Also, it means that if you want to support higher order functions that support both a void and a generic return type you have to write two different functions.
- ref and out parameters with lambdas. They just... don't mix!
- out parameters vs 4.0 tuples. Really C# needed syntactic sugar for multiple return types long ago, but the idiomatic way to do this in C# is with a feature that simply does not play well with functional programming.
There are other things that make Scala nicer as well.
-In Scala every statement is also an expression and Scala has the bottom type, which again makes writing functional code much simpler.
-Scala's collection's library is superior. It has functional collections and it's design enables overriding methods to have much more sensible static return types.
-Scala's way of extending class functionality with implicits is more powerful and object-oriented than C#'s extension methods. In fact, Scala in general feels much more OO than C#.
-Scala has a form of controlled multiple implementation inheritance (traits) that I really miss in C#.
These are just the practical things I can think of on top of my head that I miss in C# versus Scala. On the other hand, I get the impression that C# was originally designed to be a more performant Java by hybridizing it with C++. It's richer value type system, the fact that class methods are non-virtual by deafult, and the ease by which one can drop into unsafe code mean that one can port a lot more performant C-style code to C# than on any JVM-originating language, which I think is C#'s greatest strength compared to Scala.
Still, I think if people gave Scala a chance they would find it to be a very clean, productive, and well-designed language compared to C#. That alone may not be enough to convince people to switch to Scala in droves, but enough so that people who want to target both platforms will be willing to consider Scala as a solution rather than to use something like Mono.
>> so that there is no way to create a Func<void>
Does Func<Action> not achieve what you are after?
Does Func<Action> not achieve what you are after?
Func<Action> would be a function that takes no arguments and returns an Action. The desire is to be able to specify void as the return type of a Func, so that you can use Funcs for all callbacks, instead of having to use Funcs for callbacks that return a value and Actions for callbacks that don't.
Most of the your examples look like they're caused by the base class library not keeping up with language advancements. Which I agree can be a real issue.
Couldn't say it any better, thanks!
It's an interesting project, but in my 6+ years of Enterprise .NET development, I've yet to work in a single shop that released a production .NET application that wasn't written in C# or VB.NET. Even F# seems to be very rarely deployed.
It's hard to get excited about any new CLR-based language development when clearly the broader .NET community and the customer base could care less.
It's hard to get excited about any new CLR-based language development when clearly the broader .NET community and the customer base could care less.
They're out there - we embed IronPython in our C# application, and are looking into using F# for some of the financial reporting our application creates. It is rare, but there are definitely uses to having multiple languages available on the CLR (and DLR).
This is probably a fair point about the "enterprise .NET" community, which is by nature very conservative and closely aligned to core Microsoft technologies where the guarantees of support are strongest and the developer pool the largest.
However we as a smaller shop have used F# on a couple of projects within the last year -- to embed an expression engine within an analytics product, and for the parser/analyser in our Sass plugin for Visual Studio. But I know I'd have struggled to get that technology choice into the last enterprise environment I worked in. So the lack of uptake may be more to do with the culture of "enterprise .NET" shops, more than the "broader .NET community."
However we as a smaller shop have used F# on a couple of projects within the last year -- to embed an expression engine within an analytics product, and for the parser/analyser in our Sass plugin for Visual Studio. But I know I'd have struggled to get that technology choice into the last enterprise environment I worked in. So the lack of uptake may be more to do with the culture of "enterprise .NET" shops, more than the "broader .NET community."
Well put. When I wrote "broader .NET community", I was mostly speaking to the vast majority of .NET developers, which are unfortunately stuck in typical Enterprise environments.
There are definitely small shops out there doing interesting things and I love hearing about them!
There are definitely small shops out there doing interesting things and I love hearing about them!
And it appears I'm official negligent about learning Scala. I know it's been around for years, but I just really learned about it recently and now it seems to be going crazy.
With the ability to use .NET or the JVM... I mean, wow.
With the ability to use .NET or the JVM... I mean, wow.
Pragmatism over principle again; today's hacker culture is crippled.
Getting Shit Done trumps all things. The reality as well is that the majority of the .Net platform (with the exception of the Standard Libraries, I believe) are open ECMA Standards (See among others, #335).
The reality is that .NET is a very probable patent trap for the FOSS community and Microsoft is trying hard to make us dependent on it.
Unlike .NET, Java has a free implementation (OpenJDK) and any code derived from OpenJDK is granted Java patents. Apache is a different story as they are developing a Java implementation under permissive license, which means that Apache code could be used in non-free software (including .NET), that would make Java vulnerable to the "Embrace, Extend and Extinguish" strategy. That is what Apache is paid for by Microsoft.
So my point is that supporting .NET is bad for the ideals of the free software community, yet it is good for pragmatic reasons as it could bring more users. And I have a strong impression that today pragmatism is favored over principle by the community, the decline of copyleft is also a sign of that.
Unlike .NET, Java has a free implementation (OpenJDK) and any code derived from OpenJDK is granted Java patents. Apache is a different story as they are developing a Java implementation under permissive license, which means that Apache code could be used in non-free software (including .NET), that would make Java vulnerable to the "Embrace, Extend and Extinguish" strategy. That is what Apache is paid for by Microsoft.
So my point is that supporting .NET is bad for the ideals of the free software community, yet it is good for pragmatic reasons as it could bring more users. And I have a strong impression that today pragmatism is favored over principle by the community, the decline of copyleft is also a sign of that.
So is it that you don't buy the Community Promise, or that you don't know about it? http://tirania.org/blog/archive/2009/Jul-06.html
FSF: Microsoft's Empty Promise (http://www.fsf.org/news/2009-07-mscp-mono)
There are pretty strong guidelines with regards to patents for any technology you turn over to an ECMA standard which basically removes your ability to patent troll by legal license.
Who sets these principles? I ask because FSF has bashed Apple and MS at various points in time. If the FSF is writing the religious-book here, then you're not supposed to work with the cloud, you're not supposed to use to chromeOS notebooks and boy you should really go dump those smartphones since they're either proprietary or open-but-not-quite.
In that same vein, code inside a car's sensors isn't open sourced and Toyota had a rather messy couple of months because of it. So boycott cars too ? Build your own car ?
I really don't get the excuses people come up with to complain about people getting shit done. A "principles based" fight is being fought in politics all the time; fat load of good that's doing.
In that same vein, code inside a car's sensors isn't open sourced and Toyota had a rather messy couple of months because of it. So boycott cars too ? Build your own car ?
I really don't get the excuses people come up with to complain about people getting shit done. A "principles based" fight is being fought in politics all the time; fat load of good that's doing.
Being a part of the hacker culture means sharing the hacker ethics, including the principle of information-sharing, which is the base of the FSF philosophy. These principles are not set by someone, there are what is meant by the word "hacker". If you do not consider these principles to define what the hacker culture is, then we are talking about different "hacker cultures". I use the common programmer subculture meaning of "hacker":
http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)
Sharing the same ethics means having similar views of good and evil. Seeing something as evil does not mean you must boycott it, yet it is logical though not always practically possible to avoid what you consider to be evil.
Sharing the same ethics means having similar views of good and evil. Seeing something as evil does not mean you must boycott it, yet it is logical though not always practically possible to avoid what you consider to be evil.
The hacker culture is all about doing what you can, and saying "screw you" to anyone who tries to tell us what is principled or not. If you want to talk principles go to church.
So if I kill people and say "screw you" to anyone who tell me that this is wrong am I a hacker?
That is nihilism. If it is called a culture, there must be ethics. For instance, information-sharing is an important hacker ethic: http://www.catb.org/jargon/html/H/hacker-ethic.html
That is nihilism. If it is called a culture, there must be ethics. For instance, information-sharing is an important hacker ethic: http://www.catb.org/jargon/html/H/hacker-ethic.html
It is indeed sad that everybody does not meet your expectations
C# has non-broken generics, (contra/co)variance, closures, method pointers, expression trees, type inference, value types (can implement complex numbers that take up just 8 bytes!) and many other little features that show that the language designers have some respect for programmers.
If anything, C# is the language that Java refugees are looking for, not Scala.