language-ext

this.X, Y ?? this.Y, Z ?? this.Z); Then you can use named parameters to do partial updates: value = value.With(X: 456, Y: "World"); Obviously it's still more boilerplate than F#, but C# is never going to have significantly less until we get proper record types and ADTs. > Functional programming is also seeping in but again tons of boiler plate. Do you have an example? It's something I've worked on quite heavily over the past few years, so I'm always looking for areas to try and improve the lot of C# devs trying to write functionally. [1] https://github.com/louthy/language-ext/releases/tag/v2.1.0

I'll get errors that the F# DLL expected a function or type to exist that I'd removed from the C# one. And the absolute classic about the necessity for ordering files in the project in dependency order... I get that this reduces cyclomatic complexity, and that's laudable, but it's just a pain once a project gets to a reasonable size. For my open-source projects I had to drop F# APIs from the projects because I couldn't create net451 and netstandard1.X project files that would build, pack, and be deployable to nu-get. Also the interop story between C# and F# really isn't that good. Even though it's shouted from the rooftops as a main selling point. Everything prefixed with FSharp is ugly, FSharpFunc can't implicitly convert to Func, FSharpOption evaluates to null for None, so you get none of the safeness in C#, FSharpAsync is reeeaaally difficult to consume from C#, etc. This means we have to build an interop layer and that always feels like needless effort. It would be much better if there was some tooling support that could create proxies between the F# and C# worlds. It always feels like there's something in the way. And the way of human inertia is that those seemingly minor niggles will tend to put people off full-scale adoption. I love F# as a language (well, not its OO grammar, but I don't use that), but C# + language-ext actually gives me pretty much everything I need (bar ADTs). [1] https://github.com/louthy/language-ext

m variablename in asString(many(noneOf('='))) from ws2 in ch('=') from openbrack in ch('(') from filepath in asString(many(noneOf(')'))) from closebrack in ch(')') select new JCLCommand(variablename, filepath); But the power of parser combinators are their reusable nature. So I'd break that down to a set of tools: static Parser<A> token<A>(Parser<A> p) => from x in p from _ in either(spaces, eof) select x; static Parser<string> symbol(string x) => token(str(x)); static Parser<string> identifier = token(asString(many1(alphaNum))); static Parser<A> quotes<A>(Parser<A> p) => between(symbol("\""), symbol("\""), p); static Parser<A> parens<A>(Parser<A> p) => between(symbol("("), symbol(")"), p); static Parser<string> quoteText = token(quotes(asString(many(satisfy(x => x != '"'))))); static Parser<string> parensText = token(parens(asString(many(satisfy(x => x != ')'))))); Then your final parsers would look like this: static readonly Parser<JCLCommand> JCLText = from open in symbol("$") from command in identifier from content in quoteText select new JCLCommand(command, content); static readonly Parser<JCLCommand> GlobalText = from variablename in identifier from ws2 in symbol("=") from filepath in parensText select new JCLCommand(variablename, filepath); static readonly Parser<Seq<JCLCommand>> Commands = from _ in spaces from commands in many1(either(JCLText, GlobalText)) select commands; Which is much easier to understand I think. It's not exactly the same as it defines what an identifier is, but it's much more tolerant of rogue spaces because of the token parser. This is definitely the most compelling aspect of parser combinators for me, the way they compose so elegantly.

gain, no stress. Then if they say anything interesting about a part of a project I may drill down a bit more to make sure they understand the subject they're talking about. Which is slightly more stressful, but if they're competent, they'll know. I very rarely go into algorithms and data structures. It'll usually be if I'm concerned about a junior dev not having enough CS knowledge. I then send them an email post interview (if I think I want to see them again for the second interview). The email will have a link to a partially complete project, I ask them to finish it based on a written spec. It shouldn't take more than 45mins - 1hour. The request in the spec is intentionally a bit obscure. I put at the end of the spec that "If you have any questions or problems, please email me. You won't be marked down for this." The obscureness of the test is to see who emails me to ask for help. That for me is a real positive sign. So I'm trying to create a real world test: * A spec to follow * Programming in a comfortable environment * Access to dev resource (Google/Stack Overflow/Their friends) * Access to their boss for advice And to avoid anybody trying to game it and blag their way with code that they didn't write, I quiz them about their decisions in the second interview. It works amazingly well. My dev team is something I'm super proud of. A good team of people who collaborate well and believe in the product. No hierarchy or in-fighting. It's a happy place to be. So I endorse this method :) [1] https://github.com/louthy/language-ext

ing, int>, Lst<string>, Lst<int>>(list); Or an Option: Option<int> res2 = ParseInts<FOption<string, int>, Option<string>, Option<int>>(opt); And it will happily map the bound values. FLst and FOption are essentially the 'class instances'. Functor is the 'type class', it's just a C# interface [2]: public interface Functor<FA, FB, A, B> { FB Map(FA ma, Func<A, B> f); } The key thing is that 'this' won't be used, so the first argument is the value to be mapped. FLst looks like this [3]: public struct FLst<A, B> : Functor<Lst<A>, Lst<B>, A, B> { public Lst<B> Map(Lst<A> ma, Func<A, B> f) => ma.Map(f); } And FOption like so [4]: public struct FOption<A, B> : Functor<Option<A>, Option<B>, A, B>, BiFunctor<Option<A>, Option<B>, Unit, A, B> { public Option<B> BiMap(Option<A> ma, Func<Unit, B> fa, Func<A, B> fb) => ma.IsNone ? fa == null ? Option<B>.None : fa(unit) : fb == null ? Option<B>.None : fb(ma.Value); public Option<B> Map(Option<A> ma, Func<A, B> f) => ma.IsSome && f != null ? Optional(f(ma.Value)) : None; } As you can probably tell, the amount of clutter from specifying generic type-parameters that the compiler could (relatively) easily work out on its own, is pretty annoying. Which limits it's usefulness somewhat. But if you want to write truly generic code, it's doable (with some caveats of course. you'll notice that the Functor type isn't quite as strict say the definition in Haskell). I'm currently updating my language-ext project to add type-classes [5] and class-instances [6], in the hope that the C# team will take pity on me and make this technique a language feature (it's been seriously turning my head inside out trying to make it work with higher-order types like monads). This is already being investigated by some Roslyn team members [7]. I figured this feature was unlikely to move seriously in the near term without some indication of real world need. [1] https://github.com/louthy/language-ext/blob/type-classes/Lan... [2] https://github.com/louthy/language-ext/blob/type-classes/Lan... [3] https://github.com/louthy/language-ext/blob/type-classes/Lan... [4] https://github.com/louthy/language-ext/blob/type-classes/Lan... [5] https://github.com/louthy/language-ext/tree/type-classes/Lan... [6] https://github.com/louthy/language-ext/tree/type-classes/Lan... [7] https://github.com/MattWindsor91/roslyn/blob/master/concepts...

uct<TInt, int>(); // 64 var flag = ("one", "two", "three").Contains<TString, string>("one"); // true var str = ("Hello", " ", "World").Concat<TString, string>(); // "Hello World" var list = (List(1, 2, 3), List(4, 5, 6)).Concat<TLst<int>, Lst<int>>(); // [1,2,3,4,5,6]