Scala: Great potential, but not ready for production

dmoshal wrote:
> OK, I realize that I'm going to be flamed, but I thought I'd share my earnest
> attempt to port an existing java application to Scala.

Just to be clear, most the issues you're having are IDE issues, not Scala
language issues. There's been much gnashing of teeth about this. I develop in
Emacs and build with ant and haven't had any of the issues described.

For this

val v = new java.util.Vector[String]
for (a <- v)
println (a)

You could do

import scala.collection.jcl.Conversions._

val v = new java.util.Vector[String]
for (a <- v)
println (a)

or do

import scala.collection.jcl.Conversions._

val v = new java.util.Vector[String]
for (a <- convertList(v))
println (a)

David,
No flames, but a couple of points:- IDE support for Scala is less mature than it is for Java.  You might want to try NetBeans or IntelliJ.  I have found they are both far more stable than Eclipse for Scala development (I have not tried Eclipse in the last 6 weeks, so it might be better than the last snapshot I looked at.)  Most of your issues seem to be IDE related, so I'd suggest that dismissing Scala because of IDE problems may be throwing out the baby with the bathwater. - With a single line of code ( import scala.collection.jcl.Conversions._ ) you can make your Vector problem go away.
Thanks,
David
  import java.util._   import scala.collection.jcl.Conversions._
  val v = new Vector[String]      for (s <- v) println(s)

On Tue, Feb 17, 2009 at 11:34 AM, dmoshal <dmoshal@gmail.com> wrote:

OK, I realize that I'm going to be flamed, but I thought I'd share my earnest
attempt to port an existing java application to Scala.

The java application has around 150 classes, the source code, when printed
out is about 400 pages. It's currently used to support financial
transactions of around $500 million per year.

One developer (me) spent 2 weeks porting the application to Scala.
Initially things looked very promising, I was seeing a 3-5 x reduction in
the lines of code.
In addition to the conciseness of Scala, the expressiveness was also
impressive.
In particular, the pattern matching functionality was impressive.

Additionally, support from the user community (on this forum) was
impressive.
The one or two major stumbling blocks (implementing an interface of a java
library, for example), were answered on this forum within minutes.

However, once the code base reached a certain size (around 100 classes), the
compiler and/or the Eclipse plugin (I'm not sure exactly where the problem
lies), seemed to become very unstable. I was using the latest plugin, 2.7.3
I believe. Also, I use OS X 10.5.6, with Java 1.6

Almost any change to a file would require the entire projected to be
'cleaned', and the results would be fairly random, ie: the ide would report
not being able to find various classes, and these would be different on
different runs, sometimes it would be unable to find a number of classes,
but on the next run, it would be able to find those classes, but not another
set of classes

Specific examples:

1. the ide/compiler seemed unable to find classes using wildcards, eg:

import foo._

would not find class:

foo.User

nor would foo.User pop up in the context sensitive help unless explicitly
imported as "import foo.User" at least once elsewhere.

2. It seems that the ide/compiler doesn't make much attempt to check that
package names match package paths. Presumably that's a 'feature' of Scala,
but it's also an easy was to make a mistake, and there ought to be an option
to enforce this, or at least warn about this.

3. Certain Scala functionality seems to not work, for example:

abstract class Topic (val name:String)
object TopicA extends Topic ("foo")
object TopicB extends Topic ("bar")

would result in the ide reporting that it's unable to find class Topic (in
the second file where Topic is used). This seemed fairly common, actually it
seemed that the compiler/ide had the most trouble with files in which more
than one class/object/trait was specified, as in example 3 above.

4. Somewhat annoyingly, the 'for comprehension' doesn't work with
java.util.Vector, ie:

val v = new Vector [String]

for (a <- v)
 println (a)

will fail, complaining that 'foreach is not a member of java.util.Vector'
so, one has to do something like this:

val it = v.iterator
while (it.hasNext)
 println (it.next)

Why use Vectors at all, you say, and not List?

Well, it turns out that if you want to use db4o for persistence, then,
because List in a linked list, there are problems with activation depth. ie:
you'll only be able to retrieve the first 5 elements of the list without
messing with the activation depth settings for db4o, on a class-by-class
basis.

So, I'm going back to java, but I will say this, my java code seems more
concise after this exercise.

Keep up the good work, I have no doubt that I'll be using Scala extensively
in a few years time, and I look forward to exploring the functional aspects
of the language at that time.

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22064598.html
Sent from the Scala mailing list archive at Nabble.com.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

David,

This is interesting and important info; many thanks for providing it. It seems that your experience is really about the combined behavior of Scala and the IDE. Is it possible to divide the feedback into experience with the existing supporting tools and experience with Scala? Do you feel that the development experience really needs to take both together? This is a genuine question for me.

i'm from an older generation of dev's. Currently, i develop outside of an IDE like IntelliJ/Netbeans/Eclipse (though i have used IntelliJ pretty extensively to develop a compiler for the language R). Instead i use emacs. Additionally, i use code-generation tools like BNFC. These generate hundreds of Java classes. To date i have experienced no issues with Scala or emacs getting confused.

i note that my usage pattern is pretty specific. i believe that keeping as much as possible in Java will result in better performance. Further, i hardly write Java. i write Java via higher level tools. Thus, my navigation experience consists primarily of wading through a small amount of Scala code and an even smaller amount of code-generation specs.

My experience is greatly aided by maven -- which when it works, really just works (though woe to the person who needs to go outside of what works). This means build, project and dependency management is pretty much what a dev-of-very-little-brains (to paraphrase Pooh) can handle. Is your assessment based on a build and project management approached that is organized around the IDE?

i remember back in the olden times of very richly featured Common Lisp IDE's (one of which i helped create) i found myself much too dependent on their functionality and that it was very hard for me to develop outside of that environment. This is one of the reasons why i divorced myself from richly featured IDEs and vowed to decompose the functionality into bits and pieces that i could personally undertand and manage. i also realize that this is pretty idiosyncratic behavior and wonder what your take on the whole tools and environment support ecosystem is.

Best wishes,

--greg

On Tue, Feb 17, 2009 at 11:34 AM, dmoshal <dmoshal@gmail.com> wrote:

OK, I realize that I'm going to be flamed, but I thought I'd share my earnest
attempt to port an existing java application to Scala.

The java application has around 150 classes, the source code, when printed
out is about 400 pages. It's currently used to support financial
transactions of around $500 million per year.

One developer (me) spent 2 weeks porting the application to Scala.
Initially things looked very promising, I was seeing a 3-5 x reduction in
the lines of code.
In addition to the conciseness of Scala, the expressiveness was also
impressive.
In particular, the pattern matching functionality was impressive.

Additionally, support from the user community (on this forum) was
impressive.
The one or two major stumbling blocks (implementing an interface of a java
library, for example), were answered on this forum within minutes.

However, once the code base reached a certain size (around 100 classes), the
compiler and/or the Eclipse plugin (I'm not sure exactly where the problem
lies), seemed to become very unstable. I was using the latest plugin, 2.7.3
I believe. Also, I use OS X 10.5.6, with Java 1.6

Almost any change to a file would require the entire projected to be
'cleaned', and the results would be fairly random, ie: the ide would report
not being able to find various classes, and these would be different on
different runs, sometimes it would be unable to find a number of classes,
but on the next run, it would be able to find those classes, but not another
set of classes

Specific examples:

1. the ide/compiler seemed unable to find classes using wildcards, eg:

import foo._

would not find class:

foo.User

nor would foo.User pop up in the context sensitive help unless explicitly
imported as "import foo.User" at least once elsewhere.

2. It seems that the ide/compiler doesn't make much attempt to check that
package names match package paths. Presumably that's a 'feature' of Scala,
but it's also an easy was to make a mistake, and there ought to be an option
to enforce this, or at least warn about this.

3. Certain Scala functionality seems to not work, for example:

abstract class Topic (val name:String)
object TopicA extends Topic ("foo")
object TopicB extends Topic ("bar")

would result in the ide reporting that it's unable to find class Topic (in
the second file where Topic is used). This seemed fairly common, actually it
seemed that the compiler/ide had the most trouble with files in which more
than one class/object/trait was specified, as in example 3 above.

4. Somewhat annoyingly, the 'for comprehension' doesn't work with
java.util.Vector, ie:

val v = new Vector [String]

for (a <- v)
 println (a)

will fail, complaining that 'foreach is not a member of java.util.Vector'
so, one has to do something like this:

val it = v.iterator
while (it.hasNext)
 println (it.next)

Why use Vectors at all, you say, and not List?

Well, it turns out that if you want to use db4o for persistence, then,
because List in a linked list, there are problems with activation depth. ie:
you'll only be able to retrieve the first 5 elements of the list without
messing with the activation depth settings for db4o, on a class-by-class
basis.

So, I'm going back to java, but I will say this, my java code seems more
concise after this exercise.

Keep up the good work, I have no doubt that I'll be using Scala extensively
in a few years time, and I look forward to exploring the functional aspects
of the language at that time.

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22064598.html
Sent from the Scala mailing list archive at Nabble.com.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

What amazes me is the reaction to the failures of an IDE.
In the past (last year, actually) I had so many troubles using IntelliJ on large projects, that I had to eventually switch to a plain text editor + command line for running unittests; this had improved my performance greatly. The problem I guess was not with IntelliJ, but with the volume and structure of the project. I believe it should have been developed by modules: building libraries separately and providing jars for client code to use. How about this idea?
-Vlad


2009/2/17 dmoshal <dmoshal@gmail.com>

OK, I realize that I'm going to be flamed, but I thought I'd share my earnest
attempt to port an existing java application to Scala.

The java application has around 150 classes, the source code, when printed
out is about 400 pages. It's currently used to support financial
transactions of around $500 million per year.

One developer (me) spent 2 weeks porting the application to Scala.
Initially things looked very promising, I was seeing a 3-5 x reduction in
the lines of code.
In addition to the conciseness of Scala, the expressiveness was also
impressive.
In particular, the pattern matching functionality was impressive.

Additionally, support from the user community (on this forum) was
impressive.
The one or two major stumbling blocks (implementing an interface of a java
library, for example), were answered on this forum within minutes.

However, once the code base reached a certain size (around 100 classes), the
compiler and/or the Eclipse plugin (I'm not sure exactly where the problem
lies), seemed to become very unstable. I was using the latest plugin, 2.7.3
I believe. Also, I use OS X 10.5.6, with Java 1.6

Almost any change to a file would require the entire projected to be
'cleaned', and the results would be fairly random, ie: the ide would report
not being able to find various classes, and these would be different on
different runs, sometimes it would be unable to find a number of classes,
but on the next run, it would be able to find those classes, but not another
set of classes

Specific examples:

1. the ide/compiler seemed unable to find classes using wildcards, eg:

import foo._

would not find class:

foo.User

nor would foo.User pop up in the context sensitive help unless explicitly
imported as "import foo.User" at least once elsewhere.

2. It seems that the ide/compiler doesn't make much attempt to check that
package names match package paths. Presumably that's a 'feature' of Scala,
but it's also an easy was to make a mistake, and there ought to be an option
to enforce this, or at least warn about this.

3. Certain Scala functionality seems to not work, for example:

abstract class Topic (val name:String)
object TopicA extends Topic ("foo")
object TopicB extends Topic ("bar")

would result in the ide reporting that it's unable to find class Topic (in
the second file where Topic is used). This seemed fairly common, actually it
seemed that the compiler/ide had the most trouble with files in which more
than one class/object/trait was specified, as in example 3 above.

4. Somewhat annoyingly, the 'for comprehension' doesn't work with
java.util.Vector, ie:

val v = new Vector [String]

for (a <- v)
 println (a)

will fail, complaining that 'foreach is not a member of java.util.Vector'
so, one has to do something like this:

val it = v.iterator
while (it.hasNext)
 println (it.next)

Why use Vectors at all, you say, and not List?

Well, it turns out that if you want to use db4o for persistence, then,
because List in a linked list, there are problems with activation depth. ie:
you'll only be able to retrieve the first 5 elements of the list without
messing with the activation depth settings for db4o, on a class-by-class
basis.

So, I'm going back to java, but I will say this, my java code seems more
concise after this exercise.

Keep up the good work, I have no doubt that I'll be using Scala extensively
in a few years time, and I look forward to exploring the functional aspects
of the language at that time.

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22064598.html
Sent from the Scala mailing list archive at Nabble.com.

--
:)
-Vlad

Hey now.... lets not get hasty... everyone who works in IT needs to pull the
ripcord, its timing which is key, not too early and certainly not too late.

From what I read, Scala offered distinct improvement in every KPI that
mattered from a pointy and propeller headed perspective but for a couple
things.

1) Lots of IDE issues.
2) Java <-> Scala regarding for comprehensions and vectors.

#2 seems to be solvable and not significant enough to make my top 25 reasons
to yea or nay something as architecturally important as what is the best
solution stack (language as one) to use for your project and your company.

Time horizons... Where do you/company want to be 24 months from now on
this stuff?

Would setting a precedent for Scala be of value to the company over the next
1-3 years if it found increased use in your company? The first introduction
of anything is tough. If told you what I went through using IBM's 2.0
Websphere and VisualAge for Java 10 years ago ... 10 - 15 minutes on the
clock to compile a HelloWorld EJB. You got 4 compiles per hour. And it
would routinely corrupt the entire workspace. I had at least one developer
a day down and out reinstalling visual age for java. And lets not even talk
about the loss of the entire repository itself. But I could less then a year
there was light at the end of the tunnel. (I knew from IBM that Eclipse was
coming but was big secret, but then I had BEA to fall back on.) Today we do
several billion will Java code on WebSphere clusters.

If Scala succeeds, these IDE issues are ephemeral things. Netbean's IDE
works ok with 150 classes. $400 million in revenue buy 2 IDEA licenses,
flip to Netbeans, use emacs,vi, and maven. Will you avoid at least 1 roll
back of production code in a year because Scala avoided one less critical
bug? Once the IDE issue is gone will adding a new feature/function take 20%
less time with fewer bug regression?? Will you attract or retain one more
stud developer, because he/she gets to code in Scala? Will this code god
lift the team as well as the code base?

A transition of ownership and a renewed effort on the Eclipse plugin is
readily apparent on the mail list and #scala. Figure decent shot within 3-6
months these things are long gone and you have available work arounds to
bridge this and keep ... moving ... forward.

It boils down to this. Your software architecture is "right" when viewed
over a 1 year time horizon or its not. If it is right, then the issues
you've raised, from the details you have given, are insufficient to
overthrow it. If its wrong, its not wrong from the issues you've raised.

Picture you, your team, and other teams in your company doing new code base
development and enhancement to this code base 1 year from now. Do you see
advantages if you suck it up now and power through these fleeting things?
If not then fall back to Java. If you see a better end state, do what you
need to do, to get to where you want it to be.

Ray

YES! we can. The Scala for Enterprise Committee approves this message.

dmoshal wrote:
>
> OK, I realize that I'm going to be flamed, but I thought I'd share my
> earnest attempt to port an existing java application to Scala.
>
> The java application has around 150 classes, the source code, when printed
> out is about 400 pages. It's currently used to support financial
> transactions of around $500 million per year.
>
> One developer (me) spent 2 weeks porting the application to Scala.
> Initially things looked very promising, I was seeing a 3-5 x reduction in
> the lines of code.
> In addition to the conciseness of Scala, the expressiveness was also
> impressive.
> In particular, the pattern matching functionality was impressive.
>
> Additionally, support from the user community (on this forum) was
> impressive.
> The one or two major stumbling blocks (implementing an interface of a java
> library, for example), were answered on this forum within minutes.
>
> However, once the code base reached a certain size (around 100 classes),
> the compiler and/or the Eclipse plugin (I'm not sure exactly where the
> problem lies), seemed to become very unstable. I was using the latest
> plugin, 2.7.3 I believe. Also, I use OS X 10.5.6, with Java 1.6
>
> Almost any change to a file would require the entire projected to be
> 'cleaned', and the results would be fairly random, ie: the ide would
> report not being able to find various classes, and these would be
> different on different runs, sometimes it would be unable to find a number
> of classes, but on the next run, it would be able to find those classes,
> but not another set of classes
>
> Specific examples:
>
> 1. the ide/compiler seemed unable to find classes using wildcards, eg:
>
> import foo._
>
> would not find class:
>
> foo.User
>
> nor would foo.User pop up in the context sensitive help unless explicitly
> imported as "import foo.User" at least once elsewhere.
>
> 2. It seems that the ide/compiler doesn't make much attempt to check that
> package names match package paths. Presumably that's a 'feature' of Scala,
> but it's also an easy was to make a mistake, and there ought to be an
> option to enforce this, or at least warn about this.
>
> 3. Certain Scala functionality seems to not work, for example:
>
> abstract class Topic (val name:String)
> object TopicA extends Topic ("foo")
> object TopicB extends Topic ("bar")
>
> would result in the ide reporting that it's unable to find class Topic (in
> the second file where Topic is used). This seemed fairly common, actually
> it seemed that the compiler/ide had the most trouble with files in which
> more than one class/object/trait was specified, as in example 3 above.
>
> 4. Somewhat annoyingly, the 'for comprehension' doesn't work with
> java.util.Vector, ie:
>
> val v = new Vector [String]
>
> for (a <- v)
> println (a)
>
> will fail, complaining that 'foreach is not a member of java.util.Vector'
> so, one has to do something like this:
>
> val it = v.iterator
> while (it.hasNext)
> println (it.next)
>
> Why use Vectors at all, you say, and not List?
>
> Well, it turns out that if you want to use db4o for persistence, then,
> because List in a linked list, there are problems with activation depth.
> ie: you'll only be able to retrieve the first 5 elements of the list
> without messing with the activation depth settings for db4o, on a
> class-by-class basis.
>
> So, I'm going back to java, but I will say this, my java code seems more
> concise after this exercise.
>
> Keep up the good work, I have no doubt that I'll be using Scala
> extensively in a few years time, and I look forward to exploring the
> functional aspects of the language at that time.
>
> David
>
>

Thanks for the feedback!

Regarding the Vector issue: it's seems there's an easy fix (now that I have
the secret incantation), but that was the least of my issues, I didn't mind
adding an extra line of code.

Regarding IDEs: it seems to be the consensus that the Eclipse IDE is the
worst one to develop Scala code with. That's surprising to me. Certainly if
that is the case, it should be made clear where-ever possible.

Why allow Scala to get a bum rap simply because most people will be using
the worst tool available (assuming, again, that the eclipse plugin is
actually the worst tool - someone has put a lot of effort into it clearly,
and such statements aren't likely to be very motivating to that group).

I actually have both Netbeans and IntelliJ installed on my machine. I'm open
to using either (though in the past I've had issues with IntelliJ). As far
as Emacs is concerned - not something I have experience with, but if scala
on emacs has a dependency on Maven then it's definitely out of the question!

So, here's what I'll do: I'll spend one more day on this, as follows:
a) I'll install a clean version of Netbeans
b) I'll install the latest Netbeans Scala plugin
c) I'll import the project from eclipse into netbeans, and
d) report back on what happens.

Sound reasonable?

David

ps: one further problem, which seems understandable, but a problem
nonetheless:
Scala doesn't interoperate well with java classes that are java byte-code
enhanced at run-time (e.g. for JDO). Again, I was not really expecting that
too work, but it does mean that I can't use ObjectDB, my favourite OODB.

Scala on emacs has no dependency on maven.  In fact you need a little customisation (3 lines of elisp) to make emacs happy with maven (1 of which makes it happy with maven and Scala together).

2009/2/17 dmoshal <dmoshal@gmail.com>

Thanks for the feedback!

Regarding the Vector issue: it's seems there's an easy fix (now that I have
the secret incantation), but that was the least of my issues, I didn't mind
adding an extra line of code.

Regarding IDEs: it seems to be the consensus that the Eclipse IDE is the
worst one to develop Scala code with. That's surprising to me. Certainly if
that is the case, it should be made clear where-ever possible.

Why allow Scala to get a bum rap simply because most people will be using
the worst tool available (assuming, again, that the eclipse plugin is
actually the worst tool - someone has put a lot of effort into it clearly,
and such statements aren't likely to be very motivating to that group).

I actually have both Netbeans and IntelliJ installed on my machine. I'm open
to using either (though in the past I've had issues with IntelliJ). As far
as Emacs is concerned - not something I have experience with, but if scala
on emacs has a dependency on Maven then it's definitely out of the question!

So, here's what I'll do: I'll spend one more day on this, as follows:
a) I'll install a clean version of Netbeans
b) I'll install the latest Netbeans Scala plugin
c) I'll import the project from eclipse into netbeans, and
d) report back on what happens.

Sound reasonable?

David

ps: one further problem, which seems understandable, but a problem
nonetheless:
Scala doesn't interoperate well with java classes that are java byte-code
enhanced at run-time (e.g. for JDO). Again, I was not really expecting that
too work, but it does mean that I can't use ObjectDB, my favourite OODB.
--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22066091.html
Sent from the Scala mailing list archive at Nabble.com.

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

I have maintained a Scala project of around 5000 classes for the last
year. It became apparent very early on that the Eclipse plugin was...
typically Eclipse.
Similar to what you have noted, I'd rather use Scala, a hex editor
*and* stab my eyes out all at once than use Java and all its
supposedly clever tools.

The other points you make are typical user error (in any case, you're
using db4o wrong if you don't think you'll have to fiddle with
activation depth).

"So, I'm going back to java, but I will say this, my java code seems
more concise after this exercise."

Show me an example and I'll show you your error. You're not getting
flamed, just looking silly. Well done :)

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

*********************************************************
* Anteromedial Heterotopic Osseous Impingement Syndrome *
*********************************************************

http://www.ajronline.org/cgi/content/full/178/3/601
"can result in chronic ankle pain, especially in athletes and the
younger population (15-40 years old)"

http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457
"Soft-tissue and osseous impingement syndromes of the ankle can be an
important cause of chronic pain, particularly in the professional
athlete."

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

