Re: Scala Joe - a profile for regular Joe

I have a variation on these rules that I've found to be very effective:
- Write whatever you want, however you want- Do pair programming and perform code reviews- If your code is unacceptable to the remainder of the team, even after explaining how it works - then rewrite it in a different style.
The real beauty of this approach is that it scales up as your team comes to better understand the language  with repeated exposure.


On 24 September 2010 18:12, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

Hello everyone,

I see that some discussions recently on scala-user are about aspects that are the subject of debate and personal preference.

I should remind you that the proper list for that is scala-debate; please avoid polluting scala-user with this kind of discussions.

Thank you all!
Toni

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

+BigInteger.MAX_VALUE

Viktor KlangCode Connoisseurwww.akkasource.com
On Sep 24, 2010, at 19:22, Kevin Wright <kev.lee.wright@gmail.com> wrote:

I have a variation on these rules that I've found to be very effective:
- Write whatever you want, however you want- Do pair programming and perform code reviews- If your code is unacceptable to the remainder of the team, even after explaining how it works - then rewrite it in a different style.
The real beauty of this approach is that it scales up as your team comes to better understand the language  with repeated exposure.


On 24 September 2010 18:12, Antonio Cunei < (antonio [dot] cunei [at] epfl [dot] ch> wrote:

Hello everyone,

I see that some discussions recently on scala-user are about aspects that are the subject of debate and personal preference.

I should remind you that the proper list for that is scala-debate; please avoid polluting scala-user with this kind of discussions.

Thank you all!
Toni

--
Kevin Wright

mail / gtalk / msn : (kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda

Yes, I know... As it hapens though, many teams here are poor at doing
their reviews and others are left to pickup the pieces at 1 am in a
production environment...

How do you deal with temps? Mandate reviews before they leave, and
leave it to that?

On 9/24/10, Kevin Wright wrote:
> I have a variation on these rules that I've found to be very effective:
>
> - Write whatever you want, however you want
> - Do pair programming and perform code reviews
> - If your code is unacceptable to the remainder of the team, even after
> explaining how it works - then rewrite it in a different style.
>
> The real beauty of this approach is that it scales up as your team comes to
> better understand the language with repeated exposure.
>
>
>
> On 24 September 2010 18:12, Antonio Cunei wrote:
>
>> Hello everyone,
>>
>> I see that some discussions recently on scala-user are about aspects that
>> are the subject of debate and personal preference.
>>
>> I should remind you that the proper list for that is scala-debate; please
>> avoid polluting scala-user with this kind of discussions.
>>
>> Thank you all!
>> Toni
>>
>>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>

I have to admit, using temps at all sounds like a bit of a process smell here.
But that aside... If your frequency of reviews isn't much higher than your churn rate in developers, then you have problems far deeper than can be helped with a simple style guide.


On 24 September 2010 18:34, Razvan (Pub) Cojocaru <pub@razie.com> wrote:

Yes, I know... As it hapens though, many teams here are poor at doing
their reviews and others are left to pickup the pieces at 1 am in a
production environment...

How do you deal with temps? Mandate reviews before they leave, and
leave it to that?



On 9/24/10, Kevin Wright <kev.lee.wright@gmail.com> wrote:
> I have a variation on these rules that I've found to be very effective:
>
> - Write whatever you want, however you want
> - Do pair programming and perform code reviews
> - If your code is unacceptable to the remainder of the team, even after
> explaining how it works - then rewrite it in a different style.
>
> The real beauty of this approach is that it scales up as your team comes to
> better understand the language  with repeated exposure.
>
>
>
> On 24 September 2010 18:12, Antonio Cunei <antonio.cunei@epfl.ch> wrote:
>
>> Hello everyone,
>>
>> I see that some discussions recently on scala-user are about aspects that
>> are the subject of debate and personal preference.
>>
>> I should remind you that the proper list for that is scala-debate; please
>> avoid polluting scala-user with this kind of discussions.
>>
>> Thank you all!
>> Toni
>>
>>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>

--
Sent from my mobile device

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

What problems are best solved by temps?

Viktor Klang
Code Connoisseur
www.akkasource.com

On Sep 24, 2010, at 19:34, "Razvan (Pub) Cojocaru" wrote:

> Yes, I know... As it hapens though, many teams here are poor at doing
> their reviews and others are left to pickup the pieces at 1 am in a
> production environment...
>
> How do you deal with temps? Mandate reviews before they leave, and
> leave it to that?
>
>
>
> On 9/24/10, Kevin Wright wrote:
>> I have a variation on these rules that I've found to be very effective:
>>
>> - Write whatever you want, however you want
>> - Do pair programming and perform code reviews
>> - If your code is unacceptable to the remainder of the team, even after
>> explaining how it works - then rewrite it in a different style.
>>
>> The real beauty of this approach is that it scales up as your team comes to
>> better understand the language with repeated exposure.
>>
>>
>>
>> On 24 September 2010 18:12, Antonio Cunei wrote:
>>
>>> Hello everyone,
>>>
>>> I see that some discussions recently on scala-user are about aspects that
>>> are the subject of debate and personal preference.
>>>
>>> I should remind you that the proper list for that is scala-debate; please
>>> avoid polluting scala-user with this kind of discussions.
>>>
>>> Thank you all!
>>> Toni
>>>
>>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail / gtalk / msn : kev.lee.wright@gmail.com
>> pulse / skype: kev.lee.wright
>> twitter: @thecoda
>>
>

On Friday September 24 2010, Razvan (Pub) Cojocaru wrote:
> Yes, I know... As it hapens though, many teams here are poor at doing
> their reviews and others are left to pickup the pieces at 1 am in a
> production environment...
>
> How do you deal with temps? Mandate reviews before they leave, and
> leave it to that?

You're addressing the real problem (developers who don't do their job
well) with a bunch of rules that will in no way make them better
developers.

Who on Earth uses temporary people as software developers? It sounds
like your organization has problems that cannot possibly be solved by
circumscribing parts of the Scala language as off-limits.

Randall Schulz

How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".

Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.

I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

I just left a place where I'd been for 7 years...

Viktor Klang
Code Connoisseur
www.akkasource.com

On Sep 24, 2010, at 20:03, Razvan Cojocaru-2 wrote:

>
> How many of you guys are full-time employees with more than 5 years at the
> same company? Most of the great developers I know are contractors, i.e.
> "temps".
>
> Temporary contractors are great for developing components, as self-contained
> as possible...but even those need maintaining at some point.
>
> I toned down the thing and now, reading it again, it's more of a style
> guide...the degree of adherence should obviously vary from dev shop to dev
> shop...
>
>
>
> -----
> Razvan Cojocaru,
> Work: http://www.sigma-systems.com
> Playground: http://wiki.homecloud.ca
> Latest cool toys: http://scripster.razie.com Scripster and
> http://github.com/razie/gremlins Gremlins
> Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
> http://twitter.com/razie Twitter , http://github.com/razie GitHub .
>

Hi,

I work professionally as a Java Software developer and I'm lurking the Scala lists for a couple of years. I own the Programing in Scala book and I've made some personal pet projects to get a grasp on this language.

I am a Java/Scala regular Joe.

I think that lots of features of the language are wonderful and I truly believe that when used correctly, it can give amazing results. But I agree with the OP mindset. IMHO some feature are best not to be used/abused, at least outside the EPFL.

Someone smarter that me said the code is written once but read many times. In that sense some advanced Scala features are very intimidating to read (in the perlish sense) unless you have very advanced FP/Scala skills. It was mentioned in that list earlier that some kind of developer profile could be introduced to ease the transition from Javaland to the reams od FP/Scala, It would be help me personally, and it would give me a tool to try to introduce Scala where I work.

I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.

Reading the response, I feel that the more senior Scalaist on this list are having a hard time accepting/understanding this fact. It is very understandable. It happen to me when I try to teach something I master perfectly (I cannot understand they do not get it).

My 2 cents,

-Martin

PS. Here is an example of intimidating code (IMHO), taken in one of today's posts in the scala list:

    // Generic join -- no way around cartersian product
    def on[Z](f: (X, Y) => Z) = new JoinedOnExpr(first, second, f)
    class JoinedOnExpr[X, Y, Z](first: CC[X], second: Traversable[Y], f: (X, Y) => Z) {
      def equalTo(g: (X, Y) => Z)(implicit cbf: CanBuildFrom[CC[X], (X, Y), CC[(X, Y)]]): CC[(X, Y)] = for {
        x <- first
        y <- second
        if f(x, y) == g(x, y)
      } yield x -> y
    }

From: Razvan Cojocaru-2 <pub@razie.com>
To: scala-debate@listes.epfl.ch
Sent: Fri, September 24, 2010 2:03:21 PM
Subject: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe


How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".

Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.

I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2562410.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

Hah! :-)

That code _is_ for library makers, because it is written to preserve the type of the input collection in the output.

"Normal" code does not need to be that generic. Hell, Java cannot do this at all, and no one seems to mind it (not before they spend some time with Scala :).

That said, once you get how the collections work, it isn't that hard to understand it.


On Fri, Sep 24, 2010 at 15:46, Martin Renaud <mr_martin_renaud@yahoo.ca> wrote:

Hi,

I work professionally as a Java Software developer and I'm lurking the Scala lists for a couple of years. I own the Programing in Scala book and I've made some personal pet projects to get a grasp on this language.

I am a Java/Scala regular Joe.

I think that lots of features of the language are wonderful and I truly believe that when used correctly, it can give amazing results. But I agree with the OP mindset. IMHO some feature are best not to be used/abused, at least outside the EPFL.

Someone smarter that me said the code is written once but read many times. In that sense some advanced Scala features are very intimidating to read (in the perlish sense) unless you have very advanced FP/Scala skills. It was mentioned in that list earlier that some kind of developer profile could be introduced to ease the transition from Javaland to the reams od FP/Scala, It would be help me personally, and it would give me a tool to try to introduce Scala where I work.

I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.

Reading the response, I feel that the more senior Scalaist on this list are having a hard time accepting/understanding this fact. It is very understandable. It happen to me when I try to teach something I master perfectly (I cannot understand they do not get it).

My 2 cents,

-Martin

PS. Here is an example of intimidating code (IMHO), taken in one of today's posts in the scala list:

    // Generic join -- no way around cartersian product
    def on[Z](f: (X, Y) => Z) = new JoinedOnExpr(first, second, f)
    class JoinedOnExpr[X, Y, Z](first: CC[X], second: Traversable[Y], f: (X, Y) => Z) {
      def equalTo(g: (X, Y) => Z)(implicit cbf: CanBuildFrom[CC[X], (X, Y), CC[(X, Y)]]): CC[(X, Y)] = for {
        x <- first
        y <- second
        if f(x, y) == g(x, y)
      } yield x -> y
    }

From: Razvan Cojocaru-2 <pub@razie.com>
To: scala-debate@listes.epfl.ch
Sent: Fri, September 24, 2010 2:03:21 PM
Subject: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe


How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".

Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.

I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2562410.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Daniel C. Sobral

I travel to the future all the time.

Absolutely 100% valid!
The problem here is that each and every team will have a different idea of code that they find too difficult to understand.  If we've learned anything from agile, it's that you need an iterative approach to find where the boundaries are for each particular team, and to allow those boundaries to be flexible over time.
This kind of stuff just can't be prescribed.


On 24 September 2010 19:46, Martin Renaud <mr_martin_renaud@yahoo.ca> wrote:

Hi,

I work professionally as a Java Software developer and I'm lurking the Scala lists for a couple of years. I own the Programing in Scala book and I've made some personal pet projects to get a grasp on this language.

I am a Java/Scala regular Joe.

I think that lots of features of the language are wonderful and I truly believe that when used correctly, it can give amazing results. But I agree with the OP mindset. IMHO some feature are best not to be used/abused, at least outside the EPFL.

Someone smarter that me said the code is written once but read many times. In that sense some advanced Scala features are very intimidating to read (in the perlish sense) unless you have very advanced FP/Scala skills. It was mentioned in that list earlier that some kind of developer profile could be introduced to ease the transition from Javaland to the reams od FP/Scala, It would be help me personally, and it would give me a tool to try to introduce Scala where I work.

I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.

Reading the response, I feel that the more senior Scalaist on this list are having a hard time accepting/understanding this fact. It is very understandable. It happen to me when I try to teach something I master perfectly (I cannot understand they do not get it).

My 2 cents,

-Martin

PS. Here is an example of intimidating code (IMHO), taken in one of today's posts in the scala list:

    // Generic join -- no way around cartersian product
    def on[Z](f: (X, Y) => Z) = new JoinedOnExpr(first, second, f)
    class JoinedOnExpr[X, Y, Z](first: CC[X], second: Traversable[Y], f: (X, Y) => Z) {
      def equalTo(g: (X, Y) => Z)(implicit cbf: CanBuildFrom[CC[X], (X, Y), CC[(X, Y)]]): CC[(X, Y)] = for {
        x <- first
        y <- second
        if f(x, y) == g(x, y)
      } yield x -> y
    }

From: Razvan Cojocaru-2 <pub@razie.com>
To: scala-debate@listes.epfl.ch
Sent: Fri, September 24, 2010 2:03:21 PM
Subject: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe


How many of you guys are full-time employees with more than 5 years at the
same company? Most of the great developers I know are contractors, i.e.
"temps".

Temporary contractors are great for developing components, as self-contained
as possible...but even those need maintaining at some point.

I toned down the thing and now, reading it again, it's more of a style
guide...the degree of adherence should obviously vary from dev shop to dev
shop...



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2562410.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Fri, Sep 24, 2010 at 11:46 AM, Martin Renaud <mr_martin_renaud@yahoo.ca> wrote:

Hi,

I work professionally as a Java Software developer and I'm lurking the Scala lists for a couple of years. I own the Programing in Scala book and I've made some personal pet projects to get a grasp on this language.

I am a Java/Scala regular Joe.

I think that lots of features of the language are wonderful and I truly believe that when used correctly, it can give amazing results. But I agree with the OP mindset. IMHO some feature are best not to be used/abused, at least outside the EPFL.

Someone smarter that me said the code is written once but read many times. In that sense some advanced Scala features are very intimidating to read (in the perlish sense) unless you have very advanced FP/Scala skills. It was mentioned in that list earlier that some kind of developer profile could be introduced to ease the transition from Javaland to the reams od FP/Scala, It would be help me personally, and it would give me a tool to try to introduce Scala where I work.

I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.

Reading the response, I feel that the more senior Scalaist on this list are having a hard time accepting/understanding this fact. It is very understandable. It happen to me when I try to teach something I master perfectly (I cannot understand they do not get it).

My 2 cents,

-Martin

PS. Here is an example of intimidating code (IMHO), taken in one of today's posts in the scala list:

    // Generic join -- no way around cartersian product
    def on[Z](f: (X, Y) => Z) = new JoinedOnExpr(first, second, f)
    class JoinedOnExpr[X, Y, Z](first: CC[X], second: Traversable[Y], f: (X, Y) => Z) {
      def equalTo(g: (X, Y) => Z)(implicit cbf: CanBuildFrom[CC[X], (X, Y), CC[(X, Y)]]): CC[(X, Y)] = for {
        x <- first
        y <- second
        if f(x, y) == g(x, y)
      } yield x -> y
    }

I agree. I would like to see Scala eventually get accepted as a suitable language for safety-critical systems. I mean systems where a bug can cause someone to die -- or a few hundred people to die instantly. The safety requirements for those kinds of systems are obviously more stringent than for, say, a video game. (That's not to disparage video games, which have their own stringent performance requirements.)

Obviously, good coding standards are needed for safety-critical systems, but maybe more is needed than that. A while back, I suggested that perhaps a safety-critical subset of Scala could be developed, similar to the Ravanscar profile for Ada, or even Spark Ada. Ideally, that subset would substantially reduce the potential for errors without substantially reducing the expressivity of Scala.

Think about flying in an airspace with automation developed by fallible human programmers. Are there some features of Scala that you would rather not see used in the automation? I'd be interested in what Scala experts have to say about it, if anything.

Russ P.

--
http://RussP.us

YEAH - I scanned that code twice and have a vague feeling as to what it
does...and this is precisely the point: that is library code. I don't have
the time or the inclination to review tens of those every day and understand
what they do...

The discussion can go many ways from here. Basic point is this: if you're a
superstar, did haskell for a decade or have an IQ > 160, yeah, you can
review these pieces of code with ease.

If you're like me, i.e. none of the above, all they do for me is distract me
from my own tasks: it grabs a part of my IQ (or attention span) to just
parse the freaking thing before I understand what it does and only then can
I say if it's all ok or the third _ is offset... and it will screw up on a
corner case :) YEAH, when I review code that's why I review it...to think
through possible permutations of inputs that can cause it to fail at the
same time...

The pattern recognition part of my brain can't function with new constructs
every freaking time and that decreases overall efficiency and happiness.
Anyways, there's a range of books you guys can read to understand that
stuff, from Cialdini's Influences to Gladwell's Blink.

Unfortunately, superstars with an IQ > 160 that did haskell for a decade are
not that easy nor cheap to find (except maybe when they do monadic workshops
:)

Darn, I wish they were! Do I?

Bottom line, for those that think that a "thou shalt not abuse..." list is
welcome - what should be on it? More... or less than what I have at
http://gist.github.com/595556 ?

Fork it man, fork it!

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

...Viktor, you'd be exempt from any such rules - not a lot of people can
usefully review concurrent distributed actor _implementations_ anyways :))

But then... that's why you wrote this stuff, right?

...which reminds me: if have a reference to an actor that's going berserk -
how can I kill the sucker and replace the respective thread in the
underlying pool ?

thanks,
Razie

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

On Fri, Sep 24, 2010 at 3:25 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Fri, Sep 24, 2010 at 11:46 AM, Martin Renaud <mr_martin_renaud@yahoo.ca> wrote:

I think the biggest challenge Scala faces preventing it can go mainstream is not the performance of the language features but this syntax that make it look more complicated that it really is and the learning curve it implies. The suggestion of the OP with "do not abuse" list or the developer profiles mention earlier are attempt to deal with this challenge.

The problem is that Scala has extremely few gratuitous language features.  The features are there to make Scala work better, or to make using it easier and more productive.

For example, which is easier to understand?:

  val a = b + c*d
  val a = b.complexAdd(c.complexMultiply(d))

Now, do you _really_ want to say "no operator overloading"?  Maybe you want to say, "Don't write confusing names, and yes, operators are names."

Likewise, if I'm reviewing code, then

val customerEntries = db.values
val customerNames = customerEntries.map( customer => { customer.name } )
val namesWithA = customerNames.filter( name => { name.startsWith("A") } )
val aNameLengths = namesWithA.map( name => { name.length } )
val characterCount = aNameLengths.sum

is not necessarily easier to understand than

val characterCount = db.values.
  map(_.name).
  filter(_.startsWith("A")).
  map(_.length).
  sum

or the all-on-one-line equivalent

val characterCount = db.values.map(_.name).filter(_.startsWith("A")).map(_.length).sum

The point is that this code is doing some surprisingly heavy lifting.  Understanding heavy lifting is not necessarily going to be that easy without spending some time.  Java does help you feel productive because  least that lifting gets spread out over several lines, so you get a sense that you're moving forward through the code.  But I think it's largely an illusion.  The metric should be _effort per capability of the code_ not _effort per line of code_ to understand.

The reason why I find second way easier to understand is precisely _because_ of the use of the underscore.  I don't get distracted by long variables names that are longer than the actual operation that is being performed and which may or may not be chosen wisely.  I just read the operations off: name, startsWith("A"), length, sum.  Anything more than an underscore is syntactic cruft.

Think about flying in an airspace with automation developed by fallible human programmers. Are there some features of Scala that you would rather not see used in the automation?

Russ P.

For mission-critical code, I would like programmers to use whatever tools are easiest for them to understand and demonstrate the correctness of, and I would determine the correctness based on a mixture of coding process (e.g. code in pairs, with a separate pair reviewing for validity, describing why the code works to yet another person) in addition to rigorous unit testing.  I would let the coding/testing pair define themselves what works and what does not work when it comes to verifiable code.  I'd also collect statistics on things that passed the human review and yet failed a unit test, and if there was some construct that consistently caused problems, then I'd say _don't do exactly that_, because you have demonstrated an inability to do it correctly.

And, if any one failure would cause deaths, build in some redundancy!  Bridges that fail when one bolt rusts through are a bad design; likewise, so are aircraft that crash when one software package fails due to a corner case that nobody thought of or tested for.

  --Rex

Great examples!

Rex Kerr-2 wrote:
>
> Now, do you _really_ want to say "no operator overloading"? Maybe you
> want
> to say, "Don't write confusing names, and yes, operators are names."
>

Yeah...not crystal clear about what I want here. What you have above is a
style guideline and belongs there. What I mean is don't define operators
unless they make a lot of sense as applied on that data type and don't come
up with new ones, especially if you're not a DSL designer...

How would you re-phrase that "rule" ?

Rex Kerr-2 wrote:
>
> val characterCount = db.values.
> map(_.name).
> filter(_.startsWith("A")).
> map(_.length).
> sum
>
> or the all-on-one-line equivalent
>
> val characterCount =
> db.values.map(_.name).filter(_.startsWith("A")).map(_.length).sum
>
>

Well, this would pass - I have "no more than 2 map()/flatMap()s per line"
and looking at this, I'd say that's a good limit...

I prefer the multi-line version, if I wasn't afraid of multi-lines (the
operator thing at the end still bugs me, not knowing how the code formatter
will work).

Razie

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

Dear All,
So, on the last three projects i worked on i encountered no less that 15 technologies that involved different computational models. Two out of three involved 25 different technologies. To list just some of them

• storage technology
• relational db + SQL
• XML - XSD, DTD, a little relaxNG
• middle tier technology
• mixture of 3rd party libs in Java + C/C++
• primary development language (Scala, Java, and some JRuby)
• messaging technology (mostly RabbitMQ, these days)
• frontend technology
• HTML
• AJAX
• Javascript
• build technology
• Ant
• Maven
• a little SBT
• shells + scripting
• version management technology
• svn
• git
• editors + ide technology
• emacs (with a little elisp and a lot of modes)
• IntelliJ

This is pretty much par for the course for most modern developers. This is what people are dealing with on a project-by-project basis. This is relevant because looking over this list i think the primary selection criterion for a good developer is that they can eat a language/technology for breakfast and not have indigestion at lunch.
So, restricting access to language features seems like it catering to a dev who is not long for production coding -- or is in a very niche market. A good dev will shy away from really iffy language features -- or they will if they keep programming long enough.
Rather, i really like the iterative pair programming approach. It even works with contractors. It's especially important to do it with contractors who might not be around to maintain their code. Tech transfer is greatly supported by more agile techniques.
Best wishes,
--greg

On Fri, Sep 24, 2010 at 1:47 PM, Razvan Cojocaru-2 <pub@razie.com> wrote:

Great examples!


Rex Kerr-2 wrote:
>
> Now, do you _really_ want to say "no operator overloading"?  Maybe you
> want
> to say, "Don't write confusing names, and yes, operators are names."
>

Yeah...not crystal clear about what I want here. What you have above is a
style guideline and belongs there. What I mean is don't define operators
unless they make a lot of sense as applied on that data type and don't come
up with new ones, especially if you're not a DSL designer...

How would you re-phrase that "rule" ?


Rex Kerr-2 wrote:
>
> val characterCount = db.values.
>   map(_.name).
>   filter(_.startsWith("A")).
>   map(_.length).
>   sum
>
> or the all-on-one-line equivalent
>
> val characterCount =
> db.values.map(_.name).filter(_.startsWith("A")).map(_.length).sum
>
>

Well, this would pass - I have "no more than 2 map()/flatMap()s per line"
and looking at this, I'd say that's a good limit...

I prefer the multi-line version, if I wasn't afraid of multi-lines (the
operator thing at the end still bugs me, not knowing how the code formatter
will work).

Razie


-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2592103.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

On Fri, Sep 24, 2010 at 10:18 PM, Razvan Cojocaru-2 <pub@razie.com> wrote:

...Viktor, you'd be exempt from any such rules - not a lot of people can
usefully review concurrent distributed actor _implementations_ anyways :))

But then... that's why you wrote this stuff, right?

The goal with frameworks should be to make certain tasks that were previously complicated less so.
Basically I write lock&thread based code so other people won't have to.
 

...which reminds me: if have a reference to an actor that's going berserk -
how can I kill the sucker and replace the respective thread in the
underlying pool ?

Depending on what's wrong with it - you don't, since it's the JVM and Thread lifecycle management isn't exactly stellar,
We _could_ expose a possibility to interrupt the currently executing thread for a single ActorRef, but that would possibly only work for some dispatchers.

A good news is that ThreadBasedDispatcher now is just a specialized form of ExecutorBasedDispatcher, this means that the thread associated with the dispatcher can be reclaimed if not used, which is the inverted situation of what you described.

thanks,
Razie



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2587334.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Viktor Klang,
Code Connoisseur
Work:   www.akkasource.com
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

Greg - appreciated! Two comments and two questions.

Out of all the things you listed, you can only really shoot yourself in the
foot with scala...well, JavaScript is a different story altogether, the
others are fairly simple, two a day kind of things, indeed.

About the iterative pair programming - agree. At least the pair review part
of it. But what about across teams? Teams tend to be formed on friendships,
between developers of the same level...

About these projects, who maintains them once you're done? What if you did
the entire thing in the scala type system (apparently Turing-complete) and
your pair-buddy had as much fun as you did, so he gave you the nod?

If you left and we discover a bug in the BNFC grammar or generated code, how
many technologies, quirky tools and libraries do I have to learn at 2am to
fix that and bring the system back online? Exaggerating here, but...I've
actually been there and done just that! It was 20 hours of no sleep and
definitely no fun!

I also agree with you on the good developers. No comment as to how
representative they are in the developer population, but you can guess my
opinion...

I realize this is probably the worst forum to be discussing this topic,
given the general audience but...I mean, reading the list as it is now,
which of those do you take issue with? I don't see it restricting usage of
the features of the language anymore than the normal Java guidelines say not
to write the entire program on a single line...

And to Viktor's point, that's precisely why the difference: library
developers need to write the mean nasty stuff so the others don't have to...
If I had to use CanBuildFrom[Repr, B, That] _explicitely_ on a daily basis,
I would not be writing any scala code...

Cheers,
Razie

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

On Fri, Sep 24, 2010 at 11:46 AM, Martin Renaud
wrote:
> I think the biggest challenge Scala faces preventing it can go mainstream is
> not the performance of the language features but this syntax that make it
> look more complicated that it really is and the learning curve it implies.

This topic came up a couple of times today at the Scala Lift Off in
San Francisco. Martin Odersky mentioned it in his closing summary for
the day and said part of it is because people who tend to solve very
hard problems with Scala like to share their solutions... and that's
usually extremely high-level (complex) code - much like the example
you quoted - and this can "scare off" new folks coming to Scala. He'd
raised a similar issue earlier in his talk about higher-kind types
used in the 2.8 collection class hierarchy and how they show up in the
API documentation - they can make the library look much harder to use
than it actually is.

It also came up in a session on introducing new technology to
organizations. I observed that Scala's comprehensive type system,
whilst very powerful (and desirable) is quite simply beyond a lot of
the web developers I deal with on a day to day basis. Those folks are
mostly self-taught, with no comp sci background at all, and they're
used to web scripting languages that have a very loose notion of type
at runtime (if any at all). My approach to introduce those folks to FP
will be to use Clojure since it's 'closer' to what they're used to -
and I'll be perfectly happy with the likely outcome a mix of Clojure
for core application logic, Scala for back end heavy lifting (mostly
in black box libraries) and some web templating language on the front
end.

Someone else in that session commented on the dense and often
incomprehensible error messages from the compiler when you get the
types wrong in your program (they quoted the example of people
learning Lift and seeing compiler errors that were so far removed from
the code they actually wrote that they had no idea how to resolve
issues).

I sympathize... back in the day, when templates were relatively new to
C++, compiler errors from template misuse could be equally
impenetrable.

I haven't read the OP's document yet but since this thread has opened
up such a big debate in a single day, I'll be heading there next to
see what the fuss is about :)

Sean, I understand that simple rule...basically says "play nice"...that's
what this is as well, except with clear examples: this is complex, this is
ugly, this is mean, this is not.

Anyways - not a lot of comments on specifics, so I'll leave it at this for
now.

It's not like this will be useful to me anytime soon... the CTO of our
little enterprise has expressly overruled my decision to allow scala
development in parallel with Java, in any "customer facing
components"...basically excluding a few hundred developers from "organized
first contact". Talk about spooky...and don't pick on my CTO, he's smarter
than most of us...

Non-existence of these profiles/rules/simplicity guides may in fact be a
much bigger disservice to scala adoption than their existence would be to
some experts (which are exempt anyways) or tinkerers (which can keep it to
after hours) ... and, delay adoption long enough in this day of accelerating
change and I'm sure competing platforms are smiling...with...like...larger
smiles or something :)

Anyways, food for thought.

-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: http://scripster.razie.com Scripster and
http://github.com/razie/gremlins Gremlins
Follow me: http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter , http://github.com/razie GitHub .

On Sat, Sep 25, 2010 at 10:45 PM, Razvan Cojocaru-2 <pub@razie.com> wrote:

Sean, I understand that simple rule...basically says "play nice"...that's
what this is as well, except with clear examples: this is complex, this is
ugly, this is mean, this is not.

Anyways - not a lot of comments on specifics, so I'll leave it at this for
now.

It's not like this will be useful to me anytime soon... the CTO of our
little enterprise has expressly overruled my decision to allow scala
development in parallel with Java, in any "customer facing
components"...basically excluding a few hundred developers from "organized
first contact". Talk about spooky...and don't pick on my CTO, he's smarter
than most of us...

I'm sorry to hear that, hope he'll change his mind in the future.
 

Non-existence of these profiles/rules/simplicity guides may in fact be a
much bigger disservice to scala adoption than their existence would be to
some experts (which are exempt anyways) or tinkerers (which can keep it to
after hours) ... and, delay adoption long enough in this day of accelerating
change and I'm sure competing platforms are smiling...with...like...larger
smiles or something :)

Is there anything any of the senior members of the community can do to increase the level of trust that is given to the language and its eco-system?
 

Anyways, food for thought.



-----
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys:  http://scripster.razie.com Scripster  and
http://github.com/razie/gremlins Gremlins
Follow me:  http://feeds.razie.com/RazvanTech RSS Feed ,
http://twitter.com/razie Twitter ,  http://github.com/razie GitHub .

--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/Re-scala-user-Scala-Joe-a-profile-for-regular-Joe-tp2555818p2713861.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Viktor Klang,
Code Connoisseur
Work:   www.akkasource.com
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On Saturday September 25 2010, Viktor Klang wrote:
> ...
>
> Is there anything any of the senior members of the community can do
> to increase the level of trust that is given to the language and its
> eco-system?

Will the senior members of the community please stand up?

RRS

On Sat, Sep 25, 2010 at 1:45 PM, Razvan Cojocaru-2 wrote:
> It's not like this will be useful to me anytime soon... the CTO of our
> little enterprise has expressly overruled my decision to allow scala
> development in parallel with Java, in any "customer facing
> components"...basically excluding a few hundred developers from "organized
> first contact". Talk about spooky...and don't pick on my CTO, he's smarter
> than most of us...

I'm sure he has his reasons. Did he explain what those reasons are and
why he doesn't want Scala alongside Java?

Yes. It has partially to do with the perceived risk of the clients' negative perception of us incorporating unproven technologies, partially with my inability to convince him why scala is so much better to absorb the cost and potential schedule risks etc.
Personally, that discussion was the first time in more than a decade that I felt like a geek talking nonsense :) - no reflection on scala itself.
Afterwards I created this - please don't repeat the arguments - that'd be boring :) http://www.slideshare.net/razvanc/why-scalaexecutive-overview
Cheers,Razvan
On Sat, Sep 25, 2010 at 6:04 PM, Sean Corfield <seancorfield@gmail.com> wrote:

On Sat, Sep 25, 2010 at 1:45 PM, Razvan Cojocaru-2 <pub@razie.com> wrote:
> It's not like this will be useful to me anytime soon... the CTO of our
> little enterprise has expressly overruled my decision to allow scala
> development in parallel with Java, in any "customer facing
> components"...basically excluding a few hundred developers from "organized
> first contact". Talk about spooky...and don't pick on my CTO, he's smarter
> than most of us...

I'm sure he has his reasons. Did he explain what those reasons are and
why he doesn't want Scala alongside Java?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."

On Fri, Sep 24, 2010 at 1:34 PM, Rex Kerr <ichoran@gmail.com> wrote:

Think about flying in an airspace with automation developed by fallible human programmers. Are there some features of Scala that you would rather not see used in the automation?

Russ P.

For mission-critical code, I would like programmers to use whatever tools are easiest for them to understand and demonstrate the correctness of, and I would determine the correctness based on a mixture of coding process (e.g. code in pairs, with a separate pair reviewing for validity, describing why the code works to yet another person) in addition to rigorous unit testing.  I would let the coding/testing pair define themselves what works and what does not work when it comes to verifiable code.  I'd also collect statistics on things that passed the human review and yet failed a unit test, and if there was some construct that consistently caused problems, then I'd say _don't do exactly that_, because you have demonstrated an inability to do it correctly.

Rex, I'm sure you're an excellent developer who writes top-notch code, but I don't think you understand the scope of this problem. I'm not claiming to be an expert myself, but I think I have a basic understanding of the big picture.

When hundreds of lives depend on correct functioning of software, It's not just a matter of having a good development process and using good programming practices and lots of testing. Yes, you need those, but you need more. And it's not just a matter of some mid-level manager telling some good developers to do a good job. A major bureaucracy is involved. Yes, bureaucracies are inefficient, but sometimes they are necessary. And sometimes they have rules that seem unreasonable until you step back and look at the bigger picture.

Consider flight-critical software for a large commercial aircraft. Again, I am not an expert, but my understanding is that it is required to be written in a subset of Ada with strict coding standards, and it eventually undergoes a rigorous line-by-line analysis by a team at the FAA (and the code can be hundreds of thousands of lines). Nothing "fancy" is allowed -- and if I am not mistaken I think that includes features that you would probably consider fairly basic, such as dynamic dispatching. I don't know the actual rules, but I'm willing to bet that most developers (myself included) would feel uncomfortably constrained by them. Note also that even the compilers for flight-critical software must undergo a rigorous and expensive certification process that most compilers probably could not pass.

Take a look at SPARK Ada sometime. As far as I know, it is the ultimate in a defensive, rigorous programming language. I isn't required for all flight-critical software, but it is used for safety-critical systems where you just can't afford to get it wrong. Now, Ada itself is defensive enough for most purposes, but SPARK Ada takes the defensiveness much further. In fact, it's so restrictive that I don't think I'd like using it much myself - unless I knew that I was writing actual operational software that lives would really depend on. SPARK Ada also uses static assertions, and in some cases it can formally guarantee correctness based on static analysis of the code.

My point is that, when lives are at stake, you need more than just good good developers, good development methods, good programming practices, and even good software. You need verifiability and, in some cases, proof of correctness. Those are very difficult to achieve without an unusually defensive and "conservative" style. And you may also need a language that is not quite as expressive and "cool" as many developers would like.

I understand that one of the benefits of functional programming is that it facilitates analysis and proof of correctness. So maybe Scala has something to offer even beyond Ada, which does not support functional programming (as far as I know). But I also suspect that Scala has all sorts of "fancy" features that might cause problems for an FAA certification team or a "model checker" program. Yes, you can tell the developers to just avoid those features, but you may need to go a step further and rigorously prohibit those features, just as SPARK Ada prohibits certain features of Ada. I don't know what those features would be, if any, but I'd be interested to know what Scala experts think they might be.

 

And, if any one failure would cause deaths, build in some redundancy!  Bridges that fail when one bolt rusts through are a bad design; likewise, so are aircraft that crash when one software package fails due to a corner case that nobody thought of or tested for.

Yes, definitely. The software itself only implements the overall design, and the overall design must be solid too.

Russ P.

--
http://RussP.us

On Sat, Sep 25, 2010 at 7:47 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Fri, Sep 24, 2010 at 1:34 PM, Rex Kerr <ichoran@gmail.com> wrote:

Think about flying in an airspace with automation developed by fallible human programmers. Are there some features of Scala that you would rather not see used in the automation?

Russ P.

For mission-critical code, I would like programmers to use whatever tools are easiest for them to understand and demonstrate the correctness of, and I would determine the correctness based on a mixture of coding process (e.g. code in pairs, with a separate pair reviewing for validity, describing why the code works to yet another person) in addition to rigorous unit testing.  I would let the coding/testing pair define themselves what works and what does not work when it comes to verifiable code.  I'd also collect statistics on things that passed the human review and yet failed a unit test, and if there was some construct that consistently caused problems, then I'd say _don't do exactly that_, because you have demonstrated an inability to do it correctly.

When hundreds of lives depend on correct functioning of software, It's not just a matter of having a good development process and using good programming practices and lots of testing. Yes, you need those, but you need more.

I agree that you _may_ need more.  Although the pedantically careful scheme I specified above is going to catch an awful lot of problems, plus you'll have good metrics on your error rate, which will let you scrap the entire process if it's not proving to be reliable enough.  (E.g. # bugs caught during description to 5th person.)
 

Consider flight-critical software for a large commercial aircraft. Again, I am not an expert, but my understanding is that it is required to be written in a subset of Ada with strict coding standards, and it eventually undergoes a rigorous line-by-line analysis by a team at the FAA (and the code can be hundreds of thousands of lines). ...

Note also that even the compilers for flight-critical software must undergo a rigorous and expensive certification process that most compilers probably could not pass.

Fair enough.  Why are we even bothering to discuss this on this list, then?  The JVM or equivalent would have to pass the test as well, and that's out of the scope of the Scala team.  If there's a decent VM handy, then maybe it's worth looking at.

Maybe a subset of Haskell could pass, including compiler?
 

My point is that, when lives are at stake, you need more than just good good developers, good development methods, good programming practices, and even good software. You need verifiability and, in some cases, proof of correctness.

Well, there's Coq....
 

But I also suspect that Scala has all sorts of "fancy" features that might cause problems for an FAA certification team or a "model checker" program.

Casting is the only one that I can think of that's really pernicious.

Otherwise, all the stuff with higher kinded types and implicits and _ and so on would not cause problems for a model checker that understood what was allowed, and wouldn't cause problems for a FAA certification team with appropriate tools (e.g. verbose explanations of what the compiler thought of any particular line, implicits applied, etc.).

But again, the point is moot without a certified JVM.

  --Rex

On Friday September 24 2010, Russ Paielli wrote:
> ...
>
> Think about flying in an airspace with automation developed by
> fallible human programmers. Are there some features of Scala that you
> would rather not see used in the automation? I'd be interested in
> what Scala experts have to say about it, if anything.

Please explain the connection between the reliability of the software
and the "features" of the language used. Please also explain why you
think proscribing certain of these language features could increase
reliability or other desirable (or necessary) property of the resulting
software?

> Russ P.

Randall Schulz

On Sat, Sep 25, 2010 at 10:04 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday September 24 2010, Russ Paielli wrote:
> ...
>
> Think about flying in an airspace with automation developed by
> fallible human programmers. Are there some features of Scala that you
> would rather not see used in the automation? I'd be interested in
> what Scala experts have to say about it, if anything.

Please explain the connection between the reliability of the software
and the "features" of the language used. Please also explain why you
think proscribing certain of these language features could increase
reliability or other desirable (or necessary) property of the resulting
software?

As one example, race conditions are difficult to rule out analytically except in particularly simple threading models (even Erlang is not free of them, though it does do a good job preventing gratuitous races).

Thus, one reasonable subset might be to throw out everything to do with threading if you want improved ability to reason about runtime performance.

But the only reason to throw out something like higher-kinded types is if humans have been proven to repeatedly reason about them incorrectly and shoot themselves in the foot.  (In C, having multiple pointers of different data type to the same memory location seems to be of this nature; it causes weird corner-case problems so often that simply saying "don't do that, ever" might be warranted.)

  --Rex

On Sat, Sep 25, 2010 at 7:04 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday September 24 2010, Russ Paielli wrote:
> ...
>
> Think about flying in an airspace with automation developed by
> fallible human programmers. Are there some features of Scala that you
> would rather not see used in the automation? I'd be interested in
> what Scala experts have to say about it, if anything.

Please explain the connection between the reliability of the software
and the "features" of the language used. Please also explain why you
think proscribing certain of these language features could increase
reliability or other desirable (or necessary) property of the resulting
software?

For examples of other languages for which this was done, take a look at these sites:
 http://en.wikipedia.org/wiki/Ravenscar_profile http://en.wikipedia.org/wiki/SPARK_programming_language
http://www.eetimes.com/discussion/other/4023981/Introduction-to-MISRA-C

I am not claiming that a "safe subset" needs to be defined for Scala, but it could possibly be a good idea if Scala is intended to be used for safety-critical software.

Russ P.

--
http://RussP.us

Sean Corfield said:
> [... condensed]
> wrote:
> > I think the biggest challenge Scala faces preventing it can go mainstream
> > is not the performance of the language features but this syntax that
> > make it look more complicated that it really is and the learning curve
> > it implies.
>
> It also came up in a session on introducing new technology to
> organizations. I observed that Scala's comprehensive type system,
> whilst very powerful (and desirable) is quite simply beyond a lot of
> the web developers I deal with on a day to day basis. Those folks are
> mostly self-taught, with no comp sci background at all, and they're
> used to web scripting languages that have a very loose notion of type
> at runtime (if any at all). My approach to introduce those folks to FP

I can only agree.
From my experience there you have to deal with these kind of developers:
a) the good but uncaring (who's gonna maintain this is not my problem)
b) the good and caring (the ones you want)
c) the average or even not-so-average (the ones you have to accept for
various reasons)
d) the malicious (the worst kind... often they are very good but black
hearted)

Face it: A head of department has to make sure that he doesn't allow a
toolchain which allows a) or d) to make a mess which defuncts c) and drives b)
insane.
And I know that scala has already been ruled out by some some of our big
clients for being to powerfull (read: gives a) and d) too much power to bring
a project or even business down).

I think, it is the ultimate challenge to the scala enthusiasts to come up with
a solution for this or face general non-adoption.

Don't get me wrong - I like scala very much (and I am no decider myself - I'm
subjected to the tool decisions of others). But I can feel a strong breeze
against scala right now...

Worried greetings
Bernd

