Scala Debate

Hello Scalaist,

we've seen discussions about scala complexity, complex problems, fear of
complexity and related matters around scala (but not exclusively) for years
now.

This topic deals (among others) with something very fundamental: computer -
human - interaction. A programming language along with its environment is a
digital tool that interacts with humans (developers).

As I got the impression over time that all those discussions tend to run in
circles maybe something can be done to push things forward.

On 11/21/2011 11:32 AM, John Nilsson wrote:
> On Sun, Nov 20, 2011 at 11:42 PM, Tony Morris wrote:
>> * forall x y. reverse(x ::: y) == reverse(y) ::: reverse(x)
> OTOH, there is no way you can be reasonably productive if you need to
> do the kind of deduction required read this property and be confident
> that it the one you need.
>
> I would guess that what really happens is that you study this property
> once or twice until you are confident.

So, in order to avoid disagreement over the semantic meaning of "documentation".  Would it it fair to say everyone agrees that scalaz lacks a centralised set of *tutorials* explaining the concepts involved and some real-world use cases?
That's certainly a cause I could get behind...

On 20 November 2011 14:16, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

I am moving this from scala-user to scala-debate upon request. First, a bit of context (copied):

I attempt to follow scala-debate, because there are occasionally articles that are of significant importance to the Scala community. However, the group tends to drop off my radar--there is too much junk.
My own experiments in trying to handpick "debatable" topics I thought would still be of interest to the general community were obvious failures. One was maybe a partial success, but maybe that's just me trying to be face saving. I apologize to the scala-user readers who had to go through these, I tried something I thought would work and it didn't.

Type parameters are not just parameters like method parameters. The
problem with projecting names onto type parameters, unlike method
parameters, it that this departure from reality is *always*
unwelcome (unlike coincidentally having no impact for method
parameters). That is, you will always be wrong by virtue of them
actually being universally quantified variables. You will never be
right.

Dear Lists,

Now is the time to write up your experiences with your Scala library, the tool you have been developing, or any other research that you have been performing in the context of Scala. (Including that revolutionary idea that struck you during one of the legendary scala-debate threads. Shorter papers are also welcome, if they have potential to generate interesting discussions at the workshop.)

The conversations around how to make scala more popular (as with most technologies) often confuse selling vs. evaluating. These are two very different activities.

A good article on a key differences is http://weblog.raganwald.com/2007/01/what-ive-learned-from-sales-part-i.html

-Patrick