The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

vaskir (1) [Avatar] Offline
After reading a half of the ch. 13 I cannot understand several things:

1. The problem is solved completely in OOP paradigm. What's the point? The single question that will appear in mind of an average C# dev after reading it will be: "why all this unusual syntax, why the whole new language if I can do exactly the same things in C# but with far better IDE support?". And he's obviously right - the code seems was just translated to F# from C#, almost automatically.

2. Awful code duplication ( and

3. Infinite while loops + mutable vars (to escape) instead of recursive functions.

4. ADTs are not used to represent domain concepts - plane int, strings and so on are used everywhere.

5. F# 3.0 query expressions are not used, a strange mix of LINQ methods and Seq module functions are used instead.

6. Lots of annoying little things: failwith + sprintf instead of failwithf, string.Format instead of sprintf, unusual indentation and so on.

7. Private members instead on let functions everywhere.

8. No single module in the whole solution - even a bunch of constants are placed in a class as static members (

9. LINQ extension methods are used instead of Seq module functions.

10. There's no currying / partial application at all - a lot of ugly looking lambdas are used instead.

11. A hand-made parser + some tests for it instead of FParsec or something similar.

12. Manual XAML binding instead of using the Type Provider.

13. Functions are usually extracted irregulary, like this one:

14. Arrays are everywhere instead of lists -> the code is not as elegant due to lack of special operators (::, @).

In short, the solution for Chapter 13 is nothing but a not so good C# code which was directly translated to F#. I think, this approach cannot show/teach an average C# developer anything about why actually F# a so beautiful language (and yes, it's beautiful language).

Tomas Petricek (160) [Avatar] Offline
Re: Chapter 13
Hi Vasily,
thanks very much for your comments (and also for the extended discussion on Twitter). We will have a detailed look at all your feedback and make sure that we address your points.

The chapter 13 is less "cutting-edge" functional chapter, because it discusses compromises that some F# developers may need to make (or find useful to make) in the corporate "enterprise" environment where they need to interoperate or collaborate in larger team mostly used to C# programming patterns.

Your feedback is extremely useful, because it shows that we have failed to explain these compromises (or did a bit too many of them). We'll certainly review this and make sure to either, follow your advice, or clearly explain why a "better" solution was not used (because of some other constraints).

I agree that using F# in a more functional style leads to better code - and we have other chapters showing how to do that - but there are many ways to success with F# and we wanted to show multiple of them.