Potential use of Scala

[Patrick Logan]

I am interested in hearing the opinions and especially the experiences
of hiring people in Portland for developing systems using
"mostly-functional" languages, and Scala or F# in particular.

Thanks
-Patrick

[Thomas Lockney]

While there is certainly a growing talent pool in the area for these languages, it seems that currently you really have to expand the scope of the search to look for people who seem like they might be able to make the migration easily. Obviously, having a past background in some functional language can help a lot, but even that is not always easy to find, nor does it seem to be a reliable indicator that a candidate will be able to translate that past knowledge to the new domain.

Of course, looking for people outside of just the Portland area helps as well. If relocation is not an option, it's worth considering whether remote work could be possible (this doesn't work for every situation, of course). As far as Scala goes (and I'm sure it's similar with F#), there is a growing pool of talent out there, but many of them are located in the SF area or in the northeast. 

[Phil Tomson]

But certainly give it a try here in Portland first because there are
some of us out here who have been playing with functional languages
for a few years now ;-) And we've had pdxfunc for, what, about 4 years
now? Usually have about a dozen eager (or lazy :) functional
programmers show up in any given month.

Oh, and OCaml and F# are kissing cousins... just say'n because I've
been dabbling with OCaml for a while now.

Phil

[Thomas Lockney]

On Sat, Jun 18, 2011 at 11:27 AM, Phil Tomson <philt...@gmail.com> wrote:

But certainly give it a try here in Portland first because there are
some of us out here who have been playing with functional languages
for a few years now ;-) And we've had pdxfunc for, what, about 4 years
now? Usually have about a dozen eager (or lazy :) functional
programmers show up in any given month.

Oh, and OCaml and F# are kissing cousins... just say'n because I've
been dabbling with OCaml for a while now.

What Phil says is a very good point and makes me realize I should have been more precise. First, I think a better definition of what you might be hiring for is helpful. If it's a matter of needing people who can be adept at developing functional-oriented systems, I think Portland clearly has a wealth of talent that could be pulled from. If the needs are more specific, it's really hard to say without the details. In our case, we're looking for people who can be up and running on a JVM-based environment (by way of Scala, primarily) while also taking advantage of certain architectures and systems (messaging, nosql, etc.), so this results in a fairly narrow pool. 

I've certainly seen people who have grown adept at the functional side of languages not generally considered "functional" (in the commonly accepted definition) that have been very quick to pick up these functional hybrid languages and move quickly forward with them. It might even be a better direction from which to approach them. Some of the best Scala devs I know (I'm sorry to say I don't personally know any F# devs) have come from Python, Ruby and C# backgrounds. Of course, having some exposure to a more strict language (Haskell, ML, etc.) can't hurt.

I'd love to hear more from others who have been on either side of the table as to their experiences with hiring. I think it could also be helpful to hear what has worked for people learning, coming from different backgrounds. This was not the original intent of Patrick's post, I know, but I think it could inform the discussion and considerations for those of us who do have to deal with the job market. 

~thomas

[Phil Tomson]

The F# and Scala choices Patrick gave in his original post are very
similar in some respects:
Both are multiparadigm languages with a distinctive functional flavor
built on top of an existing infrastructure and libraries (F#->.Net,
Scala->JVM). Making the jump to the functional mindset is just one
part of mastering these language/library mixes. The other part is
knowing the underlying libraries/tools that come with each. I'm not
sure which part of that learning problem is more difficult. I would
tend to think that being able to think functionally is more
fundamental, but then again with these two languages the libraries are
so vast that maybe the paradigm shift is actually easier.

Of course, the other dimension to the problem is the problem domain.
And other dimensions (as Thomas mentions) related to architectural
issues - messaging, type of database, etc.... Given all of this, I
guess it's understandable that we see such highly constrained job
postings these days, you the ones where you wonder how the heck
they'll find someone with that particular mix of skills & experience.

Phil

[Thomas Lockney]

On Sat, Jun 18, 2011 at 2:21 PM, Phil Tomson <philt...@gmail.com> wrote:

 Given all of this, I

guess it's understandable that we see such highly constrained job
postings these days, you the ones where you wonder how the heck
they'll find someone with that particular mix of skills & experience.

Yup. Half the time when I see those I want to laugh out loud... the other half, I find myself thinking, "damn, sucks for them.... I know this difficulty all too well."

[Keith Irwin]

I work at a small connected-device company and am the only one working on the server side. I got to choose what I wanted and with an eye toward future developers, chose Scala, rather than, say, Clojure (love!) or (a favorite) Erlang. Couple Scala with Scalatra, Casbah (Mongo), HornetQ (problematic, but okay with Actors), and the latest SBT (and a dash of coffeescript and Scalate for the occasional GUI) and I feel like it's a really good choice. My productivity (despite being new to Scala) seems constrained more by business uncertainties than having enough people or inadequate tools. Cool stuff.

I think there are lots of people around Portland who would love the chance to join a shop unafraid of Scala or functional programming. I know I would. But the conventional wisdom is that learning such things gets you nowhere. Spring, Hibernate, etc, etc, seems to most people as the proper career path.

Keith

[Keith Irwin]

Phil--

From my own experience (and inspired by your post, rather than a direct response):

When I wrote a small project in Erlang (implementing an old visa payment system protocol as well as hooking in to several home-grown management systems), I was forced (with pleasure) to have to deal with immutable variables and the functional style because there was absolutely no other way to do things in that language. No vast infrastructure of libraries designed to be used with an imperative style. Sometimes I'd struggle with something for quite some time without even realizing that the reason I was struggling was because I was thinking imperatively. On top of that, everything had to be asynchronous because there's really no other way to do it. Writing a single, stand-alone Erlang program feels like writing a big, message-based distributed system, routing data through functions. I loved it!

With Scala (at least) it's just too easy (IMHO) to do things in a non-functional way, or, under pressure, to lose sight of the difference.

So, for me, at least, Scala, because of its extensive OO support, makes it harder to grasp the functional paradigm in any sort of intuitional way because it's so easy to get stuff done without it and very few supporting libraries help. (Unless by "functional paradigm" we mean non-side-effecty functions with map, fold, collect, filter over collections.) Scala seems to help you use functional islands in an imperative world, but doesn't help you (by necessity) re-conceive the way you might write applications in the first place. (Or I've not gotten there yet, except to pretend I'm using Erlang.)

If I had to write a serious project in Haskell (like a web service, or a node in a data pipelien), I feel like I'd really have no recourse to unconscious bad habits. Given that Clojure doesn't really encourage OO thinking, I think it has the slight advantage (if you can get people to overcome their fear of non-C syntax) for the JVM. (On the other hand, I love Scala's static typing, which is a complete 180 for me.)

In other words, there's a lot of good reasons to choose the JVM (or, I imagine, .Net), but it doesn't make moving toward a more functional paradigm any easier.

What I'd love most for the JVM is a language with namespaces, functions, pattern matching, type inference, and algebraic types (and type classes, I guess, insofar as I understand them --- kinda like interfaces?).

Keith

[Thomas Lockney]

On Sat, Jun 18, 2011 at 6:14 PM, Keith Irwin <keith...@gmail.com> wrote:

So, for me, at least, Scala, because of its extensive OO support, makes it harder to grasp the functional paradigm in any sort of intuitional way because it's so easy to get stuff done without it and very few supporting libraries help. (Unless by "functional paradigm" we mean non-side-effecty functions with map, fold, collect, filter over collections.) Scala seems to help you use functional islands in an imperative world, but doesn't help you (by necessity) re-conceive the way you might write applications in the first place. (Or I've not gotten there yet, except to pretend I'm using Erlang.)

I've seen that a lot, to be honest, in the Scala world and it has worried me at times, but I also think it's not necessarily a bad thing, overall. I'm all for functional purity and would generally choose that over any OO approach. But for quickly rolling out code, sometimes it's hard to argue against paradigms in which you or your coworkers might already be quite comfortable. 

 

What I'd love most for the JVM is a language with namespaces, functions, pattern matching, type inference, and algebraic types (and type classes, I guess, insofar as I understand them --- kinda like interfaces?).

I assume you mean you'd want *just* that and not everything else that Scala brings along, since it already includes all those features. 

[Keith Irwin]

On Jun 18, 2011, at 6:34 PM, Thomas Lockney wrote:

On Sat, Jun 18, 2011 at 6:14 PM, Keith Irwin <keith...@gmail.com> wrote:

So, for me, at least, Scala, because of its extensive OO support, makes it harder to grasp the functional paradigm in any sort of intuitional way because it's so easy to get stuff done without it and very few supporting libraries help. (Unless by "functional paradigm" we mean non-side-effecty functions with map, fold, collect, filter over collections.) Scala seems to help you use functional islands in an imperative world, but doesn't help you (by necessity) re-conceive the way you might write applications in the first place. (Or I've not gotten there yet, except to pretend I'm using Erlang.)

I've seen that a lot, to be honest, in the Scala world and it has worried me at times, but I also think it's not necessarily a bad thing, overall. I'm all for functional purity and would generally choose that over any OO approach. But for quickly rolling out code, sometimes it's hard to argue against paradigms in which you or your coworkers might already be quite comfortable. 

Yes, I think Scala is really practical on a whole lot of levels for just the reasons you mention. Scala doesn't force you to think functionally, but it doesn't prevent you, either, which in itself is a huge step forward and why I chose it for myself.

Reminds me of:

   http://enfranchisedmind.com/blog/posts/scala-not-functional/

which is really cool if only for the algebraic type demos. I'm sympathetic with the guy's main idea, though perhaps his way of stating it obscured it for most of the responders.

If you hired a Java programmer without even mentioning Scala, then put him to work on a project using it, s/he'd be fine. That's a huge plus.

What I'd love most for the JVM is a language with namespaces, functions, pattern matching, type inference, and algebraic types (and type classes, I guess, insofar as I understand them --- kinda like interfaces?).

I assume you mean you'd want *just* that and not everything else that Scala brings along, since it already includes all those features. 

Yep, that's what I meant.

Keith

[Phil Tomson]

> In other words, there's a lot of good reasons to choose the JVM (or, I
> imagine, .Net), but it doesn't make moving toward a more functional paradigm
> any easier.