I'm not at all an expert in this, but I'll take a shot.
Think of code as having two aspects:1. The intent (what it's supposed to do/accomplish)2. The actions (the specific things it does to realize the intent)
Think of reviewing code for a safety critical system as verifying on a very fine-grained level that the actions being performed by the the code are in alignment with the intent of the code.
Scala relies heavily on implicit stuff that's in the code's namespace.  For example, the collections make heavy use of implicit parameters to get things like CanBuildFrom into the method call, and all this is based on relatively complex type inference rules to make sure the right object goes into the right parameter.  The various type class patterns is another example.
Scala code tends to heavily obfuscate the actions (e.g. passing in a specific instance of CanBuildFrom) in favor of the intent (append an element to a list, resulting in a new list).
If you're the compiler, or a static analysis tool built on the compiler, all of this in completely unambiguous.  But if you are a human being, what you have a method calls and method parameters flying in left and right that don't show up in the source code that is sitting right in front of you.  This makes figuring out the specific actions being performed by a piece of Scala code very difficult.
So ironically these features that offload the task of keeping actions consistent with intent from the programmer onto the compiler, and thus 99% of the time make it far less error prone, make it much harder to manually verify that the actions are consistent with the intent.

On Sat, Sep 25, 2010 at 10:04 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday September 24 2010, Russ Paielli wrote:
> ...
>
> Think about flying in an airspace with automation developed by
> fallible human programmers. Are there some features of Scala that you
> would rather not see used in the automation? I'd be interested in
> what Scala experts have to say about it, if anything.

Please explain the connection between the reliability of the software
and the "features" of the language used. Please also explain why you
think proscribing certain of these language features could increase
reliability or other desirable (or necessary) property of the resulting
software?


> Russ P.


Randall Schulz

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

On Sunday September 26 2010, Erik Engbrecht wrote:
> I'm not at all an expert in this, but I'll take a shot.
>
> Think of code as having two aspects:
> 1. The intent (what it's supposed to do/accomplish)
> 2. The actions (the specific things it does to realize the intent)
>
> ...
>
> So ironically these features that offload the task of keeping actions
> consistent with intent from the programmer onto the compiler, and
> thus 99% of the time make it far less error prone, make it much
> harder to manually verify that the actions are consistent with the
> intent.

OK. Given the role of implicits in Scala and the fact that the standard
library is laden with them, if this is an impediment to the kind of
validation one would want to perform, then Scala itself would have to
be deemed unsuitable. Simply refraining from using implicits in any
code of your own would certainly not protect your from the putative
risk of this language feature.

However, I question whether "manual" analysis by a human inspecting the
code is even close to an acceptable way of ascertaining the code is
free of defects (discrepancy between design intent and system behavior)
at the level of certainty one would want in, say, safety-critical
systems such as avionics, biomedical devices, industrial control
systems etc.

Randall Schulz

This is somewhat related. Here is an extract of a recent interview with James Gosling (not really a regular Java Joe...):

James Gosling: I like Scala, but my big problem is that the type theory has gotten really complicated. The language lawyers are driving the bus. It's turning into something that journeyman developers and even people like me�I started getting into the Scala stuff and my head starts to spin and I go, "what?"

Full interview : http://www.basementcoders.com/transcripts/James_Gosling_Transcript.html

James Gosling probably expects to fully understand Scala's type system.  He is, after all, a language designer.  I suspect that the vast majority of Scala developers, even the ones that seem highly adept at working with Scala's type system, don't understand it at the level Gosling would expect to understand it.  I don't think most of the people working on the Scala compiler fully understand Scala's type system.
From a practical perspective I'm not sure what that means.  But I find quite often that really, really smart people claim to not understand something even when they understand it at a much deeper level than many people who claim to understand it.
It brings to mind the old cliche about how the more you know, the more you realize you don't know.
So I would take his statement with a grain or two of salt.

On Wed, Sep 29, 2010 at 6:31 PM, Martin Renaud <mr_martin_renaud@yahoo.ca> wrote:

This is somewhat related. Here is an extract of a recent interview with James Gosling (not really a regular Java Joe...):

James Gosling: I like Scala, but my big problem is that the type theory has gotten really complicated. The language lawyers are driving the bus. It's turning into something that journeyman developers and even people like me�I started getting into the Scala stuff and my head starts to spin and I go, "what?"

Full interview : http://www.basementcoders.com/transcripts/James_Gosling_Transcript.html

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

On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
> James Gosling: I like Scala, but my big problem is that the type
> theory has gotten really complicated. The language lawyers are driving
> the bus.

I always thought "language laywer" was a compliment. They are welcome
to drive my bus.

On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
> From a practical perspective I'm not sure what that means. But I find
> quite often that really, really smart people claim to not understand
> something even when they understand it at a much deeper level than
> many people who claim to understand it.

"Dunning-Kruger effect" has become a commonplace reference, but don't
coast on the wikipedia entry: it's one of my favorite non-CS papers.

http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_...

Even the title is awesome. "Unskilled and Unaware of it."

On Wed, Sep 29, 2010 at 8:04 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
> James Gosling: I like Scala, but my big problem is that the type
> theory has gotten really complicated. The language lawyers are driving
> the bus.

I always thought "language laywer" was a compliment.  They are welcome
to drive my bus.

Yeah, because everybody loves lawyers, eh. I never understood it as a compliment. I assumed it meant someone who knows every corner of the language but is not very good at using the language to produce innovative or useful software. After all, what do lawyers actually produce?
 

On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
> From a practical perspective I'm not sure what that means.  But I find
> quite often that really, really smart people claim to not understand
> something even when they understand it at a much deeper level than
> many people who claim to understand it.

"Dunning-Kruger effect" has become a commonplace reference, but don't
coast on the wikipedia entry: it's one of my favorite non-CS papers.

http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_39584049.pdf&type=journal

Even the title is awesome.  "Unskilled and Unaware of it."

That sounds a lot like the objective of the "self esteem" training in our public schools.

Russ P.

--
http://RussP.us

I don't think "language lawyer" implies any lack of knowledge or inability to produce.  I think it implies a person who will relentlessly drive out ambiguities in a code or a language, to the point where it just looks like gibberish to lay people, which means, ironically, it is ambiguous to lay people.
As a criticism of Scala it is a probably synonymous with "Scala is too academic" or perhaps "too theoretical" would be closer to Goslings meaning.  He's an engineer, and he probably thinks the theorists should be sitting on the bus, feeding the engineer useful theories that the engineer can then use or discard it setting the bus's direction.
On Wed, Sep 29, 2010 at 11:53 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Wed, Sep 29, 2010 at 8:04 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
> James Gosling: I like Scala, but my big problem is that the type
> theory has gotten really complicated. The language lawyers are driving
> the bus.

I always thought "language laywer" was a compliment.  They are welcome
to drive my bus.

Yeah, because everybody loves lawyers, eh. I never understood it as a compliment. I assumed it meant someone who knows every corner of the language but is not very good at using the language to produce innovative or useful software. After all, what do lawyers actually produce?
 

On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
> From a practical perspective I'm not sure what that means.  But I find
> quite often that really, really smart people claim to not understand
> something even when they understand it at a much deeper level than
> many people who claim to understand it.

"Dunning-Kruger effect" has become a commonplace reference, but don't
coast on the wikipedia entry: it's one of my favorite non-CS papers.

http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_39584049.pdf&type=journal

Even the title is awesome.  "Unskilled and Unaware of it."

That sounds a lot like the objective of the "self esteem" training in our public schools.

Russ P.

--
http://RussP.us

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

i don't think scala is too academic/theoretic etc. simply because you don't have to use every single feature at its maximum complexity. just ignore what is more complicated than it needs to be.

-------- Original-Nachricht --------
> Datum: Thu, 30 Sep 2010 07:53:58 -0400
> Von: Erik Engbrecht
> An: Russ Paielli
> CC: Paul Phillips , scala-debate@listes.epfl.ch
> Betreff: Re: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe

> I don't think "language lawyer" implies any lack of knowledge or inability
> to produce. I think it implies a person who will relentlessly drive out
> ambiguities in a code or a language, to the point where it just looks like
> gibberish to lay people, which means, ironically, it is ambiguous to lay
> people.
>
> As a criticism of Scala it is a probably synonymous with "Scala is too
> academic" or perhaps "too theoretical" would be closer to Goslings
> meaning.
> He's an engineer, and he probably thinks the theorists should be sitting
> on
> the bus, feeding the engineer useful theories that the engineer can then
> use
> or discard it setting the bus's direction.
>
> On Wed, Sep 29, 2010 at 11:53 PM, Russ Paielli
> wrote:
>
> > On Wed, Sep 29, 2010 at 8:04 PM, Paul Phillips
> wrote:
> >
> >> On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
> >> > James Gosling: I like Scala, but my big problem is that the type
> >> > theory has gotten really complicated. The language lawyers are
> driving
> >> > the bus.
> >>
> >> I always thought "language laywer" was a compliment. They are welcome
> >> to drive my bus.
> >>
> >
> > Yeah, because everybody loves lawyers, eh. I never understood it as a
> > compliment. I assumed it meant someone who knows every corner of the
> > language but is not very good at using the language to produce
> innovative or
> > useful software. After all, what do lawyers actually produce?
> >
> >
> >>
> >> On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
> >> > From a practical perspective I'm not sure what that means. But I
> find
> >> > quite often that really, really smart people claim to not understand
> >> > something even when they understand it at a much deeper level than
> >> > many people who claim to understand it.
> >>
> >> "Dunning-Kruger effect" has become a commonplace reference, but don't
> >> coast on the wikipedia entry: it's one of my favorite non-CS papers.
> >>
> >>
> >>
> http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_...
> >>
> >> Even the title is awesome. "Unskilled and Unaware of it."
> >>
> >>
> > That sounds a lot like the objective of the "self esteem" training in
> our
> > public schools.
> >
> >
> > Russ P.
> >
> > --
> > http://RussP.us
> >
>
>
>

The point is that's not the perspective that Gosling would come from.  He would approach Scala as a language designer trying to understand someone else's design.  And he probably concluded he would have to go study type theory for a while in order to do it.  Hence the type theorists are driving the bus.   I think part of the...backlash...against Scala by some....uhhh...thought leaders....in the Java community is because you can't sit down a feel like you fully grasp Scala.  There's this constant feeling that there's more to learn, even after working with it for a while and pushing its features.  To some people that is attractive - it's a constant voyage of discovery.  Others is scares to death.  They're used to feeling like they fully grasp their language, and here comes this language that they feel like they will never fully grasp.

On Thu, Sep 30, 2010 at 9:53 AM, Dennis Haupt <h-star@gmx.de> wrote:

i don't think scala is too academic/theoretic etc. simply because you don't have to use every single feature at its maximum complexity. just ignore what is more complicated than it needs to be.

-------- Original-Nachricht --------
> Datum: Thu, 30 Sep 2010 07:53:58 -0400
> Von: Erik Engbrecht <erik.engbrecht@gmail.com>
> An: Russ Paielli <russ.paielli@gmail.com>
> CC: Paul Phillips <paulp@improving.org>, scala-debate@listes.epfl.ch
> Betreff: Re: [scala-debate] Re: [scala-user] Scala Joe - a profile for regular Joe

> I don't think "language lawyer" implies any lack of knowledge or inability
> to produce.  I think it implies a person who will relentlessly drive out
> ambiguities in a code or a language, to the point where it just looks like
> gibberish to lay people, which means, ironically, it is ambiguous to lay
> people.
>
> As a criticism of Scala it is a probably synonymous with "Scala is too
> academic" or perhaps "too theoretical" would be closer to Goslings
> meaning.
>  He's an engineer, and he probably thinks the theorists should be sitting
> on
> the bus, feeding the engineer useful theories that the engineer can then
> use
> or discard it setting the bus's direction.
>
> On Wed, Sep 29, 2010 at 11:53 PM, Russ Paielli
> <russ.paielli@gmail.com>wrote:
>
> > On Wed, Sep 29, 2010 at 8:04 PM, Paul Phillips
> <paulp@improving.org>wrote:
> >
> >> On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
> >> > James Gosling: I like Scala, but my big problem is that the type
> >> > theory has gotten really complicated. The language lawyers are
> driving
> >> > the bus.
> >>
> >> I always thought "language laywer" was a compliment.  They are welcome
> >> to drive my bus.
> >>
> >
> > Yeah, because everybody loves lawyers, eh. I never understood it as a
> > compliment. I assumed it meant someone who knows every corner of the
> > language but is not very good at using the language to produce
> innovative or
> > useful software. After all, what do lawyers actually produce?
> >
> >
> >>
> >> On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
> >> > From a practical perspective I'm not sure what that means.  But I
> find
> >> > quite often that really, really smart people claim to not understand
> >> > something even when they understand it at a much deeper level than
> >> > many people who claim to understand it.
> >>
> >> "Dunning-Kruger effect" has become a commonplace reference, but don't
> >> coast on the wikipedia entry: it's one of my favorite non-CS papers.
> >>
> >>
> >>
> http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_39584049.pdf&type=journal
> >>
> >> Even the title is awesome.  "Unskilled and Unaware of it."
> >>
> >>
> > That sounds a lot like the objective of the "self esteem" training in
> our
> > public schools.
> >
> >
> > Russ P.
> >
> > --
> > http://RussP.us
> >
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

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

+1. Well put.

The inevitable wil happen. Hmm that makes me sound prophetic. Me likee!

Profiles may be preferable to dialects? Or do the EPFL license terms
preclude dialects and variations?

Just trying to think ahead...me likee the messianic Oracle
propheticism - like sounding statements. .

I wonder where the next divergence lies for scala. Java has had a
reasonable run, but change is accelerating. It's not a question of if
but when and how.

On 9/30/10, Erik Engbrecht wrote:
> The point is that's not the perspective that Gosling would come from. He
> would approach Scala as a language designer trying to understand someone
> else's design. And he probably concluded he would have to go study type
> theory for a while in order to do it. Hence the type theorists are driving
> the bus.
>
> I think part of the...backlash...against Scala by some....uhhh...thought
> leaders....in the Java community is because you can't sit down a feel like
> you fully grasp Scala. There's this constant feeling that there's more to
> learn, even after working with it for a while and pushing its features. To
> some people that is attractive - it's a constant voyage of discovery.
> Others is scares to death. They're used to feeling like they fully grasp
> their language, and here comes this language that they feel like they will
> never fully grasp.
>
> On Thu, Sep 30, 2010 at 9:53 AM, Dennis Haupt wrote:
>
>> i don't think scala is too academic/theoretic etc. simply because you
>> don't
>> have to use every single feature at its maximum complexity. just ignore
>> what
>> is more complicated than it needs to be.
>>
>> -------- Original-Nachricht --------
>> > Datum: Thu, 30 Sep 2010 07:53:58 -0400
>> > Von: Erik Engbrecht
>> > An: Russ Paielli
>> > CC: Paul Phillips , scala-debate@listes.epfl.ch
>> > Betreff: Re: [scala-debate] Re: [scala-user] Scala Joe - a profile for
>> regular Joe
>>
>> > I don't think "language lawyer" implies any lack of knowledge or
>> inability
>> > to produce. I think it implies a person who will relentlessly drive out
>> > ambiguities in a code or a language, to the point where it just looks
>> like
>> > gibberish to lay people, which means, ironically, it is ambiguous to lay
>> > people.
>> >
>> > As a criticism of Scala it is a probably synonymous with "Scala is too
>> > academic" or perhaps "too theoretical" would be closer to Goslings
>> > meaning.
>> > He's an engineer, and he probably thinks the theorists should be
>> > sitting
>> > on
>> > the bus, feeding the engineer useful theories that the engineer can then
>> > use
>> > or discard it setting the bus's direction.
>> >
>> > On Wed, Sep 29, 2010 at 11:53 PM, Russ Paielli
>> > wrote:
>> >
>> > > On Wed, Sep 29, 2010 at 8:04 PM, Paul Phillips
>> > wrote:
>> > >
>> > >> On Wed, Sep 29, 2010 at 03:31:32PM -0700, Martin Renaud wrote:
>> > >> > James Gosling: I like Scala, but my big problem is that the type
>> > >> > theory has gotten really complicated. The language lawyers are
>> > driving
>> > >> > the bus.
>> > >>
>> > >> I always thought "language laywer" was a compliment. They are
>> > >> welcome
>> > >> to drive my bus.
>> > >>
>> > >
>> > > Yeah, because everybody loves lawyers, eh. I never understood it as a
>> > > compliment. I assumed it meant someone who knows every corner of the
>> > > language but is not very good at using the language to produce
>> > innovative or
>> > > useful software. After all, what do lawyers actually produce?
>> > >
>> > >
>> > >>
>> > >> On Wed, Sep 29, 2010 at 08:54:15PM -0400, Erik Engbrecht wrote:
>> > >> > From a practical perspective I'm not sure what that means. But I
>> > find
>> > >> > quite often that really, really smart people claim to not
>> > >> > understand
>> > >> > something even when they understand it at a much deeper level than
>> > >> > many people who claim to understand it.
>> > >>
>> > >> "Dunning-Kruger effect" has become a commonplace reference, but don't
>> > >> coast on the wikipedia entry: it's one of my favorite non-CS papers.
>> > >>
>> > >>
>> > >>
>> >
>> http://www.scirp.org/fileOperation/downLoad.aspx?path=Psych.20090100004_...
>> > >>
>> > >> Even the title is awesome. "Unskilled and Unaware of it."
>> > >>
>> > >>
>> > > That sounds a lot like the objective of the "self esteem" training in
>> > our
>> > > public schools.
>> > >
>> > >
>> > > Russ P.
>> > >
>> > > --
>> > > http://RussP.us
>> > >
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>>
>> --
>> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
>> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
>>
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>

I remember working on a C++ library where the designer had decided to simplify code by introducing a lot of obvious operators, as opposed to methods. They were obvious--to him (or perhaps her, in all fairness). For people working on the library, it was a nightmare. It was very difficult to decide what was part of C++, the STL, or the custom library.

Scala (for all that I like it) has this problem in spades. Between a very complex type system, implicits, and various other features I can't even remember, it is very easy to write highly obfuscated code. The conciseness of higher-order programming can contribute to this problem or not. Ever seen a really concise line of APL? To those in the know it may be crystal clear, but to the majority of programmers, it's line noise. I'd also refer people to Backus' 'fp' language, which was interesting from a theoretical point of view, but could produce some truly impenetrable code.

IMHO, there are really two camps. The first is Perl's, "There's more than one way to do it", which leads to disastrous maintainability results. (Yes, I've maintained big Perl codebases. I'm not speaking out of my hat.) The second is Python's (as of a couple of generations ago) "There's only one right way to do it." Indentation is mandatory whether you like it or not, there are a limited number of idioms and new idioms are added only after cautious consideration, and one programmer's solution looks surprisingly like another programmer's solution. (And I've also maintained large Python codebases, so yes, I know what I'm talking about.) From the point of view of getting something out the door, the first is probably superior. From the point of view of having something that _lasts_, the second is the winner, not even a contest.

What I would've liked in a language. (And I'm not dissing Scala, it's still my favorite contender.) Something like Groovy, where declared types are optional but (unlike Groovy) if you declare them, they really speed code up. I think this could be a huge win. It gets rid of extremely complex type systems (admittedly requiring some type casts--but that's not a huge thing in modern IDEs), it still provides a lot of type safety, it gains speed, and it's accessible to everyone.

One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.

Cheers,
Ken

Am 30.09.2010 23:13, schrieb Kenneth McDonald:
> One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.
my experience is that compile time type checking greatly helps if it's
not your code you are trying to modify/debug/understand. in your own,
you usually know what you are doing.

Kenneth McDonald wrote 2010-09-30 23:13:
> What I would've liked in a language. (And I'm not dissing Scala, it's still my favorite contender.) Something like Groovy, where declared types are optional but (unlike Groovy) if you declare them, they really speed code up. I think this could be a huge win. It gets rid of extremely complex type systems (admittedly requiring some type casts--but that's not a huge thing in modern IDEs), it still provides a lot of type safety, it gains speed, and it's accessible to everyone.
>
> One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.

