This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Report on First Production Scala Project

15 replies
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
I've just spent the last few weeks building some utility code in Scala and thought I would share my experience.

I've been playing with Scala for about 4 years now and consider myself an informed, but casual user of Scala. I have an MSc in Computing Science and I am currently a Software Architect at Kodak.

After much consideration I recently decided to incorporate some Scala in production code:
  1. This is limited to some command line utilities. I chose Scala over the ubiquitous Windows .bat and .vbs scripts we have everywhere. On my last project I was horrified at trying to unravel the twisted thinking that goes into .bat and .vbs code. I thought I would try Scala over Groovy or something else. .cmd, .bat, .vbs and power-shell scripting very much reminds me of the horror of .sh, .csh, awk & grep spaghetti code I used to find in Unix all the time.

  2. My boss is always giving me grief about considering yet another programming language, although we really have not adopted anything new for over 6 years when we started replacing more of our C++/COM code with C#/.NET. We have been using Java for over 10 years. I added some Groovy to our product a few years ago, but it is only for the test team and does not impact customers. We have a bunch of firmware management scripts written in JavaScript, but that product is nearing EOL. While he is still skeptical of Scala, I am the Software Architect, and to some degree it is better to ask for forgiveness than permission.

  3. Most of my team is scared of Scala, probably because of the various Scala presentations I have given over the years. Face it - FP just scares some people. As the Software Architect I have to keep my team's skills and comfort in mind. I have deliberately chosen a small area of code that will not likely impact any of them significantly. Recently when I showed them some of the more simple source code of my utilities they did not feel so uneasy.

  4. The command line utilities are in a script-like environment. I do not run Scala as scripts but as compiled code. The utilities are launched by one command from a .bat or .sh file, that then invokes a .scala file as a script. This script checks the source code of the rest of the utilities against the .class files and recompiles anything out of date. Finally it calls the compiled code directly. While there is significant lag the first time the utilities are run, especially if they have to compile, subsequent runs are much quicker when the JVM is warmed up. The utilities are not run often so this lag is not a big issue. Also, the utilities will likely be run from other software as a background process so will not be a large part of the user experience. The nice part of this environment is that all the Scala sources are deployed. You only have to edit the .scala files with a conventional editor and run the utilities so the experience is almost exactly the same as a normal scripting environment.

  5. Another benefit I have found is that my utilities can call my main client and service code directly since it is written in Java. I can immediately leverage all the investment in the logging system and other APIs that have been developed in Java. This is really elegant tight coupling between the utilities and the main product code. Also, unlike .bat and .vbs files (or Windows PowerShell), the utilities are portable across Windows, OS X and Linux.

  6. The approach I have taken is that there are different levels of sophistication in the various source files. The top level commands like backup, restore, zip, etc. have very simple easy to read code that should be straightforward for most people to modify whether they know Scala or not. The infrastructure code (APIs and types) uses more sophisticated Scala features, but it is less likely anyone will have to modify it too much. I have started a practice of creating 'Scala Newbie Notes' at the end of various source files that explain what is going on to people not familiar with Scala. This also helps me too as a casual user of Scala who can be prone to forget basic concepts easily. In particular, these utilities are designed to be a learning environment for people new to Scala. These utilities are designed very much to be a toe-in-the-door for Scala in our environment.

  7. Looking back at the last few weeks it is clear building the utilities took 3 or 4 times longer because of my inexperience with Scala. There were some issues that literally took me days to figure out in Scala whereas the solution in Java would have been and hour or so. One of the issues is that once you get a piece of Scala code working correctly, then you start seeing all kinds of ways to refactor and improve the code. This is much more of a factor than with Java as there are so many more ways to improve mediocre Scala code than mediocre Java code. Often I would get my procedural Scala code working correctly, then spend yet again as much time refactoring it to an FP style. I also find that with Scala there are many more opportunities to fine tune the readability of the code than with Java. This is a huge time sink for obsessive-compulsive perfectionists who like to write text-book quality code.

  8. There is definitely a huge price to pay developing Scala code because the IDE support is so poor. Writing Java code in Eclipse goes so much easier because of all the help the IDE editors give you. The fact that Eclipse lets you hover the cursor over things and brings up these great semi-persistent tool-tips with hyperlinked javadoc makes productivity incredibly high. Also, the IDE editor is great at pointing out errors and warnings and offering options to remedy the problems. The two most frustrating parts of writing Scala code are the lack of great IDE support and the lack of excellent scaladoc pages. I profoundly believe the biggest opportunity to making Scala more productive and less frustrating is improving the IDE support.

  9. In my current utilities environment the previous problem is compounded because I have my Scala source code under src/main/resources instead of src/main/scala or src/main/java so the IDE does not know how to compile things. I am still considering ways to resolve this. I do it this way because as resources, the Scala source files are easy for my application to deploy. The editor still does the basic lexical stuff, but not nearly enough in terms of syntax and semantics. Essentially my development cycle is (1) edit the Scala source in Eclipse, (2) copy/paste the source files from Eclipse into my bin/src folder, and (3) run the utilities from the command line and watch the Scala compiler complain about all my mistakes. However, this is similar to the experience someone in the field would find having to hack the utilities code at a customer site with no IDE or other development tools.

  10. To be clear, the Scala compiler diagnostics are not nearly as good as the Java compiler diagnostics. It is a shock sometimes trying to fathom what the hell the Scala compiler is trying to tell me - usually it makes me feel stupid - as opposed to the great diagnostics I am used to from over a decade of improvements in javac. On the other hand, the Scala compiler diagnostics are significantly better than those when .bat, .vbs, or power-shell scripts go awry, which is still a good reason for using it.

  11. Dealing with the Scala community is certainly an experience to be appreciated. In the Java community there are a smaller set of solutions for issues you encounter, but in the Scala community there are multifarious ways to address the same issue, and at least half the solutions are stuff I really cannot understand without considerable thought.

  12. Overall my experience with Scala the last few weeks has been wonderful from an intellectual point of view, but terrible from a productivity point of view. I will be begging forgiveness from my boss for a long time to come as I could have done all this in Java in 1/4 the time. However, it would have taken me just as long to write all these utilities in .bat, .vbs and/or power shell. To be certain my productivity with Scala will continue to improve over time, but my extravagance the last few weeks has seriously impacted our delivery schedule.

  13. I am on the whole quite pleased with the Scala code I have written. I am also enormously grateful to the community of Scala enthusiasts who have cheerfully and patiently helped me along. My code is quite clean and readable, and the main body of my commands like backup, restore, zip (error report) are almost trivial to read. It accomplishes what I set out to do in trying to replace the horror of .cmd, .bat & .vbs hell I was dealing with before. If I were to compare utilities development to creating an enterprise web application then using Scala would be like building a rich internet applications (RIA) in one language, while using .cmd, .bat, .vbs and power shell is like the conventional hackery of HTML, XML, JSP, Struts, EJB, JavaScript, etc. and other glue, staples, baler twine and alphabet soup that too many people still use.

  14. I have to keep reassessing my opinion of Scala every few weeks, but here is where I am now. Scala is very much 'the kitchen sink' version of Java James Gosling talked about once. Java is a very conservative language while Scala is a very progressive one. Java is very stable and dependable, while things continue to evolve rapidly in Scala. I soundly believe that any software developer or architect who wants to stay informed of leading-edge, and bleeding-edge developments in computing science needs to include Scala in their perspective, but that we still have to seriously consider when and how we use Scala in our commercial products and with the conventional skills and talent of our average developers.
I am just wrapping up the final details on my utilities package, so I thought I would capture my thoughts while they were still fresh in my mind.

Cheers, Eric
Mirko Stocker
Joined: 2009-09-10,
User offline. Last seen 45 weeks 6 days ago.
Re: Report on First Production Scala Project

Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
> In my current utilities environment the previous problem is compounded
> because I have my Scala source code under src/main/resources instead of
> src/main/scala or src/main/java so the IDE does not know how to compile
> things.

Have you tried adding "src/main/resources" as a source folder? You can do this
from the context menu of the resource folder -> Build Path -> Use as Source
Folder. That way, you should get all the usual functionality from the Scala
IDE..

Cheers,

Mirko

ARKBAN
Joined: 2011-08-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Report on First Production Scala Project

My company uses IntelliJ for all its Scala work because it has pretty
decent support. I'd suggest giving it a look.

ARKBAN

On 12/8/11 9:47 AM, Eric Kolotyluk wrote:
> There is definitely a huge price to pay developing Scala code because
> the IDE support is so poor.

sreque 2
Joined: 2011-11-15,
User offline. Last seen 42 years 45 weeks ago.
Re: Report on First Production Scala Project

For the IDE experience, did you also think to try creating your scala
scripts in a separate project and then copying the files over to the
src/main/resources folder of your other project, perhaps as a separate
build step? It seems like, even with your constraints, you could have
had a much better editing experience with Scala.

Also, I remember in the past being able to get Scala documentation
from my IDE. Instead of relying on tooltips, I just used Eclipse's
symbol hyperlinking to jump straight to the source code, where I could
then read the documentation for the symbol or read the source code if
I needed more information.

On Dec 8, 8:47 am, Eric Kolotyluk wrote:
> I've just spent the last few weeks building some utility code in Scala
> and thought I would share my experience.
>
> I've been playing with Scala for about 4 years now and consider myself
> an informed, but casual user of Scala. I have an MSc in Computing
> Science and I am currently a Software Architect at Kodak.
>
> After much consideration I recently decided to incorporate some Scala in
> production code:
>
>  1. This is limited to some command line utilities. I chose Scala over
>     the ubiquitous Windows .bat and .vbs scripts we have everywhere. On
>     my last project I was horrified at trying to unravel the twisted
>     thinking that goes into .bat and .vbs code. I thought I would try
>     Scala over Groovy or something else. .cmd, .bat, .vbs and
>     power-shell scripting very much reminds me of the horror of .sh,
>     .csh, awk & grep spaghetti code I used to find in Unix all the time.
>
>  2. My boss is always giving me grief about considering yet another
>     programming language, although we really have not adopted anything
>     new for over 6 years when we started replacing more of our C++/COM
>     code with C#/.NET. We have been using Java for over 10 years. I
>     added some Groovy to our product a few years ago, but it is only for
>     the test team and does not impact customers. We have a bunch of
>     firmware management scripts written in JavaScript, but that product
>     is nearing EOL. While he is still skeptical of Scala, I am the
>     Software Architect, and to some degree it is better to ask for
>     forgiveness than permission.
>
>  3. Most of my team is scared of Scala, probably because of the various
>     Scala presentations I have given over the years. Face it - FP just
>     scares some people. As the Software Architect I have to keep my
>     team's skills and comfort in mind. I have deliberately chosen a
>     small area of code that will not likely impact any of them
>     significantly. Recently when I showed them some of the more simple
>     source code of my utilities they did not feel so uneasy.
>
>  4. The command line utilities are in a script-like environment. I do
>     not run Scala as scripts but as compiled code. The utilities are
>     launched by one command from a .bat or .sh file, that then invokes a
>     .scala file as a script. This script checks the source code of the
>     rest of the utilities against the .class files and recompiles
>     anything out of date. Finally it calls the compiled code directly.
>     While there is significant lag the first time the utilities are run,
>     especially if they have to compile, subsequent runs are much quicker
>     when the JVM is warmed up. The utilities are not run often so this
>     lag is not a big issue. Also, the utilities will likely be run from
>     other software as a background process so will not be a large part
>     of the user experience. The nice part of this environment is that
>     all the Scala sources are deployed. You only have to edit the .scala
>     files with a conventional editor and run the utilities so the
>     experience is almost exactly the same as a normal scripting environment.
>
>  5. Another benefit I have found is that my utilities can call my main
>     client and service code directly since it is written in Java. I can
>     immediately leverage all the investment in the logging system and
>     other APIs that have been developed in Java. This is really elegant
>     tight coupling between the utilities and the main product code.
>     Also, unlike .bat and .vbs files (or Windows PowerShell), the
>     utilities are portable across Windows, OS X and Linux.
>
>  6. The approach I have taken is that there are different levels of
>     sophistication in the various source files. The top level commands
>     like backup, restore, zip, etc. have very simple easy to read code
>     that should be straightforward for most people to modify whether
>     they know Scala or not. The infrastructure code (APIs and types)
>     uses more sophisticated Scala features, but it is less likely anyone
>     will have to modify it too much. I have started a practice of
>     creating 'Scala Newbie Notes' at the end of various source files
>     that explain what is going on to people not familiar with Scala.
>     This also helps me too as a casual user of Scala who can be prone to
>     forget basic concepts easily. In particular, these utilities are
>     designed to be a learning environment for people new to Scala. These
>     utilities are designed very much to be a toe-in-the-door for Scala
>     in our environment.
>
>  7. Looking back at the last few weeks it is clear building the
>     utilities took 3 or 4 times longer because of my inexperience with
>     Scala. There were some issues that literally took me days to figure
>     out in Scala whereas the solution in Java would have been and hour
>     or so. One of the issues is that once you get a piece of Scala code
>     working correctly, then you start seeing all kinds of ways to
>     refactor and improve the code. This is much more of a factor than
>     with Java as there are so many more ways to improve mediocre Scala
>     code than mediocre Java code. Often I would get my procedural Scala
>     code working correctly, then spend yet again as much time
>     refactoring it to an FP style. I also find that with Scala there are
>     many more opportunities to fine tune the readability of the code
>     than with Java. This is a huge time sink for obsessive-compulsive
>     perfectionists who like to write text-book quality code.
>
>  8. There is definitely a huge price to pay developing Scala code
>     because the IDE support is so poor. Writing Java code in Eclipse
>     goes so much easier because of all the help the IDE editors give
>     you. The fact that Eclipse lets you hover the cursor over things and
>     brings up these great semi-persistent tool-tips with hyperlinked
>     javadoc makes productivity incredibly high. Also, the IDE editor is
>     great at pointing out errors and warnings and offering options to
>     remedy the problems. The two most frustrating parts of writing Scala
>     code are the lack of great IDE support and the lack of excellent
>     scaladoc pages. I profoundly believe the biggest opportunity to
>     making Scala more productive and less frustrating is improving the
>     IDE support.
>
>  9. In my current utilities environment the previous problem is
>     compounded because I have my Scala source code under
>     src/main/resources instead of src/main/scala or src/main/java so the
>     IDE does not know how to compile things. I am still considering ways
>     to resolve this. I do it this way because as resources, the Scala
>     source files are easy for my application to deploy. The editor still
>     does the basic lexical stuff, but not nearly enough in terms of
>     syntax and semantics. Essentially my development cycle is (1) edit
>     the Scala source in Eclipse, (2) copy/paste the source files from
>     Eclipse into my bin/src folder, and (3) run the utilities from the
>     command line and watch the Scala compiler complain about all my
>     mistakes. However, this is similar to the experience someone in the
>     field would find having to hack the utilities code at a customer
>     site with no IDE or other development tools.
>
> 10. To be clear, the Scala compiler diagnostics are not nearly as good
>     as the Java compiler diagnostics. It is a shock sometimes trying to
>     fathom what the hell the Scala compiler is trying to tell me -
>     usually it makes me feel stupid - as opposed to the great
>     diagnostics I am used to from over a decade of improvements in
>     javac. On the other hand, the Scala compiler diagnostics are
>     significantly better than those when .bat, .vbs, or power-shell
>     scripts go awry, which is still a good reason for using it.
>
> 11. Dealing with the Scala community is certainly an experience to be
>     appreciated. In the Java community there are a smaller set of
>     solutions for issues you encounter, but in the Scala community there
>     are multifarious ways to address the same issue, and at least half
>     the solutions are stuff I really cannot understand without
>     considerable thought.
>
> 12. Overall my experience with Scala the last few weeks has been
>     wonderful from an intellectual point of view, but terrible from a
>     productivity point of view. I will be begging forgiveness from my
>     boss for a long time to come as I could have done all this in Java
>     in 1/4 the time. However, it would have taken me just as long to
>     write all these utilities in .bat, .vbs and/or power shell. To be
>     certain my productivity with Scala will continue to improve over
>     time, but my extravagance the last few weeks has seriously impacted
>     our delivery schedule.
>
> 13. I am on the whole quite pleased with the Scala code I have written.
>     I am also enormously grateful to the community of Scala enthusiasts
>     who have cheerfully and patiently helped me along. My code is quite
>     clean and readable, and the main body of my commands like backup,
>     restore, zip (error report) are almost trivial to read. It
>     accomplishes what I set out to do in trying to replace the horror of
>     .cmd, .bat & .vbs hell I was dealing with before. If I were to
>     compare utilities development to creating an enterprise web
>     application then using Scala would be like building a rich internet
>     applications (RIA) in one language, while using .cmd, .bat, .vbs and
>     power shell is like the conventional hackery of HTML, XML, JSP,
>     Struts, EJB, JavaScript, etc. and other glue, staples, baler twine
>     and alphabet soup that too many people still use.
>
> 14. I have to keep reassessing my opinion of Scala every few weeks, but
>     here is where I am now. Scala is very much 'the kitchen sink'
>     version of Java James Gosling talked about once. Java is a very
>     conservative language while Scala is a very progressive one. Java is
>     very stable and dependable, while things continue to evolve rapidly
>     in Scala. I soundly believe that any software...
>
> read more »

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Report on First Production Scala Project

Thanks - I have used IntelliJ in the past and it does work pretty good.
However, our team uses Eclipse or Visual Studio for most projects.
While I will probably play around with IntelliJ on my own, I don't want
to go to the effort to change the status quo of IDE's at this time.

Cheers, Eric

On 2011-12-08 7:17 AM, ARKBAN wrote:
> My company uses IntelliJ for all its Scala work because it has pretty
> decent support. I'd suggest giving it a look.
>
> ARKBAN
>
> On 12/8/11 9:47 AM, Eric Kolotyluk wrote:
>> There is definitely a huge price to pay developing Scala code because
>> the IDE support is so poor.

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Re: Report on First Production Scala Project

On 2011-12-08 9:20 AM, sreque wrote:
> For the IDE experience, did you also think to try creating your scala
> scripts in a separate project and then copying the files over to the
> src/main/resources folder of your other project, perhaps as a separate
> build step? It seems like, even with your constraints, you could have
> had a much better editing experience with Scala.

Thanks - I have considered doing that and probably will go that route
when I have more time to figure out those steps in Maven.

>
> Also, I remember in the past being able to get Scala documentation
> from my IDE. Instead of relying on tooltips, I just used Eclipse's
> symbol hyperlinking to jump straight to the source code, where I could
> then read the documentation for the symbol or read the source code if
> I needed more information.

Now that sounds interesting :-) How do I do that?

Cheers, Eric

>
> On Dec 8, 8:47 am, Eric Kolotyluk wrote:
>> I've just spent the last few weeks building some utility code in Scala
>> and thought I would share my experience.
>>
>> I've been playing with Scala for about 4 years now and consider myself
>> an informed, but casual user of Scala. I have an MSc in Computing
>> Science and I am currently a Software Architect at Kodak.
>>
>> After much consideration I recently decided to incorporate some Scala in
>> production code:
>>
>> 1. This is limited to some command line utilities. I chose Scala over
>> the ubiquitous Windows .bat and .vbs scripts we have everywhere. On
>> my last project I was horrified at trying to unravel the twisted
>> thinking that goes into .bat and .vbs code. I thought I would try
>> Scala over Groovy or something else. .cmd, .bat, .vbs and
>> power-shell scripting very much reminds me of the horror of .sh,
>> .csh, awk& grep spaghetti code I used to find in Unix all the time.
>>
>> 2. My boss is always giving me grief about considering yet another
>> programming language, although we really have not adopted anything
>> new for over 6 years when we started replacing more of our C++/COM
>> code with C#/.NET. We have been using Java for over 10 years. I
>> added some Groovy to our product a few years ago, but it is only for
>> the test team and does not impact customers. We have a bunch of
>> firmware management scripts written in JavaScript, but that product
>> is nearing EOL. While he is still skeptical of Scala, I am the
>> Software Architect, and to some degree it is better to ask for
>> forgiveness than permission.
>>
>> 3. Most of my team is scared of Scala, probably because of the various
>> Scala presentations I have given over the years. Face it - FP just
>> scares some people. As the Software Architect I have to keep my
>> team's skills and comfort in mind. I have deliberately chosen a
>> small area of code that will not likely impact any of them
>> significantly. Recently when I showed them some of the more simple
>> source code of my utilities they did not feel so uneasy.
>>
>> 4. The command line utilities are in a script-like environment. I do
>> not run Scala as scripts but as compiled code. The utilities are
>> launched by one command from a .bat or .sh file, that then invokes a
>> .scala file as a script. This script checks the source code of the
>> rest of the utilities against the .class files and recompiles
>> anything out of date. Finally it calls the compiled code directly.
>> While there is significant lag the first time the utilities are run,
>> especially if they have to compile, subsequent runs are much quicker
>> when the JVM is warmed up. The utilities are not run often so this
>> lag is not a big issue. Also, the utilities will likely be run from
>> other software as a background process so will not be a large part
>> of the user experience. The nice part of this environment is that
>> all the Scala sources are deployed. You only have to edit the .scala
>> files with a conventional editor and run the utilities so the
>> experience is almost exactly the same as a normal scripting environment.
>>
>> 5. Another benefit I have found is that my utilities can call my main
>> client and service code directly since it is written in Java. I can
>> immediately leverage all the investment in the logging system and
>> other APIs that have been developed in Java. This is really elegant
>> tight coupling between the utilities and the main product code.
>> Also, unlike .bat and .vbs files (or Windows PowerShell), the
>> utilities are portable across Windows, OS X and Linux.
>>
>> 6. The approach I have taken is that there are different levels of
>> sophistication in the various source files. The top level commands
>> like backup, restore, zip, etc. have very simple easy to read code
>> that should be straightforward for most people to modify whether
>> they know Scala or not. The infrastructure code (APIs and types)
>> uses more sophisticated Scala features, but it is less likely anyone
>> will have to modify it too much. I have started a practice of
>> creating 'Scala Newbie Notes' at the end of various source files
>> that explain what is going on to people not familiar with Scala.
>> This also helps me too as a casual user of Scala who can be prone to
>> forget basic concepts easily. In particular, these utilities are
>> designed to be a learning environment for people new to Scala. These
>> utilities are designed very much to be a toe-in-the-door for Scala
>> in our environment.
>>
>> 7. Looking back at the last few weeks it is clear building the
>> utilities took 3 or 4 times longer because of my inexperience with
>> Scala. There were some issues that literally took me days to figure
>> out in Scala whereas the solution in Java would have been and hour
>> or so. One of the issues is that once you get a piece of Scala code
>> working correctly, then you start seeing all kinds of ways to
>> refactor and improve the code. This is much more of a factor than
>> with Java as there are so many more ways to improve mediocre Scala
>> code than mediocre Java code. Often I would get my procedural Scala
>> code working correctly, then spend yet again as much time
>> refactoring it to an FP style. I also find that with Scala there are
>> many more opportunities to fine tune the readability of the code
>> than with Java. This is a huge time sink for obsessive-compulsive
>> perfectionists who like to write text-book quality code.
>>
>> 8. There is definitely a huge price to pay developing Scala code
>> because the IDE support is so poor. Writing Java code in Eclipse
>> goes so much easier because of all the help the IDE editors give
>> you. The fact that Eclipse lets you hover the cursor over things and
>> brings up these great semi-persistent tool-tips with hyperlinked
>> javadoc makes productivity incredibly high. Also, the IDE editor is
>> great at pointing out errors and warnings and offering options to
>> remedy the problems. The two most frustrating parts of writing Scala
>> code are the lack of great IDE support and the lack of excellent
>> scaladoc pages. I profoundly believe the biggest opportunity to
>> making Scala more productive and less frustrating is improving the
>> IDE support.
>>
>> 9. In my current utilities environment the previous problem is
>> compounded because I have my Scala source code under
>> src/main/resources instead of src/main/scala or src/main/java so the
>> IDE does not know how to compile things. I am still considering ways
>> to resolve this. I do it this way because as resources, the Scala
>> source files are easy for my application to deploy. The editor still
>> does the basic lexical stuff, but not nearly enough in terms of
>> syntax and semantics. Essentially my development cycle is (1) edit
>> the Scala source in Eclipse, (2) copy/paste the source files from
>> Eclipse into my bin/src folder, and (3) run the utilities from the
>> command line and watch the Scala compiler complain about all my
>> mistakes. However, this is similar to the experience someone in the
>> field would find having to hack the utilities code at a customer
>> site with no IDE or other development tools.
>>
>> 10. To be clear, the Scala compiler diagnostics are not nearly as good
>> as the Java compiler diagnostics. It is a shock sometimes trying to
>> fathom what the hell the Scala compiler is trying to tell me -
>> usually it makes me feel stupid - as opposed to the great
>> diagnostics I am used to from over a decade of improvements in
>> javac. On the other hand, the Scala compiler diagnostics are
>> significantly better than those when .bat, .vbs, or power-shell
>> scripts go awry, which is still a good reason for using it.
>>
>> 11. Dealing with the Scala community is certainly an experience to be
>> appreciated. In the Java community there are a smaller set of
>> solutions for issues you encounter, but in the Scala community there
>> are multifarious ways to address the same issue, and at least half
>> the solutions are stuff I really cannot understand without
>> considerable thought.
>>
>> 12. Overall my experience with Scala the last few weeks has been
>> wonderful from an intellectual point of view, but terrible from a
>> productivity point of view. I will be begging forgiveness from my
>> boss for a long time to come as I could have done all this in Java
>> in 1/4 the time. However, it would have taken me just as long to
>> write all these utilities in .bat, .vbs and/or power shell. To be
>> certain my productivity with Scala will continue to improve over
>> time, but my extravagance the last few weeks has seriously impacted
>> our delivery schedule.
>>
>> 13. I am on the whole quite pleased with the Scala code I have written.
>> I am also enormously grateful to the community of Scala enthusiasts
>> who have cheerfully and patiently helped me along. My code is quite
>> clean and readable, and the main body of my commands like backup,
>> restore, zip (error report) are almost trivial to read. It
>> accomplishes what I set out to do in trying to replace the horror of
>> .cmd, .bat& .vbs hell I was dealing with before. If I were to
>> compare utilities development to creating an enterprise web
>> application then using Scala would be like building a rich internet
>> applications (RIA) in one language, while using .cmd, .bat, .vbs and
>> power shell is like the conventional hackery of HTML, XML, JSP,
>> Struts, EJB, JavaScript, etc. and other glue, staples, baler twine
>> and alphabet soup that too many people still use.
>>
>> 14. I have to keep reassessing my opinion of Scala every few weeks, but
>> here is where I am now. Scala is very much 'the kitchen sink'
>> version of Java James Gosling talked about once. Java is a very
>> conservative language while Scala is a very progressive one. Java is
>> very stable and dependable, while things continue to evolve rapidly
>> in Scala. I soundly believe that any software...
>>
>> read more »

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Report on First Production Scala Project

OK, I selected Use as Source Folder, but Eclipse now seems to think this
is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala
source?

Cheers, Eric

On 2011-12-08 7:06 AM, Mirko Stocker wrote:
> Hi Eric
>
> Thanks for your report, it was very interesting to read.
>
> On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
>> In my current utilities environment the previous problem is compounded
>> because I have my Scala source code under src/main/resources instead of
>> src/main/scala or src/main/java so the IDE does not know how to compile
>> things.
> Have you tried adding "src/main/resources" as a source folder? You can do this
> from the context menu of the resource folder -> Build Path -> Use as Source
> Folder. That way, you should get all the usual functionality from the Scala
> IDE..
>
> Cheers,
>
> Mirko
>

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Report on First Production Scala Project
Probably add the Scala nature to your project. I'm not sure how you can do this retroactively on a Java project, but you can always create a brand new Scala project, extract the corresponding lines from its .project file and add them to your current .project (a project can have several natures).
-- Cédric




On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
OK, I selected Use as Source Folder, but Eclipse now seems to think this is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala source?