iD8DBQFJm1a9mnpgrYe6r60RAtjlAKDFckqeCG9riCpOhSxc6uls0eUW0gCfal8Z
0787APQMp70pwiHoDnRJVDE=
=t+SL
-----END PGP SIGNATURE-----

Tony moved all his boilerplate to his emails.

2009/2/18 Tony Morris <tmorris@tmorris.net>

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

I have maintained a Scala project of around 5000 classes for the last
year. It became apparent very early on that the Eclipse plugin was...
typically Eclipse.
Similar to what you have noted, I'd rather use Scala, a hex editor
*and* stab my eyes out all at once than use Java and all its
supposedly clever tools.

The other points you make are typical user error (in any case, you're
using db4o wrong if you don't think you'll have to fiddle with
activation depth).

"So, I'm going back to java, but I will say this, my java code seems
more concise after this exercise."

Show me an example and I'll show you your error. You're not getting
flamed, just looking silly. Well done :)

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

*********************************************************
* Anteromedial Heterotopic Osseous Impingement Syndrome *
*********************************************************

http://www.ajronline.org/cgi/content/full/178/3/601
"can result in chronic ankle pain, especially in athletes and the
younger population (15-40 years old)"

http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457
"Soft-tissue and osseous impingement syndromes of the ankle can be an
important cause of chronic pain, particularly in the professional
athlete."

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

iD8DBQFJm1a9mnpgrYe6r60RAtjlAKDFckqeCG9riCpOhSxc6uls0eUW0gCfal8Z
0787APQMp70pwiHoDnRJVDE=
=t+SL
-----END PGP SIGNATURE-----

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

Sorry, a misread.

Raoul Duke wrote:
>> "So, I'm going back to java, but I will say this, my java code
>> seems more concise after this exercise." Show me an example and
>> I'll show you your error. You're not getting flamed, just looking
>> silly. Well done :)
>
> i think perhaps the point was that having done Scala, they now know
> to try to make their Java less verbose. so Scala was nice and
> educational for them in that regard. not that Java would ever be
> less verbose than Scala, if that is how you interpreted it. i think
> perhaps.
>
>
>

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

*********************************************************
* Anteromedial Heterotopic Osseous Impingement Syndrome *
*********************************************************

http://www.ajronline.org/cgi/content/full/178/3/601
"can result in chronic ankle pain, especially in athletes and the
younger population (15-40 years old)"

http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457
"Soft-tissue and osseous impingement syndromes of the ankle can be an
important cause of chronic pain, particularly in the professional
athlete."

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

iD8DBQFJm1h8mnpgrYe6r60RAjP8AKCEE32iqPDTS9Y111BdU8WuVJrlQACfWDxW
NyGKkcU6ispE+YE/N1MLBo8=
=8axX
-----END PGP SIGNATURE-----

> "So, I'm going back to java, but I will say this, my java code seems
> more concise after this exercise."
> Show me an example and I'll show you your error. You're not getting
> flamed, just looking silly. Well done :)

i think perhaps the point was that having done Scala, they now know to
try to make their Java less verbose. so Scala was nice and educational
for them in that regard. not that Java would ever be less verbose than
Scala, if that is how you interpreted it. i think perhaps.

That's correct, I meant that, somehow by converting my java code to Scala,
then back to java, the new java code was more concise than the original
java.

For example: I found that I no longer needed Guice for dependency injection,
because it was entirely obvious where the static objects were, and it was
easy to make these static variable of the 'main' class (didn't even need to
implement singletons).

Another example: I found that in many of the cases where I was defining an
interface and then implementing that interface, I could simply do away with
the interface.

But that's not my interesting news, this is:

I took the Scala code that I had abandoned, and got it to run in Netbeans,
very easily!

So, in Netbeans I was able to find the errors (there were a handful) easily,
and fix them, whereas in Eclipse I was unable to find the bugs because it
instead found hundreds of non-existent namespace related bugs.

Netbeans isn't perfect btw, for some reason every one of my java imports is
underlined in red, with the comment "value xyz is not a member of package
abc".
However, it seems to compile fine and run fine.

The compiler seems about twice as slow on Netbeans (but it works!).

Very interesting.

For now, I'll continue in Scala, at the risk of seeming 'silly' later
(thanks for that dig Tony).

David

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

If your problem is with Eclipse, then you should have just asked :)
The common assumption that the hypothetical non-existence of Eclipse
is detrimental leads to many errors.

dmoshal wrote:
> That's correct, I meant that, somehow by converting my java code to Scala,
> then back to java, the new java code was more concise than the original
> java.
>
> For example: I found that I no longer needed Guice for dependency
injection,
> because it was entirely obvious where the static objects were, and it was
> easy to make these static variable of the 'main' class (didn't even need to
> implement singletons).
>
> Another example: I found that in many of the cases where I was defining an
> interface and then implementing that interface, I could simply do away with
> the interface.
>
> But that's not my interesting news, this is:
>
> I took the Scala code that I had abandoned, and got it to run in Netbeans,
> very easily!
>
> So, in Netbeans I was able to find the errors (there were a handful)
easily,
> and fix them, whereas in Eclipse I was unable to find the bugs because it
> instead found hundreds of non-existent namespace related bugs.
>
> Netbeans isn't perfect btw, for some reason every one of my java imports is
> underlined in red, with the comment "value xyz is not a member of package
> abc".
> However, it seems to compile fine and run fine.
>
> The compiler seems about twice as slow on Netbeans (but it works!).
>
> Very interesting.
>
> For now, I'll continue in Scala, at the risk of seeming 'silly' later
> (thanks for that dig Tony).
>
> David
>
>

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

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

iD8DBQFJm3tymnpgrYe6r60RAg5bAKCu1mIBOFriYNvvtWoB2DhDkBOJswCePUyB
KKF88sT4TugsSg3aVrwOo+o=
=R92H
-----END PGP SIGNATURE-----

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

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

If you held a gun to my head and forced me to use Java, I might
concede, but if you forced me to use Eclipse... the ineptitude of what
constitutes the very essence of Eclipse is unrelated to Scala and
exists regardless of what language you use.

For what it is worth, I have no desire for widespread adoption of
Scala - if you want to do it the hard way, then that's too bad, for
you. I promise you that the non-existence of Eclipse is to your benefit.

Also "fixing the Eclipse plugin" is an internally inconsistent
non-concept and cannot exist regardless of how much we both might wish
it weren't so _|_

dmoshal wrote:
> Tony, I had no idea that my problem was eclipse. Additionally, my
> front-end is in Flex, and Flex Builder is an eclipse plugin, so I
> still need Eclipse.
>
> Relying on java developers switching from Eclipse to emacs (or
> Netbeans, or IntelliJ) won't result in widespread adoption of
> Scala. Fixing the Eclipse plugin is critical (blocking).
>
> David
>

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

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

iD8DBQFJm4/WmnpgrYe6r60RArLMAKCeUZ1RhreMU5qUQaoQt4gvwmSKNQCgmBGl
phHzQeBytmDuWw4X6YqVzH4=
=Ee3j
-----END PGP SIGNATURE-----