If you think the main benefit of static type checking is improved
runtime performance, you should seriously consider switching to another
language. Personally, I would be scared shitless if I had to maintain a
large Python application and someone actually relied on that application
producing correct results. I'm not saying Scala is perfect, far from it,
but currently it's the best we have in the Java ecosystem. If anything I
would like to see more static checking being done by the compiler (like
side effect tracking and null checking).

/Jesper Nordenberg

On Thu, Sep 30, 2010 at 4:13 PM, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:

One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down.

Have you tried refactoring a large code base. Really refactoring it, not just moving a few things. I will claim that to be almost impossible without rigorous type checking.

Nils

On Thu, Sep 30, 2010 at 5:13 PM, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:

One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.

My experience with Python has convinced me that compile-time type-checking is vastly _under_rated for me.  It was not that the type errors were difficult to reveal with simple testing; it was that every absurdly tiny little thing had to be tested or it might randomly break, and this meant that I had to spend far more time writing test code than writing actual code to use if I wanted to avoid random type errors at runtime.  With Scala, I have a much higher probability of getting things right if it compiles, and thus to have acceptable error rates I can write tests at a higher level and less often.

Given the combination of our two experiences, perhaps the conclusion is that compile-time type-checking is vastly more important to some people than to others.  I am glad that the Oderskys of the world exist to make things easier for those of us on the "more important" end of the spectrum.

  --Rex