Cheers, Eric

On 2011-12-08 7:06 AM, Mirko Stocker wrote:
Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
In my current utilities environment the previous problem is compounded
because I have my Scala source code under src/main/resources instead of
src/main/scala or src/main/java so the IDE does not know how to compile
things.
Have you tried adding "src/main/resources" as a source folder? You can do this
from the context menu of the resource folder ->  Build Path ->  Use as Source
Folder. That way, you should get all the usual functionality from the Scala
IDE..

Cheers,

Mirko


Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: Report on First Production Scala Project

Try right click on project, Configure -> add scala nature

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Cédric Beust ?
Sent: December-08-11 2:24 PM
To: Eric Kolotyluk
Cc: Mirko Stocker; scala-debate [at] googlegroups [dot] com
Subject: Re: [scala-debate] Report on First Production Scala Project

 

Probably add the Scala nature to your project. I'm not sure how you can do this retroactively on a Java project, but you can always create a brand new Scala project, extract the corresponding lines from its .project file and add them to your current .project (a project can have several natures).


-- 

Cédric



On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:

OK, I selected Use as Source Folder, but Eclipse now seems to think this is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala source?

Cheers, Eric



On 2011-12-08 7:06 AM, Mirko Stocker wrote:

Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:

In my current utilities environment the previous problem is compounded
because I have my Scala source code under src/main/resources instead of
src/main/scala or src/main/java so the IDE does not know how to compile
things.

Have you tried adding "src/main/resources" as a source folder? You can do this
from the context menu of the resource folder ->  Build Path ->  Use as Source
Folder. That way, you should get all the usual functionality from the Scala
IDE..

Cheers,

Mirko

 

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Report on First Production Scala Project
OK - I did that and now I can see Scala show up in the project properties. However, when I open the file with a 'Scala Editor' (in a Scala perspective) it is still complaining about the same things.

Eclipse seems to still be convinced the .scala files are Java.

Cheers, Eric

On 2011-12-08 11:23 AM, Cédric Beust ♔ wrote:
YHq_PCg [at] mail [dot] gmail [dot] com" type="cite">Probably add the Scala nature to your project. I'm not sure how you can do this retroactively on a Java project, but you can always create a brand new Scala project, extract the corresponding lines from its .project file and add them to your current .project (a project can have several natures).
--  Cédric




On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
OK, I selected Use as Source Folder, but Eclipse now seems to think this is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala source?

Cheers, Eric

On 2011-12-08 7:06 AM, Mirko Stocker wrote:
Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
In my current utilities environment the previous problem is compounded
because I have my Scala source code under src/main/resources instead of
src/main/scala or src/main/java so the IDE does not know how to compile
things.
Have you tried adding "src/main/resources" as a source folder? You can do this
from the context menu of the resource folder ->  Build Path ->  Use as Source
Folder. That way, you should get all the usual functionality from the Scala
IDE..

Cheers,

Mirko


Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: Report on First Production Scala Project

I say reboot 3 times, close the project and reopen twice, then do the dance J J J

 

Nah – seriously, I do that sometimes – it seems to help

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Eric Kolotyluk
Sent: December-08-11 2:51 PM
To: scala-debate [at] googlegroups [dot] com
Subject: Re: [scala-debate] Report on First Production Scala Project

 

OK - I did that and now I can see Scala show up in the project properties. However, when I open the file with a 'Scala Editor' (in a Scala perspective) it is still complaining about the same things.

Eclipse seems to still be convinced the .scala files are Java.

Cheers, Eric

On 2011-12-08 11:23 AM, Cédric Beust ♔ wrote:

Probably add the Scala nature to your project. I'm not sure how you can do this retroactively on a Java project, but you can always create a brand new Scala project, extract the corresponding lines from its .project file and add them to your current .project (a project can have several natures).


-- 

Cédric



On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:

OK, I selected Use as Source Folder, but Eclipse now seems to think this is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala source?

Cheers, Eric



On 2011-12-08 7:06 AM, Mirko Stocker wrote:

Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:

In my current utilities environment the previous problem is compounded
because I have my Scala source code under src/main/resources instead of
src/main/scala or src/main/java so the IDE does not know how to compile
things.

Have you tried adding "src/main/resources" as a source folder? You can do this
from the context menu of the resource folder ->  Build Path ->  Use as Source
Folder. That way, you should get all the usual functionality from the Scala
IDE..

Cheers,

Mirko

 

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Report on First Production Scala Project

On Thu, Dec 8, 2011 at 17:50, Eric Kolotyluk wrote:
> OK - I did that and now I can see Scala show up in the project properties.
> However, when I open the file with a 'Scala Editor' (in a Scala perspective)
> it is still complaining about the same things.
>
> Eclipse seems to still be convinced the .scala files are Java.

May I suggest that scala-debate is *really* not the best place to get
help on this? Please avail yourself of the resources at
http://www.scala-ide.org/. In particular, look at the issues database
and, if you can't find your problem there, *open an issue*.

>
> Cheers, Eric
>
>
> On 2011-12-08 11:23 AM, Cédric Beust ♔ wrote:
>
> Probably add the Scala nature to your project. I'm not sure how you can do
> this retroactively on a Java project, but you can always create a brand new
> Scala project, extract the corresponding lines from its .project file and
> add them to your current .project (a project can have several natures).
>
> --
> Cédric
>
>
>
>
> On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk
> wrote:
>>
>> OK, I selected Use as Source Folder, but Eclipse now seems to think this
>> is Java source as it is complaining about things such as ';' expected.
>>
>> Is there something else I have to do to convince Eclipse this is Scala
>> source?
>>
>> Cheers, Eric
>>
>>
>> On 2011-12-08 7:06 AM, Mirko Stocker wrote:
>>>
>>> Hi Eric
>>>
>>> Thanks for your report, it was very interesting to read.
>>>
>>> On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
>>>>
>>>> In my current utilities environment the previous problem is compounded
>>>> because I have my Scala source code under src/main/resources instead of
>>>> src/main/scala or src/main/java so the IDE does not know how to compile
>>>> things.
>>>
>>> Have you tried adding "src/main/resources" as a source folder? You can do
>>> this
>>> from the context menu of the resource folder ->  Build Path ->  Use as
>>> Source
>>> Folder. That way, you should get all the usual functionality from the
>>> Scala
>>> IDE..
>>>
>>> Cheers,
>>>
>>> Mirko
>>>
>

sreque 2
Joined: 2011-11-15,
User offline. Last seen 42 years 45 weeks ago.
Re: Report on First Production Scala Project

It's been so long (2.7.7) since I've done anything on the JVM, I got a
new computer since then and it doesn't have Eclipse on it. I had to
download Eclipse and the scala plugin just to be sure it worked the
way I remembered! :-)

So, I just downloaded Eclipse Indigo and the latest 29.1 RC2 plugin
(including the source option). I created a new scala project and a new
scala application inside of it.
I then typed in some random source code.

val v = BitSet(1, 2, 3, 4, 5).flatMap(v => BitSet(v * v, v * v * v))

When I move my cursor to any symbol, such as "BitSet" or "flatMap" and
hit F3, Eclipse opens a page containing source code and comments the
definition of that symbol. I learned that flatMap is defined in
TraversibleLike, and has no comments! It's implementation is also only
three lines, however and if I dig into the definition of CanBuildFrom
and Builder I find that they are well commented. From them I learn
that builders are used to create new collections. After a few minutes
of digging around, I learned that flatMap applies its function to each
element, converts the result to a sequence, appends the sequence to a
builder, and then converts the builder to a new collection that it
returns.

Also, as an aside, when I hover my cursor over any symbol I get a
tooltip with type information, which is pretty helpful. It tells me
that v is of type BitSet, for instance.

> > Also, I remember in the past being able to get Scala documentation
> > from my IDE. Instead of relying on tooltips, I just used Eclipse's
> > symbol hyperlinking to jump straight to the source code, where I could
> > then read the documentation for the symbol or read the source code if
> > I needed more information.
>
> Now that sounds interesting :-) How do I do that?
>
> Cheers, Eric
>
>
>
>
>
>
>
>
>
> > On Dec 8, 8:47 am, Eric Kolotyluk  wrote:
> >> I've just spent the last few weeks building some utility code in Scala
> >> and thought I would share my experience.
>
> >> I've been playing with Scala for about 4 years now and consider myself
> >> an informed, but casual user of Scala. I have an MSc in Computing
> >> Science and I am currently a Software Architect at Kodak.
>
> >> After much consideration I recently decided to incorporate some Scala in
> >> production code:
>
> >>   1. This is limited to some command line utilities. I chose Scala over
> >>      the ubiquitous Windows .bat and .vbs scripts we have everywhere. On
> >>      my last project I was horrified at trying to unravel the twisted
> >>      thinking that goes into .bat and .vbs code. I thought I would try
> >>      Scala over Groovy or something else. .cmd, .bat, .vbs and
> >>      power-shell scripting very much reminds me of the horror of .sh,
> >>      .csh, awk&  grep spaghetti code I used to find in Unix all the time.
>
> >>   2. My boss is always giving me grief about considering yet another
> >>      programming language, although we really have not adopted anything
> >>      new for over 6 years when we started replacing more of our C++/COM
> >>      code with C#/.NET. We have been using Java for over 10 years. I
> >>      added some Groovy to our product a few years ago, but it is only for
> >>      the test team and does not impact customers. We have a bunch of
> >>      firmware management scripts written in JavaScript, but that product
> >>      is nearing EOL. While he is still skeptical of Scala, I am the
> >>      Software Architect, and to some degree it is better to ask for
> >>      forgiveness than permission.
>
> >>   3. Most of my team is scared of Scala, probably because of the various
> >>      Scala presentations I have given over the years. Face it - FP just
> >>      scares some people. As the Software Architect I have to keep my
> >>      team's skills and comfort in mind. I have deliberately chosen a
> >>      small area of code that will not likely impact any of them
> >>      significantly. Recently when I showed them some of the more simple
> >>      source code of my utilities they did not feel so uneasy.
>
> >>   4. The command line utilities are in a script-like environment. I do
> >>      not run Scala as scripts but as compiled code. The utilities are
> >>      launched by one command from a .bat or .sh file, that then invokes a
> >>      .scala file as a script. This script checks the source code of the
> >>      rest of the utilities against the .class files and recompiles
> >>      anything out of date. Finally it calls the compiled code directly.
> >>      While there is significant lag the first time the utilities are run,
> >>      especially if they have to compile, subsequent runs are much quicker
> >>      when the JVM is warmed up. The utilities are not run often so this
> >>      lag is not a big issue. Also, the utilities will likely be run from
> >>      other software as a background process so will not be a large part
> >>      of the user experience. The nice part of this environment is that
> >>      all the Scala sources are deployed. You only have to edit the .scala
> >>      files with a conventional editor and run the utilities so the
> >>      experience is almost exactly the same as a normal scripting environment.
>
> >>   5. Another benefit I have found is that my utilities can call my main
> >>      client and service code directly since it is written in Java. I can
> >>      immediately leverage all the investment in the logging system and
> >>      other APIs that have been developed in Java. This is really elegant
> >>      tight coupling between the utilities and the main product code.
> >>      Also, unlike .bat and .vbs files (or Windows PowerShell), the
> >>      utilities are portable across Windows, OS X and Linux.
>
> >>   6. The approach I have taken is that there are different levels of
> >>      sophistication in the various source files. The top level commands
> >>      like backup, restore, zip, etc. have very simple easy to read code
> >>      that should be straightforward for most people to modify whether
> >>      they know Scala or not. The infrastructure code (APIs and types)
> >>      uses more sophisticated Scala features, but it is less likely anyone
> >>      will have to modify it too much. I have started a practice of
> >>      creating 'Scala Newbie Notes' at the end of various source files
> >>      that explain what is going on to people not familiar with Scala.
> >>      This also helps me too as a casual user of Scala who can be prone to
> >>      forget basic concepts easily. In particular, these utilities are
> >>      designed to be a learning environment for people new to Scala. These
> >>      utilities are designed very much to be a toe-in-the-door for Scala
> >>      in our environment.
>
> >>   7. Looking back at the last few weeks it is clear building the
> >>      utilities took 3 or 4 times longer because of my inexperience with
> >>      Scala. There were some issues that literally took me days to figure
> >>      out in Scala whereas the solution in Java would have been and hour
> >>      or so. One of the issues is that once you get a piece of Scala code
> >>      working correctly, then you start seeing all kinds of ways to
> >>      refactor and improve the code. This is much more of a factor than
> >>      with Java as there are so many more ways to improve mediocre Scala
> >>      code than mediocre Java code. Often I would get my procedural Scala
> >>      code working correctly, then spend yet again as much time
> >>      refactoring it to an FP style. I also find that with Scala there are
> >>      many more opportunities to fine tune the readability of the code
> >>      than with Java. This is a huge time sink for obsessive-compulsive
> >>      perfectionists who like to write text-book quality code.
>
> >>   8. There is definitely a huge price to pay developing Scala code
> >>      because the IDE support is so poor. Writing Java code in Eclipse
> >>      goes so much easier because of all the help the IDE editors give
> >>      you. The fact that Eclipse lets you hover the cursor over things and
> >>      brings up these great semi-persistent tool-tips with hyperlinked
> >>      javadoc makes productivity incredibly high. Also, the IDE editor is
> >>      great at pointing out errors and warnings and offering options to
> >>      remedy the problems. The two most frustrating parts of writing Scala
> >>      code are the lack of great IDE support and the lack of excellent
> >>      scaladoc pages. I profoundly believe the biggest opportunity to
> >>      making Scala more productive and less frustrating is improving the
> >>      IDE support.
>
> >>   9. In my current utilities environment the previous problem is
> >>      compounded because I have my Scala source code under
> >>      src/main/resources instead of src/main/scala or src/main/java so the
> >>      IDE does not know how to compile things. I am still considering ways
> >>      to resolve this. I do it this way because as resources, the Scala
> >>      source files are easy for my application to deploy. The editor still
> >>      does the basic lexical stuff, but not nearly enough in terms of
> >>      syntax and semantics. Essentially my development cycle is (1) edit
> >>      the Scala source in Eclipse, (2) copy/paste the source files from
> >>      Eclipse into my bin/src folder, and (3) run the utilities from the
> >>      command line and watch the Scala compiler complain about all my
> >>      mistakes. However, this is similar to the experience someone in the
> >>      field would find having to hack the utilities code at a customer
> >>      site with no IDE or other development tools.
>
> >> 10. To be clear, the Scala compiler diagnostics are not nearly as good
> >>      as the Java compiler diagnostics. It is a shock sometimes trying to
> >>      fathom what the hell the Scala compiler is trying to tell me -
> >>      usually it makes me feel stupid - as opposed to the great
> >>      diagnostics I am used to from over a decade of improvements in
> >>      javac. On the other hand, the Scala compiler diagnostics are
> >>      significantly better than those when .bat, .vbs, or power-shell
> >>      scripts go awry, which is still a good reason for using it.
>
> >> 11. Dealing with the Scala community is certainly an experience to be
> >>      appreciated. In the Java community there are a smaller set of
> >>      solutions for issues you encounter, but in the Scala community there
> >>      are multifarious ways to address the same issue, and at least half
> >>      the solutions are stuff I really cannot understand without
> >>      considerable thought.
>
> >> 12. Overall my experience with Scala the last few weeks has been
> >>      wonderful from an intellectual point of view, but terrible from a
> >>      productivity point of view. I will be begging forgiveness from my
> >>      boss for a long time to come as I could have done all this in Java
> >>      in 1/4 the time. However, it would have taken me just as long to
> >>      write all these utilities in .bat, .vbs and/or power
>
> ...
>
> read more »

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Re: Report on First Production Scala Project

