Scalaz as courseware? (Or at least, some *organized* pointers?)

[Justin du coeur]

[Posting this to -debate mostly because Tony's expressions of frustration are part of what have gotten me thinking about this.]

I've spent a fair chunk of the past few days digging into Scalaz.  The combination of that, plus some of Tony's comments, have led me to ponder the mental disconnects going on.

I'm a serious engineer -- I've been in the field for 30 years, I'm fluent in a wide variety of languages, I've built systems at all levels.  I love to learn: my rule (especially after watching friends wash out of the field in the wake of y2k) is that you should learn something new about programming every day.  I adore Scala, proselytize it frequently, and understand most of it pretty well.  But damned if most of Scalaz isn't going right over my head.

This isn't a matter of effort: I've been digging into a lot of these concepts for quite a number of months now, and from time to time I sort of intellectually get it -- briefly.  But I'm clearly not internalizing the paradigms properly, because they aren't sticking well enough: I can read a lot of the code, but I'm not *getting* it well enough to write novel code using these functional tools myself.  The mental models just aren't wedging properly into my brain.

Stepping back and looking at it, I think the problem is pedagogical.  I'm bouncing around between Scalaz' code and examples, and miscellaneous papers on the various concepts, but it's all very ad-hoc and disorganized -- which is made worse by the fact that the concepts build on each other quite heavily.  It's rich in jargon -- and worse, rich in symbols that I have no idea how to pronounce (it is just plain harder to learn a symbol if I can't verbalize it) -- and light on real pedagogical approach.  Normally I do fine at learning new programming concepts ad-hoc, but this is just too *different* to do so that way: the mental jump to really grokking the higher-order type stuff isn't working.

People have complained about the lack of documentation for Scalaz, but what I've found myself craving, quite terribly, is a *course* in it -- not just a manual, but a real from-the-ground-up course in modern functional programming for the experienced and motivated OO engineer, who understands the now-largely-universal concepts like closures, but knows little about monads, much less applicative functors.  I'd be more than happy to take the time to sit down and do proper coursework with exercises and all that, if there was something organized enough that I felt the end result would be a well-internalized understanding of the approach.

Is this already a solved problem on the Haskell side of things?  I'd frankly prefer to use Scala+Scalaz to learn with, because it's a toolset that I reasonably expect to use for my own projects in the future, but if such a well-developed course already exists in Haskell I'd consider trying to use that and then port the knowledge over.  (More generally, pointers to proper courseware or well-structured books on the subject would be welcome.)  The Typeclassopedia is the closest I've come to finding something well-organized so far, but even that moves too briskly to serve as a good course for someone not already deeply immersed in the Haskell mindset -- it's a good reference, but not really a textbook.

So consider this a suggestion/request, if anyone is academically-minded and looking for a project that would really advance humanity (or at least the state of programming).  A course like this, focused specifically on using Scalaz as a means to learn the ins, outs and subtleties of full-bore functional programming, would be damned useful in helping to drive the usage of functional mechanisms within the language.  I suspect I'm not the only person who would *like* to understand this stuff, but is having trouble figuring out how to figure it out...

[Rúnar]

Justin du coeur <jducoeur <at> gmail.com> writes:

> People have complained about the lack of documentation for Scalaz, but what
I've found myself craving, quite terribly, is a *course* in it

Hi Justin,

We (scalaz) are working on a book as well as material for a course. Hopefully
we'll have something to show you by the end of the year.

Rúnar

[Kevin Wright]

+99

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Alex Cruise]

On Wed, Mar 16, 2011 at 9:56 AM, Rúnar <apocal...@gmail.com> wrote:

We (scalaz) are working on a book as well as material for a course. Hopefully

we'll have something to show you by the end of the year.

Excellent news!  I share most of Justin's difficulties.  

If I could make one not-so-small request... Please consider opening up the process to reader participation early on.  

If the intention is to release it under a free license, something similar to what was done with Real World Haskell and Programming Scala would be awesome.

If not, something like MEAP or Artima's system in which early purchasers get access to a forum where we can clamor for enlightenment would be very welcome too.

Thanks, and great work on Scalaz!  I hope to understand it someday. :)

 

-0xe1a

[Jim Powers]

+p1 0
where
p1 n = p1 $ n + 1

;-)

I can say that I have also poured many hours into reverse-engineering
Scalaz trying to understand the concepts behind the library. The
file-names alone imply a daunting reading list.

Although a book/course is fantastic, in the mean time something as
simple as a few A/B examples would greatly help.

Example A: Problem X with solution written in traditional idiomatic
Scala (+ optionally Java stuff thrown in there)
<series of intervening transformative steps>
Example B: Problem X with solution expressed in terms of functionality
obtained from the Scalaz library

--
Jim Powers

[Justin du coeur]

Excellent!  I look forward to it.  (And would be more than happy to serve as a beta-test guinea pig, if you find yourselves wanting some such...)

[Chris Twiner]

Damn you, I almost ruined my laptop with drool. I've only had it a
few months :<

If its written like the Iteratees intro then I see some very cool
learning and "aha" moments ahead. I had a fuzzy warm feeling about
what I wanted from them and that post clinched it for me, a question
or two on the scalaz list and I now have a lovely xmlpull system based
on iteratees.

If Jason is participating in this then I'm happy to review chunks over
beers (paypal beer tokens could also be provided for those not living
in Züri :-) )

[Tony Morris]

Hello Justin,
I understand your dilemma. I see it regularly from others, including
IRL. As Runar said, we are working toward helping you out here. My
progress has been delayed by health issues, but hoping to put those
behind real soon.

--
Tony Morris
http://tmorris.net/

[Andreas Scheinert]

Hi Justin!
I' m also really excited about the new scalaz educational efforts.
Since you ask for equivalent material based on Haskell I suggest:
Learnyouahaskell
I don't have finished it completely but so far I can tell it's well
written.
Regards Andreas

[Tony Morris]

I teach advanced programming concepts for my employer, voluntarily and
occasionally at tertiary institutions. I use haskell for teaching and
recently open-sourced (BSD3) the material that I use.
https://bitbucket.org/dibblego/haskell-course/

If you look into it, you will also notice that parts of this material
are ported to Scala.

My personal opinion is that it is somewhere near impossible to use Scala
to come to understand functional programming and advanced programming
concepts. I wish it weren't true, but repeated experience has taught me
to accept otherwise.

[Kevin Wright]

I can go one better, I just bought a brand new laptop for the express purpose of drooling over :)

Don't know about anyone else, but my biggest problem has being trying to adapt examples from LYAH, etc to scalaz, and it's rarely a direct translation... Which makes this an incredibly good thing to be happening!

[Philippe Lhoste]

On 16/03/2011 17:35, Justin du coeur wrote:
> I'm a serious engineer -- I've been in the field for 30 years, I'm fluent in a wide
> variety of languages, I've built systems at all levels. I love to learn: my rule
> (especially after watching friends wash out of the field in the wake of y2k) is that you
> should learn something new about programming every day. I adore Scala, proselytize it
> frequently, and understand most of it pretty well. But damned if most of Scalaz isn't
> going right over my head.

Same here, except I haven't tried (yet?) to learn Scalaz at all, but have some difficulty
to grasp the glimpses of (advanced?) functional programming I see here and there.

> It's rich in jargon -- and worse, rich in symbols that
> I have no idea how to pronounce (it is just plain harder to learn a symbol if I can't
> verbalize it)

Here, I can give a trick, perhaps.
I searched scalaz samples, and took the first link in Google:
http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/example/ExampleArrow.scala.html#22697

At least the code is clean, with some syntax highlighting and, more importantly,
hyperlinks on all identifiers.
I see the symbol ★ which I can identify (with BabelMap) as \u2605 and which I can name per
its Unicode name, BLACK STAR.
But I can also click on it, go to
http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Cokleisli.scala.html#25504
and see it has an alias:
def cokleisli[W[_], A, B](f: W[A] => B): Cokleisli[W, A, B] = ★(f)

So, if I understand correctly, we should name this operator "cokleisli".
(I hope I got it right...)

Now, if you have a static version of the code (plain text editor, on paper...), there is
more trouble...

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Barry Kaplan]

On Thursday, March 17, 2011 1:32:07 AM UTC-7, Tony Morris wrote:

My personal opinion is that it is somewhere near impossible to use Scala
to come to understand functional programming and advanced programming
concepts.

Do you stop at "understanding", or are you also of the opinion that "using" scala for FP is near impossible? 