On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:

One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.

Python is great for getting something out the door fast (as you said about Perl), but as others have said, it is not very good for maintainability (for larger projects at least).

I am converting some of my own Python code to Scala. Part of the process is declaring method argument types, of course. I had always assumed that would be simple, but sometimes it is not. In some cases, figuring out the argument types in my own code is a non-trivial problem. But I now realize that just having those types explicitly declared reduces confusion and improves readability considerably. In fact, if the return type of a method is not trivially clear, explicitly declaring it also improves readability.

Russ P.

--
http://RussP.us

I'm sorry, I somewhat omitted some of my case when I first wrote.
I did not mean to imply that static type checking was _only_ good for performance reasons. It can also considerably enhance code correctness, as several others have pointed out.
However, as with most things, there comes a point of diminishing returns. Trying to statically check __too__ much leads to a very complex and difficult to understand type systems.
IMHO, Scala is at the verge, if not slightly over the line, for this limit.
Again, I'll say; a language like Groovy which permits type declarations (I realize Groovy decls are not checked at compile time, but that's a detail), while allowing "duck-typing" when necessary, would be appropriate. My belief is that most programmers would declare 90%+ of their types, greatly reducing errors and potentially increasing runtime speed. Most of the rest of the type errors would be easily caught by unit tests. A trivial fraction would escape into a release product--small enough, IMHO, to make up for the increased productivity and ease of use of a "mostly static" type system.
Until we have such a language (if ever) such discussions will, unfortunately, be rather academic. However, one thing I'm willing to say without qualification, and as someone who spent much of a Ph.D. doing functional languages, including O'Caml, Haskell, Concurrent Clean, etc: The current type system for Scala is too scary for most programmers, and to the extent that it is emphasized, will scare off support.
Wish that weren't the case,Ken McDonald

On Sep 30, 2010, at 5:47 PM, Russ Paielli wrote:

On Thu, Sep 30, 2010 at 2:13 PM, Kenneth McDonald <kenneth.m.mcdonald@sbcglobal.net> wrote:

One final note. My experience with Python has convinced me that compile-time type-checking is _vastly_ overrated. 90%+ of my type errors in Python are revealed in simple testing, and the remainder aren't typically difficult to track down. I have great respect for the work Martin Odersky et al have done, but I question if it's really necessary. I wish this topic didn't suck away so much really superior talent.

Python is great for getting something out the door fast (as you said about Perl), but as others have said, it is not very good for maintainability (for larger projects at least).

I am converting some of my own Python code to Scala. Part of the process is declaring method argument types, of course. I had always assumed that would be simple, but sometimes it is not. In some cases, figuring out the argument types in my own code is a non-trivial problem. But I now realize that just having those types explicitly declared reduces confusion and improves readability considerably. In fact, if the return type of a method is not trivially clear, explicitly declaring it also improves readability.

Russ P.

-- 
http://RussP.us

On Thu, Sep 30, 2010 at 8:03 PM, Kenneth McDonald
wrote:
>
> Again, I'll say; a language like Groovy which permits type declarations (I
> realize Groovy decls are not checked at compile time, but that's a detail),
> while allowing "duck-typing" when necessary, would be appropriate. My belief
> is that most programmers would declare 90%+ of their types, greatly reducing
> errors and potentially increasing runtime speed. Most of the rest of the
> type errors would be easily caught by unit tests. A trivial fraction would
> escape into a release product--small enough, IMHO, to make up for the
> increased productivity and ease of use of a "mostly static" type system.
> Until we have such a language (if ever) such discussions will,
> unfortunately, be rather academic.

If I understand what you're writing there, I think Perl6 fits the
requirement. As you may know, it carries the Perl name but is not
backwards compatible with other versions of Perl. One of the new
features is optional type declarations and I believe it's supposed to
do type checking if you explicitly declare a type. But right now
Perl6 is only a language specification with a few separate
implementations in various stages of completion.

I'm not that bright, and I've seen plenty of code on these mailing
lists that baffles me. On the other hand, I have the books
"Programming Scala" by Venkat Subramaniam and "Programming in Scala"
by Martin Odersky, Lex Spoon, and Bill Venners and they give me a lot
of hope for the future wide use of the language because they're
phenomenally well done. I was especially nervous about the book
co-written by Odersky, I worried that people brilliant enough to
design a language would have a hard time explaining the concepts to
average developers. But it's the best book on software that I own,
and everything is explained clearly with great examples. None of it
is that difficult to understand.

Between the books and the helpful communities on the forums and
mailing lists I'm hopeful for Scala.

-Mike

Am 30.09.2010 05:04, schrieb Paul Phillips:
> "Dunning-Kruger effect" has become a commonplace reference,

Except that the effect is partly a statistical artifact

http://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-kruger-effect...

- Florian.