4 ms·

Glad to see C# (and ES too in a way) approaching towards F# (& co.) inch by inch with every release. Next and final step, introduce optional "indentation layout

by dualogy 10y ago

Glad to see C# (and ES too in a way) approaching towards F# (& co.) inch by inch with every release. Next and final step, introduce optional "indentation layout" to get rid of braces and semis and I'm a happy camper. FP through the backdoor! =)

lacampbell 10y ago
I'm wondering why the C# team is so keen on pattern matching - I feel like multiple dispatch would suit the language more and accomplish much the same thing. But C# is a weird beast in some ways - a pure OO language that keeps introducing features to make writing getters and setters more and more convenient. Maybe I just need to move on with the times. I still see a lot of value in OO, but it's clear it's not at all in vogue. I am glad that functional ideas - particularly immutable data, and anonymous functions - have come into the mainstream. But I don't feel the need to throw the baby out with the bath water.
- dualogy 10y ago
  > I'm wondering why the C# team is so keen on pattern matching It's kind of a pre-condition (though not in the current initial limited variation) for the introduction of Algebraic Data Types (as F# & co. have them), which I'd still be missing in C# if I had to get working on a C# codebase (might happen again soon, I just don't get any Haskell enquiries in my freelance channels =)
  - lacampbell 10y ago
    With multiple dispatch, you could already use the existing way of having sum types - class hierarchies - without introducing a second kind. I just don't see why you want both inheritance and ADTs in the same language. But it's entirely possible I'm missing something, I'm an amateur PLT enthusiast at best.
    - dualogy 10y ago
      Would just be syntactic sugar anyway, F# surely compiles its ADTs and parametric polymorphism down to something supported in MSIL bytecode.. but potentially powerfully productive "sugar", any highly expressive language is 80-90% sugar (just the right kind) over a much smaller intermediate core language of way fewer actual primitives
ttd 10y ago
Whitespace-as-syntax is something that I really disagree with (and I don't think I'm the only one). Once you become proficient in a language, the braces, semicolons, and parens become almost invisible structure, involving no cognitive overhead. This is one reason why I've never understood the objections to Lisps with respect to their use of parens.
- dualogy 10y ago
  > Whitespace-as-syntax is something that I really disagree with That's why I suggested "optional" ;) given how powerful .net tooling is, there'd be a dotnet --flipformat CodeFile.cs command that IDEs/editors would invoke from a button/menu. (I like Haskell's approach here, "layout-by-indentation first" but semis accepted for multiple-things-on-one-line and you can actually selectively have blocks in braces where the default indent-layout is inactive as your blocks are now brace-layouted.) I was just half-joking with the above, it's just that once you get enough FP sugar in a language to actually be able to effectively write "FP style" that the desire for such syntax evolves, to wit: EcmaScript's fat-arrow functions or C# similar fat-arrow "expression-bodied methods/properties"

by dualogy 10y ago

lacampbell 10y ago

I'm wondering why the C# team is so keen on pattern matching - I feel like multiple dispatch would suit the language more and accomplish much the same thing. But C# is a weird beast in some ways - a pure OO language that keeps introducing features to make writing getters and setters more and more convenient. Maybe I just need to move on with the times. I still see a lot of value in OO, but it's clear it's not at all in vogue. I am glad that functional ideas - particularly immutable data, and anonymous functions - have come into the mainstream. But I don't feel the need to throw the baby out with the bath water.

dualogy 10y ago
> I'm wondering why the C# team is so keen on pattern matching It's kind of a pre-condition (though not in the current initial limited variation) for the introduction of Algebraic Data Types (as F# & co. have them), which I'd still be missing in C# if I had to get working on a C# codebase (might happen again soon, I just don't get any Haskell enquiries in my freelance channels =)
- lacampbell 10y ago
  With multiple dispatch, you could already use the existing way of having sum types - class hierarchies - without introducing a second kind. I just don't see why you want both inheritance and ADTs in the same language. But it's entirely possible I'm missing something, I'm an amateur PLT enthusiast at best.
  - dualogy 10y ago
    Would just be syntactic sugar anyway, F# surely compiles its ADTs and parametric polymorphism down to something supported in MSIL bytecode.. but potentially powerfully productive "sugar", any highly expressive language is 80-90% sugar (just the right kind) over a much smaller intermediate core language of way fewer actual primitives

ttd 10y ago

Whitespace-as-syntax is something that I really disagree with (and I don't think I'm the only one). Once you become proficient in a language, the braces, semicolons, and parens become almost invisible structure, involving no cognitive overhead. This is one reason why I've never understood the objections to Lisps with respect to their use of parens.

dualogy 10y ago
> Whitespace-as-syntax is something that I really disagree with That's why I suggested "optional" ;) given how powerful .net tooling is, there'd be a dotnet --flipformat CodeFile.cs command that IDEs/editors would invoke from a button/menu. (I like Haskell's approach here, "layout-by-indentation first" but semis accepted for multiple-things-on-one-line and you can actually selectively have blocks in braces where the default indent-layout is inactive as your blocks are now brace-layouted.) I was just half-joking with the above, it's just that once you get enough FP sugar in a language to actually be able to effectively write "FP style" that the desire for such syntax evolves, to wit: EcmaScript's fat-arrow functions or C# similar fat-arrow "expression-bodied methods/properties"