To the point of Eclipse being a bottleneck. I am sure the Eclipse plugin will mature soon into a stable product. Eclipse is a fairly stable IDE and many plugins work well. 
Many on this list seem to discard the importance of Eclispe and an IDE. Whether you like it or not -- use it or not, thousands of developers use Eclipse to build very sophisticated applications. For Scala to be successful as a more wide spread language the choice of a well functioning Eclipse plugin is fairly important.
@Tony: you seem to be screaming for attention and sound rather rude and cheeky for no particular rhyme or reason. David was very politely presenting his viewpoint. He tried a few things and in general was frustrated with what he experienced. His email was in some ways a humble request to ask for some help and direction. He gladly accepted the inputs and is retrying and making an effort to make things work for him. How does that make anybody silly? Take it easy dude. Writing 5000 Scala classes seems to have affected your mental health adversely.
Thanks....Shashank
************************************************
Shashank Tiwari
web: www.shanky.org | blog: http://www.oreillynet.com/pub/au/2799
GTalk, Y! IM, Skype, Twitter : tshanky


On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

I'm only doing a personal project in Scala, but Netbeans seems pretty stable. There are occasional hangups in the validation that can lock the interface for 10sec and sometimes you need to jump between sourcefiles to update erroneous highlighted errors. I also work simultaneously in Aptana for Eclipse (commercially driven) which also broke a couple of times the last year, so it's not just Scala that is struggling in Eclipse.

On Wed, Feb 18, 2009 at 7:52 AM, Shashank Tiwari <tshanky@gmail.com> wrote:

@David: very interesting! how do you connect between Flex and Scala -- BlazeDS | LCDS (via Java) or HTTPService?
You may want to consider IntelliJ 8.1 (the latest kid in the block) -- that's the version that supports both Flex and Scala.
To the point of Eclipse being a bottleneck. I am sure the Eclipse plugin will mature soon into a stable product. Eclipse is a fairly stable IDE and many plugins work well. 
Many on this list seem to discard the importance of Eclispe and an IDE. Whether you like it or not -- use it or not, thousands of developers use Eclipse to build very sophisticated applications. For Scala to be successful as a more wide spread language the choice of a well functioning Eclipse plugin is fairly important.
@Tony: you seem to be screaming for attention and sound rather rude and cheeky for no particular rhyme or reason. David was very politely presenting his viewpoint. He tried a few things and in general was frustrated with what he experienced. His email was in some ways a humble request to ask for some help and direction. He gladly accepted the inputs and is retrying and making an effort to make things work for him. How does that make anybody silly? Take it easy dude. Writing 5000 Scala classes seems to have affected your mental health adversely.
Thanks....Shashank
************************************************
Shashank Tiwari
web: www.shanky.org | blog: http://www.oreillynet.com/pub/au/2799
GTalk, Y! IM, Skype, Twitter : tshanky


On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

On Wed, Feb 18, 2009 at 7:52 AM, Shashank Tiwari <tshanky@gmail.com> wrote:

[snip]Writing 5000 Scala classes seems to have affected your mental health adversely.

  [/snip]

No, he's been like that even before starting Scalaz ;)

And Tony, I hope that standing offer to crash at your place in case of a trip to Australia still is available ;)

Cheers,
Viktor
 

Thanks....Shashank
************************************************
Shashank Tiwari
web: www.shanky.org | blog: http://www.oreillynet.com/pub/au/2799
GTalk, Y! IM, Skype, Twitter : tshanky


On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

--
Viktor Klang
Senior Systems Analyst

On Tue, Feb 17, 2009 at 7:46 PM, Blair Zajac wrote:
> Just to be clear, most the issues you're having are IDE issues, not Scala
> language issues. There's been much gnashing of teeth about this. I develop
> in Emacs and build with ant and haven't had any of the issues described.

Funny, I count four issues of which two are IDE-specific.

I'm glad you're happy with Emacs ... I'd prefer it if you commented on
the Eclipse plugin on the basis of experience rather than hearsay.

Cheers,

Miles

On Wed, Feb 18, 2009 at 11:49 AM, Tony Morris wrote:
> I counted 3/4 issues related to IDE.

You can't count ... only 1 and 3 are IDE specific.

Cheers,

Miles

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

I counted 3/4 issues related to IDE.

Miles Sabin wrote:
> On Tue, Feb 17, 2009 at 7:46 PM, Blair Zajac wrote:
>> Just to be clear, most the issues you're having are IDE issues, not Scala
>> language issues. There's been much gnashing of teeth about this. I
develop
>> in Emacs and build with ant and haven't had any of the issues described.
>
> Funny, I count four issues of which two are IDE-specific.
>
> I'm glad you're happy with Emacs ... I'd prefer it if you commented on
> the Eclipse plugin on the basis of experience rather than hearsay.
>
> Cheers,
>
>
> Miles
>

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

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

iD8DBQFJm/XZmnpgrYe6r60RAkiqAJ9SD3OW1OVmhRHm6q0sMIpgWwHoYACglfmv
1UsRWhTQbQ7avlM/GWDM2AM=
=bSmv
-----END PGP SIGNATURE-----

I am glad the problems were pinpointed better in the discussion. From
my own experience, the Eclipse plugin has a lot of potential because
it has a more incremental approach to compilation and therefore
*theoretically* can sustain larger files and larger projects. On the
other hand, I also experienced that it can be very fragile, in
particular if there are errors in the code base. Both the Eclipse
framework and the Eclipse plugin are complex beasts. If you deal with
a lot of complexity, sometimes you take wrong turns in your designs.
For the Eclipse plugin it seems there are two problem areas: too tight
JDT integration and too aggressive dependency management.

The JDT integration has very recently been reworked by Miles. It's
available in the nightly build, but not yet in the latest 2.7.3
release. I can attest it's a definite improvement. There remain issues
and I understand Miles is currently working on these.

The other problem area seems to be dependency management. I also
experienced that I had to do a clean build
quite often because the plugin did not compile the necessessary files
itself. I believe fixing this is already high on the list of
priorities, though.

Cheers

On Tue, Feb 17, 2009 at 7:34 PM, dmoshal wrote:
> Specific examples:
> 1. the ide/compiler seemed unable to find classes using wildcards, eg:
>
> import foo._
>
> would not find class:
>
> foo.User
>
> nor would foo.User pop up in the context sensitive help unless explicitly
> imported as "import foo.User" at least once elsewhere.

This should work and does in typical cases. If you're able to
construct a small reproducible test case and attach it to a ticket in
Trac that would be much appreciated.

> 3. Certain Scala functionality seems to not work, for example:
>
> abstract class Topic (val name:String)
> object TopicA extends Topic ("foo")
> object TopicB extends Topic ("bar")
>
> would result in the ide reporting that it's unable to find class Topic (in
> the second file where Topic is used). This seemed fairly common, actually it
> seemed that the compiler/ide had the most trouble with files in which more
> than one class/object/trait was specified, as in example 3 above.

Do you mean that you're not seeing these in content assist? I've just
tried your exact example with 2.7.3.final with the above in a file
Topic.scala and then using content assist from a file TopicUse.scala
and all three are offered, so presumably there are more details to the
scenario.

As above ... a small, reproducible test case attached to a Trac ticket
would be very much appreciated.

Cheers,

Miles

On Tue, Feb 17, 2009 at 7:48 PM, David Pollak
wrote:
> (I have not tried Eclipse in the last 6 weeks, so it might be better than
> the last snapshot I looked at.)

If there are issues with Lift and 2.7.3.final then I'd like to hear
about them. I repeat my plea for help from the Lift community in
making the Lift+Eclipse experience as smooth as possible.

And please do try again with the latest nightly builds ... things have
moved on a lot since 2.7.3.

Cheers,

Miles