[Justin du coeur]

Deliciously light-hearted-looking.  I not only am likely to go through this myself, I'll probably point one of my friends at it.  (She's interested in picking up programming, and a Haskell tutorial *now* might prevent her brain from being permanently Javafied.)

Thanks for the pointer...

[Justin du coeur]

On Thu, Mar 17, 2011 at 4:32 AM, Tony Morris <tonym...@gmail.com> wrote:

I teach advanced programming concepts for my employer, voluntarily and
occasionally at tertiary institutions. I use haskell for teaching and
recently open-sourced (BSD3) the material that I use.
https://bitbucket.org/dibblego/haskell-course/

Sounds useful -- I'll give it a look.  Thanks!

 

My personal opinion is that it is somewhere near impossible to use Scala
to come to understand functional programming and advanced programming
concepts. I wish it weren't true, but repeated experience has taught me
to accept otherwise.

Hmm.  Okay, then taking it on its face, that's a challenge that the Scala community (and particularly the Scalaz community) is going to need to gradually address.  I suspect that once one has the concepts, applying them to Scalaz isn't hard -- it's really grokking the underlying ideas that is hard.  

So again, my problem comes down to figuring out a practical pedagogical approach for taking a typical experienced engineer, and helping him understand this stuff well enough to really use Scalaz as intended.  I'd be disappointed (and a bit surprised) if that couldn't be done with Scala + Scalaz (taught in a focused and organized way), but it certainly remains to be seen...

[Russ Paielli]

On Thu, Mar 17, 2011 at 1:32 AM, Tony Morris <tonym...@gmail.com> wrote:

My personal opinion is that it is somewhere near impossible to use Scala
to come to understand functional programming and advanced programming
concepts. I wish it weren't true, but repeated experience has taught me
to accept otherwise.

Tony,

A statement like that is obviously not likely to be well received by the Scala language designers. I'd be curious to know why you have that opinion and what changes you think should be made to the language. Yes, I realize that you may have already discussed it elsewhere, but statements like that need to be backed up with something. If you are tired of repeating your reasons for thinking what you do, I suggest you record them at a website and link to it whenever you need it. That can save a lot of typing!

I hope you get well soon.

Russ P.
 

--
http://RussP.us

[Jim Powers]

So far my experience has been any combination of the following:

