ThatGuyDuncan (68) [Avatar] Offline
#1
Are you advocating against TDD? I feel like the following holds just as true: "Unfortunately, the truth is that F# is a difficult skill to master, and if done \"wrongly\" can be extremely costly, with fragile code that's difficult to reason about and hard to change."

Sir, I contest! smilie
Isaac Abraham (75) [Avatar] Offline
#2
Point taken smilie

So I would answer with this (as someone who has done both TDD like a religious zealot and F# (also like a religious zealot smilie). It's *harder* to do things wrongly with F#. The language, the syntax, the compiler, the type system - all of them give you early warnings that you're doing something "wrong", and guides you towards the pit of success. Yes, of course, you can of course write poorer quality code or code that is difficult to read. The difference is that these warning signs can be spotted early and easily, and if you're coming from a C# / VB developer background, many of these rules / practices still apply.

TDD is a whole other ball game - I've worked on projects where we literally had to throw away dozens and dozens of tests, costing thousands of pounds to write in the first place, because we discovered too late in the day that they either were unmaintainable or didn't actual test what they were supposed to.

TDD done right is great - don't get me wrong. It's just it's value is diminished greatly in the world of F# (IMHO), although I still do it from time to time.
ThatGuyDuncan (68) [Avatar] Offline
#3
Makes sense!

I don't know your demographic, but I imagine it's going to be a lot like me: C# programmers who invest in themselves to become better; who have invested in TDD and reaped the benefits. Reading that section caused me "cognitive dissonance", and I doubt I'll be the only one. I personally would flesh out that assertion (ha ha) a little, even if only by including the information in your reply as context. You immediately dive into the REPL, so maybe if I came across the same claim, but later in the chapter, it would be easier to swallow. Hard to say -- I'm still reading. smilie
Isaac Abraham (75) [Avatar] Offline
#4
Indeed, that's exactly the demographic - and exactly my background, too smilie It *is* a bold (controversial?) claim to make, especially since unit tests *do* have a positive impact on C# when done properly - I can only say that this was my experience when I started working in F# more and more.

See how you get on as you get through the book smilie
monger (2) [Avatar] Offline
#5
I frowned when I read that chapter. Such a claim felt a little strange there, but I guess I see your point.
The more high-level the compiler gets, the less you have to care for certain issues. But I think testing doesn't go away, it just moves together with the language to a higher level.

You already mentioned JavaScript in the book. Another example would be, that .NET and other languages with a proper runtime have eradicated memory allocation and pointer problems, which would have needed serious testing effort in earlier compiled languages (e.g. C++).
You don't need to test what the compiler can already guarantee.

One thing that bothered me: TDD usually means you can already establish the contract of a method before it is actually implemented. But F# works so heavily with type inference, the return type seems to appear no sooner than you actually implemented the method, or am I wrong?

Long story short: I think I understand the point you are making in this chapter, but it took me a little time.