Earlier quoted context omitted.
It's not a verb.
Using Select and Where makes perfect sense.
Here it's a misuse of notation.
Learning Haskell/Python makes you a worse C# programmer
31–40 of 64 posts
Re: Learning Haskell/Python makes you a worse C# programmer
#32Re: Learning Haskell/Python makes you a worse C# programmer
#33Earlier quoted context omitted.
I think part of the problem is that, while the CLR is vastly better than the JVM at supporting languages other than its flagship, I also think that the cost of using languages other than C# or VB.NET is higher than a lot of developers are willing to admit. We just allowed some F# code into Kiln. On the one hand, it was vastly simpler than the C# code it replaced. On the other hand, we had to rearchitect our solution…
Also consider that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed. It's too bad, F# is a really great language.
> Also consider that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed.
Also consider that HR departments and some engineers falsely assume that it is hard to hire people to work on your project if you use F#, whereas c# has enough similarities to other languages that it is easy for people to get up to speed.
Re: Learning Haskell/Python makes you a worse C# programmer
#34It is unfortunate, that the type of positions that employ .NET developers, enforce C# (or sometimes VB.NET) as their language that targets the CLI. While I understand the need for consistency, it would be nice if IronPython or F# were accepted. But dont just feel defeated, make a case to your architect or manager, they might be open to it. However its worth noting that in my experience, C# is a fine language - especi…
On my case I would cry of happiness if F# would ever be allowed, sadly my employers only care to hire cheap developers that can write a few statements in any language. Java developers are sold to customers as expert .NET consultants, because on management eyes C# is just like Java! :(
> Java developers are sold to customers as expert .NET consultants, because on management eyes C# is just like Java! :(
If your Java developers have problem picking up C# on the go and doing quality job within few short weeks with the assistance of one or two experienced C# devs as team leads, I doubt that they are good Java developers at first place.
Re: Learning Haskell/Python makes you a worse C# programmer
#35People should not be so eager to jump to the new functional constructs in C# to proof it can be cool too. There is no shame in imperative programming, it has its own advantages and can be pretty too. In this case, just using C# a bit more idiomatically can go a long way: var descriptions = new ArrayList(mylist.Length); foreach (var foo in myList) { if (foo.Description == "") { continue; } descriptions.Add(foo.Descrip…
The spirit of your code is correct but I think you'll get a runtime error since the inferred type of your iteration variable, foo, will be System.Object. Here's a slightly more idiomatic C# 2.0 (i.e. sans var goodness) ArrayList descriptions = new ArrayList(mylist.Length); foreach (Foo foo in myList) if (foo.Description != "") descriptions.Add(foo.Description); return String.Join("\n", descriptions);
Hey, you're right, it would be a compile time error but indeed. I'd rather supply a generic constraint to ArrayList than have it be cast to Foo that way (does it even do that automatically?).
Also, do you think leaving out the braces is idiomatic? I think it looks really pretty but I don't like it at all, it is too brittle.
Re: Learning Haskell/Python makes you a worse C# programmer
#36Re: Learning Haskell/Python makes you a worse C# programmer
#37Anybody knows if the author moved to programming in Python or Haskell since then? He should...
Re: Learning Haskell/Python makes you a worse C# programmer
#38Wow, this is the worst article I've seen on hacker news front page in a very long time.
C# has a tremendous potential for functional programming. There's some features that make a pure functional style easier and prettier in haskell, but C# has plenty of potential.
The title is total link bait. I clicked because I know there are things to write about - like pervasive nulls and mutable-by-default variables to begin with. There really are things to complain about! But the actual contents of the article are infuriatingly obtuse.
The fact that 39 people found this interesting in 2012 just demonstrates how ineffective the entire hacker news concept really is.
Re: Learning Haskell/Python makes you a worse C# programmer
#39Earlier quoted context omitted.
Why? It's a fluent interface.
It's not a verb.
Let me guess, you prefer methods called "getLength" over methods called "length", right?
"Method names should be verb phrases" is one possible convention, but it's not the only convention. If you can get better code by violating that convention, then the convention is, in that instance, wrong. Using verb phrases for function names is more of a procedural programming technique that doesn't always translate to object-oriented programming. In this particular instance, having a more declarative interface is more readable.
Re: Learning Haskell/Python makes you a worse C# programmer
#40TLDR: C# 2.0 had ugly syntax. article from 2006 in c#3.0 we write string.Join("\n", mylist.Select(x=>x.Description()).Where(x=>x != "").ToArray()); and now string.Join("\n", mylist.Select(x=>x.Description()).Where(x=>x != ""));
A method named 'where' seems really odd.
The genius of Linq is that it makes parallels between SQL and parts of functional programming. A lot of .NET devs have grown up using SQL and aren't looking to make changes. Instead of forcing devs to do functional programming, they made FP look familiar (like SQL). It's easy to explain a Linq statement to mediocre developers. For those of us who aren't mediocre, this makes a pleasant world where we can plunge further into FP without worrying about mediocre coworkers falling too far behind.