RSS 2.0 | Atom 1.0

Sign In


# Wednesday, September 17, 2008
The learning curve is irrelevant
Something I've heard often is that "F# is too complex/functional programming is too hard". This is something that sorta came up in the comments here: http://www.atrevido.net/blog/2008/09/16/Why+NOT+F.aspx.

Why is this irrelevant? You only learn a language once. You pay the learning curve cost one time; after that, you have the techniques and power at your disposal. However, you pay the cost of code every time you read or write it. Since I'm going to read and write a lot more code than number of languages I learn, I'd much, much, prefer to pay this overhead once, up front, rather than in my code each time.

Of course, it's not necessarily this simple. It's possible to design a powerful language that renders code even more difficult. Regular expressions are perhaps a nice example of this; they're often called "write only" code. Every time I do a non-trivial regexp, I'm always going back to the reference. Another example are C macros -- text-based, they quickly let you get into trouble. The design of C# runs away from this and tries to make it very difficult to write code that is "hard" to figure out -- if there's any edge case where a feature might be confusing or not work, C# tends to not allow it at all.

F# design is different. F# doesn't try to shelter users - it gives you tools and lets you decide how to use them. It makes the assumption that if you're writing a program, *you have some clue of what you're doing*. F#'s tools are still safe (compared to say, C), but sure, you can go create a mess if you'd like.

Poor code quality is *not* something that should be fixed solely via technical measures. I liken it to using web filters to make sure "employees aren't goofing off on the Internet" -- this is a policy/management issue and should be solved via administrative means. If one of my devs is spending all day on 4chan but gets work done and adds value, what do I care? Similarly, if the code quality coming out is acceptable and the solutions work correctly, I don't care if it used macros, custom operators, "difficult" code, etc. The process to make sure code quality is high (code reviews) will take care of anyone abusing language features in stupid ways.

But in truth, F# isn't actually much more complex to use. To the beginner, what seems to be "unnecessary terseness" and a lot of complicated syntax is actually a very basic system in action. Many of the "built-in" F# features such as the |> pipeline operator are defined right in the language itself. There's no magic going on -- you can create your own functionality in exactly the same way. Once you understand the basic rules, you'll see that most everything else follows them.

But at any rate, why is "easy to learn" a benefit? Sure, it's handy to promote a language if people can pick it up easily, but it's not indicitive of long-term power. True, if you have a "web developer" who's going to add a few server-side scripts, it's nice that he doesn't have to learn much. But if you're developing an application of any substance, I fail to see how these help, given the negative effects of having a "simple" language.

P.S. On my site I'm not trying to infer that F# will take over the world or that C# will go away. I've met too many "professional developers" to realise that anything that requires thinking isn't going to achieve stellar adoption. I'm simply pointing out that the reasons come down to apathy and intelligence (with respect to the learning curve; there could be other reasons as well), regardless of how politically correct one phrases it.

Code | FSharp
Wednesday, September 17, 2008 8:49:06 PM UTC  #    Comments [6]  |  Trackback

Wednesday, September 17, 2008 11:05:02 PM UTC
Check out Erik Meijer's (of Haskell, LINQ, Visual Basic etc. fame) paper:

"Confessions of a Used Programming Language Salesman
Getting the Masses Hooked on Haskell"

Rasmus H
Thursday, September 18, 2008 2:23:33 AM UTC
Thanks, that was a good read. Unfortunately, I didn't really see any reasoning of WHY NOT for many things. He explains how they chopped down features and made VB/C# do some neat things. But it doesn't address what I'm asking. [But was still very interesting!]
Thursday, September 18, 2008 5:22:49 AM UTC
Just a couple mostly-unrelated bits...

Learning curve is, unfortunately, not irrelevant. Yes, you only learn it once. *However*, that's a not-inconsiderable barrier to entry in usage.

From an idealistic perspective, I would agree that it'd be nice if C# didn't have to put on the safety rails. From a pragmatic perspective, they're necessary, and the removal of them in F# may help a few programmers (you, for example, are obviously one) and harm the usefulness and productivity of others. C# is at the good-enough stage, and the design of the language tends to "push" the user toward good, clean code. It wins heavily on that alone, for me. You say that "if the code quality coming out is acceptable and the solutions work correctly, I don't care if it used macros, custom operators, 'difficult' code, etc."--but, see, if other developers can't understand what he's doing, maintenance is going to be unnecessarily difficult. Unless your team is a bunch of equally brilliant F# programmers, there will be issues when the macros and custom operators and "difficult" code come out. Personally, I don't see any big wins from using something like F# that would make that any less problematic for me.

