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

[Ken McDonald]

Even though this perhaps should be in scala-debate, I'm posting it here because:

    1) It's really very important.

    2) I've never seen a similar question posted.

This comes after reading a few of the "White elefant" posts.

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.

My list:

1. IDE Support. Scala must have rock-hard support in at least one IDE, and must have "pretty good" support in Eclipse, since it's the de facto standard. I don't think we're close yet. This alone could lose Scala the language wars.

2. Documentation. Scaladoc documentation needs to be expanded on greatly; at the same time Scaladoc itself could stand some enhancements, though exactly where is less obvious. I am complicit in this; I keep on intending to devote some serious time to enhancing scaladoc, and keep failing to do so, dangit!

3. A "Scala Cookbook". I'm amazed one isn't out or on the web already. I know, there's lots on stackoverflow and other sites but it's not the same. Scala is such a neat language, that a newcomer could easily get caught up and read for hours on a good cookbook, saying things like, "Wow, I can do it in just one line...".

And your suggestions? Recommended three or less because probably no one will read past the third one :-).

Ken

[Rex Kerr]

I think your list is exactly right; if anything I'd just emphasize the first two points.

On Sat, Nov 5, 2011 at 5:51 PM, Ken McDonald <ykke...@gmail.com> wrote:

Even though this perhaps should be in scala-debate, I'm posting it here because:

    1) It's really very important.

    2) I've never seen a similar question posted.

This comes after reading a few of the "White elefant" posts.

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.

My list:

1. IDE Support. Scala must have rock-hard support in at least one IDE, and must have "pretty good" support in Eclipse, since it's the de facto standard. I don't think we're close yet. This alone could lose Scala the language wars.

I think Scala must have rock-hard support in _most major IDEs_.  This includes both Eclipse and NetBeans; IDEA is also a good candidate since it seems pretty advanced already.  If I had to switch my IDE as _well_ as my language, that would be an additional barrier, I'd think.
 

2. Documentation. Scaladoc documentation needs to be expanded on greatly; at the same time Scaladoc itself could stand some enhancements, though exactly where is less obvious. I am complicit in this; I keep on intending to devote some serious time to enhancing scaladoc, and keep failing to do so, dangit!

Indeed.  Scala's core API should be as well documented as Java's.  I rarely find that the Java documentation says far more than I need, but I often find that it just barely says enough for me to do something useful.  In Scala, it's often several hours of poking around, looking at source code, blog posts, and StackOverflow, before I figure out something nontrivial that I haven't used before.

  --Rex

[HamsterofDeath]

all my votes go to "ide support". and a little tiny enhancement to the jvm: i want to be able to write List(1,2,3).filter(_ == 2) in my debugger

never had a problem with documentation. maybe i have magic eyes or i am a google prime customer, but i never have to search long until i find an answer.

[Matthew Pocock]

I agree with your list. I'd probably add making the core libs (particularly thinking of collections) faster and lower-memory/burn. This probably includes making specialization work (better?) and aggressively inlining away typeclasses. When performance really does matter there is no substitute for fast code. If the scaladocs are beefed up, I'd probably place performance at 3 in place of the cookbook.

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Andreas Flierl]

Hi,

Ken McDonald wrote:
> 1. IDE Support. Scala must have rock-hard support in at least one IDE, and must have "pretty good" support in Eclipse, since it's the de facto standard. I don't think we're close yet. This alone could lose Scala the language wars.

What other JVM language (Java aside) has better IDE support than Scala?

(Also, I find "language wars" a strange term.)

Kind regards
Andreas

[Tony Morris]

On 06/11/11 10:00, Andreas Flierl wrote:
> Also, I find "language wars" a strange term.

You must accept legitimacy of the idea of "language wars" in order to
succeed in a corporate environment. If you are having difficulty with
the self-deception required to adopt this illusion, try calling it "real
world" -- HTH.

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

[Erik Engbrecht]

I think you need to define what "rock-hard support" in an IDE means.  For example, the Eclipse plugin keeps on moving forward in terms of functionality, but where exactly is the version of it for Scala 2.9.1?  It also consumes a ton of memory and tends to "just sit there" a lot.  It's basically unusable in my work environment, while the version quite a while back, while buggier and with far fewer features, was usable.  I think the NetBeans plugin also took a step sideways when it integrated with the presentation compiler.  In my opinion the only really usable IDE for Scala right now is Emacs+ENSIME.  Maybe the ENSIME integrations for Vim and JEdit work well, too.  I'm fine with Emacs, but I wouldn't try to force in on anyone.

[Brian Schlining]

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.

1) The speed of the compiler.

 

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschl...@gmail.com

[Thorpe, Michael]

That basically. 

[William la Forge]

When you talk about real world, it is important that some of those very nice features of the language which are noticably slower than what a novice would expect should be de-emphasized a bit and come with a bit of a warning. Nothing wrong with using them, but some awareness of the costs of these features will save a lot of work tracking down why a piece of code is so slow and will help a lot in preventing the impression that Scala is a purely academic language.

These "nice" features then shouldn't be the first thing a Scala novice reads about, even though they demonstrate the elegance of the language.

Bill

[Michael Schmitz]

+1 rock-hard IDE support. When I developed in C# on .NET in a
corporate environment, I wanted to use F# (while it was beta) for
experimentation but the overhead of learning a new language alongside
IDE problems was too much. This also shows how hard it is to create
solid IDE integration since Microsoft controls Visual Studio and
releases both C# and F#.

I almost didn't use Scala because of how buggy ScalaIDE used to be.
It's a lot better now, but if it were as solid as Eclipse Java support
it'd be easy for someone to switch over and start adding Scala to
their projects.

Of course, rock-solid IDE support relates to the speed of the compiler!

Peace. Michael

[Eric Kolotyluk]

My humble take on things...

1. The very real fear of Scala needs to be addressed. I cannot remember when I have ever seen such a controversial programming language and there just seems to be so many "Scala is too complex" concerns raised by too many people.
   
   
2. IDE Support. I still struggle with installing new versions of Scala with Eclipse and run into obscure errors that I would never tolerate in Java. To coin a phrase from Steve Jobs, when he was creating NeXT, "it just works." Scala in the IDE has to be close to as dependable as Java in the IDE - it just has to work - no exceptions, no excuses. Troubleshooting Scala plug-in problems is a very serious turn-off and makes the technology seem like it is still an academic curiosity.
   
   
3. Every time I delve into the Scaladocs I cringe at the complexity - it makes me feel stupid, as in, I am not intelligent enough for this.
   

Cheers, Eric

[Simon Ochsenreither]

I think we really need SIQ or whatever we call it shipping as soon as possible.

Being able to say

here are the hundreds of lines of code you need to work with a database:

• you need some classes for ORM,
  
• dozens of annotations to describe the connection between them
• dozens of lines for simple type safe queries
• you need to know the quirks of Hibernate/JPA/EclipseLink and
  
• you probably still need to write SQL for more complex tasks

and here is how you do that in Scala, with a single line of code:

<example>

I think if we would have this, we have more or less won the whole enterprise stuff.

[Erik Engbrecht]

On Saturday, November 5, 2011 8:00:53 PM UTC-4, Andreas Flierl wrote:

(Also, I find "language wars" a strange term.)

A corporate environment with enough legacy (basically meaning "it's been around for a while") will almost certainly have a contingent of "defenders of the status quo" for any given technology that's had some success.  This is especially true if some influential individual(s) have linked their personal success to the success of this technology.  In a large enough environment there will likely be several of these groups, and they will fight with each other as much as with anything that's new.  On one hand this is all well and good, because change costs serious time and money, and often multiple overlapping technologies exist for a reason, so to the extent that fights stay on technical grounds they can be productive.  On the other hand, the fights often leave the rational world and exist almost entirely in the realm of politics.

A corporate environment with enough R&D investment in enabling technologies will almost certainly have one or more contingent of "evangelists of the new doodad."  Their aggressiveness will be roughly equivalent to the square of the amount of money invested in their doodad divided by the amount of success it has obtained.  On one hand this is can be productive, so long as the evangelists stick to technical grounds.  On the other hand, once a given technology has passed some degree of investment, the evangelism starts leaving the technical realm and becomes mostly political.

A "technology" could be a programming language, web framework, operating system, process, tool, semiconductor substrate, etc...

Now, the poor sap who has to actually create a product (meaning most engineers) has to contend with all these people who have opinions about what technologies he's supposed to use.  Furthermore, if he decides to toss his own competing technology into the mix because he thinks it fits his problem better than the ones associated with existing factions, he's going to face challenges from all sides.

If you're at a startup you probably don't have to worry about this much.  If you're at a Fortune 100 company (or one is your customer), you probably have more legacy hanging around than is humanly comprehendible and a fair bit of R&D, too.

If this poor sap is trying to use Scala, then he is "fighting a battle" for Scala in the "language wars."  Calling a bunch of nerds and managers arguing a "battle" in a "war" seems to involve a high amount of hyperbole, but it's a popular analogy none-the-less.

Anyway, if you're trying to use Scala, you could follow Tony's advice:

http://blog.tmorris.net/i-cannot-use-language-x/#comments

Except that I think the barriers identified in this thread represent rational reasons for not using Scala at this time, so rational objections will inevitably be mixed in with all the political nonsense.  You should also remember the Golden Rule: He who has the gold makes the rules.  Sticking to principles works pretty well so long as the funding isn't cut off, so you can dismiss the irrational objections of others so long as the person with the gold is doing the same.

Of course, if you dismiss all these objections and run with Scala, and then the project fails, you run a high risk that Scala will be blamed regardless of actual fault, and you will be blamed as the person who ignored the wisdom of others and charged ahead with an immature technology.

[HamsterofDeath]

that already exists, it's called db4o :)

[Simon Ochsenreither]

Which no one uses ...

I certainly don't want to choose a database based on the API.

[HamsterofDeath]

