Software Development

Book review: O'Reilly's Programming F#

After reading O'Reilly's Programming F#, Justin James says his zeal for the language is greatly diminished. Find out why.

A programming language that I have been very excited about is F#. So when I won a door prize at the Columbia Code Camp earlier this year, I jumped at the chance to get the copy of Programming F# by Chris Smith (published by O'Reilly). Although it wasn't a bad read, I was fairly disappointed because I don't think the book is very useful for most people who want to learn F#.

What I liked

Of the programming language books I've read (or tried to read) over the years, this was one of the easiest to read. Unlike my experience with The Ruby Programming Language, I was not bogged down for the better part of a year trying to force myself to slog through it. I got through Programming F# in well under a month. The chapter and section divisions are reasonable as well. Another nicety to this book is that it did not dwell on the usual "todo list" or "recipe database" applications. I also appreciated that the book was not dependent on jargon or "language geek" terminology to get the points across, despite the fact the F# very much appeals to that segment of the marketplace.

Why I was disappointed

I don't think the author did a good job of teaching F#, which made it difficult for me to stay engaged in the book. The author's biggest mistake was never once showing the power of F#. I am intrigued by the language because I have heard of dramatic reductions in the size of code for algorithm processing, but the author never shows this side of F#. I can understand that he perhaps wanted to evangelize F# as a language for day-to-day work, but after reading this book, I feel that nearly every example to show this was actually counterproductive. It looked positively miserable to use F# in a "general computing" capacity in the examples. After reading this book, there is no way that I would tell someone to replace C# or VB.NET with F#. So when the author spends so many pages with information processing style examples, I felt that my time was wasted. The reader would be better served if the author stuck to algorithmic programming, and then showed that F# is perfectly capable of interfacing with other .NET code in case it needs to talk to the .NET Framework or code written in another language.

And if you were looking for ways to improve your algorithmic code by switching to F# (which is why I was reading the book in the first place), the only thing the book really made clear is that F# is great if you need to write complex switch/case statements because of its pattern matching capabilities. While a substantial part of the book is devoted to the functional programming style, this section is not about "how to leverage functional programming" or "where to leverage function programming" or even "when to leverage functional programming," it was about "the feature of F# that fit the functional programming paradigm" like continuations. Since the author didn't show how to really make good use of F#'s capabilities, I was left thinking that I could just use lambdas in C# or VB.NET and save myself the agony of this syntax.

Syntax is another issue. It is not the author's fault that F# is a very symbol-heavy language (actually, it partially is, the author was on the F# team), but he makes the mistake of explaining a symbol once, and then using it without reinforcing the meaning or the purpose; as a result, it is very easy to get lost in the examples. I admit that about halfway through the book, the examples stopped making sense to me, and I stopped looking at them; I simply could not understand the examples once the number of symbols in any given example got too high. If I was sitting down with a compiler and a debugger and walking through the examples, they would have been good, but without that tool it was hopeless.

Conclusion

I really wanted to like F#, and I really want to find a place for F# in my toolbox, but my zeal for F# has been severely diminished after reading this book. I am going to give Real World Functional Programming a shot next, but I am at the point where I feel that, if no one can properly explain F# or functional programming with regards to F#, then maybe it isn't worth my time.

Have you read any books about F# that you recommend? If so, please list them in the discussion.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

21 comments
michaelm2010
michaelm2010

Justin: I'm sorry that a poorly-written/presented book dimmed your view of F#. Although being a C# person, I've viewed several video demos and several F# articles, which highlight the exciting possibilities of this new Functional language. If given the right exposure to F#, you may even see how C#, VB and related languages may soon fall by the wayside (or at least become marginalized). I try to check out a book's rating on Amazon.com or by using Google to see how other readers rate a text. Apress offers a pair of F# introductory texts, and you can also view numerous online videos from Microsoft evangelists who also demonstrate coding examples in F#. Don't give up hope on F#, since it apparently is not going away (now integrated with VS2010 as well). Michael.

semi-adult
semi-adult