F# may not appear to be "unnecessarily terse," to you. I would still disagree, but I've already mentioned to you my opinion of it, and neither of us will change the other's mind. ;) (It also is aesthetically unappealing to me, but that's a bit of a "gimme" as my ideal of a good-looking language is, at the moment, C#, possibly with the Sing# additions.)
Thursday, September 18, 2008 2:28:03 PM UTC
Yesterday I listened to the podcast with Amanda Laucher and Ted Neward on .Net Rocks and I realized some things that are holding F# back

1) The syntax is alien to most programmers. It is clever, and once you pick up on it, it makes a lot of sense, but the number of Haskell/OCAML programmers in the world is greatly eclipsed by all of the C#/Java/C/C++/etc programmers. I think that Nemerle was a step in the right direction, for its syntax seemed far more accessible, but as I adjust to F# I'm starting to warm to it.

2) We're all used to thinking in objects, and we force everything to fit that mold. We labor under the belief that if we just find the right abstractions we can create the perfect architecture, not wanting to admit that our paradigm is ill suited for some things. In the podcast the hosts asserted that you'd never want to write a CRUD application in F#, and to Ted's credit he came back and cast a critical eye on that, pointing out that elements of such an application like SQL and the database itself lend themselves well to functional concepts.

3) There is a tendency to define functional programming in terms that are esoteric or irrelevant to most programmers. For instance, immutability is *not* one of those things that fires the imagination of the common coder. Recursion is a theoretically nice and elegant approach to solving some problems, but outside of academia, why not just use a loop? Similarly, passing functions is all well and good, but we've got mechanisms such as delegate to achieve roughly the same thing. And as for being great when it comes to applications requiring a lot of processes/threads, we'd rather hope that we can mostly avoid developing such apps.

Coming back to your post, the learning curve is quite relevant because there is a syntactical and conceptual chasm to cross. Developers not only need to understand a new way of expressing concepts, but also how that expression brings them any benefit over what they are currently doing. Unless this can be done, it will be hard for a programming language such as F# to get the attention that it deserves.
Friday, September 19, 2008 5:49:08 PM UTC
@Ed, thanks for your comments.

You say that "yes, you only learn it once", but then go back into how teams cannot consist of high quality developers, which is exactly my point. I wouldn't hire anyone for C# who wasn't capable of dealing with other languages in the first place. (Most people I've hired didn't even know C#.) The point of code review is to make sure everyone's on the same level and that there aren’t things that are poorly done.

As far as terseness/aesthetics, yep, totally personal opinions. I didn't like F# syntax at first, but it's growing on me.

The benefits? I'll go into that another day. Suffice to say that when I'm in C# and field declarations start pushing 400 characters, F# starts looking nice. When I have to copy a method's signature into its body over and over, yea, F# is nice. This is apart from any of the functional issues: things like random perf issues because of delegates, lack of inner functions, etc...
Friday, September 19, 2008 6:00:12 PM UTC

1) Yep, it's surely different. I don't see what that really has to do with anything. For me, it was "fun" to have a new syntax, but I really don't care because F#'s a one-of-a-kind, best-of-breed for the .NET platform. So even without #light, I'd still be very interested in it.

2) Yes, the silly OO ideas are overdone. A CRUD layer in F#? Are you kidding me? At *minimum* any code like that is going to be easier in F#, and F# would handle it much nicer. FWIW, my CRUD layer is "function" in that it's completely type and function based, no "OO". In fact, you could even come up with a LINQ-to-SQL + Update/Insert with F#. (You could do it in C#, but Expression<T> seems less capable than quoted code.)

3) Delegates to achieve roughly the same thing? *EXACTLY*. I know it's not true, but I'd expect C# programmers to be actively using delegates in their code. Once you start with that, the limitations of C# start really shining, and syntax that handles it better should be a natural desire.

You and Ed are both right that this prevents people from getting into F#. But my point wasn't that. My point of "it's hard" is not an excuse. Ed says he's fine enough with C#. Well, I don't know what apps he's working in, but I haven't seen any "good" cases where F# isn't going to come out on top (with my previously mentioned caveats). So, to any professional developer, these issues aren't issues enough in light of suffering in every other app.

Now I KNOW F# won't get picked up. Just sitting there by itself, it won't cross the chasm to make others say "oh hey, I should get into F#" - learning better approaches is the responsibility of the developer herself.
Please login with either your OpenID above, or your details below.
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Live Comment Preview