Hacker News new | comments | show | ask | jobs | submit login

C# includes the static LINQ method "FirstOrDefault()" for any types implementing IEnumerable, e.g.:

    var firstNumber = numbers.FirstOrDefault();
(This isn't strictly the same as what you described if "None" is different from "null".) Once such a method exists, does it matter how many lines of code it is written in? I posit that every language feature in a reasonably intelligently designed language serves a valuable purpose, and that everybody has different needs, and the verbosity in C# serves certain needs.

Here's an implementation in C# that is a function on types T implementing the IList interface (rather than IEnumerable like LINQ does):

    public static T Head<T>(this IList<T> list) {
      return (list == null || list.Count == 0) ? null : list[0];
    }
It is used in the same way as the FirstOrDefault() example above. Much more verbose, I'll agree! But the real question for this thread is is it less convenient, and if so why? All the verbosity stems from just a few logical places:

1. the 'option' function you have in your example. In reality, your 'option' is doing all the work I did above, which means that comparing the verbosity of your sample code to the C# equivalent of FirstOrDefault() is perfectly valid in my opinion :)

2. the explicit return type. This serves a valuable purpose in my opinion.

With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one. I once had a bug like this in VB6 years ago: I changed a method to use an integer instead of a string, and VB's automatic type casting happily allowed the rest of my code to function... until in the middle of a demo I ran a function I hadn't tested and default value of 0 broke something expecting an empty string! My lesson: type inference can be dangerous.

It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.

There is a school of thought that says your unit tests should cover this aspect of the specification... but then all I'm doing is implementing explicit types in a roundabout way - let the compiler do that I say! That being said I don't know if ML/Haskell have 'interface specification' types to ward against this, where you need it (and everywhere else you get to save on verbosity)? That would be a nice improvement to C#: private methods can use extended type inference, anything public (including implementing an interface) need to be more explicit.

3. syntax: visibility (public), static modifier and return statement. This is a matter of personal preference. With Resharper in Visual Studio each of these words costs me 2 or 3 keystrokes, and if I like I can use templated code snippets to reduce that for any situation, so I'm not too bothered :)




I think you're underestimating how much work the type system is doing here: `option` isn't a function. It's part of the return type definition. The whole point of having a type system as strict as ML's or Haskell's is to avoid the sort of problem you had in VB6. Automatic typecasting is a very, very different beast to type inference: in Haskell, your problematic code likely wouldn't have got past the compiler. You're precisely wrong when you say that it's easy to break the hd function by changing the implementation to return a different type. If you do that, your program won't build.


ML's and C# have their strengths and weaknesses, but from a type theory perspective, ML's type system is simply much more powerful when it comes to ensuring correct code than C#'s. Take, for example, your implementation of Head, what if you messed up and wrote:

> return (list.Count == 0) ? null : list[0];

Would the C# compiler catch it or would you not find out until runtime? An ML compiler would tell you that function is wrong.

What about using Head? If you have a list of integers, will the compiler let you do:

> Head(integer_list) + 2

An ML compiler won't, because it's not safe.

> This isn't strictly the same as what you described if "None" is different from "null".

It is, but the important thing to note is I had to specify that the function, 'hd', can return 'null', by wrapping it in the option type. 'null' is only a valid value for option types. If I write:

> val hd : 'a list -> 'a

I could not return 'null'/None, it simply isn't valid. And the compiler wouldn't let me.

> the 'option' function you have in your example

'option' is a type, not a function (I suppose you can make some high level argument that all types are functions over values or something, but not relevant here). And 'option' itself isn't really even a type, it requires a type variable, so "'a option" is a type where "'a" is replaced by a concrete type at some point. It's not doing the work you described above, it's actually defining a contract between me and users of hd and the compiler.

> With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one.

No, it isn't actually. If I change the return type the compiler will not compile my code.

> I changed a method to use an integer instead of a string

This cannot happen in ML, the compiler won't compile it because an integer isn't a string. What you described is not type inference, it's dynamic typing. The only danger of type inferencing in ML is annoying type errors during compilation. I'm not sure you actually grok what type inferencing is.

> It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.

Actually, refactoring code in ML tends to be pretty easy. If you change the type of something the compiler won't compile your code, so you know instantly where you messed up and can fix it. You can construct code to make this not work, but in general that isn't the case. See https://ocaml.janestreet.com/?q=node/101

> let the compiler do that I say!

Exactly, and an ML compiler definitely does more of this than the C# compiler. At a cost, of course.

Your post has several statements which suggest you are ignorant of ML and type theory. If you're interested in learning more, check out Benjamin Pierce's book "Types and Programming Languages". Or just spend a weekend with Ocaml or Haskell and prepare for the compiler to frustrate you with it's strictness :)




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: