Kickstarting an Austin Scala Enthusiasts meetup on Meetup.com

[Sukant Hajra]

For all you "TL;DR" people, here's a link up-front for a meetup I'm helping
drive:

http://www.meetup.com/Austin-Scala-Enthusiasts/messages/boards/thread/36823592

I'm thinking August 21st at Capital Factory is a date/place to target, but
nothing is too set yet.

Out of a bit of laziness, I'm cross-posting this to two Google Groups: Austin
Scala Enthusiasts (ASE) and Austin Functional Programmers (AFP). Right now
there's three forums to go through (the ASE ML, the AFP ML, and the ASE Meetup
web forum). Personally, I'd prefer continued correspondence on the ASE ML [1].

[1] https://groups.google.com/forum/#!forum/austin-scala-enthusiasts

I've met a lot of people in both AFP and ASE already. A lot of you know my
interest in functional programming. At work, we're exploring functional
programming in Scala (we're getting our app down to one-and-only-one
side-effecting call!). My hopes are to bridge these two communities for a long
as makes sense.

Based on the work we've done, I think I've got some ideas on how to present the
following topics:

- pros and cons of using Scala
- style and architecture with Scala
- avoiding Scala's language "features" for greater profit

- abstracting in Scala
- choosing between traits, classes, and case classes
- understanding objects and ADTs as duals
- the "expression problem" and some solutions
- understanding universal and existential types as duals

- mastering implicits
- the dangers of simplistic implicit conversions
- better ways to do enrichment/extension
- type class encoding
- avoiding the import tax and other techniques

- digging into type classes and syntax enrichment with ScalaZ

- the power of for-yield comprehensions
- the basic examples (List, Option, Either)
- invariants we'd like for for-comprehensions to have
- an illustration of how scala.concurrent.Future breaks invariants
- how scalaz.concurrent.Future fixes the problem

- dependency injection in Scala
- a nod to the runtime exception-throwing solutions (Spring, Guice,
Subcut)
- how the "cake" pattern is just a typesafe variant of what otherwise
feels like Spring
- dependency injection composed functions (readers)
- building a for-yield comprehensions of a mini language

So I have a ton of stuff that relates to both Scala and FP communities. I also
can talk to some slightly more Scala-specific topics like:

- why SBT is a cut above and how to use it elegantly

In general, I'd like to focus a lot less on tools, and much more on programming
well. But some libraries are based on a deeper concept.

Let me know what you think. I think we can make a meetup with a lot of
educational value.

-Sukant

[Cody Koeninger]

Looking forward to the meetup, will see if some of my coworkers @ Digby are interested.  From the topics you listed, I'm especially curious about your thoughts on architecture / avoiding language features.

We've been doing a fair amount of work with Spark, which might fall into the category of a library with a deeper concept (distributed collections).  I'd be happy to talk about that at some point if people are interested.

-Cody

[Sukant Hajra]

On 2013-08-09, Cody Koeninger wrote:
>
> Looking forward to the meetup, will see if some of my coworkers @ Digby are
> interested. From the topics you listed, I'm especially curious about your
> thoughts on architecture / avoiding language features.

I'm building a small presentation right now (nothing too fancy), but I'm hoping
to cover some of this stuff (not sure how much at the kickoff). Actually
writing this out is good preparation for pending meetups, so I'll share a
little here in response. Feedback will help me refine the content, so I
appreciate your responses.

The basics are talked about a lot in the larger Scala community (although
broken surprisingly often):

- Prefer val over var.

- Turn all nulls into Options, Eithers, or something similar.

- Avoid Any (refine to the appropriate type).

- Avoid reflection.

- Avoid asInstanceOf casting.

but there's also some more that might be less common among the community at
large:

- Always pattern match in a way that the compiler can check for
exhaustivity.

- Never expose a pattern-match to an algebra that isn't locked down. We
can accept by definition that (List a) is (Cons a List a) or (Nil), but a
lot of our algebras are not so lucky. We should write visitor/fold
functions for these algebras instead and make the algebraic data type
abstract (by making type constructors private).

- Don't let case classes that encode type constructors of ADTs leak out of
the API as types. They aren't types; they are type constructors.
Scala's encoding of ADTs with subtype polymorphism is problematic.
Because of the impedance mismatch between subtyping and ADTs, in Scala we
can compile things like (Some(1): Some[Int]), but Haskell gets it right
because the compiler rejects (Just 1 :: Just Int).

- Limit subtype polymorphism. Traits can be useful internally, but look at
how badly they complicate external APIs like the standard collection
library.

- Furthermore, never use traits as mixins where linearization order
actually matters ("super" is extremely hard to reason about).

- Avoid variance (both call-site and declaration-site) to avoid error-prone
signatures like CovariantCollection.contains(a: Any), not to mention
having to back out of variance when you hit variance gridlock.

- Turn all handleable exceptions into Options, Eithers, or something
similar.

- Similarly, avoid partial functions.

- Wrap all effects with effect-tracking types (like scalaz.IO, or
scalaz.concurrent.Task) for complete referentially transparency.

Monad transformers and free monads from Scalaz helps with some of this.

At Rackspace, we're writing this work orchestration engine, so fault-tolerance
and correctness has been much larger of a concern for us than performance. I
kind of like this, though, because it plays extremely nicely into some
strengths of typed FP.

Finally, there's some features that Odersky/Typesafe has labeled "advanced"
with SIP-18, but that I feel are appropriate if not required -- especially
after all the architectural constraints above:

- using implicits (especially for type class encoding)

- enabling higher-kinded types

- using abstract types to encode existential types

- using type lambdas to partially partially apply type parameters

- allowing the use of post-fix notation, since most of our stuff is
expression-based and semicolon inference isn't that tricky.

Actually, all of this discussion reminds me. Have you seen this post?

http://eed3si9n.com/scala-the-flying-sandwich-parts

I agree with a lot of it, with only a couple of exceptions, which I talked to
in comments:

http://eed3si9n.com/scala-the-flying-sandwich-parts#comment-939276530

Actually, merging this post with some of my own thoughts might lead to a
"Scala: The Good and Bad Parts" presentation. So much to cover. . . for the
kickoff meeting, I need to make sure to not try to cover too much.

> We've been doing a fair amount of work with Spark, which might fall into the
> category of a library with a deeper concept (distributed collections). I'd
> be happy to talk about that at some point if people are interested.

This sounds good to me. I've been interested in Spark for some time, but
haven't had a project that's made it an obvious choice/fit. I'm definitely in
line with the premise that Hadoop is overused for many analytic applications.

-Sukant