Feedback Request: Conference Talk Proposal

Hello,

I want to give a talk on language-ext at a programming conference in Ohio (USA) https://www.codemash.org/ and wanted to at least make @louthy and others here aware of this fact.

I don’t expect others to take their precious time engaging in a lot of hand-holding or back-and-forth feedback/help (unless anyone is genuinely interested), but do have a few upfront questions

• Is this okay for me to do? If so:
• How and how often should I give credit for all the work everyone else has done?
• Any general “do’s” and “don’ts” for discussing the library and the philosophy behind it? (I realize this is a much more open ended question)

For reference if anyone’s interested, here’s the proposal I am currently planning submit to the conference organizer by 8/31 at midnight EST, apologies for the late notice on this overall.

The C# of Tomorrow, Today: Functional Programming with LanguageExt


C# has added many functional programming inspired features throughout its lifecycle, such as lambdas, LINQ, and pattern matching. 

These and other steady additions over the years have some programmers eagerly awaiting the day when C# overtakes Scala as a fully featured multi-paradigm powerhouse, rivaling Haskell in its functional capabilities while still allowing full object-orientation.

For those who simply can't wait, the language-ext library by Paul Louth has made major strides forward and become the de-facto standard for serious functional programming in C#. In this talk, we'll give a basic introduction to functional ideas, highlight some of the extremely useful features language-ext brings to the table, and explore the ways the library pushes C# to its limits.

[louthy]

Hi Michael,

Is this okay for me to do? If so:

For sure!

How and how often should I give credit for all the work everyone else has done?

Not sure you need to give any credit, obviously I’d be happy to have a mention, but the contributors list is there for all to see - so I guess for anyone visiting the repo they can see the list. I can’t think of another simple way of highlighting contribution (in a talk).

Any general “do’s” and “don’ts” for discussing the library and the philosophy behind it? (I realize this is a much more open ended question)

I guess the only “don’ts” I can think of would be: Don’t throw OO under the bus. A room of C# heads are likely to react badly to that, maybe keep it focussed on the positive aspects of C#'s development over the years (generics, LINQ, lambdas, records, pattern matching, tuples, etc.) - i.e. the language is gaining more FP inspired features, and so it’s right to have an FP focused library (Microsoft aren’t going to build it, so the community is).

However, feel free to throw dependency-injection frameworks under the bus (😆 ) and highlight that first-class functions are how FP does DI. There may be some useful bits about the philosophy on the wiki.

My primary objective with this is to enable: pure functional programming in C#, not just functional programming - as I believe that’s how we get to write large, stable, applications. Much of the library is directly inspired by Haskell frameworks, but also Clojure, and some F# (although not much from F#).

Immutability is also a big deal for this library - the immutable data structures are easier to use than the ImmutableCollections from Microsoft (and faster). There’s a really good talk by Rich Hickey called “Are We There Yet” - which discusses the concept of causality being modelled better with immutable data-structures (which in turn leads to more reliable, and easier to reason about, code).

If you have a script or slides, I’m happy to do a review for you beforehand. Just ping them over to plouth at gmail.

[louthy]

I think OO is a tool just like FP is a tool. It has its place, and for some tasks is better. The problems with OO (as it’s practiced in industry) are:

• Mutable hidden state - hard to reason about
• Leaky abstractions - interfaces aren’t composable like pure functions

Those two cause soooo many problems. But, it’s entirely possible to create classes that are immutable with methods that are pure and declarative. OO has extensible type hierarchies (inheritance) which FP doesn’t have (the so called ‘Expression Problem’) - so it’s good to remember that we’re expanding our toolbox, and not trying to solve every problem with the OO hammer.

There’s also a meme of engineers in FP-land looking down on the OO crowd. It even leads to languages like F# being compromised because the designers consider certain language features to be ‘too hard’ (like higher-kinds). I doubt anybody likes being told they’re not smart enough or that they’ve been doing it wrong. So, giving everyone the tools to make their own minds up I think is the best approach (this is IMHO of course).

The Clojure influence is definitely clear

Transducers in the next major release too 😉