Live data from Hacker News

More functional C#

news.ycombinator.com

81–90 of 98 posts

Re: More functional C#

#81
post #63

Earlier quoted context omitted.

It's sad how C# is put on a pedestal, since it has plenty of obvious critical flaws, see links below for a list and this is just the tip of the iceberg. http://hestia.typepad.com/flatlander/2012/01/action-func-voi... http://trelford.com/blog/post/LighterCSharp.aspx http://stackoverflow.com/questions/411906/c-sharp-net-design... http://joeduffyblog.com/2010/06/27/on-partiallyconstructed-o... http://blogs.msdn.com/b/ds…

http://hestia.typepad.com/flatlander/2012/01/action-func-voi... I fail to see how it is an "obvious critical flaw" :) You have to create a separate overload that takes an Action instead of a Func, and has an identical implementation except for omitting the return keyword. Granted, that’s not much work for a simple helper like the above, but what if it were more complicated? No, it's simply not true that you need "an…

Your solution is at least as ugly as the one mentioned in the article.

The problem is that void can't be used as a regular type identifier.

In a lot of langages (like Python, Haskell, F#, ...) there is a regular type for void. This type is often implemented as such :

  sealed struct Void {
  }
Then you can define Action just as Func.

As the compiler is smart enough to see there is only one kind of Void value, it can be entierly removed from the generated code and thus doesn't make your code slower.

Re: More functional C#

#82
post #63

Earlier quoted context omitted.

http://hestia.typepad.com/flatlander/2012/01/action-func-voi... I fail to see how it is an "obvious critical flaw" :) You have to create a separate overload that takes an Action instead of a Func, and has an identical implementation except for omitting the return keyword. Granted, that’s not much work for a simple helper like the above, but what if it were more complicated? No, it's simply not true that you need "an…

Your solution is at least as ugly as the one mentioned in the article. The problem is that void can't be used as a regular type identifier. In a lot of langages (like Python, Haskell, F#, ...) there is a regular type for void . This type is often implemented as such : sealed struct Void { } Then you can define Action just as Func . As the compiler is smart enough to see there is only one kind of Void value, it can be…

And quite what's so ugly about it? It's hackish, but once you create these overloads, you don't need to worry about it anymore and you can call the method just as if Func could be casted to Action. I don't think it can even be compared to the one suggested in the article, since it does not require "creating a separate overload with an identical implementation" (!!!), potentially copy-pasting hundreds of lines of code if the method in question was indeed "more complicated". This is ridiculous and the fact the author couldn't think of a workaround that didn't involve it baffles me.

Re: More functional C#

#83
post #79

Earlier quoted context omitted.

> Do you have any examples? Sure, write a self-executing function in C#.

((Action)(() => Console.WriteLine("Hello")))(); or new Action(() => Console.WriteLine("Hello"))(); Yeah, it's verbose because you have to cast the lambda expression before executing it, but honestly I don't know any case where a self executing function can be useful in C#.

Not too bad. Actions return null though. How about a self-executing function that returns a value? This is useful for assigning values to variables. IIRC it's going to start getting more ugly from here.

Re: More functional C#

#84
post #83

Earlier quoted context omitted.

((Action)(() => Console.WriteLine("Hello")))(); or new Action(() => Console.WriteLine("Hello"))(); Yeah, it's verbose because you have to cast the lambda expression before executing it, but honestly I don't know any case where a self executing function can be useful in C#.

Not too bad. Actions return null though. How about a self-executing function that returns a value? This is useful for assigning values to variables. IIRC it's going to start getting more ugly from here.

    (new Func(() => 2))();

Re: More functional C#

#85
post #11

I have read a lot of lang. wars and complaints about programming languages... but C# is one of the only languages that I can't remember reading any complaints about. None. I must conclude, by the usual Stroustrup quote, that no one uses C#. (yes this is tongue in cheek)

I have 1. You can't do generic constructors for custom attributes. That's a pretty small complaint though...

Re: More functional C#

#86
post #74
post #54

While sprinkling a few expressions like this around is nice, it's quite a chore to embrace a true dataflow or similiar functionally typed design through your whole application, because the types in c# are so verbose i.e. public Generate(TState initialState, Func condition, Func iterate, Func resultSelector, IScheduler scheduler)

Methods with that many arguments are probably not a very good idea anyway.

Unfortunately there's probably not a great alternative in many cases such as this

Re: More functional C#

#87
post #6

You can write Java code which works similarly to your C# code by using RxJava: https://github.com/Netflix/RxJava Or Python, via RxPy: https://github.com/Reactive-Extensions/RxPy Or JavaScript, via RxJs: https://github.com/Reactive-Extensions/RxJS Or Ruby, via Rx.rb: https://github.com/Reactive-Extensions/Rx.rb Or Objective-C, via Rx.ObjC: https://github.com/Reactive-Extensions/Rx.ObjC Your code is a good demonstratio…

Rx was invented by Microsoft, so C# is a rightful first choice for Rx examples :). That code doesn't demonstrate Rx per se, it demonstrates how lambda expressions, extension methods, anonymous types, type inference enable a succinct backwards-compatible (to some extent) functional syntax in C#.

Look at the type signatures of many LINQ and Rx methods. I would hardly say they are succint. While just using expressions can be compact, maintaining a functional library or creating functional methods in your application will be a chore in c# due to the verbosity of the type syntax (Type inference won't help you on method signatures)

Re: More functional C#

#88
post #78

Earlier quoted context omitted.

It's not that it is only ever used for enterprise, just that it seems to be mostly used for enterprise. Think of the licensing costs for visual studio, sqlserver and windows server. Sure there is the Bizspark, but it runs out, and I think most founders would be squeamish with the potential business-technical debt that would represent. At least right now, MS is still seen (although less lately) like the Big Bad, so gi…

"Think of the licensing costs for visual studio, sqlserver and windows server." Think of the costs of paying your developers. Those things are a pittance compared to the cost of hiring and retaining good developers.

Shrug, your costs might be different, but 13k per developer per year is hardly a pittance compared to my salary. I'd much rather have 13k in my pocket or in awesome stuff like monitors, desk, keyboard, etc.

Re: More functional C#

#89
post #19

Earlier quoted context omitted.

Well, I use it =) C# is a language with a somewhat limited market ("Enterprise" applications running on Windows Servers, and yes, I know about Mono). And in this market, a very strict subset of C# (see: Java) is happily used. I know a lot of people who refrain from using even lambdas and implicit typing, let alone the other "fringe functional stuff", because "they make things complicated".

C# is a language with a somewhat limited market ("Enterprise" applications running on Windows Servers, and yes, I know about Mono) One would think that Windows Phone - fastest growing smartphone OS - would go before Mono... geez, I make a living out of desktop C# apps (WPF). Not solely, but on a daily basis.

I would be interested to know what these apps are? Who buys them? Where do you sell them? I never found a decent place to sell WPF desktop apps.

Re: More functional C#

#90
post #78

Earlier quoted context omitted.

"Think of the licensing costs for visual studio, sqlserver and windows server." Think of the costs of paying your developers. Those things are a pittance compared to the cost of hiring and retaining good developers.

Shrug, your costs might be different, but 13k per developer per year is hardly a pittance compared to my salary. I'd much rather have 13k in my pocket or in awesome stuff like monitors, desk, keyboard, etc.

In what world are you paying 13k per developer for year to use Microsoft products? Top of the line MSDN sub is like ~3k, and we get good desks and monitors and keyboards and computers too. Most places don't even buy MSDN, I do fine with a <1k in software to develop on .NET.
Post reply on HN