What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

> 3. Being able to use Scala for scripting. Than implies 1 and a better
> starting time + something to include automagically dependencies,
> essentially. And it will be so good to show how cool and powerful Scala
> is in some little lines. I really would *love* to convert the sysadmin I
> work with to use it as possible replacement of perl or python (or bash),
> but for now, the lauching time are killing that possibility.

My 2c.

System administrators, in general, have rather particular
requirements.

Here's a couple that I've observed:

1) Simplicity.
2) Stability.
3) Speed, but simplicity is much more important.
4) An API, (where applicable) which wraps OS level functionality in
simple fashion.
5) Can be installed, without playing version bingo, from the OS
package management system.
6) Fast code/test/deploy cycle, for a 200 line program, compile/
startup time of more than 2 seconds is too long.
7) Is Bourne, Python, Ruby or for those hangers on from the dot-com
boom, Perl.

System administrators, in general, don't like the following things.

1) Dynamic behaviour redefinition, think implicits.
2) Factory classes, design patterns, types, static typing.
3) Monads, Monoids, things that make more than 2 minutes to make sense
of.
4) Stuff that needs to constantly auto-update itself from some server
in Switzerland, every time you do a build.

I could be wrong....

On 2011, Nov 10, at 1:22 PM, bryan hunt wrote:
>> is in some little lines. I really would *love* to convert the sysadmin I
>> work with to use it as possible replacement of perl or python (or bash),
>> but for now, the lauching time are killing that possibility.
> System administrators, in general, have rather particular
> requirements.

System administrators, in general, are not developers. They need a different toolset than us devvie guys do. I don't think it is possible to build a tool that does both well.

I would love to be proven wrong on this one, tough.

Geir

On Thu, Nov 10, 2011 at 10:22, bryan hunt wrote:
>> 3. Being able to use Scala for scripting. Than implies 1 and a better
>> starting time + something to include automagically dependencies,
>> essentially. And it will be so good to show how cool and powerful Scala
>> is in some little lines. I really would *love* to convert the sysadmin I
>> work with to use it as possible replacement of perl or python (or bash),
>> but for now, the lauching time are killing that possibility.
>
> My 2c.
>
> System administrators, in general, have rather particular
> requirements.
>
> Here's a couple that I've observed:
>
> 1) Simplicity.
> 2) Stability.

System administrators love stability from others. For their own
script, I have never seen one give a fig. And I think the wild ride
that are the scripting languages is proof enough of that attitude.

> 3) Speed, but simplicity is much more important.

If speed wasn't important, Perl would never have been born. Log files
can be HUGE, and handling them efficiently is important.

> 4) An API, (where applicable) which wraps OS level functionality in
> simple fashion.

I'd go even beyond that. They want "a library for that". CPAN is not
simply a result of Perl's popularity: it is an integral part of it. I
can *browse* the available libraries from CLI by typing "perl -MCPAN
-e shell". I can search for a Ruby library on shell with "gem search".
I'm not familiar with Python, but I bet it has the same thing.

So, while sbaz, as it is, doesn't work, having a working sbaz, and a
web site equivalent, would be fundamental in actually getting Scala
accepted as a system administrator tool.

> 5) Can be installed, without playing version bingo, from the OS
> package management system.

Well, they do like that, but I can tell you this is not a situation
one encounters that often. Again, this is true much more for stuff
sent by devel than stuff done by sysadmin themselves.

> 6) Fast code/test/deploy cycle, for a 200 line program, compile/
> startup time of more than 2 seconds is too long.

Well, there are third party solutions to that, but it can't be helped
except by having a JVM daemon running.

> 7) Is Bourne, Python, Ruby or for those hangers on from the dot-com
> boom, Perl.
>
> System administrators, in general, don't like the following things.
>
> 1) Dynamic behaviour redefinition, think implicits.

Actually, I think they'd love implicits.

> 2) Factory classes, design patterns, types, static typing.

Mostly (well, see stuff like Python-written Ganeti or Perl-written
OTRS for counter-examples). As for static typing, the problem is not
static typing, the problem is boilerplate. In fact, you could replace
that whole line with "boilerplate" and be done with it and be more
accurate, to boot.

> 3) Monads, Monoids, things that make more than 2 minutes to make sense
> of.

Word.

> 4) Stuff that needs to constantly auto-update itself from some server
> in Switzerland, every time you do a build.

As if there isn't a package manager that isn't download-happy. They
don't like being FORCED to update at a time they don't want to. Other
than that... business as usual.

On Thu, Nov 10, 2011 at 10:31, Geir Hedemark wrote:
> On 2011, Nov 10, at 1:22 PM, bryan hunt wrote:
>>> is in some little lines. I really would *love* to convert the sysadmin I
>>> work with to use it as possible replacement of perl or python (or bash),
>>> but for now, the lauching time are killing that possibility.
>> System administrators, in general, have rather particular
>> requirements.
>
> System administrators, in general, are not developers. They need a different toolset than us devvie guys do. I don't think it is possible to build a tool that does both well.
>
> I would love to be proven wrong on this one, tough.

Ruby and Python were born as system administration scripting
languages, as far as I know. I do know that my first contact with Ruby
was in such a role. And I think it is undeniable that Perl is the
ultimate system administrator tool. :-)

Which is more and more besides the point. Devops is here to stay.

Whilst I agree - I have been bitten countless times by malformed format strings. Many times these lead to stuff like actors shutting down (with no accompanying stack trace) and can be a complete nightmare to detect. Particularly when the string format was itself supposed to indicate some exceptional situation (so the system fails silently, possibly months after the code was written):
 catch { case e => log.info("Fallen over with: %d".format(e)) }
I have become hypersensitive to checking my own format strings carefully, whereas with IDEA I needed only to be aware of the fact that they were not highlighted as malformed
Chris

> Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?
> From: channing.walton@googlemail.com
> Date: Wed, 9 Nov 2011 21:13:58 +0000
> To: scala-user@googlegroups.com
>
>
> On 9 Nov 2011, at 20:21, Andreas Joseph Krogh wrote:
>
> > I use IDEA-11 EAP with the latest scala-plugin and I really don't consider IDE-support at all to be an issue anymore.
>
> This is also my experience too although I use IDEA-11 and Eclipse. The only thing that irritates me in IDEA is that one still needs to do a full compile occasionally to see if the red lines in editors are real problems or not. But a couple of bugs I submitted recently were fixed in 1 day which made the experience much better.
>
> The IDE is simply not an issue any more, certainly not one that should prevent anyone from benefitting from Scala.
>

I don't post often, but when I do...

This thread is becoming an IDE flame war, but in the meantime, take a
look at this article just published:

http://www.informationweek.com/news/software/info_management/231902645

The Big Data Stack is probably the next big thing to work its way into
large enterprises. What offering does Scala have here? Scala
ecosystem recently bet big on parallel collections, lang
virtualization, and absorbing AKKA (all truly amazing stuff). But,
these are just different directions than big enterprises are taking.
With the Big Data Stack, numerous industries are realizing the value
of a generic, supported framework for the storage and analysis of
unlimited data in structured and unstructured forms. This solves a
huge industry problem as general trend is more real-time results, more
introspection of your customer's data so you can sell or offer more
value than competitor, and of course it solves the data explosion
problem in an affordable, predictable way without vendor lock in.

I am consulting with a big financial center currently, so let me give
some background and context of the environment. There might be a
dozen or two of us who could write code in Scala right now. But the
other 10,000 developers will not have a clue how to read it, how to
get trained, how to get started, how to get Management to pay for all
their training and lost productivity while they train, rewrite, and
learn on the job. We'd no doubt see the range of Scala as it is very
flexible, making it very difficult to maintain and read. This
contradicts the process and control lock down big companies must have
to make sure strategy flows from top to bottom as it is translated
into execution. From a ground up perspective, the first time a
Manager who codes "Enterprise Style Java", risks his reputation (and
budget and bonus) on some smart consultant's Scala recommendation,
only to experience first hand a random long pauses using an IDE or has
an unexpected class explosion from specialization or a code review
with someone pushing the type system, he will shut it down and
vocalize his perception to other managers and that consultant is
booted.

In a big company, it is not uncommon to find millions of lines of code
written in Java, with huge chunks of it pre generics. I don't see
that code going anywhere. It is simple to read, buggy as heck to
modify beyond its intended extension points, but in Management's mind
it has powered the company for almost a decade so why change it? They
see so many other areas that would have a higher return on investment.

I think Scala could make inroads in another way. Big companies buy
smaller companies all the time. If eventually enough small companies
are ingested that are using Scala, the base make up of the big company
changes. Big companies also go with proven advantages from vendors or
open source, but they typically do not make big risky bets, and they
only change tooling and paradigms when competition forces change.
There's also ingestion in the small - great libraries.

But this would take a long time, and I suspect great progress is not
happing in this direction. Why? I'm not sure, but I don't see a
great migration in open source to replace Java for enterprise tooling
with Scala (I am aware of the contributions flowing from startups). I
do not see dozens of Apache projects banging out new libraries and
Java Enterprise API implementations using Scala, even where they are
small, lightweight subsets like JAXB and JAX-RS. So something is
amiss with the value proposition of Scala, such that it is not getting
ingested by the Java ecosystem in the small. There is some progress,
but not as much as I thought there would be at the "Apache" level.

How about in the large? The Big Data Stack is the next big thing, and
it has been incubating on the JVM almost as long as Scala has, yet I
see very little to no influence by Scala. If Scala is such a great
productive language, why are not all the new tools around the Big Data
Stack and pieces of the Big Data Stack written in Scala? Again, I'm
just not sure why this didn't happen, just that it appears not to be,
and thus ingestion as a mechanism to break out appears not to be
happening.

Then there is the operational requirements of big enterprise. How do
we constrain Scala for Enterprise? Enterprises follow a model that is
the opposite of Academia in terms of the composition and use of labor
(many cogs following directed, repeatable process to generate globally
usable artifacts vs Acadmia's accretion of new knowledge using search
and investigation to generate narrow use artifacts.) How would you
get 10,000 or maybe 1000 developers or 100 or 10 to follow an approved
subset of the language? Trust? Ugh. Scala has turing complete type
system (side stepping tractability issues) - amazing for research and
exploration of the possible - not so good for 9 to 5 coder who might
be proficient in 2004-2008 era Java writing code that any of those
other 10,000 devs must be able to read and modify.

I used to think Scala was going to crack the enterprise by 2009-2010
(been an avid follower since 2007). Then the great collection rewrite
showed us that type abstraction in Scala would allow us to do things
more correctly and keep type safety. However that type safety had a
cost and the collection API is now non-navigable or extendable by new
users. How do we make the same kinds of jumps in usability
abstraction?

In many ways Scala's direction appears to be the antithesis of big
enterprise tooling. But, every consumer having a ubiquitous computing
device that is always connected in their hand is forcing big
enterprises to increase capabilities or lose their relationship with
those customers. This is an opportunity for Scala, but maybe not the
Scala we all know and love. Maybe it is time to evaluate a Scala
"light"?

Scala's hypothesis of a scalable language fusing FP and OO was and
continues to be needed (thanks Martin), but what has been learned here
can certainly feed into a subset language that leverages Scala, but
answers another hypothesis: How do we bridge a scalable language to a
constrained environment to deliver value to the masses that don't grok
type theory, category theory/abstract algebra, and that don't have
much time to learn anything that does not fit their current analogies
or at least have obvious, predictable value model? I used to think
DSLs were the vehicle by which Scala would crack into the enterprise.
While they are targeted, and offer high levels of productivity - in
the end they require you must understand all of Scala to extend, grow,
and therefore require passing the enterprise test before they can be
used to bring the language in.

Is working with the constrained big enterprise something the Scala
community even wants to solve? It cuts into resources and that cuts
into all the great edge problems Scala allows us to interact with.
You could think of Scala as an incubator - somewhere between edge
research and somewhere between getting real stuff done at tomorrows
big companies (startups). These environments have a great deal in
common, and it isn't surprising Scala can thrive there. But
enterprise is a re-think if you want to target them. I don't think
providing more documentation or a flawless GUI based environment
solves the problem outright. Imagine one small team using modern day
fighter jet fighter for missions. The training, the documentation,
the hours to effectively use it are unreal so you have to be a top
student - but the result is very capable, fast, and far reaching
instrument a handful can use. Well, enterprises are more like big
battleships. slow to turn. lots of hands on deck taking orders in a
hierarchy to accomplish things. Sure battleships might have some cool
bolt-on technology, and some really smart people on board (and even
more 9-5er types). But, I don't think providing more doc, training,
or a flawless heads up display will turn battleship hands into jet
fighter pilots, let alone battleships into aircraft carriers. Maybe
it is time to reframe the problem.

Just some food for thought on this issue.

Kind Regards,

Jim Herber

WOW. I hear you and used to think so, but then I also find it amazing that
these "big companies" don't use Cobol that much anymore... that builds kind
of a contradiction there...

Our customers - many orders of magnitude larger than us, have vey funky
environments. I have seen all sorts of scripting environments known to man
(and a few in-house) in production all over the place.

Also - the moment I stopped pushing for it, some guys here started picking
it up... now we have at least one "official" project using an internal scala
DSL :)

Maybe the most important thing we all need to do is just chill... of course
a great UI won't hurt the chilling process!

------

About Big data - yeah. Kind'a easy to explain to someone: map-reduce this
sh!t. somehow that sounds better to the masses than "flat-map this sh!t"?

That however will be just a stepping stone kicking in new paradigms... Yo,
Greg - how's your book coming along?

------

To answer the original "what scala needs to succeed in the enterprise" ?

Karma!

Cheers,
RAzie

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of jherber
Sent: November-10-11 9:24 AM
To: scala-user
Subject: [scala-user] Re: What is highest priority for Scala to succeed in
corporate world (Should be in scala-debate?) ?

I don't post often, but when I do...

This thread is becoming an IDE flame war, but in the meantime, take a look
at this article just published:

http://www.informationweek.com/news/software/info_management/231902645

The Big Data Stack is probably the next big thing to work its way into large
enterprises. What offering does Scala have here? Scala ecosystem recently
bet big on parallel collections, lang virtualization, and absorbing AKKA
(all truly amazing stuff). But, these are just different directions than
big enterprises are taking.
With the Big Data Stack, numerous industries are realizing the value of a
generic, supported framework for the storage and analysis of unlimited data
in structured and unstructured forms. This solves a huge industry problem
as general trend is more real-time results, more introspection of your
customer's data so you can sell or offer more value than competitor, and of
course it solves the data explosion problem in an affordable, predictable
way without vendor lock in.

I am consulting with a big financial center currently, so let me give some
background and context of the environment. There might be a dozen or two of
us who could write code in Scala right now. But the other 10,000 developers
will not have a clue how to read it, how to get trained, how to get started,
how to get Management to pay for all their training and lost productivity
while they train, rewrite, and learn on the job. We'd no doubt see the
range of Scala as it is very flexible, making it very difficult to maintain
and read. This contradicts the process and control lock down big companies
must have to make sure strategy flows from top to bottom as it is translated
into execution. From a ground up perspective, the first time a Manager who
codes "Enterprise Style Java", risks his reputation (and budget and bonus)
on some smart consultant's Scala recommendation, only to experience first
hand a random long pauses using an IDE or has an unexpected class explosion
from specialization or a code review with someone pushing the type system,
he will shut it down and vocalize his perception to other managers and that
consultant is booted.

In a big company, it is not uncommon to find millions of lines of code
written in Java, with huge chunks of it pre generics. I don't see that code
going anywhere. It is simple to read, buggy as heck to modify beyond its
intended extension points, but in Management's mind it has powered the
company for almost a decade so why change it? They see so many other areas
that would have a higher return on investment.

I think Scala could make inroads in another way. Big companies buy smaller
companies all the time. If eventually enough small companies are ingested
that are using Scala, the base make up of the big company changes. Big
companies also go with proven advantages from vendors or open source, but
they typically do not make big risky bets, and they only change tooling and
paradigms when competition forces change.
There's also ingestion in the small - great libraries.

But this would take a long time, and I suspect great progress is not happing
in this direction. Why? I'm not sure, but I don't see a great migration in
open source to replace Java for enterprise tooling with Scala (I am aware of
the contributions flowing from startups). I do not see dozens of Apache
projects banging out new libraries and Java Enterprise API implementations
using Scala, even where they are small, lightweight subsets like JAXB and
JAX-RS. So something is amiss with the value proposition of Scala, such
that it is not getting ingested by the Java ecosystem in the small. There
is some progress, but not as much as I thought there would be at the
"Apache" level.

How about in the large? The Big Data Stack is the next big thing, and it
has been incubating on the JVM almost as long as Scala has, yet I see very
little to no influence by Scala. If Scala is such a great productive
language, why are not all the new tools around the Big Data Stack and pieces
of the Big Data Stack written in Scala? Again, I'm just not sure why this
didn't happen, just that it appears not to be, and thus ingestion as a
mechanism to break out appears not to be happening.

Then there is the operational requirements of big enterprise. How do we
constrain Scala for Enterprise? Enterprises follow a model that is the
opposite of Academia in terms of the composition and use of labor (many cogs
following directed, repeatable process to generate globally usable artifacts
vs Acadmia's accretion of new knowledge using search and investigation to
generate narrow use artifacts.) How would you get 10,000 or maybe 1000
developers or 100 or 10 to follow an approved subset of the language?
Trust? Ugh. Scala has turing complete type system (side stepping
tractability issues) - amazing for research and exploration of the possible
- not so good for 9 to 5 coder who might be proficient in 2004-2008 era Java
writing code that any of those other 10,000 devs must be able to read and
modify.

I used to think Scala was going to crack the enterprise by 2009-2010 (been
an avid follower since 2007). Then the great collection rewrite showed us
that type abstraction in Scala would allow us to do things more correctly
and keep type safety. However that type safety had a cost and the
collection API is now non-navigable or extendable by new users. How do we
make the same kinds of jumps in usability abstraction?

In many ways Scala's direction appears to be the antithesis of big
enterprise tooling. But, every consumer having a ubiquitous computing
device that is always connected in their hand is forcing big enterprises to
increase capabilities or lose their relationship with those customers. This
is an opportunity for Scala, but maybe not the Scala we all know and love.
Maybe it is time to evaluate a Scala "light"?

Scala's hypothesis of a scalable language fusing FP and OO was and continues
to be needed (thanks Martin), but what has been learned here can certainly
feed into a subset language that leverages Scala, but answers another
hypothesis: How do we bridge a scalable language to a constrained
environment to deliver value to the masses that don't grok type theory,
category theory/abstract algebra, and that don't have much time to learn
anything that does not fit their current analogies or at least have obvious,
predictable value model? I used to think DSLs were the vehicle by which
Scala would crack into the enterprise.
While they are targeted, and offer high levels of productivity - in the end
they require you must understand all of Scala to extend, grow, and therefore
require passing the enterprise test before they can be used to bring the
language in.

Is working with the constrained big enterprise something the Scala community
even wants to solve? It cuts into resources and that cuts into all the
great edge problems Scala allows us to interact with.
You could think of Scala as an incubator - somewhere between edge research
and somewhere between getting real stuff done at tomorrows big companies
(startups). These environments have a great deal in common, and it isn't
surprising Scala can thrive there. But enterprise is a re-think if you want
to target them. I don't think providing more documentation or a flawless
GUI based environment solves the problem outright. Imagine one small team
using modern day fighter jet fighter for missions. The training, the
documentation, the hours to effectively use it are unreal so you have to be
a top student - but the result is very capable, fast, and far reaching
instrument a handful can use. Well, enterprises are more like big
battleships. slow to turn. lots of hands on deck taking orders in a
hierarchy to accomplish things. Sure battleships might have some cool
bolt-on technology, and some really smart people on board (and even more
9-5er types). But, I don't think providing more doc, training, or a
flawless heads up display will turn battleship hands into jet fighter
pilots, let alone battleships into aircraft carriers. Maybe it is time to
reframe the problem.

Just some food for thought on this issue.

Kind Regards,

Jim Herber

Am Donnerstag, 10. November 2011, 14:08:48 schrieb Daniel Sobral:
> On Thu, Nov 10, 2011 at 10:31, Geir Hedemark
wrote:
> > On 2011, Nov 10, at 1:22 PM, bryan hunt wrote:
> >>> is in some little lines. I really would *love* to convert the sysadmin
> >>> I work with to use it as possible replacement of perl or python (or
> >>> bash), but for now, the lauching time are killing that possibility.
> >>
> >> System administrators, in general, have rather particular
> >> requirements.
> >
> > System administrators, in general, are not developers. They need a
> > different toolset than us devvie guys do. I don't think it is possible
> > to build a tool that does both well.
> >
> > I would love to be proven wrong on this one, tough.
>
> Ruby and Python were born as system administration scripting
> languages, as far as I know. I do know that my first contact with Ruby
> was in such a role. And I think it is undeniable that Perl is the
> ultimate system administrator tool. :-)
>

I find myself using scala for "ad hoc" scripting more and more.
Speed aside (that's not the point for "ad hoc" usage) I find scala REPL
sessions SO MUCH MORE convenient than perl fuzzing.

The typical: I have to repeat this stupid thing now 1374 times - I could do it
manually - spending 2 days effort and producing lapse of concentration errors
on every ~100'th repeat.

Or I could do it perl - writing that thing from scratch for one-time-use.
Sprinkling around all kind of debug prints and data::dumper because I know it
won't work the first time... but at least it would be done considerably faster
in the end.

Or I could delegate it to a colleage who would try to get it done with Excel.

Or I can use the REPL and "find my way" interactively. And in the end I can
copy the "valuable" statements together (while the work is already done)
sprinkle some object { def main...} around it - a little polishing et voila:
another small script tool as jump-starter for the next similar problem.
And I'm getting it faster done than with perl.

And no: I don't think about types, monoids, monads, functors et al. in this
context. "It simply happens"...

Scala isn't always complex ;-)

And to satisfy the thread:

* more advertisment / good advertisment
Scala has many things to offer - we have just to show it...

Greetings
Bernd

Hey - I like that "find my way interactively" - you could look at the
scripster: http://github.com/razie/scripster for administration of
java/scala-based server apps. That is its main objective - it's basically an
embeddable REPL session, with content assist, over the web or telnet.

I built it specifically so people can "find their way interactively" through
an application's admin objects, like say...

runtime.adapters.map (_.reconnect)

what's more, it has an embedded "quoting" ability (like a gist/pastie) so
you can easily send runnable admin scripts around...

So - scala should succeed in the enterprise for admins ! :) Given its DSL
capabilities and with something like the scripster, how can it be
out-featured?

cheers,
Razie

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of Bernd Johannes
Sent: November-10-11 3:11 PM
To: scala-user@listes.epfl.ch
Cc: Daniel Sobral; Geir Hedemark; bryan hunt; scala-user
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed
in corporate world (Should be in scala-debate?) ?

Am Donnerstag, 10. November 2011, 14:08:48 schrieb Daniel Sobral:
> On Thu, Nov 10, 2011 at 10:31, Geir Hedemark
wrote:
> > On 2011, Nov 10, at 1:22 PM, bryan hunt wrote:
> >>> is in some little lines. I really would *love* to convert the
> >>> sysadmin I work with to use it as possible replacement of perl or
> >>> python (or bash), but for now, the lauching time are killing that
possibility.
> >>
> >> System administrators, in general, have rather particular
> >> requirements.
> >
> > System administrators, in general, are not developers. They need a
> > different toolset than us devvie guys do. I don't think it is
> > possible to build a tool that does both well.
> >
> > I would love to be proven wrong on this one, tough.
>
> Ruby and Python were born as system administration scripting
> languages, as far as I know. I do know that my first contact with Ruby
> was in such a role. And I think it is undeniable that Perl is the
> ultimate system administrator tool. :-)
>

I find myself using scala for "ad hoc" scripting more and more.
Speed aside (that's not the point for "ad hoc" usage) I find scala REPL
sessions SO MUCH MORE convenient than perl fuzzing.

The typical: I have to repeat this stupid thing now 1374 times - I could do
it manually - spending 2 days effort and producing lapse of concentration
errors on every ~100'th repeat.

Or I could do it perl - writing that thing from scratch for one-time-use.
Sprinkling around all kind of debug prints and data::dumper because I know
it won't work the first time... but at least it would be done considerably
faster in the end.

Or I could delegate it to a colleage who would try to get it done with
Excel.

Or I can use the REPL and "find my way" interactively. And in the end I can
copy the "valuable" statements together (while the work is already done)
sprinkle some object { def main...} around it - a little polishing et voila:

another small script tool as jump-starter for the next similar problem.
And I'm getting it faster done than with perl.

And no: I don't think about types, monoids, monads, functors et al. in this
context. "It simply happens"...

Scala isn't always complex ;-)

And to satisfy the thread:

* more advertisment / good advertisment
Scala has many things to offer - we have just to show it...

Greetings
Bernd

Hi Jordi,

I can certainly feel your pain. I have more than 100 issues in the tracker myself. But do I think Scala is “not ready for the industry at large” because of that? No, because it is pretty much what software engineering is in the end.
The only issue-free software is the one not in use anymore. I don't know from which language do you come from, but in my experience it is pretty much the same with Java (with the difference that bugs in Scala are handled much more transparently and the developers are much more responsive).

You can still crash the Java compiler quite easily, but is this a reason why Java shouldn't be used in industry? IMHO, no.

Keep up your great work and thank you for filing the bugs!

Simon

> I find myself using scala for "ad hoc" scripting more and more.
> Speed aside (that's not the point for "ad hoc" usage) I find scala REPL
> sessions SO MUCH MORE convenient than perl fuzzing.
>
> The typical: I have to repeat this stupid thing now 1374 times - I
> could do it
> manually - spending 2 days effort and producing lapse of concentration
> errors
> on every ~100'th repeat.
>
> Or I could do it perl - writing that thing from scratch for one-time-
> use.

[...]

> And no: I don't think about types, monoids, monads, functors et al. in
> this context. "It simply happens"...

Well, in my company we once introduced Groovy and made
good experience, because it has been easily adapted by
different people, allowing for easy embedding (GroovyConsole e.g.)
and fast RAD and scripting tasks.

Trying to push Scala as a replacement in this area here
would be absolutely void.

So even when trying to avoid a term like "language war", one has
to face the question "why not Groovy" one time.
(I indeed had recently.) But there is so much debate over
Scala vs. Java, that this question is silently avoided.

Regarding the original topic: I don't think that this area
adds to it. In general, scripting in Scala is possible, but
not its main selling point (IMO).

KR
Det

On 09/11/2011 23:30, Francois Armand wrote:

> A "Scala Cookbook" could be intersting, but I would much more prefer a
> repository of Scala scripts, if they were usable for real.

I'd find this useful too. I'd also be happy to contribute - for example
at the moment I'm writing a simple stand-alone J2EE servlet that allows
you to browse Mercurial history without running 'hg serve' for each
repo. Part of that involves parsing XML via a pipe and processing the
resulting scala.xml.Document - not rocket science but there's a couple
of bits that took some hunting around and reading of the library source
to figure out - for example the fact that BufferedSource sometimes
scribbles on stderr and that ProcessIO leaks file descriptors.

My concern is that I'm still learning Scala so I'm not sure my code is
exactly 'Best Scala Practice'. If such a script repository was set up I
think there'd need to be some vetting process for the content. Ideally
it would be possible to annotate the scripts with comments and
suggestions - for people learning Functional concepts, "why" is every
bit as important as "how".

On Thu, Nov 10, 2011 at 9:24 AM, jherber wrote:
> In a big company, it is not uncommon to find millions of lines of code
> written in Java, with huge chunks of it pre generics.

(replying on scala-debate, not scala-user; I hope others will follow)

In 2050, when you and I are dead or our beards are long and gray, all
that Java code will still be Java and still maintained, just as today
in 2011 millions of lines of COBOL and Fortran code from decades past
is still with us.

Java is too big to fail. It's normal and not something Scala should be
wringing its hands over. We should look for opportunities where they
exist. Gradually Java will fade and new languages will grow. Let's
find fresh soil to grow in and not to be too obsessed with pulling up
existing plants.

(I'm agreeing, not disagreeing.)

tid: 9 status: 1 Iulian,
re: 2.9.1 support for Eclipse
I saw that announced the other day and was very pleased.
re: Eclipse versus ENSIME
I think there are two big differences between Eclipse and ENSIME in the way they work.  First, in ENSIME the presentation compiler runs in a separate process.  This means that if it hangs, spends a bunch of time thinking, consumes a massive amount of heap space, or whatever, the editor keeps on working.  This also helps if you happen to be running a 32bit OS the standard desktop where I work is 32 bit XP, right now using anything else requires giving things up) splitting the two processes helps because the presentation compiler can have all the memory.  Second, the in ENSIME you request autocompletion by hitting tab, as opposed to it automatically triggering based on some delay.  So Eclipse tries to autocomplete much more frequently than ENSIME does, and when ENSIME does it you really want it to do it.
The last version of the Eclipse plugin I tried at work was a 2.9.2 beta build maybe three weeks ago and it just didn't work (note - I could only give it a 900MB heap), and I didn't want to be using a pre-release version of Scala, anyway.  The last build I tried at home on my Mac was a 2.8.1 build a few months ago.  It ran ok because it had enough memory, but autocomplete was still pretty slow (my Mac is getting more than a little long in the tooth) and I had to exit periodically because it seemed to keep on using more and more memory and eventually appeared to spend all its time running GC. -Erik

On 05/11/2011 22:51, Ken McDonald wrote:
> [....]
>
> The question is simple: List, in descending order of priority, what
> you feel needs to be addressed/fixed/whatever for Scala to succeed in
> the corporate (and hence IMHO ultimately the "real") world.
>
[...]

I just get the feedback of a (experience and good) Java programmer with
his first hours of Scala. His main problems were:

#1 (and a big 'one') : Binary (un)compatibility.

That one is just complettly unexpected for a Java user, and so it tooks
a rather long time for him to understand that most of his problems were
due to that point.
Just to be clear: he wasn't even aware that there might be some issues
of that kind in Scala - Java really comes with bad habbits ;)

The good news is that that one should be rather easy to correct, at
least for the 'awarness' issue: just make a lot of documentation and
warning all around the internet until it's known and expected that you
have to be carefull (or more preciselly to take care) of what versions
of Scala are used in what libraries (or what you Eclipse plugin force
you to use).

#2: brittle feeling about the Eclipse plugin

Most of his problem were due to the binary compatibility issue, but
nonetheless, the Eclipse plugin seems to give a bad feeling to
newcomers. It's a combination of things: performance (slow completion,
memory used, etc), bugs, bad (or not fisrt-class) integration with other
tools like SBT, etc.

That were his two main concerns, the first one being the worst - because
it really was unexpected for a Java-dev, and make nothing works,
sometimes in really strange ways.

Thanks,

If the scala/Java world wasn't pretty much standardized on sbt/Maven, maybe the binary compatibility would be an issue but I fail to see how that is a (big?) problem, especially starting with scala 2.9

Cant stop wondering How on earth he found that as an issue during his first hours of playing with the language?

I also can't stop but notice he had NO issues with the language itself ??

Thanks,
Razvan

On 2011-11-11, at 9:31 AM, Francois wrote:

> On 05/11/2011 22:51, Ken McDonald wrote:
>> [....]
>>
>> The question is simple: List, in descending order of priority, what you feel needs to be addressed/fixed/whatever for Scala to succeed in the corporate (and hence IMHO ultimately the "real") world.
>>
> [...]
>
>
> I just get the feedback of a (experience and good) Java programmer with his first hours of Scala. His main problems were:
>
> #1 (and a big 'one') : Binary (un)compatibility.
>
> That one is just complettly unexpected for a Java user, and so it tooks a rather long time for him to understand that most of his problems were due to that point.
> Just to be clear: he wasn't even aware that there might be some issues of that kind in Scala - Java really comes with bad habbits ;)
>
> The good news is that that one should be rather easy to correct, at least for the 'awarness' issue: just make a lot of documentation and warning all around the internet until it's known and expected that you have to be carefull (or more preciselly to take care) of what versions of Scala are used in what libraries (or what you Eclipse plugin force you to use).
>
>
> #2: brittle feeling about the Eclipse plugin
>
> Most of his problem were due to the binary compatibility issue, but nonetheless, the Eclipse plugin seems to give a bad feeling to newcomers. It's a combination of things: performance (slow completion, memory used, etc), bugs, bad (or not fisrt-class) integration with other tools like SBT, etc.
>
> That were his two main concerns, the first one being the worst - because it really was unexpected for a Java-dev, and make nothing works, sometimes in really strange ways.
>
> Thanks,
>

