The whitespace i hate in languages like VB, because when you have very long code, it’s just plain hard to see where something ends, with brackets it’s completely non-trivial, cause they sorta jump into your face to say: hey look, i start here & end here ..i love brackets 🙂

And in the example where you say: {1..10} |> Seq.fold (+) 0;;
is more readable, sorry, but i find: Enumerable.Range(1, 10).Sum();
to be the most readable (and understandable) of what is going on. The F# example just looks like a bunch of mathematical gibberish to me.

Dropping the var doesn’t shock me at all tho i can understand some ppl might wanna keep it as a visual queue (like me for brackets).

Then for static imports ..i guess it won”t change much from extension methods, just do a (go to definition).

–
Robert

I usually wouldn’t reply to an Anonymous person, but your response is well written.

I too have to often read the code of others. This is life. The complexity or verbosity of a language doesn’t make this more difficult or more easy. I’ve decyphered perl code that was more complex than 8086 assembly and I’ve read perl code that was easier to read than Java in articles on java world. The language and its features do not matter her.

Static imports might be a little confusing, but Java has them and they don’t confuse the java folks. Your argument against would be the exact same argument against extension methods, but we have extension methods. Refactoring tools and good IDE tools make this a trivial no brainer. F12 go-to-definition will still work in Visual Stuido.

Your argument here against var shows that you don’t understand what var in C# is. It is not dynamic. C# 3 has no dynamic variables or dynamic typing. it is not quasi-dynamic. it is absolutely no different than explicitly putting a type before the variable declaration except that the compiler fills in the type from the assignment portion of the statement.

Type Inference we agree on. Good!

Whitespace: you have obviously never read or written either Boo. Python or Yaml. These whitespace significant languages have never suffered from what you describe.

Sorry, but on the three points you differ with me on, you arguments don’t hold up. I am open to changing my mind on these requests, but I would need to be swayed and these points aren’t swaying me.

Let me first preface the following comments with an important bit of information. I am in the consulting business and, as such, I often have to read code written by other developers and fix it or modify it. As I am sure you are aware, every developer has his/her own unique style. This is both a good and bad thing. The good should be pretty obvious. The bad, however, is that because everybody has their own style, it makes reading somebody else’s code difficult. Most of the suggestions you have proposed only make that job (deciphering someone else’s code) all the more difficult.

Static Imports – Confusing. If I am reading code in ClassA and I see a method call DoSomething, I expect that DoSomething to be a method of ClassA. Static imports mean I can no longer make this assumption and, instead, have to remember more of the entire design of your code.

Drop var – NO, just NO. This is just a terrible idea. C# is not a dynamic language. I do not want to have every typo I make end up being a new dynamic variable. I already struggle with this enough in JavaScript.

Better type inference – Unless I misunderstand, I think I agree with this one (at least, based on the example you gave)

Optional Whitespace Significance – OMG! No no no. Please no. If you don’t like C#’s syntax, use a different language. It’s bad enough that people can’t agree on whether to put braces on the same line as constructs, tabs vs spaces, commenting styles, etc. Bad programmers are far more common than good ones, and giving the bad programmers more options for creating write-only code only makes my life more miserable.