Corporate scala levels

[bjohanns]

Hello scala fans,

as I am new to scala and this list - please excuse if I'm not in the right place for my question... and the lenght of my post - please skip if you are in a hurry.

Scala is fairly new and gets more and more attention these days. This was the reason for me [as QA/Test fellow and informatics-analphabet] to look a little more into "the scala side" of life as there are some myths flowing around going from

- strongly-typed-statically-checked-concurrency-ready-catch-all miracle

to

- undecipherable-unpredictable-incomprehensive-ambiguityStrikesYouAnywhere-slow.


What I got from the documentation and some other sources most of the good points seem to be true.

However I have still some concerns about scala and the topic:
  code-quality/code-maintenance and coding-policies:

At the moment there are no supporting tools (as far as I know) which would enable automatic code policy / code style review. This is not surprising as scala is still emerging and not mature yet.

However I think that this is the right time to ask some questions and argue about it:


[1] * Scala knowledge levels

- are there language constructs which are more likely to be misused/misunderstood by an "average" corporate programmer (Java/VB background)
- can these constructs be constrainted by "compiler-policies" so that they are not available or emit at least warnings during compile so that the programmer must be aware of these non-compliances
- can it be done by the IDE or is the compiler the more natural choice (perhaps per compiler plugin?)

=> so the "vision" is that someone responsible for code policies can layout do-and-don'ts (according to the requirements of the component and the knowledge level of the available staff) for those team and have them enforced in different environments [that's why I am aiming at the compiler and not at the IDE firstplace].


[2] * code ambiguities caused by whitespaces

- is there a possibility to alter (e.g. per configuration choice/policy) the syntactic rules in any places where whitespace alterations especially CR/LF could alter the meaning of the code, to rule out those ambiguities?
-> yes - this would mean we have two different styles of scala syntax - one more concise but somewhat ambiguous for the more scientific environments and one which does simply not allow ambiguities of this whitespace-type for the... well... more corporate environments.

reason: while I am quite happy with most of the syntactic constructs of scala (even if they seem a little odd at first glance when used to java and pl/sql) I strongly disagree with ambiguities caused by inserted or removed whitespace class characters.

In my experience corporate source code (I do not strictly refer to "software product code" but also and especially to those thousand of lines of "glue-code" which one can find in almost any corporate infrastructure to keep things working) is transfered and transformed many times during development and maintenance (through tools and by hand). And I see the risk of unintended changes which can alter the meaning of the code while still being syntactically correct.
To make things even worse: most of the diff-tools I've seen in use are configured the way that they ignore whitespace-sortof changes as they are encountered all the time (space-tab-space transformations in between editors and the like).

resume:
While scala compiler policies (or comparable things like style preprocessors or something like that) could help to make the transition smoother and to instrument the possibilities according to the skills of the staff involved, I strongly recommend to remove or provide at least the option to remove the whitespace-induced ambiguities as I am sure that these things will bite back in production environments.
 
Greetings - and keep up the good work!
Bernd

[Daniel Sobral]

Bernd, there's really few instances where a whitespace change can alter meaning without causing outright errors. All I can think of relate to blocks. For example:

 

class A

{

  class B

 

  {

  // stuff

  }

}

 

is different than

 

class A

{

  class B

  {

  // stuff

  }

}

In all cases involving blocks, however, this can be solved by mandating { on the end of the previous line instead of by itself, which can be checked by code style tools. Are you thinking of any other instance of whitespace-caused problems?

The most problematic Scala feature is the implicit conversion. You can disable their usage, but, unfortunately, they are an essential feature of the language. My suggestion, in this case, is the following:

 

1. Review all implicit definitions (a simple "grep" can find them)

 

2. Do not allow implicit conversions between two non-local types. In other words, in an implicit conversion from A to B, require for either A or B (or both) to be a class from your own packages.

 

3. Define guidelines for implicit definitions -- for example, require that they always be put on an object called Implicits, so you can easily find where they are being imported to.

 

4. Restrict definition (not use) of implicit conversions according to programmer level. Can be checked with grep and judicious use of validation scripts.

 

On Fri, Oct 23, 2009 at 1:58 PM, bjohanns <bjohanns@...> wrote:

Hello scala fans,

as I am new to scala and this list - please excuse if I'm not in the right
place for my question... and the lenght of my post - please skip if you are
in a hurry.

Scala is fairly new and gets more and more attention these days. This was
the reason for me [as QA/Test fellow and informatics-analphabet] to look a
little more into "the scala side" of life as there are some myths flowing
around going from

- strongly-typed-statically-checked-concurrency-ready-catch-all miracle

to

-
undecipherable-unpredictable-incomprehensive-ambiguityStrikesYouAnywhere-slow.


What I got from the documentation and some other sources most of the good
points seem to be true.

However I have still some concerns about scala and the topic:
 code-quality/code-maintenance and coding-policies:

At the moment there are no supporting tools (as far as I know) which would
enable automatic code policy / code style review. This is not surprising as
scala is still emerging and not mature yet.

However I think that this is the right time to ask some questions and argue
about it:


[1] * Scala knowledge levels

- are there language constructs which are more likely to be
misused/misunderstood by an "average" corporate programmer (Java/VB
background)
- can these constructs be constrainted by "compiler-policies" so that they
are not available or emit at least warnings during compile so that the
programmer must be aware of these non-compliances
- can it be done by the IDE or is the compiler the more natural choice
(perhaps per compiler plugin?)

=> so the "vision" is that someone responsible for code policies can layout
do-and-don'ts (according to the requirements of the component and the
knowledge level of the available staff) for those team and have them
enforced in different environments [that's why I am aiming at the compiler
and not at the IDE firstplace].


[2] * code ambiguities caused by whitespaces

- is there a possibility to alter (e.g. per configuration choice/policy) the
syntactic rules in any places where whitespace alterations especially CR/LF
could alter the meaning of the code, to rule out those ambiguities?
-> yes - this would mean we have two different styles of scala syntax - one
more concise but somewhat ambiguous for the more scientific environments and
one which does simply not allow ambiguities of this whitespace-type for
the... well... more corporate environments.

reason: while I am quite happy with most of the syntactic constructs of
scala (even if they seem a little odd at first glance when used to java and
pl/sql) I strongly disagree with ambiguities caused by inserted or removed
whitespace class characters.

In my experience corporate source code (I do not strictly refer to "software
product code" but also and especially to those thousand of lines of
"glue-code" which one can find in almost any corporate infrastructure to
keep things working) is transfered and transformed many times during
development and maintenance (through tools and by hand). And I see the risk
of unintended changes which can alter the meaning of the code while still
being syntactically correct.
To make things even worse: most of the diff-tools I've seen in use are
configured the way that they ignore whitespace-sortof changes as they are
encountered all the time (space-tab-space transformations in between editors
and the like).

resume:
While scala compiler policies (or comparable things like style preprocessors
or something like that) could help to make the transition smoother and to
instrument the possibilities according to the skills of the staff involved,
I strongly recommend to remove or provide at least the option to remove the
whitespace-induced ambiguities as I am sure that these things will bite back
in production environments.

Greetings - and keep up the good work!
Bernd
--
View this message in context: http://www.nabble.com/Corporate-scala-levels-tp26028979p26028979.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[bjohanns]

Am Freitag, 23. Oktober 2009 18:45:26 schrieb Daniel Sobral:
> Bernd, there's really few instances where a whitespace change can alter
> meaning without causing outright errors. All I can think of relate to
> blocks. For example:
[...]
>. Are you thinking of any other instance of
> whitespace-caused problems?

Perhaps my use-case is not so common, but I often receive parts of source-code
per email (cut & paste - it's the easiest way for a busy programmer to answer
pesky questions about what his code is doing or why his code is doing or not
doing something).
While java, perl, pl/sql, C, C++, C# code can easily be restored from
reformating issues caused by text processors of all kind (email client, word
documents, blogs and the like) scala code cannot (at least if you cannot
enforce ";" usage by some tool or rule).
Maybe I didn't get things right, but from my perception it is rather difficult
and ambiguous to get back the semantic of a piece of code if it has been
flattened to a "oneliner" (i.e. all CR/LF removed).

The most consistent way of achieving enforced ";" usage (in my opinion) would
be to have a switch / plugin whatsoever for the compiler to require it. This
could either be some kind of source file preamble like "// #parse-option:
require_semicolon"  or a configurable "style"-plugin. The source file level
preamble - while being ugly - would have the benefit to be minimal invasive
(you can use any 3rd party source level library without modification while
constraining your own productions to some sort of compliance).
 
>  The most problematic Scala feature is the implicit conversion. You can
> disable their usage, but, unfortunately, they are an essential feature of
> the language. My suggestion, in this case, is the following:

This will surely cause some surprises - but I am with you that the language
should not be crippled in its functionality. My initial concern with scala is
form not function (as with the ";" above). In its effort to remove as much
"boiler plate" as possible (which is good for the programmer) it removes
redundancy which is not always good for the reader.

What I am missing currently is an "expanded view" - something like:

* take the code I am giving you

* expand anything that is expanded automatically up to a certain level (e.g.
add the ";", add the infered types, perhaps add or comment on  the implicit
conversions and overloaded "+-..." operators)

* maybe beautify a little

* show it to me

I think this could help newbies to understand what is going on and would
provide additional context and robustness if code has to be exchanged for
inspection/discussion. I could look at the compact/original version to get the
"overall" picture and have typing and some other details in the expanded view.

But I am not sure if this can be achieved at all. But it would help a lot to
have such an expanded view in an IDE (where the programmer can easily cut and
paste it away into an email :-).

Greetings
Bernd

[_retronym]

Scala X-Ray does a lot of this today:

http://www.nabble.com/-scala--ANN:-Scala-X-Ray-%28sxr%29-td23077962.html

On Wed, Oct 28, 2009 at 9:04 AM, Bernd Johannes <bjohanns@...> wrote:

What I am missing currently is an "expanded view" - something like:

* take the code I am giving you

* expand anything that is expanded automatically up to a certain level (e.g.
add the ";", add the infered types, perhaps add or comment on  the implicit
conversions and overloaded "+-..." operators)

* maybe beautify a little

* show it to me

[Colin Bullock]

* take the code I am giving you

* expand anything that is expanded automatically up to a certain level (e.g.
add the ";", add the infered types, perhaps add or comment on  the implicit
conversions and overloaded "+-..." operators)

I find scalac -Xprint:typer to be invaluable (and generally sufficient) for this.

Having just said that, it occurs to me that it would be pretty neat to have some "phases view" of a given source file in the eclipse plugin.

- Colin