In a larger sense, most of what's published now on technical topics such as this has serious weakness. [Disclaimer: curmudgeonly rant follows. /] There was a time when technical product came with documentation that documented. You could expect three or four items in the box, including a piece on installation, a geek book that laid out internals or at the least the API, and a usage guide with examples that worked. The software publisher wrote those books and put them in the box. Those days are gone. There was a shift in our subspace decades ago, when accountants got in the game and the actual costs of development moved from trivial to driving force. The first obvious sign of this was when actual books disappeared from product shipments. For a while there were files on diskette or CD called 'documentation', but this of course was a cruel hoax. Today's world hides what information there is, useless or otherwise, on websites designed to enhance tendencies to rage and aggression. At the same time the original books disappeared, business-minded souls outsourced documentation to specialty houses. The software operations got rid of something they didn't like to do, and a new category of profitability was created with deals and contracts for everyone. The books became just another object in the game. I know part of the change has to do with complexity. Anything like F# would take several volumes to cover, plus the platform subjects necessary to get it to run at all. Getting a committee of geeks (who actually wrote a product, much less knew it) to write a coherent and thorough explanation would be outside human expectation. The bean counters would be apoplectic at the cost of it, not to mention the delay in 'time to market', which translates for them into delayed income and therefore upsets the 90-days-or-else gene. A common notion of documentation is to have several individuals, who may or may not ever sit together in a room for coffee, generate specific sections of a huge collection of islands. This leads to hours of fascinating investigation for those who have the temerity to try and find connections between the parts. Sometimes it produces extensive somewhat-parallel explanations of what might be the same thing in different sections, although terminologies or other minor details might not mesh well. One sign of decay is the segregation of 'writing documentation' into a ghetto of 'editors' and 'versions'. The game seems to be to write the most bland and general pap possible, as quickly as possible, then to 'edit' (I use the term loosely) and ship. The 'editors' (again loosely) are not necessarily the writers, and may only occasionally be users, much less technically significant. Having someone that writes a few spreadsheets a year as the arbiter of content for a new text on programming doesn't really make sense. And of course there's the wonderful world of new versions. The 1600 page monster is given a few paragraphs, happily scattered throughout, that mention the improvements, but nothing like a whole chapter in one place, or anything resembling a reason why it matters. Actually rewriting affected sections? Surely you jest. That would mean having to PAY.... oh never mind. The most recent trend is to just leave it to the cloud. Spend a few otherwise useless hours online trying to find something when you need to learn a specific thing, a 'how-to' topic. Be prepared. Bring coffee, and Xanax. There are many hits for almost any search, but there's only a chance of any one result that truly gives you more than a possible code fragment that MIGHT come close to working in YOUR requirement. Don't get your hopes up for an explanation in useful terms. You've only begun to touch the sore spot. There's nothing wrong with profit. However, schniding for profit has some drawbacks. ============================ PS -- O'Reilly is, of course, the brightest spot in documentation these days. At least half my bookshelf comes from them.

Justin James
Justin James

This book really made me feel a lot less excited about F# than I was before. Has this ever happened to you? Or have you had the opposite experience, where reading a book about a language made you want to try it? J.Ja

Justin James
Justin James

... by and large focuses far too much on syntax, with an assumption that the developer is familiar with the functional programming paradigm and how/where/when best to use it. I've look at the other books on Amazon, and for the most part, they follow this formula. The "Real World Functional Programming" book seems to be the only one that may deviate from the norm, and it's next on my list. I agree that F# is a cool tech. I've been a proponent of it for about 3 years now; I was one of the first tech writers to talk about it (my first F# article was in 2007!). But at the same time, it gets kind of old wondering if it is a solution in search of a problem. :( J.Ja

Justin James
Justin James

The Perl docs are the standard that I hold other docs to... they explain not just the "how" but also the "why" as well as the "why not". They also have a lot of "cookbook" type stuf that shows you how to accomplish common tasks and why that way is the best way. It kills me how bad the MSDN stuff is for .NET. It is filled with "worst practices" (or at least "not best practices") and most of the examples are useless. Copy and paste the code from MSDN into a code file and run the VS code style system on it, and see all the little nags it comes up with. Their examples don't even match their own code standards! While I came around a bit after the "Golden Age" for a lot of this stuff, I did catch some of it. My copy of Delphi 1.0 had some great books that came with it. For that matter, all of the Borland stuff had good docs. Microsoft stuff used to come with huge books in the box, and they were useful. But, as you say, someone discovered that this stuff cost money, and now vendors like to pretend that wikis, search engines, and Q & A sites like Stack Overflow are an effective substitute for actual docs, meanwhile the book publishing industry thrives on filling the gaps. Funny how so many books are written by people on the team, when that used to be part of their day job? J.Ja

ITOdeed
ITOdeed

IMHO, there hasn't been a good book written for programming since "Running DOS," by Van Wolverton.

jvansanten
jvansanten

Justin, Thanks, as always, for your thoughtful commentary on the programming scene. A note on bibliography, Expert F# 2.0 by Don Syme et al, was apparently released last month, to reflect the same concerns addressed in Expert F#, but based on the new language. My reaction to _Programming F#_ was almost the precise opposite of yours. I'd read through chapters of Expert. That had acquainted me with the strategies and concepts underlying functional programming. But, I needed a better handle on the syntax to actually implement that functionality. That's what _Programming_ did for me. For me, functional programming offers a paradigm shift. That seems to present itself much as the elephant did to the blind men. Perhaps it's only when the many perspectives are combined, that the true picture emerges...

gbrownsword
gbrownsword

sorry for the duplicate!! disregard this and read the previous!!

gbrownsword
gbrownsword

Give this one a try if you haven't already!! Foundations of F# "Apress" Copyright 2007 by Robert Pickering ISBN-13: 978-1-59059-757-6 ISBN-10: 1-59059-757-5 You might find it to be a decent book, Good luck. www.ljacks.info

gak
gak

I fully agree with your description of the book, but my I reaction happened to be totally different. Our days everything is documented, just look into MSDN. Yes, sometimes there are discussions on the wonderful abilities of a non-static class without a public constructor and no info on how to get an instance of that, but it is more of exception than a rule. Lots of examples for everything are everywhere. So, why one may need a book for? My answer is to have something readable from beginning to end so that it is easy to understand where to look in MSDN and what to focus on in the examples. This book is good enough at that, so it must be a good book. Yes, this book does not spoon feed the benefits of functional programming; Google does. Yes, it silently assumes that while reading you have at least fsi handy, exactly like a book on archery silently assumes you have a bow.

Jaqui
Jaqui

I posted the url for your entry in a "review" of the book on the O'Reilly website. Maybe it will get the author to revise it. ;)

semi-adult
semi-adult

"Saving money" (or, if you like, "increasing profit") is one of the most expensive options possible. It does seem strange that people on the 'team' would be writing things ("documentation sold separately") that should be part of the product. If one were a cynic, one could presume that the bean-herders are happy that the cost to market is reduced, the writers are happy that they get paid for anything they can churn out, and the publishers are happy to be selling a couple of pounds of something. Disregard the actual user that pays fifty bucks or more per book on top of the cost of the product. My personal favorite for documentation goes back a bit farther. In pre-history, the documentation for IBM mainframe software was absolutely the best. There was a lot of it on every aspect of whatever they did. It was perfectly organized, the indexing was complete and accurate, the contents were clearly labeled, and everything worked. And if you had a legitimate question, there was someone you could call that actually knew the answer or would find it. As an example, the COBOL docs laid out every single item in absolute detail; every command was shown with every option, syntax was nailed, and even the casual user could use it. Here's something you may not have known that seems to have happened to a particular product line, and may have been emblematic for the whole subject. In the 90s, Borland basically subsidized writing documentation for Delphi (as you noted) plus other products such as Paradox. The content came from the real source, and essentially the physical publication was given over to outside printers. Somewhere in the game, as Borland slid into fiscal hell, they stopped subsidizing the work, and the printers simply refused to pay for writing. Whatever the deal was, it collapsed; within a matter of months ALL the books on Paradox simply disappeared from the shelves. And never returned. Delphi books seemed to suffer too, although not so immediately. I'm sure the accountants were happy. Most of the stuff on the shelves today is a criminal waste of trees.

Jaqui
Jaqui

C Programming, A Modern Approach 2nd Edition. by K.N. King knking.com is his website. a very well written course in working with C. since the author teaches programming in a university, he has a pretty good knowledge on how to educate people. :D

Justin James
Justin James

2007 is pretty out of date, unfortuately. F# has changed a lot since then, and in many fundamental ways. I remember working with it around that time, and it was different (for example, lazy evaluation was the norm, now it isn't). J.Ja

Justin James
Justin James

... I doubt it. The author recently left Microsoft to work for Google, if I recall. I did post an abbreviated version at Amazon too, publishers (or authors, at the very least) seem pretty good at monitoring those. J.Ja

ITOdeed
ITOdeed

I agree, just as everything about programming on the Internet is a criminal waste of energy. The "beginner" online courses are okay for people who are just curious about a particular language. But as far as advanced features go, it's a jungle out there, or rather, a wasteland, online or in bookstores. I'm looking for reference material about how to program USB ports. Anybody know of a source?

gbrownsword
gbrownsword

I see. Thanks for the info. One of the many books I wanted to get around to reading in my collection, but now I won't have to waste my time. Oh so precious little of it!!!

Justin James
Justin James

I get where you are coming from (as someone who used FoxPro for a while and liked it), but F# and FoxPro have nothing to do with each other. F# would be miserable to do what FoxPro did, and vice versa. Beleive me, no one is encouraging people to move from FoxPro to F#. FoxPro was for data manipulation, F# is for algorithms more than anything else. I guess you can use the transformative stuff in F# to do some of what F# was for, but the data access story is entirely different. J.Ja

don.gulledge
don.gulledge

F#, proported as being this new efficent functional programming language seems like just another attempt by MS to capture the programming language and entrap the programmers into their little world just so they can make the money. They killed off the best functional language called Foxpro simply because it wouldn't provide the money return and the lock-in they desire. It was mature, object oriented and very functional. Now, they want the Foxpro people to leap onto F#. It's more hype than reality. Doesn't matter, they'll change it to Z# later anyway. MS has become more like a car manufacturer than a software company, they feel they have to change the models every four years just to stay current at the same time trying to foil anyone else from advancing.