Yeah, just to clarify, because I think the wording wasn't clear in my
email when I reread it: I'm saying that given the two problems:
1)developing a functional "mindset" and 2) Learning the libraries...

given the size of the .Net and Java libs it might actually be easier
to develop a functional mindset than it is to learn those libraries to
the degree that one becomes highly productive.

Phil

[Keith Irwin]

Ah.

Heh.

If you further distinguish between "libraries" and "frameworks," I'd totally agree on the framework front. I know it's a wiggly distinction, though.

Keith

[Jeremy Voorhis]

Phil is right. Every language has a runtime that you must learn. They consist of data abstractions and system calls that you will use. The runtime is not inherently functional, even in packages like ghc. The challenge is to capture the meaning of what your program is, and then to lower it into those system calls and mutable things. The process is similar in most languages.

> --
> You received this message because you are subscribed to the Google Groups "pdxfunc" group.
> To post to this group, send email to pdx...@googlegroups.com.
> To unsubscribe from this group, send email to pdxfunc+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pdxfunc?hl=en.
>

[Leif]

When I started with Scala, I thought it was just another "academic"
language to toy around, in the same dustbin as Prolog, Haskell, XSLT,
J, Links, XSPARQL, etc. I never imagined that a bit later I'd be
using it for work. You mention Spring, Hibernate, etc... The place
using Scala was using it with those and all the other regular big Java
tools. That to me might be the main selling point of Scala - it looks
like a dynamic language that developers prefer to work in over Java,
but supports all the heavy-duty backend things Java is good for.
Thanks to Scala they could work in the same HOF style with maps &
folds & things in both the server code and the client-side JavaScript.

In learning Scala, I thought since I knew Haskell and Java I could
just combine the two... But no; I'm not sure knowing Haskell was a
help, at least in the beginning. I started using it as just a less
verbose Java. The higher-order functions, pattern-matching, and other
tricks can be thrown in later. I don't think it'd be a big shift from
using something like C# or dynamic languages like Ruby, Python,
JavaScript...
-Leif

[Patrick Logan]

On Sat, Jun 18, 2011 at 1:00 PM, Thomas Lockney <tho...@lockney.net> wrote:
>

> I think a better definition of what you might be hiring for is
> helpful.

Each of these responses has been helpful. My original post was
deliberately simple. We are at the beginning of a new project,
technically from scratch although the business is fairly well
established. I am not hiring at the moment, but gathering
hiring-related information into our technical-options analysis.

> I'd love to hear more from others who have been on either side
> of the table as to their experiences with hiring. I think it
> could also be helpful to hear what has worked for people
> learning, coming from different backgrounds.

Yes, please.

[Keith Irwin]

Patrick--

It struck me this morning that Scala is a huge language, with many, many ways (it seems) to do similar things. For instance, I seem to be using the list comprehension features more now than I ever did, and I'm still not really sure it's completely appropriate for what I'm using it for. I use Option a lot, but I'm not sure if I'm always using it to best effect, even though what I do works. These things come with time, experience, reading other people's code, and an intuitive sense that you're working a bit too hard.

Given that, I wonder if Scala suffers a tiny bit from the problem that C++ suffers from in that any given user of Scala tends to reduce all the possible ways of solving a problem down to a subset of the language. For instance, I never use deep object hierarchies or even traits all that much, but do try to incorporate algebraic types (e.g., a status attribute for an object is indicated by its type).

If you (or whoever) interviews people for a position and you're worried about their Scala skills right up front, it could be that they just work in a different subset of the language and thus seem befuddled when you ask certain questions or review some of the code they've written in the language.

Then again, maybe that's just generally the case.

Keith