Ahhhhh.....

After a bit of fiddling I was able to get this to work too, but I had to
update my Scala plugin.

Not as nice as the Java experience, but definitely useful :-)

Many thanks for the cool tip.

Cheers, Eric

On 2011-12-08 5:07 PM, sreque wrote:
> It's been so long (2.7.7) since I've done anything on the JVM, I got a
> new computer since then and it doesn't have Eclipse on it. I had to
> download Eclipse and the scala plugin just to be sure it worked the
> way I remembered! :-)
>
> So, I just downloaded Eclipse Indigo and the latest 29.1 RC2 plugin
> (including the source option). I created a new scala project and a new
> scala application inside of it.
> I then typed in some random source code.
>
> val v = BitSet(1, 2, 3, 4, 5).flatMap(v => BitSet(v * v, v * v * v))
>
> When I move my cursor to any symbol, such as "BitSet" or "flatMap" and
> hit F3, Eclipse opens a page containing source code and comments the
> definition of that symbol. I learned that flatMap is defined in
> TraversibleLike, and has no comments! It's implementation is also only
> three lines, however and if I dig into the definition of CanBuildFrom
> and Builder I find that they are well commented. From them I learn
> that builders are used to create new collections. After a few minutes
> of digging around, I learned that flatMap applies its function to each
> element, converts the result to a sequence, appends the sequence to a
> builder, and then converts the builder to a new collection that it
> returns.
>
> Also, as an aside, when I hover my cursor over any symbol I get a
> tooltip with type information, which is pretty helpful. It tells me
> that v is of type BitSet, for instance.
>
>>> Also, I remember in the past being able to get Scala documentation
>>> from my IDE. Instead of relying on tooltips, I just used Eclipse's
>>> symbol hyperlinking to jump straight to the source code, where I could
>>> then read the documentation for the symbol or read the source code if
>>> I needed more information.
>> Now that sounds interesting :-) How do I do that?
>>
>> Cheers, Eric
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Dec 8, 8:47 am, Eric Kolotyluk wrote:
>>>> I've just spent the last few weeks building some utility code in Scala
>>>> and thought I would share my experience.
>>>> I've been playing with Scala for about 4 years now and consider myself
>>>> an informed, but casual user of Scala. I have an MSc in Computing
>>>> Science and I am currently a Software Architect at Kodak.
>>>> After much consideration I recently decided to incorporate some Scala in
>>>> production code:
>>>> 1. This is limited to some command line utilities. I chose Scala over
>>>> the ubiquitous Windows .bat and .vbs scripts we have everywhere. On
>>>> my last project I was horrified at trying to unravel the twisted
>>>> thinking that goes into .bat and .vbs code. I thought I would try
>>>> Scala over Groovy or something else. .cmd, .bat, .vbs and
>>>> power-shell scripting very much reminds me of the horror of .sh,
>>>> .csh, awk& grep spaghetti code I used to find in Unix all the time.
>>>> 2. My boss is always giving me grief about considering yet another
>>>> programming language, although we really have not adopted anything
>>>> new for over 6 years when we started replacing more of our C++/COM
>>>> code with C#/.NET. We have been using Java for over 10 years. I
>>>> added some Groovy to our product a few years ago, but it is only for
>>>> the test team and does not impact customers. We have a bunch of
>>>> firmware management scripts written in JavaScript, but that product
>>>> is nearing EOL. While he is still skeptical of Scala, I am the
>>>> Software Architect, and to some degree it is better to ask for
>>>> forgiveness than permission.
>>>> 3. Most of my team is scared of Scala, probably because of the various
>>>> Scala presentations I have given over the years. Face it - FP just
>>>> scares some people. As the Software Architect I have to keep my
>>>> team's skills and comfort in mind. I have deliberately chosen a
>>>> small area of code that will not likely impact any of them
>>>> significantly. Recently when I showed them some of the more simple
>>>> source code of my utilities they did not feel so uneasy.
>>>> 4. The command line utilities are in a script-like environment. I do
>>>> not run Scala as scripts but as compiled code. The utilities are
>>>> launched by one command from a .bat or .sh file, that then invokes a
>>>> .scala file as a script. This script checks the source code of the
>>>> rest of the utilities against the .class files and recompiles
>>>> anything out of date. Finally it calls the compiled code directly.
>>>> While there is significant lag the first time the utilities are run,
>>>> especially if they have to compile, subsequent runs are much quicker
>>>> when the JVM is warmed up. The utilities are not run often so this
>>>> lag is not a big issue. Also, the utilities will likely be run from
>>>> other software as a background process so will not be a large part
>>>> of the user experience. The nice part of this environment is that
>>>> all the Scala sources are deployed. You only have to edit the .scala
>>>> files with a conventional editor and run the utilities so the
>>>> experience is almost exactly the same as a normal scripting environment.
>>>> 5. Another benefit I have found is that my utilities can call my main
>>>> client and service code directly since it is written in Java. I can
>>>> immediately leverage all the investment in the logging system and
>>>> other APIs that have been developed in Java. This is really elegant
>>>> tight coupling between the utilities and the main product code.
>>>> Also, unlike .bat and .vbs files (or Windows PowerShell), the
>>>> utilities are portable across Windows, OS X and Linux.
>>>> 6. The approach I have taken is that there are different levels of
>>>> sophistication in the various source files. The top level commands
>>>> like backup, restore, zip, etc. have very simple easy to read code
>>>> that should be straightforward for most people to modify whether
>>>> they know Scala or not. The infrastructure code (APIs and types)
>>>> uses more sophisticated Scala features, but it is less likely anyone
>>>> will have to modify it too much. I have started a practice of
>>>> creating 'Scala Newbie Notes' at the end of various source files
>>>> that explain what is going on to people not familiar with Scala.
>>>> This also helps me too as a casual user of Scala who can be prone to
>>>> forget basic concepts easily. In particular, these utilities are
>>>> designed to be a learning environment for people new to Scala. These
>>>> utilities are designed very much to be a toe-in-the-door for Scala
>>>> in our environment.
>>>> 7. Looking back at the last few weeks it is clear building the
>>>> utilities took 3 or 4 times longer because of my inexperience with
>>>> Scala. There were some issues that literally took me days to figure
>>>> out in Scala whereas the solution in Java would have been and hour
>>>> or so. One of the issues is that once you get a piece of Scala code
>>>> working correctly, then you start seeing all kinds of ways to
>>>> refactor and improve the code. This is much more of a factor than
>>>> with Java as there are so many more ways to improve mediocre Scala
>>>> code than mediocre Java code. Often I would get my procedural Scala
>>>> code working correctly, then spend yet again as much time
>>>> refactoring it to an FP style. I also find that with Scala there are
>>>> many more opportunities to fine tune the readability of the code
>>>> than with Java. This is a huge time sink for obsessive-compulsive
>>>> perfectionists who like to write text-book quality code.
>>>> 8. There is definitely a huge price to pay developing Scala code
>>>> because the IDE support is so poor. Writing Java code in Eclipse
>>>> goes so much easier because of all the help the IDE editors give
>>>> you. The fact that Eclipse lets you hover the cursor over things and
>>>> brings up these great semi-persistent tool-tips with hyperlinked
>>>> javadoc makes productivity incredibly high. Also, the IDE editor is
>>>> great at pointing out errors and warnings and offering options to
>>>> remedy the problems. The two most frustrating parts of writing Scala
>>>> code are the lack of great IDE support and the lack of excellent
>>>> scaladoc pages. I profoundly believe the biggest opportunity to
>>>> making Scala more productive and less frustrating is improving the
>>>> IDE support.
>>>> 9. In my current utilities environment the previous problem is
>>>> compounded because I have my Scala source code under
>>>> src/main/resources instead of src/main/scala or src/main/java so the
>>>> IDE does not know how to compile things. I am still considering ways
>>>> to resolve this. I do it this way because as resources, the Scala
>>>> source files are easy for my application to deploy. The editor still
>>>> does the basic lexical stuff, but not nearly enough in terms of
>>>> syntax and semantics. Essentially my development cycle is (1) edit
>>>> the Scala source in Eclipse, (2) copy/paste the source files from
>>>> Eclipse into my bin/src folder, and (3) run the utilities from the
>>>> command line and watch the Scala compiler complain about all my
>>>> mistakes. However, this is similar to the experience someone in the
>>>> field would find having to hack the utilities code at a customer
>>>> site with no IDE or other development tools.
>>>> 10. To be clear, the Scala compiler diagnostics are not nearly as good
>>>> as the Java compiler diagnostics. It is a shock sometimes trying to
>>>> fathom what the hell the Scala compiler is trying to tell me -
>>>> usually it makes me feel stupid - as opposed to the great
>>>> diagnostics I am used to from over a decade of improvements in
>>>> javac. On the other hand, the Scala compiler diagnostics are
>>>> significantly better than those when .bat, .vbs, or power-shell
>>>> scripts go awry, which is still a good reason for using it.
>>>> 11. Dealing with the Scala community is certainly an experience to be
>>>> appreciated. In the Java community there are a smaller set of
>>>> solutions for issues you encounter, but in the Scala community there
>>>> are multifarious ways to address the same issue, and at least half
>>>> the solutions are stuff I really cannot understand without
>>>> considerable thought.
>>>> 12. Overall my experience with Scala the last few weeks has been
>>>> wonderful from an intellectual point of view, but terrible from a
>>>> productivity point of view. I will be begging forgiveness from my
>>>> boss for a long time to come as I could have done all this in Java
>>>> in 1/4 the time. However, it would have taken me just as long to
>>>> write all these utilities in .bat, .vbs and/or power
>> ...
>>
>> read more »

