[Haskell-cafe] Most used functions in hackage

[Casey Basichis]

I just ordered Mathsemantics for a hefty $2.10.

Your article's were an enjoyable read and very informative.  I'll dig more
into you blog tonight.

I've read the Great Good book, Haskell school of music, and I'm working my
way through Real World Haskell. I've also read countless blog articles on
Haskell.

With a great deal read and understood about Haskell I have no confidence
that I can make anything in it at all.

Kurt Vonnegut retyped James Joyce's work to feel a great novel under his
fingers before writing his own.

Webster knew English better than Shakespeare.  Shakespeare was a master of
creation.

To be able to create from a small core and then extend those intuitions
with knowledge over time is to me far more effective than mastering
language and then attempting creation.

While not rigorous, getting hands on with high level practical libraries
and working by example would have built my intuitions far faster than all
of the countless reading and toy examples I've done.  The problem is, for
that approach, there isn't any material for a book or insightful blog post
to be written. Mimetics are mundane and unnecessary to those in the know.
 The teachers seem to be unaware of how their own intuitions were formed.

While learning the fundamentals my mind struggles to imagine how these
basic concepts play into the larger picture - how would they use foldr to
build persistent?  I don't have real answers to those questions but it's a
constant distraction.

I am certain that sitting down with a few simple examples of how to use a
library like Persistent, without any concern as to how it works, will
surely take me from a useless Haskeller to being able to make useful tools
that I can use in my career as a composer.

In learning Do notation the books took me through three ways of expressing
the same thing before arriving at the sugary syntax that I will likely use
for the next ten projects. I don't see that as building a core towards
creation, but rather the elevation of a fetishy obsession with language.
 Children learn the most critical words before grammar - only in language
studies does grammar come before vocabulary.

The question is what is the core knowledge that facilitates creation?

That core is a mutating form.  It works from the high level downward as it
needs to, not from the low level upward because it is thought that it
should.  There are thousands of articles on how to use raw C++ pointers.
One in the know knows to use smart pointers because they facilitate
creation.

I constantly read authors of blog posts say things like "I wish I had
learned monad transformers sooner."  What is a rigorous way to prioritize
learning the full scope of Haskell so that creative intuition is maximized?
 How can I know that Arrows will be generally more effective than
Category-Extras for creating things?

If data mining Hackage to find the practical reality of how Haskell is
actually being used by people who are creating complete and useful things
is not an effective way to learn, what approach is better?

Best,
Casey


On Fri, Feb 1, 2013 at 10:05 AM, Rustom Mody <rustompmody at gmail.com> wrote:

>
>
> On Fri, Feb 1, 2013 at 9:41 PM, Casey Basichis <caseybasichis at gmail.com>wrote:
>
>> That book Mathsemantics sounds like something I should read, would you
>> recommend it?
>>
>>
>
> Well its quite a favourite of mine, if that counts as a recommendation…
>
>
>
>> Your point occurred to me the other day when measuring number of
>> downloads of whole packages was mentioned as being the ideal measure.
>>
>> I have more confidence in measuring the contents of the packages
>> themselves as creating a Hackage package suggests a competency with the
>> language and baseline of sophistication.
>>
>> My thought was the best measure might be the count of functions across
>> all packages, where an included function in any individual package would
>> only be counted once per package.
>>
>> In this sense, map and fold would still likely be towards the top, but
>> that is as it should be.
>>
>> But it seems there are many measures that would be useful, like the
>> percentage of functions from a package that tend to get used in the same
>> project - do people nit pick particular functions from a specific package
>> or does the package use tend to require the use of all of its functions in
>> every project the package is used in.
>>
>> I'd love to hear some thoughts on this as I generally don't know where to
>> begin in solving these sorts of problems and would like to know more about
>> those methods in general.
>>
>>
> Well… it seems to be a good idea to back off from here a bit and ask how
> we came here.
> You want to learn haskell  for which you want to pinpoint the 'most' used
> functions.
> Lets leave aside the question that 'most' may be harder to specify than we
> may first imagine.
>
> Instead lets make a map (functor?) from learning the programming language
> Haskell to learning the natural language English.
> So I dont know English (and yeah there are Godelian anomalies in that
> statement) and I gather that vocabulary is a key to mastering the language.
> Now Webster is a bit too fat to cram up as a whole so I decide to isolate
> the 5000 most used English words.
> Do you think my English mastery will be improved that way?
> Surely Webster had a bigger vocabulary than Shakespeare.
> Do you think Webster knew English better than Shakespeare?
> [You can of course replace Shakespeare to whoever happens to take your
> fancy]
>
> IOW mastering the paradigm is more important than the details.
>
> Now its important to get that the paradigm cannot be caught in any
> single-point sloganeering such as:
> "Functional programming is programming without side-effects"
> "Haskell is syntactically sugared lambda calculus"
> "The key feature of Haskell is its sexy type magic"
>
> Nevertheless its also true that 'paradigm' consists of far fewer elements
> than 'the 500 most used functions.'
>
> I have a couple of pages on my blog:
> http://blog.languager.org/2012/10/functional-programming-lost-booty.html
> gives a few of the basics that FPers should know (IMHO) before going to
> advanced stuff. I should mention that it was written it because Haskell is
> becoming increasingly hard for beginners with the focus on 'type-magic' is
> overshadowing the basics. [In any case after 25 years of teaching, I am
> finding it harder and harder to teach] If you have crossed over the basic
> stage it may not be much use to you :-)
>
> There is also
> http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and
> sequel
> which is more of a grumble about CS education than about FP/Haskell per se.
> Still, an undercurrent of that grumble is that much of the nonsense of CS
> education is because FP has not become mainstream soon enough.
>



-- 
Casey James Basichis
Composer - Cartoon Network
http://www.caseyjamesbasichis.com
caseybasichis at gmail.com
310.387.7540
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130201/73ffec62/attachment-0001.htm>