Am 06.11.2011 19:00, schrieb Simon Ochsenreither:
> Which no one uses ...
>
> I certainly don't want to choose a database based on the API.

you can always fall back to just saving hashmaps using an
objectoutputstream.

there is no solution which is both simple and efficient. you can have
one or the other.

[martin odersky]

On Sat, Nov 5, 2011 at 10:51 PM, Ken McDonald <ykke...@gmail.com> wrote:

Even though this perhaps should be in scala-debate, I'm posting it here because:

    1) It's really very important.

    2) I've never seen a similar question posted.

This comes after reading a few of the "White elefant" posts.

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.

My list:

Your list is pretty much spot on as far as I can tell. Here's what we (Typesafe & EPFL) are doing about it.

 

1. IDE Support. Scala must have rock-hard support in at least one IDE, and must have "pretty good" support in Eclipse, since it's the de facto standard. I don't think we're close yet. This alone could lose Scala the language wars.

Typesafe now has 3 FTEs working on the Scala Eclipse IDE, plus 2 part-timers (one of them myself). None of this is paid for by anyone. We are doing this because we think its important, and universities can't do it. It's grunt work. Have you tried a recent beta of Scala IDE 2.0? If you have serious problems we'd like to see a ticket!

Also, I realize that even with this amount of committed resources we are still moving too slowly. So if you have time & expertise to contribute, this would be hugely appreciated!

 

2. Documentation. Scaladoc documentation needs to be expanded on greatly; at the same time Scaladoc itself could stand some enhancements, though exactly where is less obvious. I am complicit in this; I keep on intending to devote some serious time to enhancing scaladoc, and keep failing to do so, dangit!

Heather Miller and Josh Suereth have recently released http://docs.scala-lang.org/. Now there's no more excuse not to contribute!

3. A "Scala Cookbook". I'm amazed one isn't out or on the web already. I know, there's lots on stackoverflow and other sites but it's not the same. Scala is such a neat language, that a newcomer could easily get caught up and read for hours on a good cookbook, saying things like, "Wow, I can do it in just one line...".

I think Cay Horstmann's excellent "Scala for the Impatient" comes close. A preprint of the first half is available for free from the typesafe.com site.

Cheers

 -- Martin

[Simon Ochsenreither]

Did you have a look at the things happening with SIQ/...?

1. One definition of the database url and the credentials
2. .fromDb
3. Use the API known from the collection stuff

That's how it should be done.

[Luc Evers]

  Hi, Ken

  Scala Cookbook , indeed a missing book.

  I should extend your list with :

  - Scala Swing book

  - Scala RIA?

       Not bad is Scala Vaadin but no real good information.

  - Scala Android developer book.

   Luc.

[Peter Walkley]

Rock solid IDE and maven support.

 

My experience so far is that the maven plugins all work absolutely fine - BUT so much emphasis (here and the lift forum) is around sbt that it is very easy to pick up the misunderstanding that you need to switch build tool.  That would be an automatic fail in many enviroments as maven is so heavily entrenched. Configuring builds is boring crap no-one wants to do twice.

 

For this reason, I'm making a deliberate point of not using sbt as I climb the scala learning curve. Should I find a bug, I'll be raising it very promptly !

 

There's some points in a similar question on linkedin that may be of relevance: Is scala the future of java

[Bastian, Mark]

IDE support is far and away #1 for me. This comes from two standpoints:

1. I like a good IDE, even though Scala has made me less IDE-dependent than I used to be since I use the repl and other iterative tools so much more than I used to.
2. Even more important, when I am trying to get other developers to adopt Scala the first thing they want is a good IDE plugin. Getting others to try out Scala requires a gentle introduction. The first thing they want to do is write Java-as-Scala in their IDE of choice, not dive into FP. From what I have seen, the Eclipse plugin has come a long way towards making this happen (good job, team).

As an aside, it seems like "better IDE support" is frequently translated as "better Eclipse support." However, it seems that many experienced Scala developers use some sort of "Glorified Code Editor"+build tool to avoid many of the Eclipse headaches and to take advantage of the great features of mvn/sbt/fsc/etc. (they all take some learning, but are more powerful the deeper you dive). Most of the time I use NetBeans as a glorified code editor with some combination of sbt and/or mvn running in a console. To this end, I would really like to see better support for the NB plugin.

Just my $0.02.

-Mark

[Peter C. Chapin]

On Mon, 2011-11-07 at 10:50 -0500, Bastian, Mark wrote:

> I use NetBeans as a glorified code editor with some combination of sbt
> and/or mvn running in a console. To this end, I would really like to
> see better support for the NB plugin.

I'm also a NetBeans user and would love to see the NetBeans plugin
continue to evolve. Yes, I know... why don't I contribute? Well, as for
many of us I just don't have the personal resources to do that right
now.

I can't wait until retirement. Then I'll be able to get some real
programming done. :)

Peter

[John Cheng]

And your suggestions? Recommended three or less because probably no one will read past the third one :-).

Ken

I strongly agree with IDE as #1. However, I am skeptical about the value of better Scala Docs. Perhaps I am a pessimist, but while I agree that better Scala Doc would be incredibly useful to me as a developer, I think it means very little to CTOs and people who are on the fence about learning Scala. 

I think organizing meet ups and sharing success stories in the development community will be key. At a recent Scala meet up in Los Angeles, I met a small group of developers who are interested in getting started with Scala, but noone with in depth knowledge and success stories. I think that can be disheartening to new developers. In this respect, I think I can only rely on companies like TypeSafe getting out and help organize more meetups in major development hubs. 

--
---
John L Cheng

[Luc Duponcheel]

about Scala RIA

maybe ScalaFX is an interesting technology to consider
http://code.google.com/p/scalafx

btw: here is ScalaFX demo that I have developed
http://code.google.com/p/scalafx/source/browse/demo/scalafx/JumpingFrogsPuzzle.scala?spec=svn280146c3b01da9dac672e9b3bfedaddb00fe7a78&r=280146c3b01da9dac672e9b3bfedaddb00fe7a78

Luc

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

[Arif Mustafa]

think Scala's weakness (with regards to its adoption in the "Enterprise") is that it never projected/marketed  itself as such... the focus has always been on esoteric topics like bloom filters, actors etc. Now if we were to divide Enterprises into two broader categories (1) Traditional Enterprises (which are against any disruption/innovation...like most major financial institutions) (b) New/Innovative Enterprises (like Facebook, Google etc) ... Scala's appeal is to the second types of Enterprises. For first type of Enterprises you need many examples like "Duke's shopping cart" ;-) ... thus showing that Scala (Like Java/JEE) can answer the needs for presentation and business tier and Web Services ... so yes ..such a book is required.

my two cents worth

cheers

[Daniel Sobral]

If only Scala were *not* being adopted in major financial
institutions, like it is, that argument would be stronger.

Alas, someone once divided financial institutions between loaning
banks and investment banks, where the first are very conservative and
the second will try anything that can give it an edge.

--
Daniel C. Sobral

I travel to the future all the time.

[Channing Walton]

On Tuesday, 8 November 2011 19:52:55 UTC, Daniel Sobral wrote:

If only Scala were *not* being adopted in major financial
institutions, like it is, that argument would be stronger.

Alas, someone once divided financial institutions between loaning
banks and investment banks, where the first are very conservative and
the second will try anything that can give it an edge.

Spot on. From what I can see, Scala is rapidly gaining traction in most major financial orgs. The devs love it and don't mind that the IDE's aren't great right now, the benefits of the language outweigh the short-term problem of good IDEs.

What needs to happen is for everyone to stop worrying about a problem that doesn't really exist.

[Kevin Wright]

For my part, I'm seeing a lot of adoption in media.  Including broadcast, papers, online gaming, social, etc, etc.

Basically, lots of people who're after an edge in being more responsive to the market than their competition, so not just investment banking :)

Banks are just more visible because they tend to pay more for support contacts, and use recruiters who are far spammier on LinkedIn and the like.

[Arif Mustafa]

@Kevin spot on... "broadcast, papers, online gaming, social, etc, etc." ...and thats where I have observed the adoption rate of Scala to be high ... and ..."Banks"  (Tradional model, who would rather pay IBM'ers and/or Tata Consultancy etc to run their IT) have low adoption rate of Scala is low.

[Jordi Salvat i Alabart]

> 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'll only list 1: reliability.

As a software development manager, I recently shied away from Scala in
a newly starting project mainly because I judged the compiler to be
unreliable.

As for IDE support, while it is very important (even essential to
attract the Java lot), it is only an absolute must because the correct/
compile/run cycle is so slow. PHP, for example, is quite successful in
spite of having extremely poor IDE/tooling support.

--
Salut,

Jordi.

[Naftoli Gugenheim]

On Tue, Nov 8, 2011 at 9:48 PM, Jordi Salvat i Alabart <jordi.salva...@gmail.com> wrote:

mainly because I judged the compiler to be
unreliable.

Why?

[Tomás Lázaro]

IDE Support would be the most important issue for me. I use Netbeans to write the code and SBT on a terminal to compile and run. I really do not want to use Eclipse, I don't like it as a whole (I don't have a problem with the Scala IDE itself). How hard would it be to have the Eclipse plugin work in Netbeans? It supports OSGI so maybe it could re-use a lot of stuff. Off course integration with the editor itself is definitely going to be different but Caoyuan has gone a long way with the Scala plugin for NB and there should be enough stuff already figured out there.

I started using Scala in the "real world" more than 3 years ago, I think 4. We had a custom server over TCP, hundreds of clients, several databases and many other legacy servers using different custom communication protocols as well as some desktop applications for internal use and for clients... all of that was done in Java. One day we discovered Scala, thought it was cool, bought the first book the day it came out and started using it right away when we noticed we could mix Scala code with our current code base without much trouble. We ended up converting most of the code to Scala and only produced new code with it. We never looked back. I don't work there anymore but they still use Scala. There is no compelling reason not to use it in the "real world".

I never had a problem with documentation or the available books regarding the language itself. I never minded googling for stuff or browsing stack overflow. I never had a problem asking questions on the mailing list either.

[jilen]

The problem with eclipse scala-ide I found
1. Performance, too much heap memory usage , too slow.
2. Syntax color, I always see only two color, that is somewhat boring.
3.Coding express is not good enough. Code completion sometimes not available.

The problem with Netbeans
1.Swing seems not work well with linux.

[martin odersky]

2011/11/9 Tomás Lázaro <tlaz...@gmail.com>

IDE Support would be the most important issue for me. I use Netbeans to write the code and SBT on a terminal to compile and run. I really do not want to use Eclipse, I don't like it as a whole (I don't have a problem with the Scala IDE itself). How hard would it be to have the Eclipse plugin work in Netbeans? It supports OSGI so maybe it could re-use a lot of stuff. Off course integration with the editor itself is definitely going to be different but Caoyuan has gone a long way with the Scala plugin for NB and there should be enough stuff already figured out there.

I think Caoyuan is already using the presentation compiler, which is at the core of the Eclipse IDE. And so is ENSIME. Hopefully it will only take minor upgrade works to the latest version to get many improvements. The other large trend is that we are going to

put more functionality out of the Eclipse SDT and into the presentation compiler. That should also help the other plugins. 

Cheers

 -- Martin

[bryan hunt]

Thomas, Wow.

Have you been using Netbeans to compile real world projects? My
experience of Scala Netbeans integration is:
The guy who was maintaining the plug-in left 2 years ago and that it
currently chokes on anything more serious than Hello World.

Scala-IDE, the Eclipse plugin while not quite there compared to
Eclipse's Java support is still WAAAEEEEY ahead of the competition.

And yes, I use IDEA for ActionScript but it's Scala support is at
best, enthusiast grade.

I say this having written an approx 30,000 LOC Scala project last year
all of which parses and compiles (slowly) using Scala-IDE and/or
Maven.

Regards,

Bryan Hunt

[Geir Hedemark]

On 2011, Nov 9, at 11:51 AM, bryan hunt wrote:
> Scala-IDE, the Eclipse plugin while not quite there compared to
> Eclipse's Java support is still WAAAEEEEY ahead of the competition.
>
> And yes, I use IDEA for ActionScript but it's Scala support is at
> best, enthusiast grade.

Oh, I dont know. My team all use intellij since last year or so. Eclipse just did not work out for us - it was too buggy.

We all seem to think intellij is good enough. So do the consultants I know around here who actively use Scala.

YMMV.

Geir

[Aleksey Nikiforov]

You may be having problem with inference. Reducing inference by annotating types can help reduce ram consumption and compilation time significantly. This is mostly true for multi-level inference that has to go through several layers of parentheses.

For example: val x = A(B(C(a, b, c)))

If the type of x is something like A[X[Y[Z]]], then you are better off declaring it: val x = A[X[Y[Z]]](B(C(a, b, c)))

It may take a bit of extra work, at least with large existing projects, but it will make everything compile in reasonable amount of time.

This problem has been fixed for command line compilations, but it still makes Eclipse IDE eat up all ram and slow down to a crawl. My guess it will be fixed in Eclipse sometime soon as well.

[iulian dragos]

On Sun, Nov 6, 2011 at 2:08 AM, Erik Engbrecht <erik.en...@gmail.com> wrote:
> I think you need to define what "rock-hard support" in an IDE means.  For
> example, the Eclipse plugin keeps on moving forward in terms of
> functionality, but where exactly is the version of it for Scala 2.9.1?

If you refer to the download page, the version number is indeed 2.9.2,
because of changes to the presentation compiler. Since the
presentation compiler is part of the compiler, we need an updated
version to take advantage of the new features. However, since
yesterday we ship with the standard 2.9.1 library, so you should not
feel any difference.

The Eclipse IDE is really low on features. We're basically focusing on
completion, hyperlinking and interactive error reporting. IntelliJ has
been a lot more active in adding new features, though, so maybe you
mixed them.

>  It
> also consumes a ton of memory and tends to "just sit there" a lot.  It's
> basically unusable in my work environment, while the version quite a while
> back, while buggier and with far fewer features, was usable.

What versions are we talking about, or when did you try Eclipse last?
This sounds really surprising, since my own experience, and most
people that cared to try Eclipse one year ago, agreed that it's much
more usable now.

>I think the
> NetBeans plugin also took a step sideways when it integrated with the
> presentation compiler.  In my opinion the only really usable IDE for Scala
> right now is Emacs+ENSIME.  Maybe the ENSIME integrations for Vim and JEdit

ENSIME uses the presentation compiler, so it can't be much better
(assuming the presentation compiler is the problem).

iulian

> work well, too.  I'm fine with Emacs, but I wouldn't try to force in on
> anyone.
>
>
>

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Peter C. Chapin]

On Wed, 2011-11-09 at 05:51 -0500, bryan hunt wrote:

> Thomas, Wow.
>
> Have you been using Netbeans to compile real world projects? My
> experience of Scala Netbeans integration is:
> The guy who was maintaining the plug-in left 2 years ago and that it
> currently chokes on anything more serious than Hello World.

I'm using NetBeans on a Scala project. It's not a huge project, but
definitely larger than "Hello, World." The Scala plugin is working fine.
It's a bit quirky but it gets the job done. I should say that I'm using
the latest version from the git repository compiled from source. The
person maintaining the plugin is still active with it, although activity
is light. The last commit was maybe a couple of months ago (I haven't
tried a pull recently though).

Peter

[Brian Schlining]

> I'm using NetBeans on a Scala project. It's not a huge project, but
> definitely larger than "Hello, World." The Scala plugin is working fine.
> It's a bit quirky but it gets the job done. I should say that I'm using
> the latest version from the git repository compiled from source.

For the curious, the git repo is https://github.com/dcaoyuan/nbscala

--
Brian Schlining

[Donald McLean]

I find this very hard to believe. The JetBrains folks have been
working steadily on their plugin and they have made tremendous
progress in features and usability. In the beginning, it's syntax
parsing was often a bit sketchy but those problems have pretty much
disappeared and all of the IDEA niceties have started showing up.

I have found that IDEA vs Eclipse is a chocolate/vanilla or
purple/green question. I've had to use Eclipse a couple of times and I
just didn't like it.

Donald

[Andreas Joseph Krogh]

Agreed.
It's not just how the IDE understands Scala itself, it's also about how the IDE integrates other features of the IDE in Scala-files/projects. IDEA is just fantastic here. My JPA-model written in Scala shows up in the "Show ER-diagram", my JPQL is highlighted correctly to give me code-completion in my JPQL working with JPA-entities written in Scala. SQL code-completion in scala-classes. Spring-integration for Scala is *almost* just as good as in JAVA. The list is long...

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.

I only have one thing which I think is important to succeed in the corporate world:
1. Binary compatibility among version-upgrades

I have another nit-picking-list though:-)
- JAVA interoperability (yes, there are cases where they don't play nicely [1][2])
- Consistent handling of "val" (finals) [3]

[1] Should be able to use JAVA-enums and other "public static final" in annotation-parameters.
[2] https://issues.scala-lang.org/browse/SI-4549
[3] http://stackoverflow.com/questions/7762838/scala-forward-references-why-does-this-code-compile

-- 
Andreas Joseph Krogh <and...@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

[Francois Armand]

Le 05/11/2011 22:51, Ken McDonald a écrit :
[...]

> 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.
>

> My list:
>
> 1. IDE Support. [...]
>
> 2. Documentation. [...]
>
> 3. A "Scala Cookbook". [...]
>

My shop list would be:

1. A compiler as fast as the java one. And a modular scala-lib. Yeah, I
now...
2. An as powerful and great library to deals with immutable data
structure modification as the collection one is for collection (lens,
zipper, etc)
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.

IDE support is reaching the point where Eclipse does not go in my way
anymore and is of real help for boring things (imports, completion of
long method names, formatting, things like that).

Documentation is OK, especially with so many books and blogs post online.

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

Cheers,

--
Francois Armand
http://fanf42.blogspot.com

[Daniel Sobral]

On Wed, Nov 9, 2011 at 21:30, Francois Armand <fan...@gmail.com> wrote:
> Le 05/11/2011 22:51, Ken McDonald a écrit :
> [...]
>>
>> 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.
>>
>> My list:
>>
>> 1. IDE Support. [...]
>>
>> 2. Documentation. [...]
>>
>> 3. A "Scala Cookbook". [...]
>>
>
>
> My shop list would be:
>
> 1. A compiler as fast as the java one. And a modular scala-lib. Yeah, I
> now...
> 2. An as powerful and great library to deals with immutable data structure
> modification as the collection one is for collection (lens, zipper, etc)
> 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.

You mean like this?

#!/usr/bin/env scalas
!#

/***
scalaVersion := "2.9.0-1"

libraryDependencies ++= Seq(
"net.databinder" %% "dispatch-twitter" % "0.8.3",
"net.databinder" %% "dispatch-http" % "0.8.3"
)
*/

import dispatch.{ json, Http, Request }
import dispatch.twitter.Search
import json.{ Js, JsObject }

def process(param: JsObject) = {
val Search.text(txt) = param
val Search.from_user(usr) = param
val Search.created_at(time) = param

"(" + time + ")" + usr + ": " + txt
}

Http.x((Search("#scala") lang "en") ~> (_ map process foreach println))

See https://github.com/harrah/xsbt/wiki/Scripts. Works like a charm.

>
> IDE support is reaching the point where Eclipse does not go in my way
> anymore and is of real help for boring things (imports, completion of long
> method names, formatting, things like that).
>
> Documentation is OK, especially with so many books and blogs post online.
>
> A "Scala Cookbook" could be intersting, but I would much more prefer a
> repository of Scala scripts, if they were usable for real.
>
> Cheers,
>
> --
> Francois Armand
> http://fanf42.blogspot.com
>

--

[Francois Armand]

Le 10/11/2011 00:39, Daniel Sobral a �crit :

> On Wed, Nov 9, 2011 at 21:30, Francois Armand<fan...@gmail.com> 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.
>
> You mean like this?
>

[...]

> See https://github.com/harrah/xsbt/wiki/Scripts. Works like a charm.
>

Exactly like this, thanks for pointing it !

Now, it only remains compiler speed and starting time :)

(wow, that's really cool, what a pity I missed that... Does it exists
for a long time ?)

[Jordi Salvat i Alabart]

I found one bug in the compiler and 1 in the Language Spec in a few hours of tinkering around (well, actually I found more, but I was playing with experimental features so I didn't count those).

As a result of that research I fell in love with the language and have been playing with it in personal projects since. A couple of months later, I've filed a total of 21 bug reports (my username is "jsalvata" in Jira, if you want to see the listing).

Of course some of those may be false positives, and many are at the edges (playing with Xexperimental, problems internal to the compiler, ...), but I still stand by my initial assessment: Scala is not ready for the industry at large, except possibly for specially complex problems where it provides significant advantage (such as Scala's flagship use in industry, Twitter's engine)

--
Salut,

Jordi.

2011/11/9 Naftoli Gugenheim <nafto...@gmail.com>

[Channing Walton]

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.

[Channing Walton]

Its all good!

[Chris Marshall]

> On Sun, Nov 6, 2011 at 2:08 AM, Erik Engbrecht <erik.en...@gmail.com> wrote:

> > I think you need to define what "rock-hard support" in an IDE means. 

Here are some of the things that IDEA can do for me in Java files that have not-much to do with refactoring/navigation. These things will (I suspect) come as a *big* surprise to the people who are used to VIM and emacs but they are the sorts of things that save a lot of time.

1. Intelligent string parsing. IDEA can tell me when my format string passed to String.format is malformed wrt to the types of the arguments I pass to it (it is highlighted as a bug). It can render *strings* which represent SQL or regex such that they have coloring appropriate to SQL (different color keywords etc).

2. Auto-complete *within Strings*. In a String value in my program, IDEA detects whether the string looks like a path and can auto-complete within the string. For example, if I am creating an ImageIcon with the path to an image resource, IDEA can offer me the choices of images within the directory. It even pops up an *image viewer* as I scroll down the options, even though all I have written is something like: "/path/to/images/ CTRL-SPACE"

3. Color choosing. IDEA spots when a java.awt.Color is created in my program and offers a little square of that color in the sidebar. Clicking on the square gives me a color picker which I can then use to change the color's parameters (requires enterprise edition)

4. Warnings: IDEA warns me when a piece of code is redundant, or when a return value or parameter is not used. It tells me when a method call is being placed against something that might reasonably be null (under certain circumstances), and when a code block (like an if-statement) can be simplified, or its sense reversed. etc etc.

5. When I perform a refactoring, IDEA spots whether other snippets of code in the same file are duplicates (and hence can also be replaced by the refactored item). Refactoring options are many; allowing me to extract fields, constants, parameters, perform renamings which are detected across other file types (such as properties files or XML config files).

6. I can navigate to my types and auto-complete methods and class names from within config or properties files. I can, from within a config file, get a popup of the constructor-params which a type takes. etc etc.

Admittedly these individually are minor things (and a few are already possible with the scala IDEA plugin) but they do add up in such a way that stepping into scala-land can feel less enterprisey (not always a bad thing). Obviously I feel that, on balance, scala is still way ahead in the productivity stakes - but you can at least imagine the reaction of developers when *features that they are used to and use every day* are no longer available.

Chris

[Dennis Haupt]

-------- Original-Nachricht --------
> Datum: Thu, 10 Nov 2011 10:25:31 +0000
> Von: Chris Marshall <oxbow...@hotmail.com>
> An: scala...@googlegroups.com
> Betreff: RE: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

>
> > On Sun, Nov 6, 2011 at 2:08 AM, Erik Engbrecht
> <erik.en...@gmail.com> wrote:
> > > I think you need to define what "rock-hard support" in an IDE means.
>
> Here are some of the things that IDEA can do for me in Java files that
> have not-much to do with refactoring/navigation. These things will (I suspect)
> come as a *big* surprise to the people who are used to VIM and emacs but
> they are the sorts of things that save a lot of time.
> 1. Intelligent string parsing. IDEA can tell me when my format string
> passed to String.format is malformed wrt to the types of the arguments I pass
> to it (it is highlighted as a bug). It can render *strings* which represent
> SQL or regex such that they have coloring appropriate to SQL (different
> color keywords etc).

it works for nested languages in general (sql, hibernate query stuff). for example, i have native javascript inside my gwt java classes. idea offers full support for these snippets. i pity my eclipse co-workers every time :)

> 2. Auto-complete *within Strings*. In a String value in my program, IDEA
> detects whether the string looks like a path and can auto-complete within
> the string. For example, if I am creating an ImageIcon with the path to an
> image resource, IDEA can offer me the choices of images within the directory.

really helpful inside xml files

> It even pops up an *image viewer* as I scroll down the options, even
> though all I have written is something like: "/path/to/images/ CTRL-SPACE"
> 3. Color choosing. IDEA spots when a java.awt.Color is created in my
> program and offers a little square of that color in the sidebar. Clicking on the
> square gives me a color picker which I can then use to change the color's
> parameters (requires enterprise edition)

it also shows the color in the debugger.

[bryan hunt]

Ok, an example, one of many, Scala-Query (the project) is not parsed
correctly by Intellij.

Having spent a number of years on theserverside.com, I'm well versed
in the world of AstroTurfing(TM).

I am for the record, a fully paid up, subscribed Intellij Enterprise
customer, but I keep a copy of Eclipse for when I need to do Scala.

Intellij cannot accurately parse more than about 20 (Scala) classes
without crapping itself, Java and Flex support are outstanding, even
if the UI is a bit sluggish.

Regards,

Bryan Hunt

[bryan hunt]

> 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....

[Geir Hedemark]

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

[Daniel Sobral]

On Thu, Nov 10, 2011 at 10:22, bryan hunt <sentimen...@gmail.com> 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.

[Daniel Sobral]

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.

[Chris Marshall]

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: channin...@googlemail.com
> Date: Wed, 9 Nov 2011 21:13:58 +0000
> To: scala...@googlegroups.com

[jherber]

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

[Razvan Cojocaru]

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...@googlegroups.com [mailto:scala...@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?) ?

[Bernd Johannes]

Am Donnerstag, 10. November 2011, 14:08:48 schrieb Daniel Sobral:
> On Thu, Nov 10, 2011 at 10:31, Geir Hedemark <geir.h...@gmail.com>
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

[Razvan Cojocaru]

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...@googlegroups.com [mailto:scala...@googlegroups.com] On
Behalf Of Bernd Johannes
Sent: November-10-11 3:11 PM
To: scala...@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?) ?

[Simon Ochsenreither]

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

[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.

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

[Alan Burlison]

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".

--
Alan Burlison
--

[Erik Engbrecht]

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

[Francois]

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,

--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

[Razvan Cojocaru]

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

[Naftoli Gugenheim]

On Fri, Nov 11, 2011 at 8:55 AM, Erik Engbrecht <erik.en...@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.

[Francois]

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.

[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

[Daniel Sobral]

On Fri, Nov 11, 2011 at 07:41, Alan Burlison <alan.b...@gmail.com> 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
> --
>

--

[Mirco Dotta]

> 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

-- Mirco

[Francois]

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,

[Bernd Johannes]

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

[Razvan Cojocaru]

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

[Bernd Johannes]

[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

[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

[Maxime Lévesque]

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 <mirco...@gmail.com>:

[Razvan Cojocaru]

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

[Tim Pigden]

Re: use of the verb "to pimp"
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

[Francois]

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.

[Alan Burlison]

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,

--
Alan Burlison
--

[Daniel Sobral]

On Fri, Nov 11, 2011 at 22:57, Alan Burlison <alan.b...@gmail.com> 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.

[Philippe Lhoste]

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... :-)

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Philippe Lhoste]

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.

[Mirko Stocker]

On Sat, Nov 12, 2011 at 09:37, Philippe Lhoste <Phi...@gmx.net> 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

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st

[Xuefeng Wu]

1,2,3 me to

[Daniel Sobral]

On Sat, Nov 12, 2011 at 06:37, Philippe Lhoste <Phi...@gmx.net> 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
> --  (near) Paris -- France
> --  http://Phi.Lho.free.fr
> --  --  --  --  --  --  --  --  --  --  --  --  --  --
>
>

--

[Matthew Pocock]

On 12/11/2011, Daniel Sobral <dcso...@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 22:57, Alan Burlison <alan.b...@gmail.com>
> 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.
>

--
Dr Matthew Pocock
Integrative Bioinformatics Group, School of Computing Science, Newcastle
University
mailto: turingate...@gmail.com
gchat: turingate...@gmail.com
msn: matthew...@yahoo.co.uk
irc.freenode.net: drdozer
skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

[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

[Ken McDonald]

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

[marc]

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.  

[Eric Kolotyluk]

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.

Interesting Idea!

[Clint Gilbert]

-----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.

-----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-----

[Francois]

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

[Cay Horstmann]

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

Cheers,

Cay

[marc]

That is the phrase I use too. 

[Razvan Cojocaru]

@Eric:
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…

[Josh Suereth]

On Mon, Nov 14, 2011 at 1:43 PM, Ken McDonald <ykke...@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.

[Clint Gilbert]

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

Cool, thanks! "Enriching" and the Rich{String,Foo} naming pattern sound
nice to me.

iEYEARECAAYFAk7BcpwACgkQ5IyIbnMUeTt0hgCfRobgQX2ZWeOoPz2Qss8Ze7Ao
y4IAoKnzqyTna2NupvUJUwDY7ovr5de4
=JmE2
-----END PGP SIGNATURE-----