Seth,

although I haven't followed the original thread, i fundamentally agree
with your thoughts!

corporate world (taking a guess on what the original thread may have
been) - i guess from my personal perspective, byte code compatibility
between releases sounds pretty important. I know its a double edged
sword, but if I were to start using scala full scale, there would be
locally reusable components created that I won't want to recompile
every time a consuming project looks at upgrading scala version. But
like I said, that's just my personal opinion.

the other big thing, IMHO, is developer productivity - at the moment,
the learning curve to writing *quality code* in scala seems to be too
steep (as compared to for example RoR). Anything done to address that
would, IMHO, lead to better adoption.

Best regards
Aishwarya

On Nov 11, 6:24 pm, Seth Tisue wrote:
> On Thu, Nov 10, 2011 at 9:24 AM, jherber wrote:
> > In a big company, it is not uncommon to find millions of lines of code
> > written in Java, with huge chunks of it pre generics.
>
> (replying on scala-debate, not scala-user; I hope others will follow)
>
> In 2050, when you and I are dead or our beards are long and gray, all
> that Java code will still be Java and still maintained, just as today
> in 2011 millions of lines of COBOL and Fortran code from decades past
> is still with us.
>
> Java is too big to fail. It's normal and not something Scala should be
> wringing its hands over. We should look for opportunities where they
> exist. Gradually Java will fade and new languages will grow. Let's
> find fresh soil to grow in and not to be too obsessed with pulling up
> existing plants.
>
> (I'm agreeing, not disagreeing.)
>
> --
> Seth Tisue | Northwestern University |http://tisue.net
> lead developer, NetLogo:http://ccl.northwestern.edu/netlogo/

On Fri, Nov 11, 2011 at 8:55 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

 Second, the in ENSIME you request autocompletion by hitting tab, as opposed to it automatically triggering based on some delay.  So Eclipse tries to autocomplete much more frequently than ENSIME does, and when ENSIME does it you really want it to do it.

That's just a setting. Open Preferences, go to Java / Editor / Content Assist, disable auto activation.

On 11/11/2011 16:21, Razvan Cojocaru wrote:
> If the scala/Java world wasn't pretty much standardized on sbt/Maven, maybe the binary compatibility would be an issue but I fail to see how that is a (big?) problem, especially starting with scala 2.9
>
> Cant stop wondering How on earth he found that as an issue during his first hours of playing with the language?

Simple : download Play! framework, use sbt:eclipse, then use eclipse
IDE. But Play! was built for Scala 2.8, and Scala IDE came with 2.9.

One comment regarding feedback I have received when introducingScala to my colleagues.  The phrases "pimp my library" and "pimp" are distinctly notamenable to corporate culture.  Not only is this offensive to some, but also,it shows a level of immaturity that some extend to the language as a whole.
Anyway, Please do keep up the great work with Scala.  marc

On Fri, Nov 11, 2011 at 07:41, Alan Burlison wrote:
> On 09/11/2011 23:30, Francois Armand wrote:
>
>> A "Scala Cookbook" could be intersting, but I would much more prefer a
>> repository of Scala scripts, if they were usable for real.
>
> I'd find this useful too.  I'd also be happy to contribute - for example at

It is VERY easy to contribute stuff to docs.scala-lang.com, through
the http://github.com/scala/scala.github.com repository. The syntax is
just wiki style, with just a small header you can almost copy&paste
from other files. For example:

---
layout: overview
title: Handling nulls

disqus: true
---

## Introduction

Instead of writing

if (o != null) { return func(o); } else { return somethingElse(); }

write

Option(o) map (func) getOrElse (somethingElse())

**DON'T DO THIS**

val x = Option(o)
if (o.nonEmpty) func(o.get) else somethingElse()

There. Put this in a file on the "tutorials" directory, and you'll
have made a page with a title, code with syntax highlighting, and some
bold text.

> the moment I'm writing a simple stand-alone J2EE servlet that allows you to
> browse Mercurial history without running 'hg serve' for each repo.  Part of
> that involves parsing XML via a pipe and processing the resulting
> scala.xml.Document - not rocket science but there's a couple of bits that
> took some hunting around and reading of the library source to figure out -
> for example the fact that BufferedSource sometimes scribbles on stderr and
> that ProcessIO leaks file descriptors.
>
> My concern is that I'm still learning Scala so I'm not sure my code is
> exactly 'Best Scala Practice'.  If such a script repository was set up I
> think there'd need to be some vetting process for the content.  Ideally it
> would be possible to annotate the scripts with comments and suggestions -
> for people learning Functional concepts, "why" is every bit as important as
> "how".
>
> --
> Alan Burlison
> --
>

> and Scala IDE came with 2.9.

For the record, the Scala IDE supports both 2.8 and 2.9.

http://download.scala-ide.org/releases-28/stable/site
http://download.scala-ide.org/releases-29/stable/site

On 11/11/2011 21:55, Mirco Dotta wrote:
>> and Scala IDE came with 2.9.
> For the record, the Scala IDE supports both 2.8 and 2.9.
>
> http://download.scala-ide.org/releases-28/stable/site
> http://download.scala-ide.org/releases-29/stable/site

I do know that, as I think any Scalaiste more than some days old do.
What I wanted to report is that complettly newcomers, especially Java
one, it was a surprise to have to care about binary compatibility
between Scala version.

Well, and it was just a report, I don't want to have to argue against
fact. You can take care of them of not, it was just to contribute what
might be an "highest priority for Scala to succeed in corporate world".

Thanks,

Am Freitag, 11. November 2011, 08:48:36 schrieb Detering Dirk:
> > I find myself using scala for "ad hoc" scripting more and more.
> > Speed aside (that's not the point for "ad hoc" usage) I find scala REPL
> > sessions SO MUCH MORE convenient than perl fuzzing.
> >
> > The typical: I have to repeat this stupid thing now 1374 times - I
> > could do it
> > manually - spending 2 days effort and producing lapse of concentration
> > errors
> > on every ~100'th repeat.
> >
> > Or I could do it perl - writing that thing from scratch for one-time-
> > use.
>
> [...]
>
> > And no: I don't think about types, monoids, monads, functors et al. in
> > this context. "It simply happens"...
>
> Well, in my company we once introduced Groovy and made
> good experience, because it has been easily adapted by
> different people, allowing for easy embedding (GroovyConsole e.g.)
> and fast RAD and scripting tasks.
>
> Trying to push Scala as a replacement in this area here
> would be absolutely void.

I wouldn't try to push it - it's just natural to me (as a Groovy dyslexical)
to use Scala for scripting as this is possible.

The reasoning isn't: "scala is great for scripting - so promote its use as
such."

It's more the other way round: I selected scala as "complement" to Java
because it was the best match for my requirements (scala and closure where the
only contender on my short list). But as I discovered how great it fits my
scripting needs I adopted it for this, too.

I wouldn't have selected scala "just for scripting" alone. Nor Groovy or
something else because I was perfectly comfortable with perl until I came to
know scala...

> Regarding the original topic: I don't think that this area
> adds to it. In general, scripting in Scala is possible, but
> not its main selling point (IMO).

I agree: scripting is not scalas main selling point. But it doesn't hurt to
remind people that it is useful for that too (read: synergy).

Greetings
Bernd

Agreed. At the same time though, everyone, java or on any other platform, always cares about version compatibility between different libraries like JUNIT or LOG4J even so why is this such an issue?

The fact that you call it "binary" is a reference to the JVM binary compatibility, which only means that you can run the compiled bytecode on the JVM, not that it will still be compatible with whatever version of the whatever library. Which is the case here.

Also, from what I understand, things got a lot better starting FROM 2.9 which is when the compiler got stable enough.

You can see why I find it amazing that that was his biggest problem! Which is not even a problem... Anymore.

Sorry, don't want to seem confrontational but I am puzzled!

Thanks,
Razvan

On 2011-11-11, at 4:27 PM, Francois wrote:

> On 11/11/2011 21:55, Mirco Dotta wrote:
>>> and Scala IDE came with 2.9.
>> For the record, the Scala IDE supports both 2.8 and 2.9.
>>
>> http://download.scala-ide.org/releases-28/stable/site
>> http://download.scala-ide.org/releases-29/stable/site
>
> I do know that, as I think any Scalaiste more than some days old do. What I wanted to report is that complettly newcomers, especially Java one, it was a surprise to have to care about binary compatibility between Scala version.
>
> Well, and it was just a report, I don't want to have to argue against fact. You can take care of them of not, it was just to contribute what might be an "highest priority for Scala to succeed in corporate world".
>
> Thanks,
>

Am Freitag, 11. November 2011, 20:06:35 schrieb marc:
> One comment regarding feedback I have received when introducing
> Scala to my colleagues. The phrases "pimp my library" and "pimp" are
> distinctly not
> amenable to corporate culture. Not only is this offensive to some, but
> also,
> it shows a level of immaturity that some extend to the language as a whole.
>
> Anyway, Please do keep up the great work with Scala.
> marc

[German context - pimp is a foreign term for us]
While I don't perceive the term as offensive or immature it still has some
"aftertaste". It's associated with - well - "tribal" like blatancy and often
assigned to "lower social ranks and their patterns of macho behaviour". [It's
a prejudice - but we can't wish it away... by the way: scala is complex -
isn't it?]

For a technical audience (devs and admins) I would use it without second
thought. Developers and admins are known to use a rather hefty language.

But in any other settings I would substitute the term with something else. I
didn't have the opportunity to introduce scala to some audience yet. But I
would coin a term like "consumer driven/assigned enhancement". That's not
fancy on any scale. But it's neutral.

Greetings
Bernd

Francois, don't take it personally, I was simply reporting a fact.

Going back to binary compatibility, I think that an important step has been made: Scala minor releases
are now binary compatible.
That demonstrates the problem is (1) relevant, and (2) work is being done to mitigate it.

I agree with you when you say that a Java dev is not used to deal with binary incompatibilities, hence we
need to make his (and our!) life easier.

How can we do that? In my opinion, the first thing that is needed is a way to tell programmatically if a
library is binary incompatible wrt the used scala library (the example you reported for Play! is a perfect
use case).

Just imagine the Scala IDE issuing an error when you add in the classpath a library that is not binary compatible.
I bet that it would make binary compatibility a much simpler problem to deal with (for everyone).
But for making this real we need help from the compiler. Specifically, we need to know with what Scala version
a binary class is compiled.

An additional important aspect is improving the documentation and understanding of how to evolve Scala
code to ensure release-to-release binary compatibility. If library maintainers are given the tools to strive for
binary compatible releases, then the whole problem will simply go away.

Cheers,
Mirco

On Nov 11, 2011, at 10:27 PM, Francois wrote:

> On 11/11/2011 21:55, Mirco Dotta wrote:
>>> and Scala IDE came with 2.9.
>> For the record, the Scala IDE supports both 2.8 and 2.9.
>>
>> http://download.scala-ide.org/releases-28/stable/site
>> http://download.scala-ide.org/releases-29/stable/site
>
> I do know that, as I think any Scalaiste more than some days old do. What I wanted to report is that complettly newcomers, especially Java one, it was a surprise to have to care about binary compatibility between Scala version.
>
> Well, and it was just a report, I don't want to have to argue against fact. You can take care of them of not, it was just to contribute what might be an "highest priority for Scala to succeed in corporate world".
>
> Thanks,
>

Another thing that mitigiates the pains of binary incompatibility is
the the cross building capacity of SBT,
if I declare a dependency on, for example :

"com.weiglewilczek.slf4s" %% "slf4s" % "1.0.7"

then when I updrade scala version, things will happen painlessly,

provided that :

1) the maintainers of the libraries are quick to release their jars
when new Scala versions come out
2) the maintainers of the libraries use proper version naming scheme
to not break the magic

It's a big if, but I think most maintainers of libraries are aware of this.

Also what makes binary incompatibility less painfull for me as an
eclipse user is that I use SBT's eclipse plugin
to generate and update the project definition. My build config is the
single source of
truth in terms of versions, that are all agnostic of the Scala release.

I take the time to mention this, because I think there could be more
documentation out there
that explains the availability of a tool chain that can go a long way
in making the binary incompatibility
much more acceptable.

Right now the doc is on thres sites :

- ScalaIDE's site
- SBT's site
- SBT's eclipse plugin github page

I'm sure that most seasoned Scala devs are aware of this, but someone
starting Scala will
loose a lot of time if they don't discover this quickly.

Cheers

2011/11/11 Mirco Dotta :
> Francois, don't take it personally, I was simply reporting a fact.
>
> Going back to binary compatibility, I think that an important step has been made: Scala minor releases
> are now binary compatible.
> That demonstrates the problem is (1) relevant, and (2) work is being done to mitigate it.
>
> I agree with you when you say that a Java dev is not used to deal with binary incompatibilities, hence we
> need to make his (and our!) life easier.
>
> How can we do that? In my opinion, the first thing that is needed is a way to tell programmatically if a
> library is binary incompatible wrt the used scala library (the example you reported for Play! is a perfect
> use case).
>
> Just imagine the Scala IDE issuing an error when you add in the classpath a library that is not binary compatible.
> I bet that it would make binary compatibility a much simpler problem to deal with (for everyone).
> But for making this real we need help from the compiler. Specifically, we need to know with what Scala version
> a binary class is compiled.
>
> An additional important aspect is improving the documentation and understanding of how to evolve Scala
> code to ensure release-to-release binary compatibility. If library maintainers are given the tools to strive for
> binary compatible releases, then the whole problem will simply go away.
>
> Cheers,
>  Mirco
>
> On Nov 11, 2011, at 10:27 PM, Francois wrote:
>
>> On 11/11/2011 21:55, Mirco Dotta wrote:
>>>> and Scala IDE came with 2.9.
>>> For the record, the Scala IDE supports both 2.8 and 2.9.
>>>
>>> http://download.scala-ide.org/releases-28/stable/site
>>> http://download.scala-ide.org/releases-29/stable/site
>>
>> I do know that, as I think any Scalaiste more than some days old do. What I wanted to report is that complettly newcomers, especially Java one, it was a surprise to have to care about binary compatibility between Scala version.
>>
>> Well, and it was just a report, I don't want to have to argue against fact. You can take care of them of not, it was just to contribute what might be an "highest priority for Scala to succeed in corporate world".
>>
>> Thanks,
>>
>> --
>> Francois ARMAND
>> http://fanf42.blogspot.com
>> http://www.normation.com
>>
>
>

All there is to backwards compatibly in scala is matching the compiler version to the scala library version used to run the compiled code... Far as I can tell.

As to knowing and matching compiled versions , sbt does add the compiler version to the artifact and it also can compile and publish a few versions of the artifact already...

Use %% and insist the library dev publishes a few versions...?

Thanks,
Razvan

On 2011-11-11, at 5:41 PM, Mirco Dotta wrote:

> Francois, don't take it personally, I was simply reporting a fact.
>
> Going back to binary compatibility, I think that an important step has been made: Scala minor releases
> are now binary compatible.
> That demonstrates the problem is (1) relevant, and (2) work is being done to mitigate it.
>
> I agree with you when you say that a Java dev is not used to deal with binary incompatibilities, hence we
> need to make his (and our!) life easier.
>
> How can we do that? In my opinion, the first thing that is needed is a way to tell programmatically if a
> library is binary incompatible wrt the used scala library (the example you reported for Play! is a perfect
> use case).
>
> Just imagine the Scala IDE issuing an error when you add in the classpath a library that is not binary compatible.
> I bet that it would make binary compatibility a much simpler problem to deal with (for everyone).
> But for making this real we need help from the compiler. Specifically, we need to know with what Scala version
> a binary class is compiled.
>
> An additional important aspect is improving the documentation and understanding of how to evolve Scala
> code to ensure release-to-release binary compatibility. If library maintainers are given the tools to strive for
> binary compatible releases, then the whole problem will simply go away.
>
> Cheers,
> Mirco
>
> On Nov 11, 2011, at 10:27 PM, Francois wrote:
>
>> On 11/11/2011 21:55, Mirco Dotta wrote:
>>>> and Scala IDE came with 2.9.
>>> For the record, the Scala IDE supports both 2.8 and 2.9.
>>>
>>> http://download.scala-ide.org/releases-28/stable/site
>>> http://download.scala-ide.org/releases-29/stable/site
>>
>> I do know that, as I think any Scalaiste more than some days old do. What I wanted to report is that complettly newcomers, especially Java one, it was a surprise to have to care about binary compatibility between Scala version.
>>
>> Well, and it was just a report, I don't want to have to argue against fact. You can take care of them of not, it was just to contribute what might be an "highest priority for Scala to succeed in corporate world".
>>
>> Thanks,
>>

I'm glad someone else raised this. Call me old-fashioned if you wish,
but I certainly can't see any circumstances in which I'd use the verb
"to pimp" in formal or informal English other than to mean "to procure
prostitutes" (not that it's a frequent topic of conversation).
I can guarantee that it would incur offence in many circles. The
vitriolic way it was used on the radio today (BBC Radio 4 if you're
interested) by people working to help protect prostitutes from (often
fatal) violence assures me of that, whatever wikipedia might say about
it's use in certain corporate circles.
A poor choice of terminology that we'd be better off without IMO. Even
in the context of the "Pimp my ride" TV show it didn't have a very
positive connotation - most of the "enhancements" to the cars are
gaudy, flashy and pointless.

Tim

On 11/11/2011 23:41, Mirco Dotta wrote:
> [...]
> I agree with you when you say that a Java dev is not used to deal with binary incompatibilities, hence we
> need to make his (and our!) life easier.
>
> How can we do that? In my opinion, the first thing that is needed is a way to tell programmatically if a
> library is binary incompatible wrt the used scala library (the example you reported for Play! is a perfect
> use case).

That would be perfect. In the reported example, it would have made clear
where the errors were coming from.

But even without that, the incompability between major revision should
be made much more visible (I mean, in a "can not be ignored" fashion) on
Scala IDE page.

If that information was really blazing in the first page, new comers may
at least wonder why so much fuzz is written about different Scala
version and take about that, and that may ring a bell when some times
after, they will see libraries with different scala version on their
artifact name.

I remember that my first complexe Scala project (as in something with
Scala external libraries) implied Lift, and that I quickly become aware
of the binaries problem. That was on Scala 2.6 series, so we don't have
all the goodness of present days to handle it, but David Pollak did make
really clear and apparent, and in a good number of ml threads and other
media that you *had* to use the same Scala version than the one Lift was
compilled with. That helps and certainly saved me some days and WTF
moments.

> Just imagine the Scala IDE issuing an error when you add in the classpath a library that is not binary compatible.
> I bet that it would make binary compatibility a much simpler problem to deal with (for everyone).
> But for making this real we need help from the compiler. Specifically, we need to know with what Scala version
> a binary class is compiled.
>
> An additional important aspect is improving the documentation and understanding of how to evolve Scala
> code to ensure release-to-release binary compatibility. If library maintainers are given the tools to strive for
> binary compatible releases, then the whole problem will simply go away.

Of course, what would be even better, but it is more looking like a more
involved, and so middle to long term solution.

Thanks,

On 11/11/2011 19:20, Daniel Sobral wrote:

> It is VERY easy to contribute stuff to docs.scala-lang.com, through

http://docs.scala-lang.org/ I believe...

> the http://github.com/scala/scala.github.com repository. The syntax is
> just wiki style, with just a small header you can almost copy&paste
> from other files. For example:

I've read http://docs.scala-lang.org/contribute.html and I have a couple
of questions:

1. Is it possible to preview your new content somehow?

2. Would it be possible to set up a specific section for cookbook-style
examples on the site?

Thanks,

On Fri, Nov 11, 2011 at 22:57, Alan Burlison wrote:
> On 11/11/2011 19:20, Daniel Sobral wrote:
>
>> It is VERY easy to contribute stuff to docs.scala-lang.com, through
>
> http://docs.scala-lang.org/ I believe...
>
>> the http://github.com/scala/scala.github.com repository. The syntax is
>> just wiki style, with just a small header you can almost copy&paste
>> from other files. For example:
>
> I've read http://docs.scala-lang.org/contribute.html and I have a couple of
> questions:
>
> 1. Is it possible to preview your new content somehow?

Very easily. See the README on the github page -- you need to install
ruby gems and then use it to install jekyll -- assuming neither is
available. I agree this information could be at least linked to from
the contribute page you mentioned. That's something to contribute
already there. :-)

> 2. Would it be possible to set up a specific section for cookbook-style
>   examples on the site?

The site is just starting. Everything is possible, but it is better to
add content to some place that might not be best and then move
everything latter than wait for all the proper sections and layout to
be done. See, for instance, the FAQ I added to tutorial -- definitely
not the place for a FAQ, but it's better than nothing for now. Also,
my initial contribution had serious formatting problems, which Heather
kindly fixed.

On 12/11/2011 04:36, Daniel Sobral wrote:
>>> the http://github.com/scala/scala.github.com repository. The syntax is
>
> Very easily. See the README on the github page -- you need to install
> ruby gems and then use it to install jekyll -- assuming neither is
> available. I agree this information could be at least linked to from

Uh. So if you spot a typo and want to fix it, a Windows user have to
download and install Git, Ruby, Ruby Gems then Jekyll.
Suddenly, I see some value in Web-based applications... :-)

Git, OK, I already have it as it is useful to grab and update some open
source projects. But for the tooling, I wonder why it doesn't use
Scala-based software... :-P

It isn't a major problem, but needing to install lot of stuff just to
contribute something (and probably to register to GitHub as well?) can
be quite a high barrier for an occasional contributor, discouraging many.
I know that sometime I come across a project (freeware, open source) and
I want to mention an issue or two, without having the intent to get more
involved. If I have to register somewhere (forum...), I just go away: I
am already registered in too many places, including a good number I
already forgot...
(Now, Scala isn't a fix & forget product, you have to get involved in it
to be able to contribute something. Just saying...)

It is not a fundamental criticism of the process, which is already a big
progress with regard to nothing at all! I just point out some potential
issues.

To end on a positive note: if Ruby tools are needed only for
previsualization, one can indeed just fix what is needed, hope markup
syntax is OK, and rely on maintainer to fix formatting issue.
But still, putting up a small server with the Ruby tools where we can
paste some text with markup and see the result in the browser could be
quite useful.
Just a suggestion... :-)

On 12/11/2011 00:51, Tim Pigden wrote:
> Re: use of the verb "to pimp"

In a similar note, the "flatMap that s...t" expression that some Scala
developers affectionate [1] doesn't really offend me (although I would
raise a brow if it was used in French in front of me... :-)) as I have
heard worse [2], but it can offend other people, and doesn't seem
appropriate.
If Tony reads this, he will laugh, telling that's just words, but some
people [3] attach importance to words, seeing some as offensive.

[1] Promoting, probably with irony, flatMap to a kind of golden hammer.
Or, perhaps, a brown one...
[2] But I wouldn't use it...
[3] Can depend on age, origin, culture, social background, etc. You
don't know who read you on the Internet.

On Sat, Nov 12, 2011 at 09:37, Philippe Lhoste wrote:
> Uh. So if you spot a typo and want to fix it, ..

I don't know if this came up already in this thread, but if all you
want is to fix a typo, you can use the "Fork and edit this file"
button on GitHub.

Cheers,

Mirko

1,2,3 me to

On Sat, Nov 12, 2011 at 06:37, Philippe Lhoste wrote:
> On 12/11/2011 04:36, Daniel Sobral wrote:
>>>>
>>>> the http://github.com/scala/scala.github.com repository. The syntax is
>>
>> Very easily. See the README on the github page -- you need to install
>> ruby gems and then use it to install jekyll -- assuming neither is
>> available. I agree this information could be at least linked to from
>
> Uh. So if you spot a typo and want to fix it, a Windows user have to
> download and install Git, Ruby, Ruby Gems then Jekyll.
> Suddenly, I see some value in Web-based applications... :-)

Well, if you are crippled... ;-)

I see your point, but installing Ruby is pretty easy. I have never
installed Gems on Windows, but I don't expect it to be hard. And using
gem to install Jekyll is trivial.

HOWEVER, if all you want is to fix a typo, there's still hope!

As it happens, Github supports markdown. I don't know if it supports
the full Maruku extensions, but you can get at least an approximation
by just visualizing the file on github.

AND, you can fork the project on github (you'd need to do that
anyway), and EDIT the file on github itself! Github even provides
limited syntax highlighting of markdown elements.

So, in fact, if all you want is to submit small corrections, all you
need is a browser.

See? I told you it was easy to contribute to it. :-)

>
> Git, OK, I already have it as it is useful to grab and update some open
> source projects. But for the tooling, I wonder why it doesn't use
> Scala-based software... :-P
>
> It isn't a major problem, but needing to install lot of stuff just to
> contribute something (and probably to register to GitHub as well?) can be

You do need to register to github. Of course, you could simply open an
issue with the contribution, but that would but a very high bar on
getting your contributions committed, and you'd still need to
register. Besides, you need to register to github only once, and then
you'll be able to contribute to thousands of different open source
projects, besides having a place to put your own projects and
snippets.

> quite a high barrier for an occasional contributor, discouraging many.
> I know that sometime I come across a project (freeware, open source) and I
> want to mention an issue or two, without having the intent to get more
> involved. If I have to register somewhere (forum...), I just go away: I am
> already registered in too many places, including a good number I already
> forgot...
> (Now, Scala isn't a fix & forget product, you have to get involved in it to
> be able to contribute something. Just saying...)
>
> It is not a fundamental criticism of the process, which is already a big
> progress with regard to nothing at all! I just point out some potential
> issues.
>
> To end on a positive note: if Ruby tools are needed only for
> previsualization, one can indeed just fix what is needed, hope markup syntax
> is OK, and rely on maintainer to fix formatting issue.
> But still, putting up a small server with the Ruby tools where we can paste
> some text with markup and see the result in the browser could be quite
> useful.
> Just a suggestion... :-)
>
> --
> Philippe Lhoste

On 12/11/2011, Daniel Sobral wrote:
> On Fri, Nov 11, 2011 at 22:57, Alan Burlison
> wrote:
>> On 11/11/2011 19:20, Daniel Sobral wrote:
>>
>>> It is VERY easy to contribute stuff to docs.scala-lang.com, through
>>
>> http://docs.scala-lang.org/ I believe...
>>
>>> the http://github.com/scala/scala.github.com repository. The syntax is
>>> just wiki style, with just a small header you can almost copy&paste
>>> from other files. For example:
>>
>> I've read http://docs.scala-lang.org/contribute.html and I have a couple
>> of
>> questions:
>>
>> 1. Is it possible to preview your new content somehow?
>
> Very easily. See the README on the github page -- you need to install
> ruby gems and then use it to install jekyll

Very easy is: 1. load this url 2. type in this text area 3. done.
Very east is not: 1. pick platform-specific instruction list. 2.
Install applications x,y,z. 3. Edit stuff locally and then invoke
magical incantations to do something with it.

Come on people! In the age of google docs, AWS and wikipedia, we
should be able to do better at 'very easy' than this.

Matthew

>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.
Not too long ago, I would have said this is incorrect, because Scala can be used at 90% productivity while being no more complex than Java. My attitude was changed by the aforementioned articles, plus some recent experience with collections.breakOut.
1) The obvious: Scala can be used as great advantage without undue complexity. However, there will always be people in an organization who are capable of using the more complex features, and ultimately do so regardless of coding guidelines. They will leave behind them code that the standard programmer, or even another advanced programmer who took a different tack in the Scala ecosphere, are simply unable to maintain. This is simply death to a large organization; much as we would like to think of ourselves as uniquely talented individuals, they _must_ have interchangeable engineers in order to continue their existence.
2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one feature does not "overlap" another feature, so each additional feature multiplies the abilities of Scala by the number of its possible states. Java is not so orthogonal, so let's say that each feature adds to the abilities of Java by the number of its position in the feature sequence. Let's assume that each language has five "features", each of which may be "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by contract, has 1+2+3+4+5. The counterargument to this is that you can understand entire swaths of the Scala feature set by understanding a single concept. This is theoretically true, but realistically invalid. For example, I placed in the upper part of the top 1% of the GREs when I took them, and I don't understand a freakin' thing about scalaz, plus my understanding of implicit parameters is coming along very slowly. I'm sure that many of you are brighter than I, but consider the target; the Enterprise programmer. They are not even in my IQ range, let alone yours. (No offense to EP programmers out there. I've appreciated other people's well-written, non fancy code, as opposed to brilliant, impenetrable code, many times in my career. And to be honest, you almost certainly have a much more successful personal life than I do.)
3) Least obvious: more power =/= more productivity. So the Scala type system is Turing complete, great. How many think this is important? How many think this should be used in code? How many think this is, net, a gain? I'm hoping the answer is well under 5% in each case. This is a bit of a rehash of (2) above, but not completely. Scala has a lot of features. To be honest, it has _enough_ features for the time being, unless new features can simplify it.
How to handle this situation in the Enterprise? One previous post mentioned "Scala Lite", but did not elaborate. I think it's time to consider the possibility of optionally "feature-restricting" Scala so that the Enterprise can ensure its code is at a certain level of approachability. I won't try to give a full spec here, but will give one suggestion I think makes sense: It should be possible, in the Enterprise, to disable the ability to define implicit parameters.
Other suggestions are left for other readers.

Cheers,Ken

Re "to pimp", "map that sh!t", etc.
Agreed 100% with readers protesting this use of the language. It's just another example of the middle/upper class trying to be "cool" by appropriating mannerisms of the (often criminal) lower class. Tattoos I'm OK with now that they've become part of the cultural mainstream and are sometimes even artistic (But boy, are they going to look awful on a saggy 70-year old). The language doesn't make the cut, guys.
Ken

