Addicted to Scala - I hate the Java Posse!

[Alex Turner]

I have listened to the podcast on and off for some time, and Scala has
always been a language/approach talked about with a great deal of
passion. I was reminded of where I heard about it when listening to
the discussion on the future of Java and Java programmers. I finally
dusted off my Programming in Scala book about a month ago I guess,
then I remembered it was 2011 and I had bought the eBook version as
well, and I have a iPad sitting on my desk, so I put the book back on
the shelf, and picked up my iPad.

In a few weeks, I have become thoroughly addicted. I would in no way
classify myself as a functional programming expert yet, and I'm still
learning what seems like basic syntax at times, though concepts like
recursion, closures, and list comprehensions are things I get, and
have quickly sucked me into the Scala world which is increasing my
functional programming knowledge daily.

I now have a very serious problem. I spend from 5pm on Friday till
9am on Monday coding in Scala (and I confess Grails a little too).
Then I log on at work, and I have to write Java again (where it's more
like 11am by the time I can face it). Monday is agony, pure agony, I
want to run away screaming. It's like going from Zen calligraphy to
paint by numbers with crayons.

I finally decide after another pretty lousy year, I'm gonna nose
around and find out what the job market is like.

Searching for Scala jobs in my Area on Dice: 3, one of them is a typo,
one lists it as a helpful extra-curricular interest. Searching for
Scala jobs where I want to relocate to on Dice: 0. I switch to a
nationwide search, and the results are in the low three digit range.
Monster.com yields slightly better results but still pitiful.

What have you done! I hate you! I will be subjected to daily torture
at work until delivered from the prison that is Java syntax!

I am beginning to understand now, why all the functional programmers
have been staring down their noses at the mere mortals who inhabit
regular cube-jobs (that sounded a bit wrong).

I wrote AOP code last year, and was told off because no one else could
understand AOP yet (srsly?), and so it couldn't be maintained (a fair
point, but tragic, as it was made of win, and uncovered a massive
bug). The number of other people I know in my division who could
write the first year CompSci exercise to reverse a list using
recursion by rote could likely be counted on the fingers of one hand,
and it's possible Captain Hook's bad hand would cover it. Even if I
could convince our management that Scala was the next step on the path
to enlightenment, I can't imagine too many others would be lining up
to join a project using it as the primary language.

How the heck do you find a job working in Scala outside of the Bay
Area or New York city?

[Dick Wall]

Hi Alex

Glad to have caused strife :-) . You neglected to mention where you are located. I know of quite a few different locations around where it is quite possible to get a job working in Scala, for example Boston has a pretty lively Scala scene going, and we have done training courses in St Louis, Ann Arbor, Pennsylvania and a bunch of other places. If you are serious about looking, my best advice is to find out if there is a Scala developer group nearby, and show up for a meeting there. Certainly at BASE (the Bay Area Scala Enthusiasts), hooking up Scala developers with Scala jobs is a part of the meetings, and I imagine it will be the same elsewhere.

Glad you like Scala. I am in the middle of learning Haskell as a way of rounding out my functional programming skills :-).

Dick

[Casper Bang]

On Saturday, December 17, 2011 3:41:42 AM UTC+1, Alex Turner wrote:

I wrote AOP code last year, and was told off because no one else could
understand AOP yet (srsly?), and so it couldn't be maintained

Ah, now I understand better. You had me interested until you mentioned AOP. :)

[Ed G]

Thanks for the laugh this morning with the anecdotes about AOP and the
problems with basic compsci work! BTDT

[Alex Turner]