sreque 2
Joined: 2011-11-15,
User offline. Last seen 42 years 45 weeks ago.
Re: Report on First Production Scala Project

Surely enough, in TraversibleLike there is a yellow arrow in the left
column next to the definition of flatMap. If I click on it, it takes
me to GenTraversibleLike, where I see good documentation for the
function. I got a cool tip today too!

>That's because it overrides the flatMap in class GenTraversableLike,>which carries full comments. ScalaDoc copies comments from overridden>methods if they are missing in an overriding method. This lets us>avoid lots of needless duplication in the comments. Documentation,>just as code, should follow the DRY principle.
>To see the comments you need to follow the triangle on the left>indicating overridden methods.
>Cheers

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Report on First Production Scala Project
OK, I have created ticket #1000801

Cheers, Eric

On 2011-12-08 4:06 PM, Daniel Sobral wrote:
CAHyB3VXxvVtHDV0bQecB8DjbJC8Jj_zkbSR020kk37YnfNWG6Q [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Dec 8, 2011 at 17:50, Eric Kolotyluk eric [dot] kolotyluk [at] gmail [dot] com (<eric [dot] kolotyluk [at] gmail [dot] com>) wrote:
OK - I did that and now I can see Scala show up in the project properties.
However, when I open the file with a 'Scala Editor' (in a Scala perspective)
it is still complaining about the same things.

Eclipse seems to still be convinced the .scala files are Java.
May I suggest that scala-debate is *really* not the best place to get
help on this? Please avail yourself of the resources at
http://www.scala-ide.org/. In particular, look at the issues database
and, if you can't find your problem there, *open an issue*.

Cheers, Eric


On 2011-12-08 11:23 AM, Cédric Beust ♔ wrote:

Probably add the Scala nature to your project. I'm not sure how you can do
this retroactively on a Java project, but you can always create a brand new
Scala project, extract the corresponding lines from its .project file and
add them to your current .project (a project can have several natures).

--
Cédric




On Thu, Dec 8, 2011 at 11:20 AM, Eric Kolotyluk eric [dot] kolotyluk [at] gmail [dot] com (<eric [dot] kolotyluk [at] gmail [dot] com>)
wrote:
OK, I selected Use as Source Folder, but Eclipse now seems to think this
is Java source as it is complaining about things such as ';' expected.

Is there something else I have to do to convince Eclipse this is Scala
source?

Cheers, Eric


On 2011-12-08 7:06 AM, Mirko Stocker wrote:
Hi Eric

Thanks for your report, it was very interesting to read.

On Thursday 08 December 2011 06:47:52 Eric Kolotyluk wrote:
In my current utilities environment the previous problem is compounded
because I have my Scala source code under src/main/resources instead of
src/main/scala or src/main/java so the IDE does not know how to compile
things.
Have you tried adding "src/main/resources" as a source folder? You can do
this
from the context menu of the resource folder ->  Build Path ->  Use as
Source
Folder. That way, you should get all the usual functionality from the
Scala
IDE..

Cheers,

Mirko


      


Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland