Scala coding guidelines needed? NOT formatting style!

This effort is well under way
see http://davetron5000.github.com/scala-style/control_structures/comprehensions.html

-Stefan

2010/1/28 jonathan mawson <umptious@gmail.com>

I'm learning Scala and I'm *very* impressed. At first it looked like a
kitchen sink language, but now I see it's anything but that - the chosen
features fit together very well so that they multiplicative rather than
additive. Really excellent, profound well-thought out design. I did have a
"Hmmm, it's a pity that.." list. Then I looked at the spec for 2.8 and found
that the whole list had been take care of.

But - isn't it time for some coding style guidelines? I don't mean the
trivial stuff that emacs can hack, like function names and how many spaces
to a tab, but when to use an Array and when a List, when pattern matching to
get the value from an Option and when a HOF. What features tend to make code
slow and by how much? Where the gotchas? More importantly, what are the
questions that I don't know enough to ask, but really should? A lightweight
version of "Effective C++/Java/Perl/Whathaveyou", is what I'm suggesting, I
suppose.

It might help a lot if guidance like this evolved now - it could be the best
way of avoiding disasters, disappointments , and FUD during the Scala Boom,
which the language seems to be heading towards. Especially as so many people
will be coming from a background of strictly procedural/OO languages.
--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27356975.html
Sent from the Scala mailing list archive at Nabble.com.

It's a good question, but I don't know a great answer.

Programming in Scala is a great guide to the language and to good usage patterns (and to good code formatting too).  It's definitely the place to start.  The coding guidelines Stefan linked to contain a lot of formatting tips (e.g. "indent this way, it'll be clearer") but there are some good hints on usage patterns, too.

But I don't know of any good reference that will fill in all the next steps for what you've asked.  For example, there aren't any good guides I know of that talk extensively about performance and what the "dos" and "don'ts" are when performance is critical.  To some extent, this is beyond the scope of Scala documentation; arrays vs. lists give fast/slow performance in Scala just like they do in (virtually) all other languages because of the intrinsic properties of lists and arrays.  (Lists grow and shrink easily but seek slowly; arrays seek quickly but grow and shrink slowly; trees grow and shrink and seek at intermediate speeds.)  But to another extent, there's a lot of knowledge about styles that is not documented anywhere except implicitly in code that experienced Scala coders have written.  (Browsing the Scala API source can be particularly instructive, for example, as can reading the top answers to questions posted on StackOverflow in the Scala category.  Reading the scala-user mailing list is also very instructive--more even than the scala mailing list, as it gets higher volume and contains more questions of the sort, "I want to do X, how do I do it efficiently/prettily/at all in Scala?".)

And in some cases, there is not yet any established wisdom.  For example, on this list there will almost always be a disagreement over a statement that says, "do (or do not do) X, it is slow!"

  --Rex

P.S. One general piece of advice: Scala is an unusually expressive language.  A common mistake (in C++ also) is to try to use this to maximize _brevity_.  But this can lead to utterly surprising results once you've forgotten all the clever little tricks that have gone in to shorten the amount of typing.  Think instead of maximizing _clarity_.  Brevity is important, as it's easier to understand something short and clear than something long and clear (and hence, once you have learned all the filter/flatMap/foreach/etc. constructs, you'll want to use them!), but it is not the only or even the primary concern.


On Thu, Jan 28, 2010 at 9:38 AM, jonathan mawson <umptious@gmail.com> wrote:

[How can I learn] when to use an Array and when a List, when pattern matching to
get the value from an Option and when a HOF. What features tend to make code
slow and by how much? Where the gotchas?

I like the style guide very much:
http://davetron5000.github.com/scala-style/index.html
but IMO its quite hard to find for a scala starter.
couple of thoughts:
* shouldn't it be mentioned at least at the scala-lang page?
* this mailing list is good and fine but a FAQ or even the style guide
should be "stickys" in a forum, unfortunately this: http://scala-forum.org/
gives me nothing?! over the mailing list maybe that its not used by so many
people like this list. There is also stackoverflow where a lot of scala
knowledge is gathered and some like the rating mechanism.. In the end its
hard to know which place fits your needs the best.

+1 for linking the style guide from the scala-lang website.  I think that right there is probably sufficient to make it "findable" for beginners.

Daniel

On Thu, Jan 28, 2010 at 10:47 AM, andreas s. <andreas_scheinert@web.de> wrote:

I like the style guide very much:
http://davetron5000.github.com/scala-style/index.html
but IMO its quite hard to find for a scala starter.
couple of thoughts:
* shouldn't it be mentioned at least at the scala-lang page?
* this mailing list is good and fine but a FAQ or even the style guide
should be "stickys" in a forum, unfortunately this: http://scala-forum.org/
gives me nothing?! over the mailing list maybe that its not used by so many
people like this list. There is also stackoverflow where a lot of scala
knowledge is gathered and some like the rating mechanism.. In the end its
hard to know which place fits your needs the best.
--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27358538.html
Sent from the Scala mailing list archive at Nabble.com.

Stefan Langer-4 wrote:
>
> This effort is well under way
> see
> http://davetron5000.github.com/scala-style/control_structures/comprehens...
>
> -Stefan
>

That's great - thank you to you and Andreas. Could this be made a sticky
here and promoted more, perhaps?

Rex Kerr-2 wrote:
>
> But I don't know of any good reference that will fill in all the next
> steps
> for what you've asked. For example, there aren't any good guides I know
> of
> that talk extensively about performance and what the "dos" and "don'ts"
> are
> when performance is critical. To some extent, this is beyond the scope of
> Scala documentation; arrays vs. lists give fast/slow performance in Scala
> just like they do in (virtually) all other languages because of the
> intrinsic properties of lists and arrays. (Lists grow and shrink easily
> but
> seek slowly; arrays seek quickly but grow and shrink slowly; trees grow
> and
> shrink and seek at intermediate speeds.)
>

I think its always worth being as specific as you can about performance
trade offs and the designers' intentions. Especially in a design as
sophisticated as Scala. I just found this -

[quote]
http://www.drmaciver.com/2008/06/scala-arrays/

When used monomorphically, Scala arrays are Java arrays.

When used polymorphically, Scala arrays are scala.runtime.BoxedArray
instances. There is a separate subclass of BoxedArray for each primitive
type and one for object. When a monomorphic method receives a BoxedArray it
will usually unbox it rather than call its apply and update methods.
There is also BoxedAnyArray. This has a fairly high overhead and is used
*only* for creating polymorphic arrays. The compiler will get rid of it at
the earliest possible opportunity and rebox as other forms.

So, what does this mean in terms of performance?

Firstly, if you use arrays monomorphically, they will be Java arrays and
have no additional overhead associated with them (you'll need to box them
for invoking methods on Array like map, projection, etc, but this isn't too
bad). So if you want really high performance code, only use monomorphic
arrays.

At the next level, you can still get reasonably high performance code if you
use polymorphic arrays but only create them monomorphically. You'll get a
boxing overhead for primitives, but that's true of any polymorphic code in
Scala.

Slowest of all is when you create an array polymorphically and continue to
use it polymorphically. Once you're in monomorphic code it will regain
normal performance characteristics and future uses of it will behave as if
it had been instantiated monomorphically (but previously stored references
to it will continue to pass through a BoxedAnyArray and have the associated
overhead).

One final point of warning. Consider the following code:

class Foo[T]{
private[this] val arr = new Array[T](2);
def apply(i : Int) = arr(i);
def update(i : Int, t : T) = arr(i) = t;
}

Note that the Array never escapes this. So there's no way to unbox it!
[/quote]

That really is superb.

It answers a lot of my questions about the array implementation and answers
(and raises) more questions about polymorphism and performance, and
definitely deserves inclusion in any "Effective Scala" guide.

(I'm not obsessed with performance - although I like to know what my options
are - it's just a for-instance.)

I think this would be great to get linked from scala-lang website.  With increased visibility comes an increased need to ensure the stuff in here is well-agreed upon.
I haven't made radical changes to this from Daniel's original, but the ones I've made I put up for discussion here and when discussion died down, I made the changes that no one objected to.  That might be OK for a while, but can anyone think of a better way to build consensus?
Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com



On Thu, Jan 28, 2010 at 11:56 AM, Daniel Spiewak <djspiewak@gmail.com> wrote:

+1 for linking the style guide from the scala-lang website.  I think that right there is probably sufficient to make it "findable" for beginners.

Daniel

On Thu, Jan 28, 2010 at 10:47 AM, andreas s. <andreas_scheinert@web.de> wrote:

I like the style guide very much:
http://davetron5000.github.com/scala-style/index.html
but IMO its quite hard to find for a scala starter.
couple of thoughts:
* shouldn't it be mentioned at least at the scala-lang page?
* this mailing list is good and fine but a FAQ or even the style guide
should be "stickys" in a forum, unfortunately this: http://scala-forum.org/
gives me nothing?! over the mailing list maybe that its not used by so many
people like this list. There is also stackoverflow where a lot of scala
knowledge is gathered and some like the rating mechanism.. In the end its
hard to know which place fits your needs the best.
--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27358538.html
Sent from the Scala mailing list archive at Nabble.com.

andreas s. wrote:
> I like the style guide very much:
> http://davetron5000.github.com/scala-style/index.html
> but IMO its quite hard to find for a scala starter.
> couple of thoughts:
> * shouldn't it be mentioned at least at the scala-lang page?
> * this mailing list is good and fine but a FAQ or even the style guide
> should be "stickys" in a forum, unfortunately this: http://scala-forum.org/
> gives me nothing?! over the mailing list maybe that its not used by so many
> people like this list. There is also stackoverflow where a lot of scala
> knowledge is gathered and some like the rating mechanism.. In the end its
> hard to know which place fits your needs the best.
>
Much of the style guide makes it impossible to write high-level,
compositional and neat (in a deeper sense than is its objective) Scala
code. I am happy to ignore it (and all mailing list threads about it),
however if it is linked from scala-lang.org, then one day in the future
someone might suggest/force me to use it to the detriment of the overall
objective. For this reason, I must now object to linking from
scala-lang.org.

-1

On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
> Much of the style guide makes it impossible to write high-level,
> compositional and neat (in a deeper sense than is its objective) Scala
> code. I am happy to ignore it (and all mailing list threads about it),
> however if it is linked from scala-lang.org, then one day in the
> future someone might suggest/force me to use it to the detriment of
> the overall objective. For this reason, I must now object to linking
> from scala-lang.org.

I also object, for the same reasons. This is the age of google: put it
wherever you want and I guarantee you programmers who want it will find
it. It's premature to be pushing an official style. And please, I'd
really prefer not to have to take time away from working on 2.8 to argue
about it in detail.

On Thu, 2010-01-28 at 09:13 -0800, jonathan mawson wrote:
> [quote]
> http://www.drmaciver.com/2008/06/scala-arrays/
>
> When used monomorphically, Scala arrays are Java arrays.

Arrays changed in 2.8, see:

http://www.scala-lang.org/sid/7

Best,
Ismael

Tony Morris-4 wrote:
>
> andreas s. wrote:
>> I like the style guide very much:
>> http://davetron5000.github.com/scala-style/index.html
>> but IMO its quite hard to find for a scala starter.
>> couple of thoughts:
>> * shouldn't it be mentioned at least at the scala-lang page?
>> * this mailing list is good and fine but a FAQ or even the style guide
>> should be "stickys" in a forum, unfortunately this:
>> http://scala-forum.org/
>> gives me nothing?! over the mailing list maybe that its not used by so
>> many
>> people like this list. There is also stackoverflow where a lot of scala
>> knowledge is gathered and some like the rating mechanism.. In the end its
>> hard to know which place fits your needs the best.
>>
> Much of the style guide makes it impossible to write high-level,
> compositional and neat (in a deeper sense than is its objective) Scala
> code. I am happy to ignore it (and all mailing list threads about it),
> however if it is linked from scala-lang.org, then one day in the future
> someone might suggest/force me to use it to the detriment of the overall
> objective. For this reason, I must now object to linking from
> scala-lang.org.
>
>

Well - I'm fascinated by that! I've been reading your Scala articles with
quite a lot of admiration.

Paul Phillips-3 wrote:
>
> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>> Much of the style guide makes it impossible to write high-level,
>> compositional and neat (in a deeper sense than is its objective) Scala
>> code. I am happy to ignore it (and all mailing list threads about it),
>> however if it is linked from scala-lang.org, then one day in the
>> future someone might suggest/force me to use it to the detriment of
>> the overall objective. For this reason, I must now object to linking
>> from scala-lang.org.
>
> I also object, for the same reasons. This is the age of google: put it
> wherever you want and I guarantee you programmers who want it will find
> it.
>

How much is that guarantee worth, Paul? Because I'd like to claim whatever
it is you're paying. The closest that document comes to having decent search
visibility is in being linked to from a document that appears towards the
bottom of the first page of google results for "Scala coding guide lines".

If the coding guidelines are flawed, then saying people "I don't want them
linked; people will find them with google" isn't an answer. It's trying to
have your hiding-them cake and your-not-hidden cake eating orgy at the same
time. If the coding guidelines are flawed, then for goodness sake get less
flawed ones sorted out now, when they can have maximum influence on the
direction of growth.

Otoh, if this is just a case of there being nothing really wrong the style
in those guidelines but some people preferring a different and equally valid
style - well, as Scala takes off coding standards and guidelines will
emerge. Smart ones are better than dumb ones. This is the time when you can
have maximum impact. Trying to bury every style guide that might be used
against you is a futile strategy.

I agree 100%. The lack of well-known style and coding guidelines is
extremely detremental to Scala's adoption. Remember, the audience we
really need to target with these guidelines is the Scala newcomers,
the ones who haven't been following the list and don't know the magic
keywords to find the guide on Google. Remember, Google only works if
people link to the target document.

As for flaws in the guidelines, I know what you're referring to, and I
disagree. If you write your Scala in a very Haskell-esque style, then
yes, the guidelines will be a hinderance. However, if you embrace the
object-functional style (especially with respect to traits), then the
guide will result in clean, composable code. Scala allows many
paradigms to be used with more or less effectiveness. As such, any
style guide (which necessarily must pick only one such paradigm) will
be unsatisfactory to a large number of developers. So in summary: Are
the guidelines fundamentally flawed (preventative of composable
architecture)? No. Are they the best practice for all Scala usage
patterns? No (not even close). Are they important and valuable for
Scala beginners? Without a doubt.

Danie

On Jan 28, 2010, at 5:28 PM, "jonathan mawson"
wrote:

>
>
>
> Paul Phillips-3 wrote:
>>
>> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>>> Much of the style guide makes it impossible to write high-level,
>>> compositional and neat (in a deeper sense than is its objective)
>>> Scala
>>> code. I am happy to ignore it (and all mailing list threads about
>>> it),
>>> however if it is linked from scala-lang.org, then one day in the
>>> future someone might suggest/force me to use it to the detriment of
>>> the overall objective. For this reason, I must now object to linking
>>> from scala-lang.org.
>>
>> I also object, for the same reasons. This is the age of google:
>> put it
>> wherever you want and I guarantee you programmers who want it will
>> find
>> it.
>>
>
> How much is that guarantee worth, Paul? Because I'd like to claim
> whatever
> it is you're paying. The closest that document comes to having
> decent search
> visibility is in being linked to from a document that appears
> towards the
> bottom of the first page of google results for "Scala coding guide
> lines".
>
> If the coding guidelines are flawed, then saying people "I don't
> want them
> linked; people will find them with google" isn't an answer. It's
> trying to
> have your hiding-them cake and your-not-hidden cake eating orgy at
> the same
> time. If the coding guidelines are flawed, then for goodness sake
> get less
> flawed ones sorted out now, when they can have maximum influence on
> the
> direction of growth.
>
> Otoh, if this is just a case of there being nothing really wrong the
> style
> in those guidelines but some people preferring a different and
> equally valid
> style - well, as Scala takes off coding standards and guidelines will
> emerge. Smart ones are better than dumb ones. This is the time when
> you can
> have maximum impact. Trying to bury every style guide that might be
> used
> against you is a futile strategy.
>
>
>

I didn't say "Haskell-esque style". I said high-level, compositional and
neat.

Daniel Spiewak wrote:
> I agree 100%. The lack of well-known style and coding guidelines is
> extremely detremental to Scala's adoption. Remember, the audience we
> really need to target with these guidelines is the Scala newcomers,
> the ones who haven't been following the list and don't know the magic
> keywords to find the guide on Google. Remember, Google only works if
> people link to the target document.
>
> As for flaws in the guidelines, I know what you're referring to, and I
> disagree. If you write your Scala in a very Haskell-esque style, then
> yes, the guidelines will be a hinderance. However, if you embrace the
> object-functional style (especially with respect to traits), then the
> guide will result in clean, composable code. Scala allows many
> paradigms to be used with more or less effectiveness. As such, any
> style guide (which necessarily must pick only one such paradigm) will
> be unsatisfactory to a large number of developers. So in summary: Are
> the guidelines fundamentally flawed (preventative of composable
> architecture)? No. Are they the best practice for all Scala usage
> patterns? No (not even close). Are they important and valuable for
> Scala beginners? Without a doubt.
>
> Danie
>
> On Jan 28, 2010, at 5:28 PM, "jonathan mawson"
> wrote:
>
>>
>>
>>
>> Paul Phillips-3 wrote:
>>>
>>> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>>>> Much of the style guide makes it impossible to write high-level,
>>>> compositional and neat (in a deeper sense than is its objective) Scala
>>>> code. I am happy to ignore it (and all mailing list threads about it),
>>>> however if it is linked from scala-lang.org, then one day in the
>>>> future someone might suggest/force me to use it to the detriment of
>>>> the overall objective. For this reason, I must now object to linking
>>>> from scala-lang.org.
>>>
>>> I also object, for the same reasons. This is the age of google: put it
>>> wherever you want and I guarantee you programmers who want it will find
>>> it.
>>>
>>
>> How much is that guarantee worth, Paul? Because I'd like to claim
>> whatever
>> it is you're paying. The closest that document comes to having decent
>> search
>> visibility is in being linked to from a document that appears towards
>> the
>> bottom of the first page of google results for "Scala coding guide
>> lines".
>>
>> If the coding guidelines are flawed, then saying people "I don't want
>> them
>> linked; people will find them with google" isn't an answer. It's
>> trying to
>> have your hiding-them cake and your-not-hidden cake eating orgy at
>> the same
>> time. If the coding guidelines are flawed, then for goodness sake get
>> less
>> flawed ones sorted out now, when they can have maximum influence on the
>> direction of growth.
>>
>> Otoh, if this is just a case of there being nothing really wrong the
>> style
>> in those guidelines but some people preferring a different and
>> equally valid
>> style - well, as Scala takes off coding standards and guidelines will
>> emerge. Smart ones are better than dumb ones. This is the time when
>> you can
>> have maximum impact. Trying to bury every style guide that might be used
>> against you is a futile strategy.
>>
>>
>>

Yes, but there are many ways to do "high-level, compositional and neat" code in Scala.  That's exactly my point.  It all boils down to what your primary unit of abstraction is.  If you are relying primarily on functions (and secondarily on objects), then you will end up needing a style which emphasizes point-free, currying, typeclasses and so on.  From what I have seen of your publically-available code (and I've seen a lot of it), you lean more toward the functional style than the object-oriented.  There's nothing wrong with that, but it's certainly a very different style from the one encouraged (and facilitated) by the guide.

I know for a fact that it is possible to do high-level, compositional and neat Scala code following the guide because I do it on a regular basis.  My code is just as terse, maintainable and readable as any, but it doesn't rely as heavily on functional features as yours does.  As I said, different paradigms require different style guidelines.

Scala is unique in that it is even possible to have this sort of debate.  With most languages, there's really only one right design methodology, all of the others are measurably inferior.  As such, it's easy to write style guidelines for those languages because they only need to encourage the "right way" and discourage the "wrong one".  With Scala, there are a number of different ways in which "high-level, compositional and neat" code may be written.  The guide as it stands encourages one way.  It doesn't encourage yours, which is perfectly fine.  When I was learning Scala, I made a conscious choice to try to blend OO and FP paradigms as much as possible in my own methodology.  The original draft of the guide was the result of that blending.  Is it the only way?  Not at all.

Daniel

On Thu, Jan 28, 2010 at 5:46 PM, Tony Morris <tonymorris@gmail.com> wrote:

I didn't say "Haskell-esque style". I said high-level, compositional and
neat.


Daniel Spiewak wrote:
> I agree 100%.  The lack of well-known style and coding guidelines is
> extremely detremental to Scala's adoption.  Remember, the audience we
> really need to target with these guidelines is the Scala newcomers,
> the ones who haven't been following the list and don't know the magic
> keywords to find the guide on Google.  Remember, Google only works if
> people link to the target document.
>
> As for flaws in the guidelines, I know what you're referring to, and I
> disagree.  If you write your Scala in a very Haskell-esque style, then
> yes, the guidelines will be a hinderance.  However, if you embrace the
> object-functional style (especially with respect to traits), then the
> guide will result in clean, composable code.  Scala allows many
> paradigms to be used with more or less effectiveness.  As such, any
> style guide (which necessarily must pick only one such paradigm) will
> be unsatisfactory to a large number of developers.  So in summary: Are
> the guidelines fundamentally flawed (preventative of composable
> architecture)?  No.  Are they the best practice for all Scala usage
> patterns?  No (not even close).  Are they important and valuable for
> Scala beginners?  Without a doubt.
>
> Danie
>
> On Jan 28, 2010, at 5:28 PM, "jonathan mawson" <umptious@gmail.com>
> wrote:
>
>>
>>
>>
>> Paul Phillips-3 wrote:
>>>
>>> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>>>> Much of the style guide makes it impossible to write high-level,
>>>> compositional and neat (in a deeper sense than is its objective) Scala
>>>> code. I am happy to ignore it (and all mailing list threads about it),
>>>> however if it is linked from scala-lang.org, then one day in the
>>>> future someone might suggest/force me to use it to the detriment of
>>>> the overall objective. For this reason, I must now object to linking
>>>> from scala-lang.org.
>>>
>>> I also object, for the same reasons.  This is the age of google: put it
>>> wherever you want and I guarantee you programmers who want it will find
>>> it.
>>>
>>
>> How much is that guarantee worth, Paul? Because I'd like to claim
>> whatever
>> it is you're paying. The closest that document comes to having decent
>> search
>> visibility is in being linked to from a document that appears towards
>> the
>> bottom of the first page of google results for "Scala coding guide
>> lines".
>>
>> If the coding guidelines are flawed, then saying people "I don't want
>> them
>> linked; people will find them with google" isn't an answer. It's
>> trying to
>> have your hiding-them cake and your-not-hidden cake eating orgy at
>> the same
>> time. If the coding guidelines are flawed, then for goodness sake get
>> less
>> flawed ones sorted out now, when they can have maximum influence on the
>> direction of growth.
>>
>> Otoh, if this is just a case of there being nothing really wrong the
>> style
>> in those guidelines but some people preferring a different and
>> equally valid
>> style - well, as Scala takes off coding standards and guidelines will
>> emerge. Smart ones are better than dumb ones. This is the time when
>> you can
>> have maximum impact. Trying to bury every style guide that might be used
>> against you is a futile strategy.
>>
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27365010.html
>>
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>


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

This is precisely the argument I wish to avoid having. I'd rather solve
problems.

Daniel Spiewak wrote:
> Yes, but there are many ways to do "high-level, compositional and neat" code
> in Scala. That's exactly my point. It all boils down to what your primary
> unit of abstraction is. If you are relying primarily on functions (and
> secondarily on objects), then you will end up needing a style which
> emphasizes point-free, currying, typeclasses and so on. From what I have
> seen of your publically-available code (and I've seen a lot of it), you lean
> more toward the functional style than the object-oriented. There's nothing
> wrong with that, but it's certainly a very different style from the one
> encouraged (and facilitated) by the guide.
>
> I know for a fact that it is possible to do high-level, compositional and
> neat Scala code following the guide because I do it on a regular basis. My
> code is just as terse, maintainable and readable as any, but it doesn't rely
> as heavily on functional features as yours does. As I said, different
> paradigms require different style guidelines.
>
> Scala is unique in that it is even possible to have this sort of debate.
> With most languages, there's really only one right design methodology, all
> of the others are measurably inferior. As such, it's easy to write style
> guidelines for those languages because they only need to encourage the
> "right way" and discourage the "wrong one". With Scala, there are a number
> of different ways in which "high-level, compositional and neat" code may be
> written. The guide as it stands encourages one way. It doesn't encourage
> yours, which is perfectly fine. When I was learning Scala, I made a
> conscious choice to try to blend OO and FP paradigms as much as possible in
> my own methodology. The original draft of the guide was the result of that
> blending. Is it the only way? Not at all.
>
> Daniel
>
> On Thu, Jan 28, 2010 at 5:46 PM, Tony Morris wrote:
>
>
>> I didn't say "Haskell-esque style". I said high-level, compositional and
>> neat.
>>
>>
>> Daniel Spiewak wrote:
>>
>>> I agree 100%. The lack of well-known style and coding guidelines is
>>> extremely detremental to Scala's adoption. Remember, the audience we
>>> really need to target with these guidelines is the Scala newcomers,
>>> the ones who haven't been following the list and don't know the magic
>>> keywords to find the guide on Google. Remember, Google only works if
>>> people link to the target document.
>>>
>>> As for flaws in the guidelines, I know what you're referring to, and I
>>> disagree. If you write your Scala in a very Haskell-esque style, then
>>> yes, the guidelines will be a hinderance. However, if you embrace the
>>> object-functional style (especially with respect to traits), then the
>>> guide will result in clean, composable code. Scala allows many
>>> paradigms to be used with more or less effectiveness. As such, any
>>> style guide (which necessarily must pick only one such paradigm) will
>>> be unsatisfactory to a large number of developers. So in summary: Are
>>> the guidelines fundamentally flawed (preventative of composable
>>> architecture)? No. Are they the best practice for all Scala usage
>>> patterns? No (not even close). Are they important and valuable for
>>> Scala beginners? Without a doubt.
>>>
>>> Danie
>>>
>>> On Jan 28, 2010, at 5:28 PM, "jonathan mawson"
>>> wrote:
>>>
>>>
>>>>
>>>> Paul Phillips-3 wrote:
>>>>
>>>>> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>>>>>
>>>>>> Much of the style guide makes it impossible to write high-level,
>>>>>> compositional and neat (in a deeper sense than is its objective) Scala
>>>>>> code. I am happy to ignore it (and all mailing list threads about it),
>>>>>> however if it is linked from scala-lang.org, then one day in the
>>>>>> future someone might suggest/force me to use it to the detriment of
>>>>>> the overall objective. For this reason, I must now object to linking
>>>>>> from scala-lang.org.
>>>>>>
>>>>> I also object, for the same reasons. This is the age of google: put it
>>>>> wherever you want and I guarantee you programmers who want it will find
>>>>> it.
>>>>>
>>>>>
>>>> How much is that guarantee worth, Paul? Because I'd like to claim
>>>> whatever
>>>> it is you're paying. The closest that document comes to having decent
>>>> search
>>>> visibility is in being linked to from a document that appears towards
>>>> the
>>>> bottom of the first page of google results for "Scala coding guide
>>>> lines".
>>>>
>>>> If the coding guidelines are flawed, then saying people "I don't want
>>>> them
>>>> linked; people will find them with google" isn't an answer. It's
>>>> trying to
>>>> have your hiding-them cake and your-not-hidden cake eating orgy at
>>>> the same
>>>> time. If the coding guidelines are flawed, then for goodness sake get
>>>> less
>>>> flawed ones sorted out now, when they can have maximum influence on the
>>>> direction of growth.
>>>>
>>>> Otoh, if this is just a case of there being nothing really wrong the
>>>> style
>>>> in those guidelines but some people preferring a different and
>>>> equally valid
>>>> style - well, as Scala takes off coding standards and guidelines will
>>>> emerge. Smart ones are better than dumb ones. This is the time when
>>>> you can
>>>> have maximum impact. Trying to bury every style guide that might be used
>>>> against you is a futile strategy.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>>
>> http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-sty...
>>
>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>
>>>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

On Thursday January 28 2010, Daniel Spiewak wrote:
> I agree 100%. The lack of well-known style and coding guidelines is
> extremely detremental to Scala's adoption.

I'm with the nay's. I'm concerned that if I manage to get a job
programming Scala I might be required to follow such guidelines,
which is something I strongly object to.

Randall Schulz

Fair enough.  Arguing about style guidelines and coding methodology is pretty pedantic.  However, the fact remains that newcomers to the language and even experienced developers when working in a team need some sort of style guide.  I've experienced both of these cases first-hand.  To my knowledge, this style guide is the only one which attempts to solve these problems.  It absolutely should be publicized so that users can find it easily.

I don't have any objection to a "style guide page" at scala-lang.org which links to a number of competing style guides; we don't have to pick just one as the final word.  However, we do need something.  As I said, the information vacuum is hurting Scala's adoption on multiple fronts (newcomers and growing teams).

Daniel

On Thu, Jan 28, 2010 at 6:05 PM, Tony Morris <tonymorris@gmail.com> wrote:

This is precisely the argument I wish to avoid having. I'd rather solve
problems.

Daniel Spiewak wrote:
> Yes, but there are many ways to do "high-level, compositional and neat" code
> in Scala.  That's exactly my point.  It all boils down to what your primary
> unit of abstraction is.  If you are relying primarily on functions (and
> secondarily on objects), then you will end up needing a style which
> emphasizes point-free, currying, typeclasses and so on.  From what I have
> seen of your publically-available code (and I've seen a lot of it), you lean
> more toward the functional style than the object-oriented.  There's nothing
> wrong with that, but it's certainly a very different style from the one
> encouraged (and facilitated) by the guide.
>
> I know for a fact that it is possible to do high-level, compositional and
> neat Scala code following the guide because I do it on a regular basis.  My
> code is just as terse, maintainable and readable as any, but it doesn't rely
> as heavily on functional features as yours does.  As I said, different
> paradigms require different style guidelines.
>
> Scala is unique in that it is even possible to have this sort of debate.
> With most languages, there's really only one right design methodology, all
> of the others are measurably inferior.  As such, it's easy to write style
> guidelines for those languages because they only need to encourage the
> "right way" and discourage the "wrong one".  With Scala, there are a number
> of different ways in which "high-level, compositional and neat" code may be
> written.  The guide as it stands encourages one way.  It doesn't encourage
> yours, which is perfectly fine.  When I was learning Scala, I made a
> conscious choice to try to blend OO and FP paradigms as much as possible in
> my own methodology.  The original draft of the guide was the result of that
> blending.  Is it the only way?  Not at all.
>
> Daniel
>
> On Thu, Jan 28, 2010 at 5:46 PM, Tony Morris <tonymorris@gmail.com> wrote:
>
>
>> I didn't say "Haskell-esque style". I said high-level, compositional and
>> neat.
>>
>>
>> Daniel Spiewak wrote:
>>
>>> I agree 100%.  The lack of well-known style and coding guidelines is
>>> extremely detremental to Scala's adoption.  Remember, the audience we
>>> really need to target with these guidelines is the Scala newcomers,
>>> the ones who haven't been following the list and don't know the magic
>>> keywords to find the guide on Google.  Remember, Google only works if
>>> people link to the target document.
>>>
>>> As for flaws in the guidelines, I know what you're referring to, and I
>>> disagree.  If you write your Scala in a very Haskell-esque style, then
>>> yes, the guidelines will be a hinderance.  However, if you embrace the
>>> object-functional style (especially with respect to traits), then the
>>> guide will result in clean, composable code.  Scala allows many
>>> paradigms to be used with more or less effectiveness.  As such, any
>>> style guide (which necessarily must pick only one such paradigm) will
>>> be unsatisfactory to a large number of developers.  So in summary: Are
>>> the guidelines fundamentally flawed (preventative of composable
>>> architecture)?  No.  Are they the best practice for all Scala usage
>>> patterns?  No (not even close).  Are they important and valuable for
>>> Scala beginners?  Without a doubt.
>>>
>>> Danie
>>>
>>> On Jan 28, 2010, at 5:28 PM, "jonathan mawson" <umptious@gmail.com>
>>> wrote:
>>>
>>>
>>>>
>>>> Paul Phillips-3 wrote:
>>>>
>>>>> On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
>>>>>
>>>>>> Much of the style guide makes it impossible to write high-level,
>>>>>> compositional and neat (in a deeper sense than is its objective) Scala
>>>>>> code. I am happy to ignore it (and all mailing list threads about it),
>>>>>> however if it is linked from scala-lang.org, then one day in the
>>>>>> future someone might suggest/force me to use it to the detriment of
>>>>>> the overall objective. For this reason, I must now object to linking
>>>>>> from scala-lang.org.
>>>>>>
>>>>> I also object, for the same reasons.  This is the age of google: put it
>>>>> wherever you want and I guarantee you programmers who want it will find
>>>>> it.
>>>>>
>>>>>
>>>> How much is that guarantee worth, Paul? Because I'd like to claim
>>>> whatever
>>>> it is you're paying. The closest that document comes to having decent
>>>> search
>>>> visibility is in being linked to from a document that appears towards
>>>> the
>>>> bottom of the first page of google results for "Scala coding guide
>>>> lines".
>>>>
>>>> If the coding guidelines are flawed, then saying people "I don't want
>>>> them
>>>> linked; people will find them with google" isn't an answer. It's
>>>> trying to
>>>> have your hiding-them cake and your-not-hidden cake eating orgy at
>>>> the same
>>>> time. If the coding guidelines are flawed, then for goodness sake get
>>>> less
>>>> flawed ones sorted out now, when they can have maximum influence on the
>>>> direction of growth.
>>>>
>>>> Otoh, if this is just a case of there being nothing really wrong the
>>>> style
>>>> in those guidelines but some people preferring a different and
>>>> equally valid
>>>> style - well, as Scala takes off coding standards and guidelines will
>>>> emerge. Smart ones are better than dumb ones. This is the time when
>>>> you can
>>>> have maximum impact. Trying to bury every style guide that might be used
>>>> against you is a futile strategy.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>>
>> http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27365010.html
>>
>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>
>>>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>


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

Tony Morris-4 wrote:
>
> I didn't say "Haskell-esque style". I said high-level, compositional and
> neat.
>

Tony - could you give an example of what you object to? Because to me these
guidelines look like nothing but a set of formatting guidelines. Not the
sort of thing I was looking for (people here have read "Effective C++" or
its Java or Perl clones, yes?) and too surface oriented for me to understand
why they deserve so much ire. I've only skimmed them so far, but I can't
understand why guidelines like "Put a space after, but not before, a type
qualifier following a value name" would stop you from writing "high-level"
or "compositional" code. "Neat", of course, is extremely subject. Come to
think of it, I can only guess what you mean by "compositional".

To give an idea of the sort of thing I was thinking of:

"Item #1, use val whenever possible instead of var." ..And then into
rationale, the benefits, and associated tactics, like calculating a complex
value inside a block.

"Item #14, close file handles when you finish with them" - I think this is
true for Scala, yes?

Object identity versus equality; shallow and deep cloning; implementation of
and penalties for using generics, virtual functions; use of Option and
language support via pattern matching (cf map fns built-in to Option). Etc.
That sort of thing. Important stuff with communicable objective right and
wrong answers. Not conventions about how many spaces make a tab or a war
over whether an opening brace should be on the same line as its function
name or (heresy!) on the next one.

I'd really prefer not to, at least on the mailing list. I hope you
understand, but it's just not worth it. Your enthusiasm is welcome;
perhaps in private.

jonathan mawson wrote:
>
> Tony Morris-4 wrote:
>
>> I didn't say "Haskell-esque style". I said high-level, compositional and
>> neat.
>>
>>
>
> Tony - could you give an example of what you object to? Because to me these
> guidelines look like nothing but a set of formatting guidelines. Not the
> sort of thing I was looking for (people here have read "Effective C++" or
> its Java or Perl clones, yes?) and too surface oriented for me to understand
> why they deserve so much ire. I've only skimmed them so far, but I can't
> understand why guidelines like "Put a space after, but not before, a type
> qualifier following a value name" would stop you from writing "high-level"
> or "compositional" code. "Neat", of course, is extremely subject. Come to
> think of it, I can only guess what you mean by "compositional".
>
>

Tony, Paul!
I concur its bad to stop you from coding while arguing here.

Yet i would like to Share my opinion:
i think the style guide (from here on oos, for Object Orient style/Scala)
is important and also to put a Link on the offical page.
At the offical Site i there there was a "getting started for oo/imperative
People"
i think it would fit nice there.
But also Reading a lot of tonys Blogs and Some Code i absolutly agree that
there is another style, more terse, maybe fp like.
I don't Know if we need an "fp" style guide. But i think thats one of the
fundamental challenges with scala. When to apply which style and where what
would be the possible pro/ cons.
IMO an oo AND fp style Guide would be nice it really would help People to
understand the diffrent options you have with Scala.

I think what we'll do is link to the style guide from java-lang.org,
but have some explanatory text saying that this is so far the most
detailed and complete style guide available, but that we do not claim
it should be followed by everyone. See yourself whether you think it
works out for you.

By the same token, if people disagree with that style guide and want
to work on different ones, we might link to these also once they are
in a mature state, and provided we find their principles consistent
and defensible, like we do for the current one.

Cheers

On Fri, Jan 29, 2010 at 5:17 PM, martin odersky <martin.odersky@epfl.ch> wrote:

I think what we'll do is link to the style guide from java-lang.org,

we should probably also finally get around to having java-lang.org redirect to scala-lang.org ;-)
adriaan 

+1 thereGiven that Java is now branded in red, it even looks to co-ordinate well with our logo...


On 29 January 2010 16:53, Adriaan Moors <adriaan.moors@cs.kuleuven.be> wrote:

On Fri, Jan 29, 2010 at 5:17 PM, martin odersky <martin.odersky@epfl.ch> wrote:

I think what we'll do is link to the style guide from java-lang.org,

we should probably also finally get around to having java-lang.org redirect to scala-lang.org ;-)
adriaan 

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Randall Schulz wrote:
>
> On Thursday January 28 2010, Daniel Spiewak wrote:
>> I agree 100%. The lack of well-known style and coding guidelines is
>> extremely detremental to Scala's adoption.
>
> I'm with the nay's. I'm concerned that if I manage to get a job
> programming Scala I might be required to follow such guidelines,
> which is something I strongly object to.
>
>
> Randall Schulz
>
>

Why should you object to being required to be competent? And don't you want
to work with other people who are competent? Once again: I am NOT talking
about formatting and variable naming.* But stuff like this (example from the
Artima Scala Forum):

> http://www.artima.com/forums/flat.jsp?forum=282&thread=237361
>
> Hi,
>
> I started playing with the language, and the first try does not go well.
>
> (1 to 3000000).toList.sort(_>_)
>
> takes 100% CPU and does not return. I have to kill it after 4 min. Sorting
> 3 million integer should take no time. For example, on python
>
> l = range(3000000, 0, -1)
> l.sort()
>
> returns immediately.
>
> Why scala sort is so slow? Is it the sort algorithm or the language?
>
> Thanks,
>
> ------------------
>
> Your code looks harmless, but under the hood it is generating a Range
> object, then converting that to a List, then performing a sort, then
> creating a String representation of the result, then printing a truncated
> version of the result to the Console.
>
> Your example highlighted a missing function on the Collection API - sort.
> But, since it is not there, we can add it with one slick line of implicit
> magic.
>
> implicit def ArraySort(a:Array[Int]) = new { def sort() = {
> scala.util.Sorting.quickSort(a); a } }
>
> Now you compare apples with apples:
>
>
> scala> def timesort()={ val s=System.currentTimeMillis;
> Array.range(1,3000000).sort; val e=System.currentTimeMillis; e-s}
> timesort: ()Long
>
> scala> timesort
> res61: Long = 1823
>
>
> To summarize, when run from the Scala Console, big Arrays and Lists
> attempt to create string representations of results even though they are
> merely showing a truncated version in the console. This is why even my
> newfangled Array#sort will run out of memory, when you run directly in the
> Console as Array.range(1,3000000).sort.
>

This would be handled by two items in an Effective Scala document:

> Performance: Beware string representations of arrays and lists in console.
> Although they may appear only in truncated form...
>
> Performance: Beware hidden conversions. Use "implicit" to avoid
> unnecessary ones...
>

*And if you think that not having a reasonable set of Scala formatting
guidelines will allow you to Do It My Way, then you are lousy at politics!
If there aren't guidelines for Scala, a more likely effect is that you'll be
instructed to follow the shop guidelines for Java, if they are inclined to
giving such instruction. Me, I'd use a decent editor that will convert
between your and the standard formatting style if it really is such an issue
for you.

Martin Odersky wrote:
>
> I think what we'll do is link to the style guide from java-lang.org,
> but have some explanatory text saying that this is so far the most
> detailed and complete style guide available, but that we do not claim
> it should be followed by everyone. See yourself whether you think it
> works out for you.
>

A style guide could be made friendly to several camps by giving an options
and say when they are appropriate. And my very strong suspicion is that
without an official style guide, then Scala will be forced into a Java
shaped formatting mould rather than set free.

But it isn't really a set of formatting guidelines that I think is really
needed - the really crucial issues are much deeper. It's what to and what
not to do, rather than how to format the text.

Btw - my best friend's jaw dropped when hew saw how few BNF clauses were
needed to define Scala compared to C++. *Nice* design!

On Fri, Jan 29, 2010 at 5:53 PM, Adriaan Moors
wrote:
>
>
> On Fri, Jan 29, 2010 at 5:17 PM, martin odersky
> wrote:
>>
>> I think what we'll do is link to the style guide from java-lang.org,
>
> we should probably also finally get around to having java-lang.org redirect
> to scala-lang.org ;-)

Oops, slip of the fingers... Yes, that would be neat if we could pull
that off ;-) in fact, the domain java-lang.org is currently parked,
not sure how much they want for it ...

Cheers

I'm actually releasing a book titled "Scala In Depth" (sometime next year) that should serve as a lightweight version of "Effective Scala".  The early access program starts sometime soon, but I need to finish tweaking the first couple chapters for that.

There's already a lot of good guidance/wisdom but it requires reading a lot of old blogs and digging through this mailing list for nuggets of wisdom, as well as some good old blood, sweat and tears.


Anyway, I totally agree with you that this kind of information is needed and I'm actively trying to help fill that gap!

- Josh Suereth.

On Thu, Jan 28, 2010 at 9:38 AM, jonathan mawson <umptious@gmail.com> wrote:

I'm learning Scala and I'm *very* impressed. At first it looked like a
kitchen sink language, but now I see it's anything but that - the chosen
features fit together very well so that they multiplicative rather than
additive. Really excellent, profound well-thought out design. I did have a
"Hmmm, it's a pity that.." list. Then I looked at the spec for 2.8 and found
that the whole list had been take care of.

But - isn't it time for some coding style guidelines? I don't mean the
trivial stuff that emacs can hack, like function names and how many spaces
to a tab, but when to use an Array and when a List, when pattern matching to
get the value from an Option and when a HOF. What features tend to make code
slow and by how much? Where the gotchas? More importantly, what are the
questions that I don't know enough to ask, but really should? A lightweight
version of "Effective C++/Java/Perl/Whathaveyou", is what I'm suggesting, I
suppose.

It might help a lot if guidance like this evolved now - it could be the best
way of avoiding disasters, disappointments , and FUD during the Scala Boom,
which the language seems to be heading towards. Especially as so many people
will be coming from a background of strictly procedural/OO languages.
--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27356975.html
Sent from the Scala mailing list archive at Nabble.com.

I agree with Tony and Paul.  I think at this point there are several major styles for writing Scala, and I can't say that any of them are "wrong" or "preferable."

On Thu, Jan 28, 2010 at 5:48 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
> Much of the style guide makes it impossible to write high-level,
> compositional and neat (in a deeper sense than is its objective) Scala
> code. I am happy to ignore it (and all mailing list threads about it),
> however if it is linked from scala-lang.org, then one day in the
> future someone might suggest/force me to use it to the detriment of
> the overall objective. For this reason, I must now object to linking
> from scala-lang.org.

I also object, for the same reasons.  This is the age of google: put it
wherever you want and I guarantee you programmers who want it will find
it.  It's premature to be pushing an official style.  And please, I'd
really prefer not to have to take time away from working on 2.8 to argue
about it in detail.

--
Paul Phillips      | We must respect the other fellow's religion, but only
Analgesic          | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
i pull his palp!   |     -- H. L. Mencken

--
http://erikengbrecht.blogspot.com/

On Sat, Jan 30, 2010 at 2:57 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I agree with Tony and Paul.  I think at this point there are several major styles for writing Scala, and I can't say that any of them are "wrong" or "preferable."

I've got 5 bux that say you can.

;)
 

On Thu, Jan 28, 2010 at 5:48 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Jan 29, 2010 at 08:18:46AM +1000, Tony Morris wrote:
> Much of the style guide makes it impossible to write high-level,
> compositional and neat (in a deeper sense than is its objective) Scala
> code. I am happy to ignore it (and all mailing list threads about it),
> however if it is linked from scala-lang.org, then one day in the
> future someone might suggest/force me to use it to the detriment of
> the overall objective. For this reason, I must now object to linking
> from scala-lang.org.

I also object, for the same reasons.  This is the age of google: put it
wherever you want and I guarantee you programmers who want it will find
it.  It's premature to be pushing an official style.  And please, I'd
really prefer not to have to take time away from working on 2.8 to argue
about it in detail.

--
Paul Phillips      | We must respect the other fellow's religion, but only
Analgesic          | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
i pull his palp!   |     -- H. L. Mencken

--
http://erikengbrecht.blogspot.com/

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

On Sat, Jan 30, 2010 at 9:03 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Sat, Jan 30, 2010 at 2:57 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

I agree with Tony and Paul.  I think at this point there are several major styles for writing Scala, and I can't say that any of them are "wrong" or "preferable."

I've got 5 bux that say you can.

;)

I think you're wrong!

Josh Suereth wrote:
>
> I'm actually releasing a book titled "Scala In Depth" (sometime next year)
> that should serve as a lightweight version of "Effective Scala". The
> early
> access program starts sometime soon, but I need to finish tweaking the
> first
> couple chapters for that.
>
> There's already a lot of good guidance/wisdom but it requires reading a
> lot
> of old blogs and digging through this mailing list for nuggets of wisdom,
> as
> well as some good old blood, sweat and tears.
>
>
> Anyway, I totally agree with you that this kind of information is needed
> and
> I'm actively trying to help fill that gap!
>
> - Josh Suereth.
>

Well - at least I've explained what I mean well enough so that someone who
has already had it can recognize it. The explanation on your blog of why and
how to avoid the Application trait is *exactly* the sort of thing I was
talking about, Josh. If you want a proof reader/tester/suggester of
questions then just let me know.

Viktor Klang wrote:
>
> On Sat, Jan 30, 2010 at 2:57 PM, Erik Engbrecht
> wrote:
>
>> I agree with Tony and Paul. I think at this point there are several
>> major
>> styles for writing Scala, and I can't say that any of them are "wrong" or
>> "preferable."
>
>
> I've got 5 bux that say you can.
>
> ;)
>
>

Once again: I'm not talking about formatting. I'm talking about a set of
guidelines that will clue people in on things like the hidden cost of using
Application.

I wasn't talking about talking about formatting, either.
Look at the source for pieces of the Scala standard library, Lift, and Scalaz.  I think you'll find several fundamentally different approaches to writing Scala.
Collecting gotchas and general weird Scala behavior is another matter.  I think someone is maintaining a list of Scala puzzlers somewhere, but I can't recall who or where.
On Sat, Jan 30, 2010 at 12:33 PM, jonathan mawson <umptious@gmail.com> wrote:

Viktor Klang wrote:
>
> On Sat, Jan 30, 2010 at 2:57 PM, Erik Engbrecht
> <erik.engbrecht@gmail.com>wrote:
>
>> I agree with Tony and Paul.  I think at this point there are several
>> major
>> styles for writing Scala, and I can't say that any of them are "wrong" or
>> "preferable."
>
>
> I've got 5 bux that say you can.
>
> ;)
>
>

Once again: I'm not talking about formatting. I'm talking about a set of
guidelines that will clue people in on things like the hidden cost of using
Application.

--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27385685.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

Erik Engbrecht wrote:
>
> I wasn't talking about talking about formatting, either.
>
> Look at the source for pieces of the Scala standard library, Lift, and
> Scalaz. I think you'll find several fundamentally different approaches to
> writing Scala.
>

Then it's even more mysterious that anyone should worry about an Effective
C++ style gotcha list being used to preclude their coding style. Except for
people who were doing things that were just plain wrong - not writing copy
constructors when they were needed, writing trashy destructors, etc - I've
never heard of this happening.

> Collecting gotchas and general weird Scala behavior is another matter. I
> think someone is maintaining a list of Scala puzzlers somewhere, but I
> can't
> recall who or where.
>

This is a real issue that could cause a lot of genuine pain as well as FUD.
Take a look at

http://jeppenejsum.wordpress.com/2009/07/04/beware-of-scalas-lazy-range-...

http://www.eishay.com/2009/06/unexpected-repeated-execution-in-scala.html

"As Jorge’s explained it: the "gotcha" is that, because of the way Scala's
collections work, Range's laziness is "contagious" when you use functional
for-comprehensions (for ... yield ...) and a Range is the first thing in the
comprehension."

This sort of thing needs highlighting. It's not enough to say "It's in
Scaladoc" (although apparently in this case it's arguably obscured there).
Really surprising and somewhat dangerous behaviour should have attention
clearly drawn to it! List of hidden problems, explanation and cure for each.
I'm not asking for a massive effort - just suggesting something like a
sticky thread, so that as experienced Scaloids answer questions that are
important enough they can summarize them under a general title and link
them.

>>>>> "jonathan" == jonathan mawson writes:

jonathan> Take a look at
jonathan> http://jeppenejsum.wordpress.com/2009/07/04/beware-of-scalas-lazy-range-...
jonathan> http://www.eishay.com/2009/06/unexpected-repeated-execution-in-scala.html
jonathan> "As Jorge’s explained it: the "gotcha" is that, because of
jonathan> the way Scala's collections work, Range's laziness is
jonathan> "contagious" when you use functional for-comprehensions (for
jonathan> ... yield ...) and a Range is the first thing in the
jonathan> comprehension."

You may already be aware, but Range was redesigned for Scala 2.8 so this
is no longer an issue. (And yeah, I know you were just using this as an
example.)

On 1/30/2010 7:57 AM, Erik Engbrecht wrote:
> I agree with Tony and Paul. I think at this point there are several
> major styles for writing Scala, and I can't say that any of them are
> "wrong" or "preferable."
>

My thoughts exactly. In fact, I would rather see, in those cases where
a project is
multi-language, some consistency across languages than mere consistency
within
each one. People need freedom when being creative.

For example, guys who use GUI editors probably like to use a lot of
whitespace
to separate logical divisions in code. It makes it easier to read. But
people who
use emacs or vi scroll vertically through code, and some of them hate
whitespace.
They would rather see dense code. Telling either group "this is how it
should be done"
will likely be ignored.

Bob (ishmal)

Seth Tisue wrote:
>
>>>>>> "jonathan" == jonathan mawson writes:
>
> jonathan> Take a look at
> jonathan>
> http://jeppenejsum.wordpress.com/2009/07/04/beware-of-scalas-lazy-range-...
> jonathan>
> http://www.eishay.com/2009/06/unexpected-repeated-execution-in-scala.html
> jonathan> "As Jorge’s explained it: the "gotcha" is that, because of
> jonathan> the way Scala's collections work, Range's laziness is
> jonathan> "contagious" when you use functional for-comprehensions (for
> jonathan> ... yield ...) and a Range is the first thing in the
> jonathan> comprehension."
>
> You may already be aware, but Range was redesigned for Scala 2.8 so this
> is no longer an issue. (And yeah, I know you were just using this as an
> example.)
>

Bob Jamison-4 wrote:
>
> On 1/30/2010 7:57 AM, Erik Engbrecht wrote:
>> I agree with Tony and Paul. I think at this point there are several
>> major styles for writing Scala, and I can't say that any of them are
>> "wrong" or "preferable."
>>
>
> My thoughts exactly. In fact, I would rather see, in those cases where
> a project is
> multi-language, some consistency across languages than mere consistency
> within
> each one. People need freedom when being creative.
>
> For example, guys who use GUI editors probably like to use a lot of
> whitespace
> to separate logical divisions in code. It makes it easier to read. But
> people who
> use emacs or vi scroll vertically through code, and some of them hate
> whitespace.
> They would rather see dense code. Telling either group "this is how it
> should be done"
> will likely be ignored.
>

I can't say enough that this sort of trivial "Let's have a war about which
end to crack an egg at!" stuff isn't what I was talking about. Hence the
"NOT formatting style!" in the the thread title. My mistake was probably in
not using more exclamation marks...

If you go back to my original post, I was agreeing with Tony and Paul that there shouldn't be some sort of "official" style guide linked off of the main Scala website.  I would also expect a style guide to be more than a collection of "don't do that"'s, and even if it was just that, I think if it reached any depth there would be some strong differences of opinion.  That's why I don't think it should be official.
That doesn't mean one (or more than one) wouldn't be valuable.  They would be valuable.

On Sat, Jan 30, 2010 at 1:50 PM, jonathan mawson <umptious@gmail.com> wrote:

Erik Engbrecht wrote:
>
> I wasn't talking about talking about formatting, either.
>
> Look at the source for pieces of the Scala standard library, Lift, and
> Scalaz.  I think you'll find several fundamentally different approaches to
> writing Scala.
>

Then it's even more mysterious that anyone should worry about an Effective
C++ style gotcha list being used to preclude their coding style. Except for
people who were doing things that were just plain wrong - not writing copy
constructors when they were needed, writing trashy destructors, etc - I've
never heard of this happening.



> Collecting gotchas and general weird Scala behavior is another matter.  I
> think someone is maintaining a list of Scala puzzlers somewhere, but I
> can't
> recall who or where.
>

This is a real issue that could cause a lot of genuine pain as well as FUD.
Take a look at

http://jeppenejsum.wordpress.com/2009/07/04/beware-of-scalas-lazy-range-in-foryield/

http://www.eishay.com/2009/06/unexpected-repeated-execution-in-scala.html

"As Jorge’s explained it: the "gotcha" is that, because of the way Scala's
collections work, Range's laziness is "contagious" when you use functional
for-comprehensions (for ... yield ...) and a Range is the first thing in the
comprehension."

This sort of thing needs highlighting. It's not enough to say "It's in
Scaladoc" (although apparently in this case it's arguably obscured there).
Really surprising and somewhat dangerous behaviour should have attention
clearly drawn to it! List of hidden problems, explanation and cure for each.
I'm not asking for a massive effort - just suggesting something like a
sticky thread, so that as experienced Scaloids answer questions that are
important enough they can summarize them under a general title and link
them.
--
View this message in context: http://old.nabble.com/Scala-coding-guidelines-needed--NOT-formatting-style%21-tp27356975p27386334.html
Sent from the Scala mailing list archive at Nabble.com.

--
http://erikengbrecht.blogspot.com/

Erik Engbrecht wrote:
> If you go back to my original post, I was agreeing with Tony and Paul
> that there shouldn't be some sort of "official" style guide linked off
> of the main Scala website. I would also expect a style guide to be more
> than a collection of "don't do that"'s, and even if it was just that, I
> think if it reached any depth there would be some strong differences of
> opinion. That's why I don't think it should be official.

I think this issue could be solved by having two levels of coding
guidelines;

* Rules, which we could all agree with, and
* Recommendations, which are more a matter of style, or areas
where there isn't agreement within the community, or where there
are well known exceptions

IMNSHO, this is the only way to get an official, i.e. respected by
all, coding guideline.

If coding guidelines are codified in one (or two) statement each
(with accompanying examples and text), instead of vague but well
meaning texts, then it is also so much more simple to know what
exactly the guideline says, and whether people agree with it or
not.