I'm in SE Pennsylvania, outside of Philly, which is part of the
problem to be honest. The infrastructure in this region is beyond
awful (I'm originally from the UK), so getting into the city is pretty
much a nightmare no matter how you choose to do it (pick a bus and two
trains, a drive and a train, or a drive straight down the Schuylkill
expressway) it takes about an hour and a half anywhere near rush-hour
(it's about 35 mi). I'm looking to relocate at the moment, and San
Diego has been high on the list, at least it's closer to the bay
area. I know there's a JUG here, haven't checked if there's a scala
user group, I'll definitely have to dig around.

Alex

[Alex Turner]

I could ask what's wrong with AOP, but you're probably thinking about
the same as me on that one. I like to call code like that "god"
code. It's the hidden mysterious force that can really screw things
up without almost anyone knowing where it came from and why, or being
able to fathom it's intention. Sometimes though - a little divine
intervention is handy :D

[Kevin Wright]

I guess the biggest issue with AOP is that in 99% of cases it's used to shoehorn FP concepts into a mostly-object-oriented-but-not-functional[1] language.

You take an object, you pick on some of the methods therein and wrap them with around advice, before advice, after advice, etc.  In FP these methods can be treated as first-class concepts in their own right.  You take a function, pass it to a function, return a function; there's no need to build these specialist constructs just to access methods that can only ever exist within the context of an object.

After all... In the kingdom of nouns, the only thing you can ever do with a verb is execute it.  Put verbs on an equal footing with nouns and you can deal with them directly, no tricky marshalling required.


[1] Yes, mostly, primitives and static members are most emphatically *NOT* object-oriented.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"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

[Ricky Clarkson]

I thought that in 99% of cases it was used to show how useful AOP is,
and thereafter limited to logging so that the program remains readable
(i.e., the code does what the code says).

[Jess Holle]

On 12/20/2011 2:22 PM, Alex Turner wrote:

I could ask what's wrong with AOP, but you're probably thinking about
the same as me on that one.  I like to call code like that "god"
code.  It's the hidden mysterious force that can really screw things
up without almost anyone knowing where it came from and why, or being
able to fathom it's intention.  Sometimes though - a little divine
intervention is handy :D

Agreed.  I hate the idea of doing AOP when there's a more easily understood and maintainable alternative or of 99% of developers in an organization of any size doing/seeing any AOP.

Sometimes, however, there's a place for a few engineers to write "god" code that is nicely tucked away and does what needs to be done and can't be done as well any way but AOP.

--
Jess Holle

[Casper Bang]

On Tuesday, December 20, 2011 9:22:43 PM UTC+1, Alex Turner wrote:

I could ask what's wrong with AOP, but you're probably thinking about
the same as me on that one.  I like to call code like that "god"
code.

Yup, I have yet to see a problem that could not be solved without AOP. Of course these fads are common within this business, i.e. after AOP came DI, which is another great example of a solution looking for a problem, making it hard to reason about code in an IDE.

[Cédric Beust ♔]

On Tue, Dec 20, 2011 at 1:27 PM, Casper Bang <caspe...@gmail.com> wrote:

Yup, I have yet to see a problem that could not be solved without AOP. Of course these fads are common within this business, i.e. after AOP came DI, which is another great example of a solution looking for a problem, making it hard to reason about code in an IDE.

I agree with the skepticism about AOP but strongly disagree about DI.

However, the main benefit I get from DI on the (big) code base I work on these days comes from an often overlooked benefit of Guice: being able to add a field to some dependency in one line instead of having to pass it all the way down from main().

I can't imagine the nightmare that our method signatures would look like without DI.

-- 

Cédric

[Robert Casto]

Agreed. Dependency Injection it of a huge benefit. I didn't appreciate it until I joined a project that had 16 different vertical markets all built on the same core but each with different requirements from the users. Being able to pick and choose objects and inject them into a class so it could work with the right object has been immensely useful.

2011/12/20 Cédric Beust ♔ <ced...@beust.com>

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

[Fabrizio Giudici]

On Tue, 20 Dec 2011 22:40:20 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> I agree with the skepticism about AOP but strongly disagree about DI.

I think that DI is one of the most important things to write modular and
testable code.

For what concerns AOP, I think I disagree with others, but perhaps it's a
matter of what we mean with AOP. For sure I don't use it at full power,
e.g. to do dramatic changes to existing code. From this respect, yet, AOP
can be dangerous because it's the classic very powerful tool by which you
can kill yourself. But limited to the proper scopes, such as transactions
and security (in addition to the cited logging), it's very good. It's true
that with this limited use it's more a tool to implement a pattern (proxy
/ decorator) rather than a programming paradigm.

PS I also like it in Spring to perform DI to beans not managed by Spring
with static weaving.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Kevin Wright]

No need to be so disparaging!

It's not just about logging, AOP is used for database transactions as well...

[Jess Holle]

On 12/20/2011 4:15 PM, Kevin Wright wrote:
> No need to be so disparaging!
>
> It's not just about logging, AOP is used for database transactions as
> well...

And performance profiling / instrumentation via byte-code weaving (ala
ASM, AspectJ, etc, being too heavy), especially to code you don't own
(e.g. JVM internals).

In general though I distrust and avoid AOP -- until it's really the only
alternative.

--
Jess Holle

[Kevin Wright]

In general though I distrust and avoid AOP -- until it's really the only alternative.

I have yet to see either a theoretical or real-world usage of AOP where it's not just a hack to deal with the lack of first-class & higher-kinded functions.

Bring on the closures and method handles already, then it'll *never* be the only alternative!

Or, if impatient, just use groovy/scala/clojure/jruby/mirah.  If you've gone AOP then you're already using a different language, either AspectJ or - far, far worse - XML [1].  Seeing as you're flipping language anyway, at least flip to a decent one :)

[1] e.g. defining pointcuts in Spring

[Cédric Beust ♔]

On Tue, Dec 20, 2011 at 3:28 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

I have yet to see either a theoretical or real-world usage of AOP where it's not just a hack to deal with the lack of first-class & higher-kinded functions.

I can think of quite a few, for example injecting exceptions to force your code to fail in odd places. AOP is much less intrusive than any other solution for this kind of problem.

-- 

Cédric

[Jess Holle]

The closest thing I've found to a real-world usage for "normal" AOP was temporary debugger-like pointcuts via AspectJ.

By "normal" I mean via AspectJ, XML, or the like.

Targeted byte-code weaving via ASM is daunting, but truly useful in very limited cases.

[Roland Tepp]

Oh my gotd are you building a straw man...

If the only thing you see in AOP is functions accepting functions and returning functions, then - superficially speaking - AOP is, as you say, merely a wrapper for offering some functional-like features for (mostly) OO language...
But man, are you wrong in proposing that AOP is _just that_.

All I see is that AOP uses these tools (that are indeed functional in their nature) to achieve separation of concerns and cleanliness of

I've seen AOP used in many places where *not* using AOP would have otherwise polluted the actual code base with explicit implementation details of the completely orthogonal concerns like cacheing, transaction management, performance logging, security, etc.

The premise of AOP is not that it allows to compose functions and do FP style stuff. I can do that in Java today (albeit it's somewhat more awkward than, let say ... umm ... scala) without any help from AOP.
The premise of AOP is that it allows to divorce completely orthogonal concerns that cut across the entire cofde base from the main business logic in a cleanly separated manner.

That is not to say, it one can not use other good engineering practices to achieve that goal, but this would be akin to using FP style in Java - doable but awkward.

[BigKahuna]

Hah hah, I feel your pain. I'm experiencing the same things myself using Scala and then having to do all the boilerplate stuff with Java. Should have stuck with the blue pill. :D

[Kevin Wright]

People, please, calm down...

Java is a platform and not just a language.  Java is what makes Scala fast, cross-platform, etc, etc.

By all means, say that you hate being forced to write verbose/repetitive logic, but don't say you hate Java... Because we all love it really, the important bits at least :)

[Casper Bang]

I agree with the skepticism about AOP but strongly disagree about DI.

Mind you, I do not "strongly disagree with DI", Guice is indeed very nice (but also not your typical heavyweight Spring framework full of XML). However, I strongly disagree with the premise that we should drag in and rely on omnipotent wiring containers just for the sake of them. It still baffles me for instance, that so few people know and use SPI's (ServiceLocator pattern), when that's a neat built-in mechanism for dependency injection through the class-path. While singletons have been declared an anti-pattern and can probably cost you a job interview just for mentioning it, this is often because people have not paired it with a ServiceLocator. That's a perfectly viable and simple solution to the dependency carrying problem (access to some common shared application context, say connection pool, further down the dependency chain). Need a special mock version of a component? Implement the SPI and declare a dependency in the test scope/classification of your POM .

[Fabrizio Giudici]

On Sun, 25 Dec 2011 14:35:19 +0100, Casper Bang <caspe...@gmail.com>
wrote:

LOL - and I'm going to explain why LOL :-) First, I don't disagree. In
particular, I'm still using Locator. In my code you'll find stuff such as:

private final Service service = Locator.find(Service.class);

or

private final Provider<Service> service =
Locator.createProviderFor(Service.class);

Locator is simple syntactic sugar about the NetBeans Platform Lookup. I'm
using this a lot in my Platform projects (guess that...) and Android (to
which I've adapted Lookup).

Some time ago (1/2 years? I don't recall precisely) there was a long flame
in the NetBeans Plaform mailing list because a guy accused the Platform to
be obsolete since there was no DI, etc.... At the time, I developed a
very simple adapter that makes it possible to replace the two above lines
with:

@Inject
private Service service;

@Inject
private Provider<Service> service;

I had some doubts because of the loss of 'final' (and I'm still struggling
to find a way to preserve it in a meaningful way), but OTOH I appreciate
the fact that now the code is also compatible with Spring and Guice. I
resisted for some time to Spring, but I've started using it more and more
in the past three years and to me now is a superior alternative to JEE.
Having code that is reused in different projects (NetBeans Platform,
Spring, Android) I appreciate the use of @Inject. Of course, with some
reflection trickery I could have Locator to work with Spring... but isn't
simpler @Inject?

[Cédric Beust ♔]

On Sun, Dec 25, 2011 at 5:35 AM, Casper Bang <caspe...@gmail.com> wrote:

While singletons have been declared an anti-pattern and can probably cost you a job interview just for mentioning it

I'm sad to see this misconception still being bandied around, so I hereby declare "Declaring that singleton is an anti-pattern" an anti-pattern. 

Singletons are a fine and quite ubiquitous concept (you even used one in that very message), the anti-pattern is simply to implement them with statics. I have written more about this subject here for people interested in doing Singletons the right way.

Other than that, I agree that ServiceLocator is an unsung hero of the JDK (I support it in TestNG so you can declare listeners in your classpath and TestNG will automatically find them through the ServiceLocator. No need for third party libraries).

-- 

Cédric

[Cédric Beust ♔]

I'm talking about the ServiceLoader, of course, not Locator...

-- 

Cédric

2011/12/27 Cédric Beust ♔ <ced...@beust.com>

[Reinier Zwitserloot]

Singletons WITH STATE, that's the anti-pattern. stateless singletons are a great idea and we have them all over the place.

[Alex Turner]

Well,

It seems you are entirely right.  I got laid off yesterday, and since beginning the job search, I've already been contacted about four jobs that involve Scala, two of which are directly in my area.

I think I'm definitely going to have a look at Haskell at this point too, seems like a great way to really double enforce the functional mindset.

Alex

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/J-hjwM_vCg4J.