• Intellectually unprepared: the explicit inclusion of constructs and concepts that comprise the currency of FP simply isn't common in most software engineering discourse or even thought.  While the concepts still play out they are implicit and not well understood by the practitioners (myself included).
• FP Infrastructure not generally available: particularly in the case of Scala, the design of the language and standard libraries constitute a balance (compromise?) - a move in the direction of a more modern language an library while still appearing mostly familiar.  To move further towards more fully embracing the products of FP requires a fair bit of work to bring those FP products to Scala, hence Scalaz (and similar, I'm guessing).  The remaining challenge (which is connected to my first point) is then how to wrangle the immense amount of Java code out there into a useable "functional" form.  Likely success in this area will not be 100%.  Unlike Haskell, for instance, one needs to look at every library you use and decide how you will engineer it into a "functional" version, if possible.  It's hard enough merely wrestling Java code into something that does not "pollute" your Scala "core" with Java idioms.  Then add to that packaging all that up in a nice FP wrapper.  Then again, perhaps (quite likely) I'm missing something yet again (first point) and these issues aren't meaningful to those with the knowledge of how to make the pieces fit, I would be very happy if this were the case.
• Performance concerns: Scala is an amazing language and the team writing the compiler and libraries are doing fantastic work, but Scala is not Haskell and the JVM/JIT were not designed for Scala.  The compiler magicks-up a lot of stuff (implicit conversions, expansions into map, flatMap, and foreach, etc.) and many of these pieces of magic the JIT is not aware of and has limited ability to optimize out.  Using a for-comprehension vs a while loop in the center of a hotspot is always concerning and so, at least in some limits, one is forced to abandon the "tools" of FP for fugly imperative code.  Again, I will add the caveat that I may be completely wrong on this point (first point), only that I have not discovered the Scala/FP magic that allows my FP Scala code run at the same speeds as my Scala while-loop code.

--

Jim Powers

[martin odersky]

Some of this discussion is drifting to a statement that being purely functional, typeclass based in the syle of Haskell and scalaz is necessarily better than the "old OO style" which Scala only adopts to run well on the JVM and to be palatable to Java programmers. I could not disagree more. And that despite the fact that I am a member of the WG 2.8 expert group of functional programming and collaborate closely with the likes of Simon Peyton Jones and Phil Wadler. Also despite the fact that I have influenced significant parts of the type theory that you find in Haskell today.

Type classes and implicits are important tools for software architects, I would not know how to write software without them in Scala. But so are traits, mixin composition, abstract types, and self types. The challenge for Scala should not be to imitate the more esoteric fringe of Haskell programmers, but to further explore ways to combine object-oriented and functional techniques in creating something new and special.

Let's face it: If classical FP was so great for component-based programming, it would have taken the world over by now. But fact is it hasn't. What's more, the real-world programs I have seen in Haskell left me unimpressed in what concerns their modularity and composability (not the small examples; they are beautiful, but they tend to be hard to scale). That's my impression from what I have seen, but YMMV. In any case, FP is no silver bullet here; it makes it harder than necessary to do recursive dependencies, partial abstractions, or first class components that can be wired at run-time. You can do all that, and some people have fun doing it, but at least for my eyes it's just too hard.

Again, YMMV. If you enjoy exploring this new branch of FP (there are many others), by all means do so. You'll learn a lot. But don't feel inferior or left out if you decide it's not for you.

Cheers

 -- Martin

[Jason Zaugg]

Assuming that your goal is to explore pure functional programming (and
without debating whether or not this is a worthy goal), it's clear
that a language like Haskell, which doesn't have language features
extraneous to this approach, can provide a more focussed learning
environment.

But personally, I've certainly learnt a lot about functional
programming through Scalaz; and through Functional Java before it. So
it's certainly possible! But I know that I'm only scratching the
surface, and some language imposed barriers do prevent convenient
exploration of more advanced topics.

=Type Inference=

The type inferencer in Scala has a lot more work to do that its
Haskell counterpart, thanks to subtyping. Higher Kinded types (e.g.
List rather than List[Int]) can be inferred in some circumstances
since Scala 2.8. But there are cases when you have to explicitly
provide the type arguments. As I've slowly digested the excellent
"Essence of the Iterator Pattern", I've tried to implement part of the
Word Count example in Scalaz [1]. But the essense of the example is
quickly obscured by explicit type arguments!

=Implicit Search=

There have been a few papers written about the way that Scala can
encode type classes with implicit parameters. But none deeply address
the conflicts that arise with using type classes and subtyping in
combination.

* type classes are resolved based on the static type, and can defy
expectations based on polymorphic dispatch. What should this return?
implicitly[Equal[Iterable[Int]]].===(LinkedHashSet(1, 2),
LinkedHashSetSet(2, 1))
* contravariant implicit search prefers Ordering[Any] over Ordering[X]

=Strict-by-default Evaluation=

Many algorithms are elegantly expressed in a lazy evaluation model.
Scala provides optional laziness, indeed I just implemented LazyOption
in Scalaz. But the default evaluation mode is pervasive, and it's hard
to push the boundaries of lazy evaluation through your program. For
example, using LazyOption#map [2] we can:

val opt = LazyOption.some[Int](error(""))
LazyOption.some(error("")).map(_ => 0) // LazySome(0)

But not:

implicitly[Functor[LazyOption[Int]].fmap(opt, _ => 0)

It's just a toy example, and by no means motivates the usefulness of
lazy evaluation. But it does show that to support laziness for this
type, we would need to change the the signature of Functor, and all
the implementations thereof. Similar issues exist for Stream in
collection: it's a lazy structure that always feels awkward in a
strict world.

Do these problems signal design failures in Scala? Not at all, as
Martin wrote, becoming a perfect place for the Haskell-like functional
programming wasn't in it's charter. Lazy evaluation isn't generally
agreed to be superior, and brings it's own set of problems, and
doesn't work well on the JVM, so it's hard to criticise the direction
Scala chose here.

It's actually fairly amazing that Scala allows us to go as far as we
do in this direction! I'm hopeful that some of the issues with
implicits and type inference can be mitigated in the future.

-jason

[1] https://github.com/scalaz/scalaz/blob/master/example/src/main/scala/scalaz/example/WordCount.scala#L11
[2] https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/LazyOption.scala#L21

[Raoul Duke]

On Thu, Mar 17, 2011 at 10:32 AM, Jason Zaugg <jza...@gmail.com> wrote:
> Assuming that your goal is to explore pure functional programming (and
> without debating whether or not this is a worthy goal), it's clear
> that a language like Haskell, which doesn't have language features
> extraneous to this approach, can provide a more focussed learning
> environment.

or, say, CAL if we're stuck on the JVM.
http://en.wikipedia.org/wiki/Quark_Framework#CAL
sincerely.

[Jim Powers]

Martin,

Interesting points, couple of questions:

On Thu, Mar 17, 2011 at 1:07 PM, martin odersky <martin....@epfl.ch> wrote:

Let's face it: If classical FP was so great for component-based programming, it would have taken the world over by now. But fact is it hasn't.

Certainly true (for some appropriate definition of "component-based programming", which in the case of Haskell may not even apply), but it is also generally known that "taking the world over" is often not correlated "meaningful" technical merit.  By comparison to FP Java has taken over the world, certainly not because of merit, but because of a considerable marketing effort to promote the language by Sun (and eventually IBM).  Java was sold as a "simpler" C++ with garbage collection (and originally no JIT or native threads - at the time things like multiple-inheritance and C++ templates were considered the "esoteric" language features that sent people running for the hills), but was lacking many promising language features where considerable amounts of research was yielding fruit: generics (*you* know all about this ;-) ), continuations, first-class functions, type algebras (I remember fondly playing with early versions of SML/NJ long before Java even arrived on the scene), etc.  Fast forward a decade and a half and the Scala team is brining (finally) some modern language features to rest on top of a run-time that has been hammered-out to make Java run nicely. While, sadly, trying to do their best to deal with the embedded warts of that run-time (e.g. type-erasure).  The irony is that some of the most popular features (functional closures, for instance) were well established at the time Java was introduced to the world, from a technical standpoint Java was more net negative than positive at the time.  So, is "taking over the world" a legitimate criteria against witch one should measure the contributions of purely functional languages like Haskell and Clean?  Imagine a world where, say, Haskell did take over the world, would you still dream up Scala?

I'm not presupposing answers to these questions, merely interested in your thoughts on them.

What's more, the real-world programs I have seen in Haskell left me unimpressed in what concerns their modularity and composability (not the small examples; they are beautiful, but they tend to be hard to scale). That's my impression from what I have seen, but YMMV. In any case, FP is no silver bullet here; it makes it harder than necessary to do recursive dependencies, partial abstractions, or first class components that can be wired at run-time. You can do all that, and some people have fun doing it, but at least for my eyes it's just too hard.

--

Jim Powers

[Justin du coeur]

On Thu, Mar 17, 2011 at 1:07 PM, martin odersky <martin....@epfl.ch> wrote:

Again, YMMV. If you enjoy exploring this new branch of FP (there are many others), by all means do so. You'll learn a lot. But don't feel inferior or left out if you decide it's not for you.

Oh, sure.  But on a purely practical basis, it's clear to me that FP is going to become nothing but more important in the coming years -- it seems to be a good approach to a number of types of problems.  

So it seems like it behooves me (as a serious engineer) to understand these tools well enough to grok when they are appropriate.  At this point, I don't really have that sense, and what I'm wrestling with is how best to develop that, especially within the Scala framework.  Nothing about feeling inferior -- it's more simply a bit of frustration at not finding good pedagogy for how to get there from here.  But this conversation has led to a couple of good pointers, and I quite look forward to seeing what the Scalaz team comes up with...

[Tony Morris]

Hello Philippe,
You will find a lot of older scalaz examples use unicode symbols. These
were used as an experiment to test viability. It was subsequently agreed
some time ago that they should not be used as much as they are in those
examples that you mention. Personally, I'm in love with ∘ and ∙ and
don't care for most of the others. You will find that unicode is not as
prevalent in more recent code.

--
Tony Morris
http://tmorris.net/

[Tony Morris]

Yes I stop here. Scala is certainly more amenable to functional
programming than many other programming environments. Also, many other
languages are much more amenable than Scala. Having a deep understanding
of the topic allows you to make better informed decisions when writing
in Scala. This is crucially important when it comes to practical
application.

I first started teaching functional programming with Scala in 2007. I
have become quite convinced that Scala alone does not give you this
required understanding to any satisfactory degree. That is to say, I
have tried with different students, teachers and tools and it is
consistently repeatable that Scala is the culprit in slowing progress
down. I know a few of my students from around 2008/2009 lurk on these
mailing lists, but probably won't speak up because they are quiet --
perhaps they can offer their point of view though. In any case, I can
point to countless examples of this manifesting itself.

In any case, I don't think it was ever intended for Scala to be used to
teach functional programming. However, I once thought I could exploit
Scala's other design goals (Java-like syntax, compile to .class, etc.),
but I have been forced to change my mind that this is possible.

[Kristian Domagala]

On Fri, Mar 18, 2011 at 8:55 AM, Tony Morris <tonym...@gmail.com> wrote:

I first started teaching functional programming with Scala in 2007. I

have become quite convinced that Scala alone does not give you this
required understanding to any satisfactory degree. That is to say, I
have tried with different students, teachers and tools and it is
consistently repeatable that Scala is the culprit in slowing progress
down. I know a few of my students from around 2008/2009 lurk on these
mailing lists, but probably won't speak up because they are quiet --
perhaps they can offer their point of view though. In any case, I can
point to countless examples of this manifesting itself.

I'm one of Tony's aforementioned students, but I guess speaking up doesn't make me one of the quiet ones in this case :-) . Here is my anecdotal experience; for what it's worth.

In mid 2008, I had a goal to learn and become proficient in Scala. I can't remember exactly what the motivations were behind that goal, although it did coincide with having just spent some time in the maintenance phase of a Ruby on Rails project; something I found very frustrating with regards to discoverability and reasoning over the existing code-base. Prior to that, I came from 8 years of programming primarily with Java and had begun noticing the limitations around avoiding duplication whilst trying to stay within the realms of (what I considered at the time to be) type safety. Scala's type inference, first-class functions, terser syntax, and ability to integrate with the Java libraries I had learned to love and hate made it a good contender for a language I wanted to learn.

Tony & I worked for the same company at the time, though I hadn't worked with him directly on any projects before. I had attended one of his introductory sessions on Scala in the previous year, but I hadn't done anything with the language since then. Working in the same office, I had also heard the terms "monad" and "functor" thrown around, and how it wasn't possible to implement those concepts in Java without some level of duplication. Perhaps it was a case that my curiosity got the better of me and I went to Tony to learn about them, thinking to myself that I would learn Scala as a side-effect (this was before knowing the problems associated with side-effects ;-) ).

How ever I got there, I do remember that one of my first failed attempts at going off by myself and working through some exercises in Scala was on an earlier version of Tony's Intermediate Scala Exercises [1]. Unlike those posted on the blog, the exercises I worked through used the actual names of the monad and functor functions, and included others such as sequence and mapM. I'd breezed through the Beginner Exercises [2], and slowly got through some of the "easier" intermediate ones, such as map and join, but just couldn't get my head around all of them.

At the time, one of our other co-workers was in the office on some down time, and wanted to use the time to learn about some of these concepts too. I think he also wanted to learn Scala, but ended up going down the path of using Haskell instead. He seemed to make quicker progress than I was making, and at some point, I made the decision to look into Haskell myself. I started off by reading through Programming in Haskell [3] and working through all of the exercises at the end of each chapter until I finished the book. I distinclty remember that the only chapter in the book that I didn't fully understand by the end of it was the one on Functional Parsers, which introduced monadic parsing. I could sort of see what was going on, and the code I wrote along the way was compiling, but it still didn't answer any of my questions about what a monad was. Aside from that, I thought it was an excellent introduction to functional programming in Haskell.

After I got through the book, I went back to the intermediate exercises, this time working with the Haskell function signatures. Eventually, I was able to get them all out. I obviously can't draw any conclusion that it was the language that helped, but one thing I noticed when going back and implementing the same solutions in Scala was the required type annotations - something I found distracting at best and confusing at worst (eg, for partially applied types). Also, using Haskell highlighted to me that there was a whole phase of unlearning (what I previously knew about programming) that had to be undertaken in order for me to start properly grasping these new concepts. In my experience, seeing Scala as "a better Java", where you could continue using what you already know, but do even more, was a hindrance to that unlearning.

From this point, I did more exercises towards the goal of learning about referential transparency. I found that Haskell lead me more down this path as a natural progression, due to it's insistence that you acknowledge side-effects in the type system. In essence, I felt it kept me more honest about the code I was writing.

I haven't written any Haskell since then, but I now use those concepts I learned every day in my job and am certainly happy that it is possible to do so in Scala. It just wouldn't be my go-to language to learn them.

Cheers,
Kristian.

[1] http://blog.tmorris.net/20-intermediate-scala-exercises/
[2] http://blog.tmorris.net/scala-exercises-for-beginners/
[3] http://www.cs.nott.ac.uk/~gmh/book.html

[ejc]

Kristian,
Thank you for sharing your experiences. I'm in the process of getting
Haskell set up, reading Tony's lessons posted previously and preparing
for some serious unlearning (I've been in PHP land for a while). I
wish I had a local resource like Tony, but take heart seeing he's
willing to answer questions an educate via e-mail.

Thanks,
Eric

On Thursday, March 17, 2011, Kristian Domagala

[Tony Morris]

On 18/03/11 18:45, ejc wrote:
> willing to answer questions an educate via e-mail.

Yeah sure any time. I'm still in hospital from major spinal surgery, but
I will eventually get to any questions you have.

[Philippe Lhoste]

Taking over the world is certainly not a criterion for technical quality, indeed.
Somehow, we can also say that PHP did take over the world of Web applications (it is
changing, but that's not the point), and certainly not because it is superior in design
over other languages... :-)
Why it is (was?) so popular? Several factors: it is relatively easy to learn (kind of
"Basic for the Web"), because of its imperative design. And it is easy to deploy, so you
find it out of the box on most servers, including cheap ones, and even some free ones (my
own Web site is given by an ISP even though I use another one). So, nearly everybody can
do Web programming (often in ugly ways, but that's another problem) in PHP. It is harder
(technically, and financially) to do so in Java (or other JVM languages -- partly because
JVM put more strain on shared servers), in Ruby, Python, Lua or even on native code (which
might run some other interpreter...).

PHP didn't has major marketing (AFAIK) but spread because of these "qualities".

[Jim Powers]

Point certainly taken. I was going to mention things like PHP, Ruby, Python, etc., but the setup for my questions was already unwieldy and long.

--
Jim Powers

On Mar 18, 2011 6:06 AM, "Philippe Lhoste" <Phi...@gmx.net> wrote:

[Elazar Leibovich]

On Fri, Mar 18, 2011 at 12:05 PM, Philippe Lhoste <Phi...@gmx.net> wrote:

Taking over the world is certainly not a criterion for technical quality,

Huh? I think that your email led me to the opposite conclusion. PHP won (and is winning) market share because of a pure technical quality - (1) it is easy to deploy, even with shared hosting (2) it is easy to convert static HTML pages to php, so that you very rapidly take a designed HTML webpage and shove there some minor dynamic content.

The fact that it's a bad language is a compromise, they made a very simple language so that it'll be easy to port it and to support backwards compatibility. With a more advance language like scala, porting it to other platforms is a much more complicated task.

I hate PHP with passion, but I chose it many times for clients because it is dead-easy to deploy, and it is so portable and backward compatible that they'll be able to run it forever wherever they want. I had a customer with a rails-based website which broke every other Monday since her shared-ISP upgraded their rails stack and everything broke. She didn't care how monadic the website design was, she just wanted never to look at the website design again after it is complete.

This is an important point that many people miss. The technical quality of the pure language is rarely the technical quality you should notice. Bad language with a third party libraries that you really need, is way better than excellent language where you'll have to re-implement it yourself, or too choose one of many half-baked libraries.

[Paul Hudson]

Could we stop the language wars? It's distracting (in my view) the thread from the original (and useful) discussion on scalaz courseware and the best ways of learning scalaz and related areas

There are many other places I can get my daily dose of "language X sucks" vs. "language X rules"

[Elazar Leibovich]

I just want to clarify that the purpose of my email is not to discuss PHP, but to note that the technical merits of a language is not the only thing that matters regarding its adoption. I really didn't meant to discuss PHP specifically, obviously not to start a so called "language war".

[Jim Powers]

On Fri, Mar 18, 2011 at 8:47 AM, Elazar Leibovich <ela...@gmail.com> wrote:

On Fri, Mar 18, 2011 at 12:05 PM, Philippe Lhoste <Phi...@gmx.net> wrote:

Taking over the world is certainly not a criterion for technical quality,

Huh? I think that your email led me to the opposite conclusion. PHP won (and is winning) market share because of a pure technical quality - (1) it is easy to deploy, even with shared hosting (2) it is easy to convert static HTML pages to php, so that you very rapidly take a designed HTML webpage and shove there some minor dynamic content.

It's a poor language with a easy-to-work-with runtime when it comes to Web-page generation.  Certainly a win when it comes to imagining a short distance between concept (web page that looks like A but with parts dynamically generated) and delivery.  In terms of PHP, as a language (and its runtime), promoting healthy and sustainable model for software development there's plenty of evidence to indicate that PHP as a language and run-time won't assist you from spiraling down the abyss.  This is not to say that there aren't successful PHP projects, they're probably successful because of design discipline and hard-earned lessons of what doesn't work rather than PHP helping the programmer to make good design decisions.  The argument from popularity would seem to indicate that this distinction is unimportant.  Hence why I asked the question in the first-place: I think it's doubtful that visions of world domination should even enter the conversation.  In the case of Scala it has done so at least implicitly: it's built on the JVM for a reason - to work with Java libraries and tools - help those who work on the JVM (warts and all) and you help Scala.

The fact that it's a bad language is a compromise, they made a very simple language so that it'll be easy to port it and to support backwards compatibility. With a more advance language like scala, porting it to other platforms is a much more complicated task.

Well, porting Scala means mostly porting the JVM, which is clearly a difficult undertaking, but it has been done numerous times. (I cannot comment on Scala.NET)

 

I hate PHP with passion, but I chose it many times for clients because it is dead-easy to deploy, and it is so portable and backward compatible that they'll be able to run it forever wherever they want. I had a customer with a rails-based website which broke every other Monday since her shared-ISP upgraded their rails stack and everything broke. She didn't care how monadic the website design was, she just wanted never to look at the website design again after it is complete.

Similar levels of stability are possible using the JVM (WAR files, self-contained web servers, etc.), and certainly with Haskell - generate stand-alone executables.

This is an important point that many people miss. The technical quality of the pure language is rarely the technical quality you should notice. Bad language with a third party libraries that you really need, is way better than excellent language where you'll have to re-implement it yourself, or too choose one of many half-baked libraries.

By that logic then we should all be programming in COBOL and FORTRAN (maybe C) ;-).  New languages get invented because they express the designers concepts for clearly.  Each language that comes into being attempts to further capture the essence of the programming tasks at hand.  I think it's safe to say that we've all benefited greatly from these endeavors.

--

Jim Powers

[Shelby]

On Mar 18 2011, 1:07 am, martin odersky <martin.oder...@epfl.ch>
wrote:

> Some of this discussion is drifting to a statement that being purely
> functional, typeclass based in the syle of Haskell and scalaz is necessarily
> better than the "old OO style" which Scala only adopts to run well on the
> JVM and to be palatable to Java programmers.

[...]

> Type classes and implicits are important tools for software architects, I
> would not know how to write software without them in Scala. But so are
> traits, mixin composition, abstract types, and self types.

I agree and also think that the main features of Scalaz could be
accomplished without abandoning subtyping. I argue those features
would make for a better foundation for the standard collections
library:

http://groups.google.com/group/scala-user/browse_thread/thread/770172e72892d8f3/8af329c4090c8b2c?#8af329c4090c8b2c

However, in best attempts to model this in Scala, there is still some
boilerplate that we could eliminate with some syntactical sugar on top
of some way to eliminate the boilerplate of passing the typeclass
implicit to every function in order to call the static functions, e.g.
Monad's `lift`.

more below...

[...]

> Let's face it: If classical FP was so great for component-based programming,
> it would have taken the world over by now. But fact is it hasn't. What's
> more, the real-world programs I have seen in Haskell left me unimpressed in
> what concerns their modularity and composability (not the small examples;
> they are beautiful, but they tend to be hard to scale).

Remember your point about open recursion not possible in FP, or at
least not with separate compilation:

http://groups.google.com/group/scala-language/msg/915ba6d6b93401dc