David,There are three types of developers:1.  Those who must have fancy, high-quality tools to work, and will not be able to work in their absence.2.  Those who like having fancy tools, but just grumble over quality issues or having to drop into a plain text editor. 3.  Those who find fancy tools to be superfluous and generally distrust their use and often people who use them.
A lot of organizations have significant populations of people in group #1, and indeed those ranks are probably expanding as people become developers without ever using a plain text edit and a build script.  For those organizations Scala is not appropriate.
But I think there are enough in #2 and #3 to gain a decent groundswell, and to demonstrate high levels of productivity.
-Erik

On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

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

What about
4.  People who like having fancy tools, and use them effectively.  Oftentimes being more productive when refactoring/writing code.   They resort to plain text editors when required, but by no means are unable to work without them.

I'm  a big fan of IDEs, they make life easier if used right.  I've also done a lot of vi coding, and TBH, I'll take the IDE anyday as long as the bugs don't delay me more than the speed increase from features.  When using the Eclipse C++ IDE, I gained a lot of speed vs doing C++ in VI.  I believe the eclipse plugin is past this break-even point with Miles' recent bug-fixing spree, so I recommend people try the nightly.

Once again, PLEASE CONTRIBUTE!!!

On Wed, Feb 18, 2009 at 8:06 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

David,There are three types of developers:1.  Those who must have fancy, high-quality tools to work, and will not be able to work in their absence. 2.  Those who like having fancy tools, but just grumble over quality issues or having to drop into a plain text editor. 3.  Those who find fancy tools to be superfluous and generally distrust their use and often people who use them.
A lot of organizations have significant populations of people in group #1, and indeed those ranks are probably expanding as people become developers without ever using a plain text edit and a build script.  For those organizations Scala is not appropriate.
But I think there are enough in #2 and #3 to gain a decent groundswell, and to demonstrate high levels of productivity.
-Erik

On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

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

On Wed, Feb 18, 2009 at 1:06 PM, Erik Engbrecht
wrote:
> There are three types of developers:
> 1. Those who must have fancy, high-quality tools to work, and will not be
> able to work in their absence.
> 2. Those who like having fancy tools, but just grumble over quality issues
> or having to drop into a plain text editor.
> 3. Those who find fancy tools to be superfluous and generally distrust
> their use and often people who use them.

I think we could do with a lot more of,

4. Those who like having fancy tools, and who deal with quality issues
by contributing rather than whining.

There are some prominent Scala community members who fall into the
fourth camp (we all know who they are) but they're rather few and far
between and there's a depressingly large constituency of Just
Grumblers.

Just Grumbling isn't so bad if you keep it to yourself, but if done
publicly it has a generally depressive effect and acts as a
disincentive to the contributions which would cure the cause of the
grumbling.

Not enough time to contribute? I don't believe you ... I'd be happy
with even a couple of percent of the time that Scala users are getting
back in terms of productivity gains from using Scala over Java. And to
be clear, I'm not just calling for contributions for the Eclipse
plugin, I'm talking about the toolchain, the standard library,
Netbeans, Emacs, the whole shebang. We all benefit from a lively Scala
ecosystem.

Cheers,

Miles

I was counting those in group #2.  Maybe "like" isn't a strong enough of a word.

On Wed, Feb 18, 2009 at 8:23 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

What about
4.  People who like having fancy tools, and use them effectively.  Oftentimes being more productive when refactoring/writing code.   They resort to plain text editors when required, but by no means are unable to work without them.

I'm  a big fan of IDEs, they make life easier if used right.  I've also done a lot of vi coding, and TBH, I'll take the IDE anyday as long as the bugs don't delay me more than the speed increase from features.  When using the Eclipse C++ IDE, I gained a lot of speed vs doing C++ in VI.  I believe the eclipse plugin is past this break-even point with Miles' recent bug-fixing spree, so I recommend people try the nightly.

Once again, PLEASE CONTRIBUTE!!!

On Wed, Feb 18, 2009 at 8:06 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

David, There are three types of developers: 1.  Those who must have fancy, high-quality tools to work, and will not be able to work in their absence. 2.  Those who like having fancy tools, but just grumble over quality issues or having to drop into a plain text editor. 3.  Those who find fancy tools to be superfluous and generally distrust their use and often people who use them.
A lot of organizations have significant populations of people in group #1, and indeed those ranks are probably expanding as people become developers without ever using a plain text edit and a build script.  For those organizations Scala is not appropriate.
But I think there are enough in #2 and #3 to gain a decent groundswell, and to demonstrate high levels of productivity.
-Erik

On Tue, Feb 17, 2009 at 11:17 PM, dmoshal <dmoshal@gmail.com> wrote:

Tony, I had no idea that my problem was eclipse. Additionally, my front-end
is in Flex, and Flex Builder is an eclipse plugin, so I still need Eclipse.

Relying on java developers switching from Eclipse to emacs (or Netbeans, or
IntelliJ) won't result in widespread adoption of Scala. Fixing the Eclipse
plugin is critical (blocking).

David

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22071948.html
Sent from the Scala mailing list archive at Nabble.com.

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

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

Given the current state and momentum of the IntelliJ plugin, the work I'm
doing, and the inherent toolability of Scala, I'm betting that in twelve
months the best Scala tools will be of quality with the best Java tools, if
not better. That should get those in group 1) on board.

Erik Engbrecht wrote:
>
> David,There are three types of developers:
> 1. Those who must have fancy, high-quality tools to work, and will not be
> able to work in their absence.
> 2. Those who like having fancy tools, but just grumble over quality
> issues
> or having to drop into a plain text editor.
> 3. Those who find fancy tools to be superfluous and generally distrust
> their use and often people who use them.
>
> A lot of organizations have significant populations of people in group #1,
> and indeed those ranks are probably expanding as people become developers
> without ever using a plain text edit and a build script. For those
> organizations Scala is not appropriate.
>
> But I think there are enough in #2 and #3 to gain a decent groundswell,
> and
> to demonstrate high levels of productivity.
>
> -Erik
>
> On Tue, Feb 17, 2009 at 11:17 PM, dmoshal wrote:
>
>>
>> Tony, I had no idea that my problem was eclipse. Additionally, my
>> front-end
>> is in Flex, and Flex Builder is an eclipse plugin, so I still need
>> Eclipse.
>>
>> Relying on java developers switching from Eclipse to emacs (or Netbeans,
>> or
>> IntelliJ) won't result in widespread adoption of Scala. Fixing the
>> Eclipse
>> plugin is critical (blocking).
>>
>> David
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-prod...
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>>
>
>

On Wed, Feb 18, 2009 at 2:44 PM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

Given the current state and momentum of the IntelliJ plugin, the work I'm
doing, and the inherent toolability of Scala, I'm betting that in twelve

"The inherent toolability of Scala"?

Static typing != inherent toolability. Did you have something else in mind?

On Wed, Feb 18, 2009 at 4:22 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Feb 17, 2009 at 7:48 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> (I have not tried Eclipse in the last 6 weeks, so it might be better than
> the last snapshot I looked at.)

If there are issues with Lift and 2.7.3.final then I'd like to hear
about them. I repeat my plea for help from the Lift community in
making the Lift+Eclipse experience as smooth as possible.

And please do try again with the latest nightly builds ... things have
moved on a lot since 2.7.3.

Miles,
I want to have good things to say about the Eclipse plugin.  The IDE issue is now the number one blocker for new Scala project adoption.
I'll be in London for QCon 3/9-3/14.  If you think it'd be valuable, I'll set aside as much time as you want to sit down and work through my development patterns, Lift, Lift projects, and the Eclipse plugin.
Thanks,
David 

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Wed, Feb 18, 2009 at 3:06 PM, David Pollak
wrote:
> I want to have good things to say about the Eclipse plugin. The IDE issue
> is now the number one blocker for new Scala project adoption.
> I'll be in London for QCon 3/9-3/14. If you think it'd be valuable, I'll
> set aside as much time as you want to sit down and work through my
> development patterns, Lift, Lift projects, and the Eclipse plugin.

That sounds like an excellent idea! Awesome even!

Yup, lets make a date for this ...

Cheers,

Miles

Sure. Static typing is part of it, but far more important is the fact that
Scala has are relatively small number of constructs, and that those
constructs are very powerful, very clean, and highly orthogonal. Mix-in
inheritance, for-comprehensions, closures, extractors, lazy values, by-name
parameters, Option, and currying are all language features around which
powerful tooling can be built, particularly for automated refactoring.
Those are just the one's I'm sure about (because I've got design notes on
what those refactorings should be). There are probably also interesting
code assists around Scala's encapsulation facilities, case classes, and
self-types, but I'm less sure about those.

David MacIver wrote:
>
>
> "The inherent toolability of Scala"?
>
> Static typing != inherent toolability. Did you have something else in
> mind?
>
>

On Wed, Feb 18, 2009 at 3:41 PM, Dave Griffith
wrote:
> Those are just the one's I'm sure about (because I've got design notes on
> what those refactorings should be).

Care to share these with us?

Cheers,

Miles

They are currently a bunch of pages in my Moleskine, but here's some
examples.

Curry Method (split a parameter list, and the arg lists of all callers).
Uncurry Method (merge split parameter list, including merging the arg lists
of callers. If method is called with partial args, either complain or
automatically create a helper method which represents the partial
application, and replace partial calls with it.)
Extract Trait (including searching for other classes which can have the same
trait extracted. Tricky with super calls, but not impossible)
Split Trait (splits trait into two traits (putting in self-types if needed),
change all extending classes to extend both traits)
Extract Extractor (select a pattern, automatically create an extractor)
Extract Closure (similar to extract method, but creating a function object)
Introduce by-name parameter
Extract type definition (obvious)
Merge nested for-comprehensions into single for-comprehension (and converse)
Split guard from for-comprehension into nested if (and converse)
Convert for-comprehension into map/filter/flatmap chain (and converse)
Wrap parameter as Option (converting null checks, etc.)
Convert instanceOf/asInstance pair to match
Replace case clause with if body to guarded case clause(s)

Miles Sabin wrote:
>
> On Wed, Feb 18, 2009 at 3:41 PM, Dave Griffith
> wrote:
>> Those are just the one's I'm sure about (because I've got design notes on
>> what those refactorings should be).
>
> Care to share these with us?
>
> Cheers,
>
>
> Miles
>

Nice List!   I like the pattern matching refactorings especially.

On Wed, Feb 18, 2009 at 11:36 AM, Dave Griffith <dave.l.griffith@gmail.com> wrote:

They are currently a bunch of pages in my Moleskine, but here's some
examples.

Curry Method (split a parameter list, and the arg lists of all callers).
Uncurry Method (merge split parameter list, including merging the arg lists
of callers.  If method is called with partial args, either complain or
automatically create a helper method which represents the partial
application, and replace partial calls with it.)
Extract Trait (including searching for other classes which can have the same
trait extracted.  Tricky with super calls, but not impossible)
Split Trait (splits trait into two traits (putting in self-types if needed),
change all extending classes to extend both traits)
Extract Extractor (select a pattern, automatically create an extractor)
Extract Closure (similar to extract method, but creating a function object)
Introduce by-name parameter
Extract type definition (obvious)
Merge nested for-comprehensions into single for-comprehension (and converse)
Split guard from for-comprehension into nested if (and converse)
Convert for-comprehension into map/filter/flatmap chain (and converse)
Wrap parameter as Option (converting null checks, etc.)
Convert instanceOf/asInstance pair to match
Replace case clause with if body to guarded case clause(s)






Miles Sabin wrote:
>
> On Wed, Feb 18, 2009 at 3:41 PM, Dave Griffith
> <dave.l.griffith@gmail.com> wrote:
>> Those are just the one's I'm sure about (because I've got design notes on
>> what those refactorings should be).
>
> Care to share these with us?
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel:    +44 (0)1273 720 779
> mobile: +44 (0)7813 944 528
> skype:  milessabin
>
>

--
View this message in context: http://www.nabble.com/Scala%3A-Great-potential%2C-but-not-ready-for-production-tp22064598p22082676.html
Sent from the Scala mailing list archive at Nabble.com.

On Wed, Feb 18, 2009 at 4:36 PM, Dave Griffith
wrote:
> They are currently a bunch of pages in my Moleskine, but here's some
> examples.

Excellent stuff.

If you're considering actively working on these it'd be great if you
could do them as scalac plugins or extensions, or at least make use of
scalac's AST. If you do it should be possible to integrate them with
Eclipse and Netbeans quite straightforwardly (both plugins use scalac
internally) and it could be a useful starting point for hooking into
Emacs, building other tools etc. ...

Cheers,

Miles

Miles Sabin wrote:
> If there are issues with Lift and 2.7.3.final then I'd like to hear
> about them. I repeat my plea for help from the Lift community in
> making the Lift+Eclipse experience as smooth as possible.
>
> And please do try again with the latest nightly builds ... things have
> moved on a lot since 2.7.3.

Does the current nightly with version 2.8.0.r17137... work with 2.7.3
final of scala?

TIA

Brett Knights

On Wed, Feb 18, 2009 at 5:02 PM, Brett Knights
wrote:
> Does the current nightly with version 2.8.0.r17137... work with 2.7.3 final
> of scala?

Not at the moment, no. Ismael Juma has put some time into putting
together a build which does (I'll let him post a pointer when/if he's
ready because I think he might be in the middle of updating it). But I
think that at the moment you should be OK with a nightly build of the
compiler and libraries as well as the plugin.

I'm currently working through a major refactoring of the plugin which
should make it quite a bit more accessible to casual hackers. When I'm
done with that (probably before the end of next week) I'll look into
putting together an official backport branch.

Cheers,

Miles

On Wed, 2009-02-18 at 09:02 -0800, Brett Knights wrote:
> Miles Sabin wrote:
> > If there are issues with Lift and 2.7.3.final then I'd like to hear
> > about them. I repeat my plea for help from the Lift community in
> > making the Lift+Eclipse experience as smooth as possible.
> >
> > And please do try again with the latest nightly builds ... things have
> > moved on a lot since 2.7.3.
>
> Does the current nightly with version 2.8.0.r17137... work with 2.7.3
> final of scala?

Sort of. There's a non-official build of r17179 with the latest from the
2.7.x branch for the compiler and standard libraries. See:

http://blog.juma.me.uk/2009/02/18/scala-plugin-for-eclipse-snapshot-r17139/

Hope it helps,
Ismael

Miles, I'm happy to comment on the eclipse issues.

Firsly, Eclipse is critical to us, because we use Flex, and while it is true
that other IDE's have plugins for Flex development, only eclipse has the
commercial Adobe plugin, which has a very useful visual editor (which
actually works). Like millions of other developers, we are very happy with
the eclipse environment, it works for us, and has an enormous eco-system of
plugins. I have both Netbeans and IntelliJ (licensed) on my machine, and
from time to time I try them out, but I always come back to Eclipse. Emacs
and text editing is not a serious alternative for us.

Ignoring Eclipse would be a fatal marketing error for Scala, the language
would simply be relegated to obscurity. For us, we're probably going to
choose to stay in Eclipse rather than develop in 2 environments (Flex in
Eclipse, Scala in Netbeans), which means that we drop the Scala port for
now.

Secondly, your eclipse scala plugin is actually very good overall. Clearly a
lot of effort has gone into it, and I don't mean (and didn't mean) to
diminish that. Rather, I have enormous respect for the eclipse plugin team -
certainly I couldn't do what you've done! The problems we ran into, while
blocking, probably wouldn't require a large level of effort to fix, and I'll
explain them below.

Lastly, your plugin compiles and launches scala amazingly slickly and
quickly.
So, please keep up the good work.

The problems:

My impression was that the plugin has namespace issues, especially when:

a) wildcards are used in import statements, e.g.: import foo.bar._

b) if package names are different from the directory structure: doesn't seem
to be any checking of this

c) when a single file contains a combination of classes/traits/objects. My
example, from above is:

a file named src/om/Topic.scala

package om

abstract class Topic (val name :String)
object Foo extends Topic ("foo")
object Bar extends Topic ("bar")

The plugin can't seem to find Topic, and this behaviour is erratic, changing
every time the project is 'cleaned'.

d) when there are namespace collisions. eg. assume classes
om/foo/ClassA.scala, and om/bar/ClassA.scala.

if imported as follows:
import om.foo._
import om.bar._

The plugin doesn't appear to pick up that there is a potential namespace
problem if the class ClassA is declared.

Regarding Tony's styles:
I can't really complain, as he was actually the most helpful in my prior
posts, answering in minutes my blocking question regarding implementing java
interfaces in Scala.
So, no worries Tony, overall, I'd take both the help on blocking issues
together with a bit of abuse, over neither.

Dave

I am in active development, but am doing so as an IDEA plugin, using IDEA's
implementation of the Scala AST. If history is any judge, it shouldn't be
too long before someone (else) reimplements them for Eclipse/NetBeans.

Miles Sabin wrote:
>
> On Wed, Feb 18, 2009 at 4:36 PM, Dave Griffith
> wrote:
>> They are currently a bunch of pages in my Moleskine, but here's some
>> examples.
>
> Excellent stuff.
>
> If you're considering actively working on these it'd be great if you
> could do them as scalac plugins or extensions, or at least make use of
> scalac's AST. If you do it should be possible to integrate them with
> Eclipse and Netbeans quite straightforwardly (both plugins use scalac
> internally) and it could be a useful starting point for hooking into
> Emacs, building other tools etc. ...
>
> Cheers,
>
>
> Miles
>

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

No actually, I checked and checked again. There are three. 1, 2 and 3
are allegedly IDE-related.

Miles Sabin wrote:
> On Wed, Feb 18, 2009 at 11:49 AM, Tony Morris
> wrote:
>> I counted 3/4 issues related to IDE.
>
> You can't count ... only 1 and 3 are IDE specific.
>
> Cheers,
>
>
> Miles
>

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

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

iD8DBQFJnIHgmnpgrYe6r60RAoU8AJ9s5ILtHWJHsEmhsxEPAG5StZ/m5wCeICr0
gdHfwga5/0chIKt74SAPm10=
=PbqQ
-----END PGP SIGNATURE-----

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

If we're talking about what there actually is, then there are none.
Perhaps we need a discussion on concept formation (but I'd rather not)?

Love the trolling charge - you're on fire! ;)

Miles Sabin wrote:
> On Wed, Feb 18, 2009 at 9:47 PM, Tony Morris
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> No actually, I checked and checked again. There are three. 1, 2
>> and 3 are allegedly IDE-related.
>
> Please take your trolling elsewhere ...
>
> There are actually two. That's _actually_, not allegedly or
> hypothetically.
>
> Cheers,
>
>
> Miles
>

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

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

iD8DBQFJnITNmnpgrYe6r60RAja3AKDIuks7OwJ2PuAkMNNaJ7ylJJfD5gCgzRJx
SoS90DnRU1AOgZmNkRfQ2JU=
=kPsx
-----END PGP SIGNATURE-----

On Wed, Feb 18, 2009 at 9:47 PM, Tony Morris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> No actually, I checked and checked again. There are three. 1, 2 and 3
> are allegedly IDE-related.

Please take your trolling elsewhere ...

There are actually two. That's _actually_, not allegedly or hypothetically.

Cheers,

Miles

Watching this thread degenerate is really a bit sad in light of http://www.reddit.com/r/programming/comments/7y5zw/scala_great_potential_but_not_ready_for_production/c07q6n9

On Wed, Feb 18, 2009 at 9:59 PM, Tony Morris wrote:
> If we're talking about what there actually is, then there are none.
> Perhaps we need a discussion on concept formation (but I'd rather not)?

You really are a ridiculous buffoon ...

Cheers,

Miles

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

You really are a pancake ... :)

Cheers,

Miles Sabin wrote:
> On Wed, Feb 18, 2009 at 9:59 PM, Tony Morris
> wrote:
>> If we're talking about what there actually is, then there are
>> none. Perhaps we need a discussion on concept formation (but I'd
>> rather not)?
>
> You really are a ridiculous buffoon ...
>
> Cheers,
>
>
> Miles
>

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

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

iD8DBQFJnIdWmnpgrYe6r60RArhWAJ0RFTNyuIq3uYPW7DX4cc16cwJvzACbBiBd
95gjmRSbVVzxnYnaycuyL5k=
=6ce7
-----END PGP SIGNATURE-----

Miles Sabin wrote:
> On Wed, Feb 18, 2009 at 1:06 PM, Erik Engbrecht
> There are some prominent Scala community members who fall into the
> fourth camp (we all know who they are) but they're rather few and far
> between and there's a depressingly large constituency of Just
> Grumblers.
>
> Just Grumbling isn't so bad if you keep it to yourself, but if done
> publicly it has a generally depressive effect and acts as a
> disincentive to the contributions which would cure the cause of the
> grumbling.

I think there's no reality to that. If you work on an open-source project, just
expect it. Personally, I contribute my time to Subversion and am a committer on
that project and we always get comments. The latest negative feedback is how it
sucks as Subversion is not a distributed version control system. One just has
to expect it if you're working in a public space.

> Not enough time to contribute? I don't believe you ... I'd be happy
> with even a couple of percent of the time that Scala users are getting
> back in terms of productivity gains from using Scala over Java. And to
> be clear, I'm not just calling for contributions for the Eclipse
> plugin, I'm talking about the toolchain, the standard library,
> Netbeans, Emacs, the whole shebang. We all benefit from a lively Scala
> ecosystem.

Subversion has helped the Scala community indirectly. Additionally, we're
working on getting legal approval to open-sourcing a Scala database migration
utility and some Spring integration code.

Regards,
Blair

On Wed, Feb 18, 2009 at 10:43 PM, Blair Zajac wrote:
> Subversion has helped the Scala community indirectly. Additionally, we're
> working on getting legal approval to open-sourcing a Scala database
> migration utility and some Spring integration code.

Sure. And my comments weren't aimed at you ... you're pretty clearly
in the fourth camp :-)

Cheers,

Miles

--
Miles Sabin
tel: +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype: milessabin