3 ms·

Yeah, no way around learning do-notation even for the simplest of programs. And do-notation is kind of a DSL with a totally different feel than the rest of the

by olavk 12y ago

Yeah, no way around learning do-notation even for the simplest of programs. And do-notation is kind of a DSL with a totally different feel than the rest of the language. So getting started writing even simple toy programs in Haskell requires you to learn two languages. No denying that Haskell is a language with a very steep learning curve. (Or is it a very shallow learning curve? Never understood that metaphor. But you have to learn a lot to get started.) However it might make sense in a tutorial or course to teach do-notation first as a DSL for IO in order to get started. And only later, when the student have a good understanding of the core language and type system, introduce monads and show how IO is a monad and how do-notation can be used with other monads. The problem with the much maligned monad tutorials is that the audience typically is beginners who get stuck on on the IO monad and do-notation immediately after writing "hello world". But the tutorials try to explain monads as a general concept, which requires a pretty through understanding of things like higher kinded types and so on. An understanding the newbie getting stuck at "hello world" obviously doesn't have yet. Then the tutorials try to be accessible by using metaphors like a "monad is a specesuit", a "monad is burrito" etc. But knowing that a monad is a buritto doesn't help the newbie who gets inscrutable compile errors after adding a second putStrLn to "hello world".

bmh100 12y ago
In operations management, a "learning curve" is an efficiency curve plotted over time. I have most often seen it as a time-per-task-completed curve. The way it works is this: The time it takes to produce widget 2 ^ t is BASE_TIME * LEARNING_RATE ^ t. Example with 120 minute starting time and 90% learning rate: Widget 1 (2 ^ 0) takes 120 (120 * 0.9 ^ 0) minutes to produce. Widget 2 (2 ^ 1) takes 108 (120 * 0.9 ^ 1) minutes to produce. Widget 4 (2 ^ 2) takes 97.2 (120 * 0.9 ^ 2) minutes to produce. Widget 8 (2 ^ 3) takes 87.48 (120 * 0.9 ^ 3) minutes to produce. Example with 120 minute starting time and 70% learning rate: Widget 1 (2 ^ 0) takes 120 (120 * 0.7 ^ 0) minutes to produce. Widget 2 (2 ^ 1) takes 84 (120 * 0.7 ^ 1) minutes to produce. Widget 4 (2 ^ 2) takes 58.8 (120 * 0.7 ^ 2) minutes to produce. Widget 8 (2 ^ 3) takes 41.16 (120 * 0.7 ^ 3) minutes to produce. If you plotted a curve of minutes per widget over time, you would note that the graph for the 70% learning rate would have a much steeper slope than that of the 90% learning rate. Looking at that you might say, "ah, high learning rates are great!" All else being equal, you would be correct. However, real world tasks with high learning rates often imply high base times and a proportionately large amount of time until proficiency or mastery is reached. That's why "steep learning curves" are "bad things", because it is going to take "a lot of effort" just to "get good" at the skill. To bring the point home, here are some contrived examples of "90%" and "70%" skills: Version control: 90% - copying and pasting files 70% - git Word processing: 90% - Microsoft Word 70% - vim and latex Databases: 90% - Excel documents in a shared folder 70% - PostgreSQL Web design: 90% - your web host's website builder 70% - Ruby on Rails 70% - hand coding in notepad This is just an introduction to the concept as I learned it. Two skills might have the same learning rate, but one might be much more productive than the other. Still this should help you understand the origin of "steep learning curve" and why that's usually considered a "bad thing."

by olavk 12y ago

bmh100 12y ago

In operations management, a "learning curve" is an efficiency curve plotted over time. I have most often seen it as a time-per-task-completed curve. The way it works is this: The time it takes to produce widget 2 ^ t is BASE_TIME * LEARNING_RATE ^ t. Example with 120 minute starting time and 90% learning rate: Widget 1 (2 ^ 0) takes 120 (120 * 0.9 ^ 0) minutes to produce. Widget 2 (2 ^ 1) takes 108 (120 * 0.9 ^ 1) minutes to produce. Widget 4 (2 ^ 2) takes 97.2 (120 * 0.9 ^ 2) minutes to produce. Widget 8 (2 ^ 3) takes 87.48 (120 * 0.9 ^ 3) minutes to produce. Example with 120 minute starting time and 70% learning rate: Widget 1 (2 ^ 0) takes 120 (120 * 0.7 ^ 0) minutes to produce. Widget 2 (2 ^ 1) takes 84 (120 * 0.7 ^ 1) minutes to produce. Widget 4 (2 ^ 2) takes 58.8 (120 * 0.7 ^ 2) minutes to produce. Widget 8 (2 ^ 3) takes 41.16 (120 * 0.7 ^ 3) minutes to produce. If you plotted a curve of minutes per widget over time, you would note that the graph for the 70% learning rate would have a much steeper slope than that of the 90% learning rate. Looking at that you might say, "ah, high learning rates are great!" All else being equal, you would be correct. However, real world tasks with high learning rates often imply high base times and a proportionately large amount of time until proficiency or mastery is reached. That's why "steep learning curves" are "bad things", because it is going to take "a lot of effort" just to "get good" at the skill. To bring the point home, here are some contrived examples of "90%" and "70%" skills: Version control: 90% - copying and pasting files 70% - git Word processing: 90% - Microsoft Word 70% - vim and latex Databases: 90% - Excel documents in a shared folder 70% - PostgreSQL Web design: 90% - your web host's website builder 70% - Ruby on Rails 70% - hand coding in notepad This is just an introduction to the concept as I learned it. Two skills might have the same learning rate, but one might be much more productive than the other. Still this should help you understand the origin of "steep learning curve" and why that's usually considered a "bad thing."