Appropriate Scala "style" in real-world (Java/corporate) environment?

I think it depends on your team.   "Don't be a ******" is my motto (fill in the blanks with your own words, they probably all fit).   In any case,  I think using some advanced Scala (5-9) on such a time is 'ok' depending on the *team* and how *you* interact with them.   Is there an open environment of teaching?  Are they eager to learn new concepts?   Great!  Don't hold them back from learning by not introducing new things to them.    Are they tired and overworked with not much time to learn Scala?   Probably best not to drag them into new concepts until they're ready to learn.
That said, you can isolate your advanced usage from the rest of the team's code as long as (a) the team is ok with that and (b) you know you're becoming a single point of failure for some aspect of the code.

On Mon, Oct 31, 2011 at 1:28 PM, Ken McDonald <ykkenmcd@gmail.com> wrote:

I don't really have (much) of a position on this, but thought it would be an interesting discussion to start.
Let's say you're working in a real-world environment, where the Java team has slowly started using Scala. You're a Scala guru (more than me), you know how to use the type system to do computation at compile time, etc, etc. You have a "Scal-o-meter" going from 0-9, where 0 is "Scala is exactly like Java, just with fewer type declarations" to 9 is "scalaz is the _low_ end--wait 'til you see _my_ HOF package".
Question: What is the appropriate Scal-o-meter setting to code at in your workplace?
My belief is no higher than 3, quite possibly 2. I find "map"'s OK, but "fold"'s are risqué and...I can't think of another good example right now, sorry :-).

Cheers,Ken

Am 31.10.2011 18:28, schrieb Ken McDonald:
> I don't really have (much) of a position on this, but thought it would
> be an interesting discussion to start.
>
> Let's say you're working in a real-world environment, where the Java
> team has slowly started using Scala. You're a Scala guru (more than
> me), you know how to use the type system to do computation at compile
> time, etc, etc. You have a "Scal-o-meter" going from 0-9, where 0 is
> "Scala is exactly like Java, just with fewer type declarations" to 9
> is "scalaz is the _low_ end--wait 'til you see _my_ HOF package".
>
> Question: What is the appropriate Scal-o-meter setting to code at in
> your workplace?
>
> My belief is no higher than 3, quite possibly 2. I find "map"'s OK,
> but "fold"'s are risqué and...I can't think of another good example
> right now, sorry :-).
>
>
> Cheers,
> Ken
scala level of others +1 so they will learn but not be overwhelmed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/2011 03:28 AM, Ken McDonald wrote:
> I don't really have (much) of a position on this, but thought it would be
> an interesting discussion to start.
>
> Let's say you're working in a real-world environment, where the Java team
> has slowly started using Scala. You're a Scala guru (more than me), you
> know how to use the type system to do computation at compile time, etc,
> etc. You have a "Scal-o-meter" going from 0-9, where 0 is "Scala is exactly
> like Java, just with fewer type declarations" to 9 is "scalaz is the _low_
> end--wait 'til you see _my_ HOF package".
>
> Question: What is the appropriate Scal-o-meter setting to code at in your
> workplace?
>
> My belief is no higher than 3, quite possibly 2. I find "map"'s OK, but
> "fold"'s are risqué and...I can't think of another good example right now,
> sorry :-).
>
>
> Cheers,
> Ken
>

Do not buy into the fallacy that measuring whether someone can read code
is done by asking that person, "can you read this code?" Rather, perform
tests which give rise to data from which to make these conclusions.
You'll be surprised at the disparity between the professed ability to
read and actual (as in real and measurable) ability to read.

Next, disregard any suggestion that you should alter the method by which
you produce software "because some people are catching up." It's a
fool's game. "Oh but but, I have colleagues who get frightened by this
or that" you might say. You're dealing with a personality disorder
(outside your field of expertise) and nothing you can do in the short
term is going to be effective. Educate them. Nothing else works. I promise.

If I was the Scala enthusiast of my team, I wouldn't promote the use of Scala unless I judge that my mates will be ready to learn the concepts I would like to use in Scala. Educating people is the greatest thing one can do, but the corporate world needs "results" in "time". Rather than doing a subjective choice that might become a disaster because I fail to correctly educate my coworkers on Scala, I would rather let them choose the language they are most comfortable with and follow them. If, however, the will to learn and use new concepts is prominent in the team, I don't see any reason to hold back on the level of scala-ity. You just have to be prepared to be questioned, be available to explain and teach. YOu'll probably end up repeating yourself a lot. That's what teaching is made of, I guess. In short, it's not about your coworkers capacity to learn , it's about your capacity to teach.

Alex

* not that I'm not Scala enthusiast, but I have currently no team to work with.

2011/10/31 Tony Morris <tonymorris@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/01/2011 03:28 AM, Ken McDonald wrote:
> I don't really have (much) of a position on this, but thought it would be
> an interesting discussion to start.
>
> Let's say you're working in a real-world environment, where the Java team
> has slowly started using Scala. You're a Scala guru (more than me), you
> know how to use the type system to do computation at compile time, etc,
> etc. You have a "Scal-o-meter" going from 0-9, where 0 is "Scala is exactly
> like Java, just with fewer type declarations" to 9 is "scalaz is the _low_
> end--wait 'til you see _my_ HOF package".
>
> Question: What is the appropriate Scal-o-meter setting to code at in your
> workplace?
>
> My belief is no higher than 3, quite possibly 2. I find "map"'s OK, but
> "fold"'s are risqué and...I can't think of another good example right now,
> sorry :-).
>
>
> Cheers,
> Ken
>


Do not buy into the fallacy that measuring whether someone can read code
is done by asking that person, "can you read this code?" Rather, perform
tests which give rise to data from which to make these conclusions.
You'll be surprised at the disparity between the professed ability to
read and actual (as in real and measurable) ability to read.

Next, disregard any suggestion that you should alter the method by which
you produce software "because some people are catching up." It's a
fool's game. "Oh but but, I have colleagues who get frightened by this
or that" you might say. You're dealing with a personality disorder
(outside your field of expertise) and nothing you can do in the short
term is going to be effective. Educate them. Nothing else works. I promise.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOrvE0AAoJEPxHMY3rBz0P8NgH/1LPLcTDXwoFMp+6l2b6Z5fV
NsHHKQUQWkSIJTWfI+HPFe2kmd0W7iCjrPoiqbQEr/LMLnmdDwPF6fIErWQ05K4Q
oxN8z+CyglmOKlfgRgsbN/vAHV51kK8Gz7d94FGZXMVIFyOx9isc/s9kL0CWzS9D
+aur0Lj3Gjsi6euJY8jl8UaUsvGb5kxaGtGLyQoVrB9HlNF3QeTjjYQKv/4z0ca8
nv7Oh2SAFuWqxomZRApTaehvwpwSWkAaj0DpQyrOFeVgLUD/6/tYOKpj0Pi0p2tC
A6SA/EH68dx95vT40kgwoR+3gQb9CdG78HCMHObhePJn/BQ2mVd6iqtbDsVtoBY=
=9P8P
-----END PGP SIGNATURE-----

--
Alex REPAIN
ENSEIRB-MATMECA - student
TECHNICOLOR R&D - intern
BORDEAUX I      - master's student
SCALA           - enthusiast

On 31/10/2011 18:43, Josh Suereth wrote:
> That said, you can isolate your advanced usage from the rest of the
> team's code as long as (a) the team is ok with that and (b) you know
> you're becoming a single point of failure for some aspect of the code.

In both senses of the (b): the bugs are your, but also the risk is that
you are the only person able to do maintenance on your code!
If you leave the company, or just move elsewhere in the
hierarchy/departments, or just are very busy with more important
matters, how to fix this bug?

"scala level of others +1" is a good formula, although I am not sure
what it means (higher level of the others, average of the others? Is
there a way to really measure that anyway?).

But somehow, use slightly more advanced concepts sparingly, and share
them profusely...
In a good team, one should do code review with a peer, so it is a good
opportunity if the code is understandable by a teammate.

If your goal is just to write code that other people can read and understand, then why not also make that the test?
Instead of trying in vain to define levels, have regular code reviews.  Then add comments or refactor as necessary for logic that people are struggling to follow in the review.
This way, I'm happily using "advanced" concepts such as self types, collection.breakOut and type lambdas.  So long as I add a brief comment whenever anybody asks "what the !!?!?! is *that*?" people seem to have no problem understanding.

On 1 November 2011 09:59, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 31/10/2011 18:43, Josh Suereth wrote:

That said, you can isolate your advanced usage from the rest of the
team's code as long as (a) the team is ok with that and (b) you know
you're becoming a single point of failure for some aspect of the code.

In both senses of the (b): the bugs are your, but also the risk is that you are the only person able to do maintenance on your code!
If you leave the company, or just move elsewhere in the hierarchy/departments, or just are very busy with more important matters, how to fix this bug?

"scala level of others +1" is a good formula, although I am not sure what it means (higher level of the others, average of the others? Is there a way to really measure that anyway?).

But somehow, use slightly more advanced concepts sparingly, and share them profusely...
In a good team, one should do code review with a peer, so it is a good opportunity if the code is understandable by a teammate.

2011/11/1 Kevin Wright <kev.lee.wright@gmail.com>

If your goal is just to write code that other people can read and understand, then why not also make that the test?
Instead of trying in vain to define levels, have regular code reviews.  Then add comments or refactor as necessary for logic that people are struggling to follow in the review.
This way, I'm happily using "advanced" concepts such as self types, collection.breakOut and type lambdas.  So long as I add a brief comment whenever anybody asks "what the !!?!?! is *that*?" people seem to have no problem understanding.

One of my LISP teacher in college (Robert Strandh, cool guy) said once that whenever you need to add comments on your code, that's because you failed to make your code clear enough. if you take that straight, that meant that good code doesn't need comments. but clearness is so dependent of the reader's mind... If you take the sentence positively, with failing not being a failure, clearing out your code through comments is the purpose of comments itself. So, good point Kevin !

On 1 November 2011 09:59, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 31/10/2011 18:43, Josh Suereth wrote:

That said, you can isolate your advanced usage from the rest of the
team's code as long as (a) the team is ok with that and (b) you know
you're becoming a single point of failure for some aspect of the code.

In both senses of the (b): the bugs are your, but also the risk is that you are the only person able to do maintenance on your code!
If you leave the company, or just move elsewhere in the hierarchy/departments, or just are very busy with more important matters, how to fix this bug?

"scala level of others +1" is a good formula, although I am not sure what it means (higher level of the others, average of the others? Is there a way to really measure that anyway?).

But somehow, use slightly more advanced concepts sparingly, and share them profusely...
In a good team, one should do code review with a peer, so it is a good opportunity if the code is understandable by a teammate.

An example of the sort of comment I'd use is:
// (collection.breakOut) forces the result to be directly built as a Map// instead of a Seq of pairs.  It's much more efficient.
Not really something you can explain in any other way, without a comment...
In general though, I prefer to make my code self-documenting.for comprehensions, for example, are a fantastic tool for achieving this.


On 1 November 2011 11:25, Alex Repain <alex.repain@gmail.com> wrote:

2011/11/1 Kevin Wright <kev.lee.wright@gmail.com>

If your goal is just to write code that other people can read and understand, then why not also make that the test?
Instead of trying in vain to define levels, have regular code reviews.  Then add comments or refactor as necessary for logic that people are struggling to follow in the review.
This way, I'm happily using "advanced" concepts such as self types, collection.breakOut and type lambdas.  So long as I add a brief comment whenever anybody asks "what the !!?!?! is *that*?" people seem to have no problem understanding.

One of my LISP teacher in college (Robert Strandh, cool guy) said once that whenever you need to add comments on your code, that's because you failed to make your code clear enough. if you take that straight, that meant that good code doesn't need comments. but clearness is so dependent of the reader's mind... If you take the sentence positively, with failing not being a failure, clearing out your code through comments is the purpose of comments itself. So, good point Kevin !

On 1 November 2011 09:59, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 31/10/2011 18:43, Josh Suereth wrote:

That said, you can isolate your advanced usage from the rest of the
team's code as long as (a) the team is ok with that and (b) you know
you're becoming a single point of failure for some aspect of the code.

In both senses of the (b): the bugs are your, but also the risk is that you are the only person able to do maintenance on your code!
If you leave the company, or just move elsewhere in the hierarchy/departments, or just are very busy with more important matters, how to fix this bug?

"scala level of others +1" is a good formula, although I am not sure what it means (higher level of the others, average of the others? Is there a way to really measure that anyway?).

But somehow, use slightly more advanced concepts sparingly, and share them profusely...
In a good team, one should do code review with a peer, so it is a good opportunity if the code is understandable by a teammate.

7

 

Did a test here – got a guy to pick-up scala in 5 days enough to design a specs-like DSL with a bunch of code around it as well – worked.

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Ken McDonald
Sent: October-31-11 1:29 PM
To: scala-user@googlegroups.com
Subject: [scala-user] Appropriate Scala "style" in real-world (Java/corporate) environment?

 

I don't really have (much) of a position on this, but thought it would be an interesting discussion to start.

 

Let's say you're working in a real-world environment, where the Java team has slowly started using Scala. You're a Scala guru (more than me), you know how to use the type system to do computation at compile time, etc, etc. You have a "Scal-o-meter" going from 0-9, where 0 is "Scala is exactly like Java, just with fewer type declarations" to 9 is "scalaz is the _low_ end--wait 'til you see _my_ HOF package".

 

Question: What is the appropriate Scal-o-meter setting to code at in your workplace?

 

My belief is no higher than 3, quite possibly 2. I find "map"'s OK, but "fold"'s are risqué and...I can't think of another good example right now, sorry :-).

 

 

Cheers,

Ken

Let's answer this with another question: s/Scala/Java/g.
--Let's say you're working in a real-world environment, using Java. You're a Java guru, you know how to do funky things with abstract classes, Proxys, reflection, complex spring/hibernate configurations etc. You have a "Jav-o-meter" going from 0-9, where 0 is "I know nothing" to 9 is "WTF?"
Question: What is the appropriate Jav-o-meter setting to code at in your workplace?--
Answer (to my question): Whatever is appropriate for your team.Answer (to your question): Whatever is appropriate for your team.
If you are going to maintain code, then write it how you like. If someone else is going to have to maintain the code, then write it at a level which is mutually understandable. But, you can expect them to learn. So the suggestion of their level + 1 is good.
Matthew Farwell.