But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though.
What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.
http://fsharpforfunandprofit.com/posts/is-your-language-unre...
Then use C. In OOP comparing objects of different types is key to inheritance. The reason their example works is because everything in C# inherits from object, so you'll always find some commonality to compare.
You could have the compiler generate a warning when object.equals is used (rather than overridden) but getting rid of comparisons between different object types completely is backwards and will reduce efficiency.
It's possible to write shitty code in every programming language. Of course, the specific methods of doing so differ, but I've yet to see a Turing-complete language that makes it impossible to write buggy code.
So yes, shipping F# with VS is a good step, and technically it's supported, it's obvious MS has some discomfort there. Which is too bad, cause F# is a rare jewel, nothing else has the combination of language features, interop/library, performance, and tooling.
See http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system.
So while I can write
var x = { FirstName = "Riff", LastName = "Raff" }
void Display({ string FirstName, string LastName } nameRecord)
{
}
In the future, I hope that FP will be the default design choice, with objects being used where needed such as for components, plug-ins, and ad-hoc dictionary-passing-style tools.
After all, simplicity is the most important property of any software system - http://www.infoq.com/presentations/Simple-Made-Easy
C# is still one of my favorite languages (even though I use F# most of the time now), but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; it's too bad that fact was lost on so many programmers.
Kudos for sharing the Rich Hickey video; it's one of my favorites of all time.
Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.
You're making an either/or distinction here without any reason. You could just as well say, "The number of cars that recently added anti-lock brakes gives significant evidence that ABS is winning out over seat belts."
I don't see these languages removing any OOP features, so I think what it shows is that functional features are either useful independent of OOP features, or complement them. (My personal belief is the latter: the languages I enjoy the most have both.)
Too short a road from the obvious to the assumed...
C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~
And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by about 40% :| It feels like in theory it should be compiled down to code with the same efficiency? This is probably more of a CLR/JIT issue though?
I wish more people knew about it. As someone else mentioned, Reactive Extensions are also great - I believe they will be getting backpressure support which will allow similar semantics to channels (but with first-class error handling)
I solved the problem by avoiding lambdas altogether in code where performance is a concern, using delegates instead and ensuring all arguments are passed in rather than closed on (so structs would remain structs, GC pressure is avoided).
Interesting. Do you have this benchmarking code posted somewhere? What do you mean by "manual currying"?
Some syntactic sugar a la await could be nice though.
1.) In the StartSenders method, you're violating the Rx grammar by calling channel.OnNext concurrently. Wrap it on a lock statement.
2) In StartReceiver you're missing out messages the way you handle the channel. Replace the loop with a call to channel.Subscribe
From http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-fea...
"Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all."
I'm hoping this is one of those 'Clark's first law' situations: http://en.wikipedia.org/wiki/Clarke's_three_laws
'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.'
They've got quite a lot of smart folks working on C#, and it's heartening to me to see them taking another look at non-nullable reference types.
Good, no copy interop with native code would also be awesome. Particularly for machine learning.
For example, Kotlin has:
• Nullability in the type system
• Good support for efficient functional programming, e.g. you can do collection.map { it * 2 } and it's as fast as an imperative for loop as the compiler inlines the block.
• Strong support for meta-programming / DSL features, so there's less need to make code generators. JetBrains are still working on this but basically the language has a lot of features that don't initially seem all that significant, but can be combined to create useful DSLs.
• Lightweight data classes that support immutability and editing via copy construction (using named arguments)
• Traits
• Delegation
• etc etc
... and it's all here today, with good IDE support, and compatible with Java 6 even.
For good native interop there is JNA and there's a research project over at Oracle looking at how to do something better than JNA directly integrated with the JVM in a future version. So don't be too jealous.
Native code interfaces were already reasonably fast, allowing more no copy semantics and array slice behaviour is going to do wonders for native library performance.
(Well, technically C# and the related libs are fully OSS now too, IIRC).
I just said, "if only open source languages had the same resources".
Because that's what I mostly get to use, and because I don't run Windows but OS X, so I don't get to play with a fully supported C# environment.
I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre conditions etc would really make things cleaner.
Current implementation feels like it requires too much setup with separate classes, duplicate method signatures in several places etc etc. It would be really cool to have something like
public int SomeMethod(int a, int b)
pre
{
Requires (a > 5);
Requires (b >= 0, new Exception("something something"));
}
{
// DoStuffHere
}
post
{
Ensures (result > 0, new Exception("needs to be above 0"));
}
Full signature would simply be without the body:
public int SomeMethod(int a, int b)
pre
{
Requires (a > 5);
Requires (b >= 0 ,new Exception("something something"));
}
post
{
Ensures (result > 0);
}
Conditions.SomeMethod
{
pre
{
Requires (a > 5);
Requires (b >= 0, new Exception("something something"));
}
post
{
Ensures (result > 0);
}
}
public IEnumerable<int> Sort (IEnumerable<int> list, Order order)
test
{
(list = {3,5,6,2}, order = Order.Ascending) => result == {2,3,5,6};
(list = {3,5,6,2}, order = Order.Descending) => result == {6,5,3,2}
}
The specifics and syntaxes of these things requires some thought but I love the basic premise, am I rambling?
edit: I saw that something in this direction if not as extensive was actually discussed
If you instruct the compiler to treat all warnings as errors (so that variables must be defintitely assigned), then the following code gives you what you want:
public PositiveInt SomeMethod(GreaterThanFive a, NonNegative b)
{
//do stuff;
}
public struct GreaterThanFive
{
readonly int n;
public GreaterThanFive (int n)
{
if(n < 5)
throw new ArgumentException("n must be greater than 5")
this.n = n;
}
public static implicit operator GreaterThanFive(int n)
{
return GreaterThanFive(n);
}
public static implicit operator int (GreaterThanFive n)
{
return n.n;
}
}
//Similar definitions for NonNegative and PositiveInt
It also might not be super amenable to static analysis.
Multiple bracket blocks is not the most esthetic of solutions I think but it's the best I can think of. Attributes feels too clunky and just stacking contracts as lines after the class statement feels too disorganized
Oh god, I want it SO BAD.