I should add that it is not the profanity that I have a problem with, if you knew me you would know that I curseregularly (you can tell my happiness working with third-party code by the metric UFPM (" uttered f*cks per minute")
However, to have a core design pattern named after an absusive industry that exists solely to subjugate and profit from the exploitation of women is more than just profane, it is offensive.  

On 2011-11-14 10:43 AM, Ken McDonald wrote:
> Hello from the original poster of this article. I've had my #1
> position changed by a couple of articles including one good, long one
> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
> accepted in the Enterprise world:
>
> Scala is too complex.
>
> Not too long ago, I would have said this is incorrect, because Scala
> can be used at 90% productivity while being no more complex than Java.
> My attitude was changed by the aforementioned articles, plus some
> recent experience with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization
> who are capable of using the more complex features, and ultimately do
> so regardless of coding guidelines. They will leave behind them code
> that the standard programmer, or even another advanced programmer who
> took a different tack in the Scala ecosphere, are simply unable to
> maintain. This is simply death to a large organization; much as we
> would like to think of ourselves as uniquely talented individuals,
> they _must_ have interchangeable engineers in order to continue their
> existence.
Well articulated! Excellent point!

As a leader in establishing agreement in coding guidelines in my
organization I was frustrated by how many compromises we had to make for
individuals coding styles - I simply could not convince some people to
stop using Hungarian Notation in Java and C#. I was further frustrated
that after achieving a consensus, some developers continued to ignore
the agreed upon guidelines. In one case when I did a code review on
someone else's changes, then failed it because it did not conform to the
guidelines, they took it as a personal insult on their ability, which
led to a mess of other issues. As the software architect I am not sure
how I would manage these issues with Scala.
>
> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
> one feature does not "overlap" another feature, so each additional
> feature multiplies the abilities of Scala by the number of its
> possible states. Java is not so orthogonal, so let's say that each
> feature adds to the abilities of Java by the number of its position in
> the feature sequence. Let's assume that each language has five
> "features", each of which may be "used" or "unused". Scala has 2^5
> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
> counterargument to this is that you can understand entire swaths of
> the Scala feature set by understanding a single concept. This is
> theoretically true, but realistically invalid. For example, I placed
> in the upper part of the top 1% of the GREs when I took them, and I
> don't understand a freakin' thing about scalaz, plus my understanding
> of implicit parameters is coming along very slowly. I'm sure that many
> of you are brighter than I, but consider the target; the Enterprise
> programmer. They are not even in my IQ range, let alone yours. (No
> offense to EP programmers out there. I've appreciated other people's
> well-written, non fancy code, as opposed to brilliant, impenetrable
> code, many times in my career. And to be honest, you almost certainly
> have a much more successful personal life than I do.)
>
> 3) Least obvious: more power =/= more productivity. So the Scala type
> system is Turing complete, great. How many think this is important?
> How many think this should be used in code? How many think this is,
> net, a gain? I'm hoping the answer is well under 5% in each case. This
> is a bit of a rehash of (2) above, but not completely. Scala has a lot
> of features. To be honest, it has _enough_ features for the time
> being, unless new features can simplify it.
>
> How to handle this situation in the Enterprise? One previous post
> mentioned "Scala Lite", but did not elaborate. I think it's time to
> consider the possibility of optionally "feature-restricting" Scala so
> that the Enterprise can ensure its code is at a certain level of
> approachability. I won't try to give a full spec here, but will give
> one suggestion I think makes sense: It should be possible, in the
> Enterprise, to disable the ability to define implicit parameters.
Interesting Idea!
>
> Other suggestions are left for other readers.
>
>
> Cheers,
> Ken
>

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

Hear, hear.

Can anyone suggest an alternative? I've been saying things like "add
methods to a class", but that isn't exactly what's happening.

On 11/14/2011 02:12 PM, marc wrote:
> I should add that it is not the profanity that I have a problem with, if
> you knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by
> the metric UFPM (" uttered f*cks per minute")
>
> However, to have a core design pattern named after an absusive industry
> that exists solely to subjugate and profit from the exploitation of
> women is more than just profane, it is offensive.

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

iEYEARECAAYFAk7BaRwACgkQ5IyIbnMUeTvyhgCfQMSLLBAhH3veizmqVazYpGLS
OEwAn3r7aoYafwi2+vyejMmlvzf30Lu8
=Hhme
-----END PGP SIGNATURE-----

On 14/11/2011 19:43, Ken McDonald wrote:
> Hello from the original poster of this article. I've had my #1
> position changed by a couple of articles including one good, long one
> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
> accepted in the Enterprise world:
>
> Scala is too complex.
>
> Not too long ago, I would have said this is incorrect, because Scala
> can be used at 90% productivity while being no more complex than Java.
> My attitude was changed by the aforementioned articles, plus some
> recent experience with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization
> who are capable of using the more complex features, and ultimately do
> so regardless of coding guidelines. They will leave behind them code
> that the standard programmer, or even another advanced programmer who
> took a different tack in the Scala ecosphere, are simply unable to
> maintain. This is simply death to a large organization; much as we
> would like to think of ourselves as uniquely talented individuals,
> they _must_ have interchangeable engineers in order to continue their
> existence.
> [...]

This is true for absolutely all and every languages. Or if not the
language, it's its frameworks. But I believe that was said many times,
so I'm not sure that saying it one more time will change anything.
For example, I believe I'm a correct programmer. I love programming,
understanding new things, etc. I did some work with Coq to prove some
properties about memory contiguity on a compiler. I now a bunch of Java
frameworks and contributes to several. All that to bring some
credibility to the following: I *never* get struts. I *never* get
hibernate. I *never* get Java generics. For each of them, sometime I
thought I finally get them, to discover at the next corner that that
wasn't true.

So, having interchangeable engineers is just an utopy. What Java really
have for it is something like 15 years of tries and errors that refined
some convention to be accepted and well documented to the point of "you
just have to copy that, don't think". I'm sure that with the same amount
of time and exposure to interchangeable engineers, Scala will have the
same patterns.
It was a time of Java and OO was also unable to maintain. Who really
succeeded in maintaining EJB entreprise applications ? OK, and in a cost
effective way ?

That being said, we (Scala user) have certainly some work to do in
speaking about how easy is Scala, and not only how many theorical buzz
word we are able to sank on a single line. Things like the example on
https://github.com/harrah/xsbt/wiki/Scripts

Thanks,

In "Scala for the Impatient", I just call it "enriching" a library. Seems to mesh well with RichString etc.

Cheers,

Cay

On Mon, Nov 14, 2011 at 11:16 AM, Clint Gilbert <clint_gilbert@hms.harvard.edu> wrote:

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

Hear, hear.

Can anyone suggest an alternative?  I've been saying things like "add
methods to a class", but that isn't exactly what's happening.

On 11/14/2011 02:12 PM, marc wrote:
> I should add that it is not the profanity that I have a problem with, if
> you knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by
> the metric UFPM (" uttered f*cks per minute")
>
> However, to have a core design pattern named after an absusive industry
> that exists solely to subjugate and profit from the exploitation of
> women is more than just profane, it is offensive.

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

iEYEARECAAYFAk7BaRwACgkQ5IyIbnMUeTvyhgCfQMSLLBAhH3veizmqVazYpGLS
OEwAn3r7aoYafwi2+vyejMmlvzf30Lu8
=Hhme
-----END PGP SIGNATURE-----

1. Relax.
2. explain that they're not good team players
3. do not fail code reviews - doesn't work in my experience (and now yours). Use them as a tool to teach newbies the guidelines
4. if it ain't working, fire their a$$ asap and save yourself the trouble. They won't come around.

I categorize people not based on their skill, which I find largely irrelevant on its own, but rather on their cost in terms of my supervising time required to keep them on-track. Un-surprisingly, one correlates negatively with the other...
And
High-cost are the first to go... regardless of their skill. And that DID include a few 'smartsies' continuously using constructs and patterns that I repeatedly deemed much too complex/costly to maintain!

-------

@Ken

Well – somewhat agree and disagree with 1)

a) From my (extensive but in one place) EP experience, I/we have NEVER asked a lesser skilled developer to fix/maintain code written by highly skilled developers. It simply never happens. The reverse is the norm. And when you’re running out of highly skilled developers, you’re royally screwed anyways…
b) Do not put smart language constructs on the same footing with poor use of stupid languages. I have seen (and see on a daily basis) such convoluted, maintenance-proof designs and code by both above and under-average developers as to turn many a hair white. There is no freaking way that any other average developers will be able to efficiently maintain said code, in either case! Languages don't screw you - people do!
c) What can I say? Automated peer reviews should work miracles…

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Eric Kolotyluk
Sent: November-14-11 2:15 PM
To: scala-user@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

On 2011-11-14 10:43 AM, Ken McDonald wrote:
> Hello from the original poster of this article. I've had my #1
> position changed by a couple of articles including one good, long one
> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
> accepted in the Enterprise world:
>
> Scala is too complex.
>
> Not too long ago, I would have said this is incorrect, because Scala
> can be used at 90% productivity while being no more complex than Java.
> My attitude was changed by the aforementioned articles, plus some
> recent experience with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization
> who are capable of using the more complex features, and ultimately do
> so regardless of coding guidelines. They will leave behind them code
> that the standard programmer, or even another advanced programmer who
> took a different tack in the Scala ecosphere, are simply unable to
> maintain. This is simply death to a large organization; much as we
> would like to think of ourselves as uniquely talented individuals,
> they _must_ have interchangeable engineers in order to continue their
> existence.
Well articulated! Excellent point!

As a leader in establishing agreement in coding guidelines in my organization I was frustrated by how many compromises we had to make for individuals coding styles - I simply could not convince some people to stop using Hungarian Notation in Java and C#. I was further frustrated that after achieving a consensus, some developers continued to ignore the agreed upon guidelines. In one case when I did a code review on someone else's changes, then failed it because it did not conform to the guidelines, they took it as a personal insult on their ability, which led to a mess of other issues. As the software architect I am not sure how I would manage these issues with Scala.
>
> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
> one feature does not "overlap" another feature, so each additional
> feature multiplies the abilities of Scala by the number of its
> possible states. Java is not so orthogonal, so let's say that each
> feature adds to the abilities of Java by the number of its position in
> the feature sequence. Let's assume that each language has five
> "features", each of which may be "used" or "unused". Scala has 2^5
> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
> counterargument to this is that you can understand entire swaths of
> the Scala feature set by understanding a single concept. This is
> theoretically true, but realistically invalid. For example, I placed
> in the upper part of the top 1% of the GREs when I took them, and I
> don't understand a freakin' thing about scalaz, plus my understanding
> of implicit parameters is coming along very slowly. I'm sure that many
> of you are brighter than I, but consider the target; the Enterprise
> programmer. They are not even in my IQ range, let alone yours. (No
> offense to EP programmers out there. I've appreciated other people's
> well-written, non fancy code, as opposed to brilliant, impenetrable
> code, many times in my career. And to be honest, you almost certainly
> have a much more successful personal life than I do.)
>
> 3) Least obvious: more power =/= more productivity. So the Scala type
> system is Turing complete, great. How many think this is important?
> How many think this should be used in code? How many think this is,
> net, a gain? I'm hoping the answer is well under 5% in each case. This
> is a bit of a rehash of (2) above, but not completely. Scala has a lot
> of features. To be honest, it has _enough_ features for the time
> being, unless new features can simplify it.
>
> How to handle this situation in the Enterprise? One previous post
> mentioned "Scala Lite", but did not elaborate. I think it's time to
> consider the possibility of optionally "feature-restricting" Scala so
> that the Enterprise can ensure its code is at a certain level of
> approachability. I won't try to give a full spec here, but will give
> one suggestion I think makes sense: It should be possible, in the
> Enterprise, to disable the ability to define implicit parameters.
Interesting Idea!
>
> Other suggestions are left for other readers.
>
>
> Cheers,
> Ken
>

On Mon, Nov 14, 2011 at 1:43 PM, Ken McDonald <ykkenmcd@gmail.com> wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.
Not too long ago, I would have said this is incorrect, because Scala can be used at 90% productivity while being no more complex than Java. My attitude was changed by the aforementioned articles, plus some recent experience with collections.breakOut.
1) The obvious: Scala can be used as great advantage without undue complexity. However, there will always be people in an organization who are capable of using the more complex features, and ultimately do so regardless of coding guidelines. They will leave behind them code that the standard programmer, or even another advanced programmer who took a different tack in the Scala ecosphere, are simply unable to maintain. This is simply death to a large organization; much as we would like to think of ourselves as uniquely talented individuals, they _must_ have interchangeable engineers in order to continue their existence.

I don't think this is a fault of the language.  In my experience, these developers will do so regardless of what language you put in front of them.  I've seen some amazingly complex Java frameworks.  At least in Scala, many of these 'complexities' are easier to understand and less magic than annotation processors and dynamic code generation.  Luckily, most of us just use perl for personal scripting and not group projects anymore....  

2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one feature does not "overlap" another feature, so each additional feature multiplies the abilities of Scala by the number of its possible states. Java is not so orthogonal, so let's say that each feature adds to the abilities of Java by the number of its position in the feature sequence. Let's assume that each language has five "features", each of which may be "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by contract, has 1+2+3+4+5. The counterargument to this is that you can understand entire swaths of the Scala feature set by understanding a single concept. This is theoretically true, but realistically invalid. For example, I placed in the upper part of the top 1% of the GREs when I took them, and I don't understand a freakin' thing about scalaz, plus my understanding of implicit parameters is coming along very slowly. I'm sure that many of you are brighter than I, but consider the target; the Enterprise programmer. They are not even in my IQ range, let alone yours. (No offense to EP programmers out there. I've appreciated other people's well-written, non fancy code, as opposed to brilliant, impenetrable code, many times in my career. And to be honest, you almost certainly have a much more successful personal life than I do.)

Claiming that Scalaz is a reason that Scala is complex is pretty poor.  Scalaz is improving, but it has for the longest time had poor documentation and naming.  As time goes on, this has been dramatically improving.   I definitely do not see Scala as a language that's "only for the intelligent".  I do see Category theory as requiring a brain able to handle abstract concepts.  However, I've done my part to try to simplify these for average developers.  I think libraries like Scalaz, if they hope to target the mass of enterprise engineers, will improve documentation and training of the core concepts.  If they don't wish to target the mass of enterprise engineers, they won't.   Simple as that.  But I don't really see the complexity of terse Scalaz code as a sign that Scala the langauge is inherently complex.   Take someone who has never seen Spring/Hibernate before and give them no help, remove the Spring manual (just source code) and see if they can understand the spring framework.   

3) Least obvious: more power =/= more productivity. So the Scala type system is Turing complete, great. How many think this is important? How many think this should be used in code? How many think this is, net, a gain? I'm hoping the answer is well under 5% in each case. This is a bit of a rehash of (2) above, but not completely. Scala has a lot of features. To be honest, it has _enough_ features for the time being, unless new features can simplify it.
How to handle this situation in the Enterprise? One previous post mentioned "Scala Lite", but did not elaborate. I think it's time to consider the possibility of optionally "feature-restricting" Scala so that the Enterprise can ensure its code is at a certain level of approachability. I won't try to give a full spec here, but will give one suggestion I think makes sense: It should be possible, in the Enterprise, to disable the ability to define implicit parameters.

It's called "code style guidelines" and they're enforced for many different languages.   The fact that C++ has heavy usage is evidence of their effectiveness.   There are even tools that can enforce style rules, perhaps we need someone in Scala to step up with one.  

Other suggestions are left for other readers.

Cheers,Ken

time for me to join the discussion.
scala is not too complex, scala is too different from what the
enterprise world is used to. once you use scala in a way where it really
gives a productivity boost, you have to change your way of thinking,
your strategies - everything is different. if scala would be just like
java, but with java's biggest 3 flaws solved, it would be accepted more
quickly. jetbrains is trying to create such a language (kotlin). it's
pretty much java + closures + attached methods + working generics + type
inference. but not more. we'll see if that works better. my guess is it
might.

where scala and other nerd languages (by this, i mean lisp) really shine
is when you manage to put together a small team of freaks like me and
let them roam freely. being in a small team means you won't need to
restrain yourself. even if everyone brings in his own concepts, no one
is being overwhelmed by too many. once the team grows too large, it's
like a (social) flock: the slowest birds slow down the rest.

java is much better suited for big teams *because* it's a stupid
language that feels like you're coding with yours hands bound. the more
humans you add to a group, the more stupid each individual gets, even if
they all are geniuses.

Am 14.11.2011 19:43, schrieb Ken McDonald:
> Hello from the original poster of this article. I've had my #1
> position changed by a couple of articles including one good, long one
> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
> accepted in the Enterprise world:
>
> Scala is too complex.
>
> Not too long ago, I would have said this is incorrect, because Scala
> can be used at 90% productivity while being no more complex than Java.
> My attitude was changed by the aforementioned articles, plus some
> recent experience with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization
> who are capable of using the more complex features, and ultimately do
> so regardless of coding guidelines. They will leave behind them code
> that the standard programmer, or even another advanced programmer who
> took a different tack in the Scala ecosphere, are simply unable to
> maintain. This is simply death to a large organization; much as we
> would like to think of ourselves as uniquely talented individuals,
> they _must_ have interchangeable engineers in order to continue their
> existence.
>
> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
> one feature does not "overlap" another feature, so each additional
> feature multiplies the abilities of Scala by the number of its
> possible states. Java is not so orthogonal, so let's say that each
> feature adds to the abilities of Java by the number of its position in
> the feature sequence. Let's assume that each language has five
> "features", each of which may be "used" or "unused". Scala has 2^5
> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
> counterargument to this is that you can understand entire swaths of
> the Scala feature set by understanding a single concept. This is
> theoretically true, but realistically invalid. For example, I placed
> in the upper part of the top 1% of the GREs when I took them, and I
> don't understand a freakin' thing about scalaz, plus my understanding
> of implicit parameters is coming along very slowly. I'm sure that many
> of you are brighter than I, but consider the target; the Enterprise
> programmer. They are not even in my IQ range, let alone yours. (No
> offense to EP programmers out there. I've appreciated other people's
> well-written, non fancy code, as opposed to brilliant, impenetrable
> code, many times in my career. And to be honest, you almost certainly
> have a much more successful personal life than I do.)
>
> 3) Least obvious: more power =/= more productivity. So the Scala type
> system is Turing complete, great. How many think this is important?
> How many think this should be used in code? How many think this is,
> net, a gain? I'm hoping the answer is well under 5% in each case. This
> is a bit of a rehash of (2) above, but not completely. Scala has a lot
> of features. To be honest, it has _enough_ features for the time
> being, unless new features can simplify it.
>
> How to handle this situation in the Enterprise? One previous post
> mentioned "Scala Lite", but did not elaborate. I think it's time to
> consider the possibility of optionally "feature-restricting" Scala so
> that the Enterprise can ensure its code is at a certain level of
> approachability. I won't try to give a full spec here, but will give
> one suggestion I think makes sense: It should be possible, in the
> Enterprise, to disable the ability to define implicit parameters.
>
> Other suggestions are left for other readers.
>
>
> Cheers,
> Ken
>

Hello Ken,

1)
This is already TOO true for java. Look at the 'framework' mess. Are
you sure you can handle everything a advanced 'spring' user did in a
company? I'm quite certain you can't.
Secondly that is not at all a scala related problem. You don't fix
your problems by putting framework XYZ in the job requirements.
Do you consider yourself a Senior developer?
http://groups.google.com/group/javaposse/browse_thread/thread/deb82e0c7e...

2)I dont think there is anything IQ related here. What I can tell from
my experience is maybe EP P's are lazy. They go to school/Univiversity
whatever learn xyz and then they go to business. Of course they try to
use the gained knowledge as long as possible. But first thing you
should learn as school is how to reflect upon yourself and your work
style. Sure EPP's ( and i'm one of them) are 'just' tools of the
enterprise to generated value out of directions ( hopefully). But to
do so I can choose some tools on my own too.
I don't know what GRE is , and I wont google it either. But I am a
curious person since I got introduced to scala and scalaz I learned
many things. Things that ALREADY help me in my dayjob with java. My
Thinking and thus my coding style changed. I discuss those change with
my coworkers and I think there is a very healthy balance things dont
get too far off. But they are changing.

3) I don't know but i dislike the idea of 'Scala Lite'

regards andreas

On 14 Nov., 19:43, Ken McDonald wrote:
> Hello from the original poster of this article. I've had my #1 position
> changed by a couple of articles including one good, long one by Jim Herber
> (sp?). So here it is: the #1 problem with Scala being accepted in the
> Enterprise world:
>
>     Scala is too complex.
>
> Not too long ago, I would have said this is incorrect, because Scala can be
> used at 90% productivity while being no more complex than Java. My attitude
> was changed by the aforementioned articles, plus some recent experience
> with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization who are
> capable of using the more complex features, and ultimately do so regardless
> of coding guidelines. They will leave behind them code that the standard
> programmer, or even another advanced programmer who took a different tack
> in the Scala ecosphere, are simply unable to maintain. This is simply death
> to a large organization; much as we would like to think of ourselves as
> uniquely talented individuals, they _must_ have interchangeable engineers
> in order to continue their existence.
>
> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one
> feature does not "overlap" another feature, so each additional feature
> multiplies the abilities of Scala by the number of its possible states.
> Java is not so orthogonal, so let's say that each feature adds to the
> abilities of Java by the number of its position in the feature sequence.
> Let's assume that each language has five "features", each of which may be
> "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by
> contract, has 1+2+3+4+5. The counterargument to this is that you can
> understand entire swaths of the Scala feature set by understanding a single
> concept. This is theoretically true, but realistically invalid. For
> example, I placed in the upper part of the top 1% of the GREs when I took
> them, and I don't understand a freakin' thing about scalaz, plus my
> understanding of implicit parameters is coming along very slowly. I'm sure
> that many of you are brighter than I, but consider the target; the
> Enterprise programmer. They are not even in my IQ range, let alone yours.
> (No offense to EP programmers out there. I've appreciated other people's
> well-written, non fancy code, as opposed to brilliant, impenetrable code,
> many times in my career. And to be honest, you almost certainly have a much
> more successful personal life than I do.)
>
> 3) Least obvious: more power =/= more productivity. So the Scala type
> system is Turing complete, great. How many think this is important? How
> many think this should be used in code? How many think this is, net, a
> gain? I'm hoping the answer is well under 5% in each case. This is a bit of
> a rehash of (2) above, but not completely. Scala has a lot of features. To
> be honest, it has _enough_ features for the time being, unless new features
> can simplify it.
>
> How to handle this situation in the Enterprise? One previous post mentioned
> "Scala Lite", but did not elaborate. I think it's time to consider the
> possibility of optionally "feature-restricting" Scala so that the
> Enterprise can ensure its code is at a certain level of approachability. I
> won't try to give a full spec here, but will give one suggestion I think
> makes sense: It should be possible, in the Enterprise, to disable the
> ability to define implicit parameters.
>
> Other suggestions are left for other readers.
>
> Cheers,
> Ken