Mats

Mats Henricson-2 wrote:
>
> Erik Engbrecht wrote:
>> If you go back to my original post, I was agreeing with Tony and Paul
>> that there shouldn't be some sort of "official" style guide linked off
>> of the main Scala website. I would also expect a style guide to be more
>> than a collection of "don't do that"'s, and even if it was just that, I
>> think if it reached any depth there would be some strong differences of
>> opinion. That's why I don't think it should be official.
>
> I think this issue could be solved by having two levels of coding
> guidelines;
>
> * Rules, which we could all agree with, and
> * Recommendations, which are more a matter of style, or areas
> where there isn't agreement within the community, or where there
> are well known exceptions
>
> IMNSHO, this is the only way to get an official, i.e. respected by
> all, coding guideline.
>
> If coding guidelines are codified in one (or two) statement each
> (with accompanying examples and text), instead of vague but well
> meaning texts, then it is also so much more simple to know what
> exactly the guideline says, and whether people agree with it or
> not.
>
> Mats
>
>

That sounds sane to me. Surely there are guidelines that everyone must agree
with? "Use val rather than var whenever possible." "Don't extend Application
when performance matters" "Understand that Range uses lazy evaluation - and
that it is contagious" (Although that one is about to be obsolete.)

It isn't a question of "rules" as much as the knowledge that gives you a
real feel for a language and how to use it safely and efficiently. It's a
list of Why's rather than of Do's and Don'ts that is needed.

jonathan mawson wrote:
> That sounds sane to me. Surely there are guidelines that everyone must agree
> with? "Use val rather than var whenever possible." "Don't extend Application
> when performance matters" "Understand that Range uses lazy evaluation - and
> that it is contagious" (Although that one is about to be obsolete.)
>
> It isn't a question of "rules" as much as the knowledge that gives you a
> real feel for a language and how to use it safely and efficiently. It's a
> list of Why's rather than of Do's and Don'ts that is needed.

I think "why's" are too vague. Simply because they can't be used
at code reviews. Also, they can't be used for automatic code
inspections, performed by computers. Example:

Understand that Range uses lazy evaluation - and that
it is contagious

What is a computer to do with such a rule or recommendation?
It can't possibly know if the author of the code understands
ranges or not. And arguing about this at a manual code review
is dangerous; "You simply don't understand ranges", "Yes I do,
but in this case the laziness don't apply".

Therefore I think do's and don'ts are better, and in this
particular case I would start with something like this:

Only use ranges when... "something"

If you can't replace "something" with well written text, then
this isn't well understood enough, or well agreed upon enough,
to become a rule or a rec.

My suggestion is to craft rules and recommendations only for
cases that

1. are important - it is better to have five recs too few than
one rec too many, since petty nitpicking undermines the
authority of a coding standard
2. are common - really weird corner cases will bite some people,
but only so rarely that it is not worth the time to bother
everyone with them
3. are specific - vague well meaning text makes noone happy

Mats

The length and popularity of this thread has been a testament to the time-saving nature of writing code in Scala - that so many people had so much time to spend discussing whether or not a link should appear on a web page is amazing.Sadly, I think we could probably have somehow used the time more fruitfully.By the way, what colour should we paint the bike shed?  ; )
--
Graham Lea
graham@grahamlea.com

On 29/01/2010, at 11:05 AM, Tony Morris wrote:

This is precisely the argument I wish to avoid having. I'd rather solve
problems.

Make it blue ++1

2010/2/1 Graham Lea <graham@grahamlea.com>

The length and popularity of this thread has been a testament to the time-saving nature of writing code in Scala - that so many people had so much time to spend discussing whether or not a link should appear on a web page is amazing. Sadly, I think we could probably have somehow used the time more fruitfully.By the way, what colour should we paint the bike shed?  ; )
--
Graham Lea
graham@grahamlea.com

On 29/01/2010, at 11:05 AM, Tony Morris wrote:

This is precisely the argument I wish to avoid having. I'd rather solve
problems.

Mats Henricson-2 wrote:
>
>
> I think "why's" are too vague. Simply because they can't be used
> at code reviews. Also, they can't be used for automatic code
> inspections, performed by computers. Example:
>
> Understand that Range uses lazy evaluation - and that
> it is contagious
>
> What is a computer to do with such a rule or recommendation?
> It can't possibly know if the author of the code understands
> ranges or not. And arguing about this at a manual code review
> is dangerous; "You simply don't understand ranges", "Yes I do,
> but in this case the laziness don't apply".
>
> Therefore I think do's and don'ts are better, and in this
> particular case I would start with something like this:
>
> Only use ranges when... "something"
>
> If you can't replace "something" with well written text, then
> this isn't well understood enough, or well agreed upon enough,
> to become a rule or a rec.
>

The rules you describe are better ones where they are possible. But are you
really saying that is better to have unexplained behavior in a program that
dramatically alters its performance and testability that a rule that can't
be automatically checked? Well, obviously you are. And obviously I don't
think it makes sense. Let's go back to your example:

"You simply don't understand ranges"

"Yes I do, but in this case the laziness don't apply".

"Ok. Why not?"

"Umm.."

"Look - this test shows that it is lazy. The database hasn't been updated!
And updating it was the point of the operation."

"Oh - so that's what you meant! That's crazy - I'd never have thought that
laziness means that. I'll take a look at those guidelines again. Without
them we might never have understood what was happening here."

jonathan mawson wrote:
>
>
> Mats Henricson-2 wrote:
>>
>> I think "why's" are too vague. Simply because they can't be used
>> at code reviews. Also, they can't be used for automatic code
>> inspections, performed by computers. Example:
>>
>> Understand that Range uses lazy evaluation - and that
>> it is contagious
>>
>> What is a computer to do with such a rule or recommendation?
>> It can't possibly know if the author of the code understands
>> ranges or not. And arguing about this at a manual code review
>> is dangerous; "You simply don't understand ranges", "Yes I do,
>> but in this case the laziness don't apply".
>>
>> Therefore I think do's and don'ts are better, and in this
>> particular case I would start with something like this:
>>
>> Only use ranges when... "something"
>>
>> If you can't replace "something" with well written text, then
>> this isn't well understood enough, or well agreed upon enough,
>> to become a rule or a rec.
>
> The rules you describe are better ones where they are possible. But are you
> really saying that is better to have unexplained behavior in a program that
> dramatically alters its performance and testability that a rule that can't
> be automatically checked? Well, obviously you are. And obviously I don't
> think it makes sense. Let's go back to your example:
>
> "You simply don't understand ranges"
>
> "Yes I do, but in this case the laziness don't apply".
>
> "Ok. Why not?"
>
> "Umm.."
>
> "Look - this test shows that it is lazy. The database hasn't been updated!
> And updating it was the point of the operation."
>
> "Oh - so that's what you meant! That's crazy - I'd never have thought that
> laziness means that. I'll take a look at those guidelines again. Without
> them we might never have understood what was happening here."

I see your point. But the problem with the initial coding
guideline was that it didn't talk about the code, it talked
about the programmer:

Understand that Range uses lazy evaluation - and that
it is contagious.

I'm not sure how to solve this problem. The only way to make
sure people don't make mistakes here is education, with good
examples, and competent programmers.

Mats

Mats Henricson-2 wrote:
>
>
> I see your point. But the problem with the initial coding
> guideline was that it didn't talk about the code, it talked
> about the programmer:
>
> Understand that Range uses lazy evaluation - and that
> it is contagious.
>

I was echoing Scott Meyer's style in Effective C++. In the C++ world
*everyone* has read these books, so it's natural to reference them when
calling for something similar. I expected at least moderate recognition of
the series here, but it seems not.

However, I like "Understand.." because it isn't overly prescriptive. Give
competent people knowledge and they'll be ok. The incompetent ones won't be
whatever you do.

> I'm not sure how to solve this problem. The only way to make
> sure people don't make mistakes here is education, with good
> examples, and competent programmers.
>

That's the purpose of what I'm proposing. Meyer's books made a huge
difference in C++. Obviously Scala isn't as dangerous as C++, but I've seen
several odd points that need attention drawing to them. And people are going
to be confused enough by the double paradigm shift to functional programming
and threading.