Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Haskell/Python makes you a worse C# programmer

lukeplant.me.uk

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Learning Haskell/Python makes you a worse C# programmer

#41

Post by njbooher »

philwelch wrote: post #39
njbooher wrote: post #26

Earlier quoted context omitted.

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-o…

No, I prefer objects with attributes called 'length'.

Re: Learning Haskell/Python makes you a worse C# programmer

#42

Post by philwelch »

njbooher wrote: post #41
philwelch wrote: post #39

Earlier quoted context omitted.

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-o…

No, I prefer objects with attributes called 'length'.

Distinguishing between attributes and methods in your interface violates encapsulation. The only thing an object's interface should be worried about is what messages it responds to, it shouldn't have to expose whether it responds to messages by fetching a variable or calling a procedure.

On the implementation side, if you just want to expose a variable then attributes are fine. Outside of your object, though, who cares whether or not "length" is an attribute? Maybe your object is encapsulating a lazily-evaluated database relation, at which point "length" would generate a SELECT COUNT query. It still fulfills the contract of "an object that has a length", and you don't want to get in the business of defining different interfaces for "an object that has a length cached in an instance variable" and "an object that has a length that is calculated dynamically".

The properties of an object are best expressed with noun phrases regardless of their implementation.

Re: Learning Haskell/Python makes you a worse C# programmer

#43

Post by noblethrasher »

tinco wrote: post #35
noblethrasher wrote: post #23

Earlier quoted context omitted.

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.

Eliding the braces does make it a bit less idiomatic I suppose; but in ten years of programming I don't think I've ever been bitten by a bug caused by that style... not even in JavaScript.

On the other hand, I think the risk of making the code slightly more brittle is worth it if it makes it much more pleasant to read. Whenever I see a for/foreach followed by a single statement then I know that the code is doing a simple projection (i.e. Select in Linq or SQL parlance). If it’s a for/foreach followed by an if statement followed by some other statement (as in the above code) then I know it’s a simple filter and projection (i.e. Where and Select).

But I wanted to illustrate your larger point, which is that C# programmers shouldn’t be so quick to use functional idioms since imperative code can not only look just a pretty, but it’s almost always slightly more performant since it doesn’t imply as many allocations and indirections.

Re: Learning Haskell/Python makes you a worse C# programmer

#44

Post by njbooher »

philwelch wrote: post #42
njbooher wrote: post #41

Earlier quoted context omitted.

No, I prefer objects with attributes called 'length'.

Distinguishing between attributes and methods in your interface violates encapsulation. The only thing an object's interface should be worried about is what messages it responds to, it shouldn't have to expose whether it responds to messages by fetching a variable or calling a procedure. On the implementation side, if you just want to expose a variable then attributes are fine. Outside of your object, though, who car…

Objects are nouns. They have attributes. Some of them can perform actions. Those actions ("verbs") are methods. It doesn't make sense to ask a noun to perform "where" or "length". Which part of this is confusing?

Re: Learning Haskell/Python makes you a worse C# programmer

#45

Post by olmobrutall »

tkellogg wrote: post #38

Wow, 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 wi…

I totally agree with you. Sometimes the anti-MS feeling here is absourd.

C# is an amazingly designed multiparadigm language with excellent tooling that works in plenty of OS and devices. If it will come by google the open source world will be wet already. Having an ideology is ok but shouldnt be confused with technical merits. Some examples:

IQueryabe and expression tress let you write expressive queries that run on the database but have compile-type checking. Amazing for mantaining big datacentric apps.

Async/await let you write complex asynchronous code as if it where usual imperative one. With for, try catch, etc... The compiler changes it for you.

And all this on a real language that runs fast and you can use in your work to build phone apps, web apps, win apps and also, but not just, compilers and authomatic theorem proving applications.

Re: Learning Haskell/Python makes you a worse C# programmer

#46

Post by bmm6o »

njbooher wrote: post #22
omgtehlion wrote: post #4

TLDR: 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.

Make an remain method called Filter then. And one called Map while you're at it. What a non-issue.

Re: Learning Haskell/Python makes you a worse C# programmer

#47

Post by philwelch »

njbooher wrote: post #44
philwelch wrote: post #42

Earlier quoted context omitted.

Distinguishing between attributes and methods in your interface violates encapsulation. The only thing an object's interface should be worried about is what messages it responds to, it shouldn't have to expose whether it responds to messages by fetching a variable or calling a procedure. On the implementation side, if you just want to expose a variable then attributes are fine. Outside of your object, though, who car…

Objects are nouns. They have attributes. Some of them can perform actions. Those actions ("verbs") are methods. It doesn't make sense to ask a noun to perform "where" or "length". Which part of this is confusing?

It's not confusing. It's just less useful. If you think of objects as having attributes and methods, you're just treating objects as bundles of functions and variables you can pass around. In essence, you're still doing procedural programming.

It's much simpler and more effective to think of objects as things that respond to messages. So instead of thinking it as asking the object to perform "where" or "length", think of it as sending the message "where" or "length" to the object and potentially receiving a response. This way you can expose more flexible and declarative interfaces, and let the object worry about which properties it computes on demand and which properties it caches or stores in instance variables.

You do have to consciously do this in C-derived languages, though. But it's easily possible.

Re: Learning Haskell/Python makes you a worse C# programmer

#48

Post by njbooher »

philwelch wrote: post #47
njbooher wrote: post #44

Earlier quoted context omitted.

Objects are nouns. They have attributes. Some of them can perform actions. Those actions ("verbs") are methods. It doesn't make sense to ask a noun to perform "where" or "length". Which part of this is confusing?

It's not confusing. It's just less useful. If you think of objects as having attributes and methods, you're just treating objects as bundles of functions and variables you can pass around. In essence, you're still doing procedural programming. It's much simpler and more effective to think of objects as things that respond to messages. So instead of thinking it as asking the object to perform "where" or "length", thin…

I'd rather not introduce event-handling semantics to a list of strings. It's easier to add a 'filter' method. Granted, a distributed task queue might benefit from this, but I'd still rather not have it baked into everything.

Re: Learning Haskell/Python makes you a worse C# programmer

#49

Post by philwelch »

njbooher wrote: post #48
philwelch wrote: post #47

Earlier quoted context omitted.

It's not confusing. It's just less useful. If you think of objects as having attributes and methods, you're just treating objects as bundles of functions and variables you can pass around. In essence, you're still doing procedural programming. It's much simpler and more effective to think of objects as things that respond to messages. So instead of thinking it as asking the object to perform "where" or "length", thin…

I'd rather not introduce event-handling semantics to a list of strings. It's easier to add a 'filter' method. Granted, a distributed task queue might benefit from this, but I'd still rather not have it baked into everything.

What event-handling semantics?

Re: Learning Haskell/Python makes you a worse C# programmer

#50

Post by njbooher »

philwelch wrote: post #49
njbooher wrote: post #48

Earlier quoted context omitted.

I'd rather not introduce event-handling semantics to a list of strings. It's easier to add a 'filter' method. Granted, a distributed task queue might benefit from this, but I'd still rather not have it baked into everything.

What event-handling semantics?

Responding to messages or choosing not to is event handling.
Post reply on HN