Re: Building Scala Projects with Ant

Randall R Schulz wrote:
> I don't see how it can. Very few of my classes have names that
> correspond precisely to a Scala source file name.

Then you are screwed :-). Ant will recompile any Filename.scala file
it finds that has no newer Filename.class file every time it is run.
So you might as well leave the clean step in the build.xml, removing
it won't save too much time.

- Florian.

Maybe the compiler could emit a simple file containing .scala files -> .class file mappings, that builders could use to check which files are out of date?

On Tue, Mar 24, 2009 at 2:39 PM, Florian Hars <hars@bik-gmbh.de> wrote:

Randall R Schulz wrote:

I don't see how it can. Very few of my classes have names that correspond precisely to a Scala source file name.

Then you are screwed :-). Ant will recompile any Filename.scala file
it finds that has no newer Filename.class file every time it is run.
So you might as well leave the clean step in the build.xml, removing
it won't save too much time.

- Florian.

Naftoli Gugenheim wrote:
> Maybe the compiler could emit a simple file containing .scala files ->
> .class file mappings,

That is not simple, since a class might depend on declarations in many
other files. People are working on that: https://chara2.epfl.ch/r/101/

- Florian

Dependencies are much more complicated, yes. This thread was discussing simply which .scala file generates which .class files. But when the dependency analysis is implemented, I suppose it would solve this problem too.

On Tue, Mar 24, 2009 at 3:10 PM, Florian Hars <hars@bik-gmbh.de> wrote:

Naftoli Gugenheim wrote:

Maybe the compiler could emit a simple file containing .scala files -> .class file mappings,

That is not simple, since a class might depend on declarations in many
other files. People are working on that: https://chara2.epfl.ch/r/101/

- Florian

On Tuesday March 24 2009, Naftoli Gugenheim wrote:
> ... This thread was discussing simply which .scala file generates
> which .class files. ...

Actually, this thread was a question about whether it was necessary to
remove all .class files before initiating compilation in an Ant target.

Randall Schulz

And if Ant could know which files were modified, then it wouldn't have to, no?

On Tue, Mar 24, 2009 at 3:43 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Tuesday March 24 2009, Naftoli Gugenheim wrote:
> ... This thread was discussing simply which .scala file generates
> which .class files. ...

Actually, this thread was a question about whether it was necessary to
remove all .class files before initiating compilation in an Ant target.


Randall Schulz

No, it 's much more subtle than that. It would need to find out how
changes would propagate if a source file changes. Due to shadowing, it
seems to be a very hard task to that right. AFAIK, there is no real
solution in sight, either.

I agree with everyone in the thread: as long as this basic (looking)
issue is not solved, scala is not really a mature environment for
serious production.

On 3/24/09, Randall R Schulz wrote:
> On Tuesday March 24 2009, Naftoli Gugenheim wrote:
>
> > And if Ant could know which files were modified, then it wouldn't
> > have to, no?
>
>
> Well, it wasn't about hypotheticals.
>
>
>
> RRS
>

On Tuesday March 24 2009, Naftoli Gugenheim wrote:
> And if Ant could know which files were modified, then it wouldn't
> have to, no?

Well, it wasn't about hypotheticals.

RRS

>>>>> "Florian" == Florian Hars writes:

Florian> That is not simple, since a class might depend on declarations
Florian> in many other files. People are working on that:
Florian> https://chara2.epfl.ch/r/101/

I am going to describe my own idiosyncratic solution (or workaround, if
you prefer) to this problem. I've been using it for about 3 months now
and I'm very happy with it for my own purposes. Perhaps this will be
interesting for at least a few other non-IDE-using types.

I got sick of messing with make and ant and ended up just writing my own
little builder... in Scala, of course. The granularity level is the
package; it always rebuilds whole packages as units. This gives me as
much speedup (relative to always rebuilding everything) as I feel I
actually need; I don't think making it smart at a finer grain level
would give much practical benefit.

I feed the builder the dependency structure of my code (which packages
depend on which) as data and it uses that to figure out which packages
need to be rebuilt.

Within a package, I use scalac's Scala/Java mixing support to allow
circular dependencies between Scala and Java. You can't have circular
dependencies between packages, but that's a feature, not a bug :-)

the dependency information is a bunch of lines like this:

"swing" -> List("awt"),
"util" -> Nil,
"window" -> List("editor","shape","swing","workspace"),

where -> means "depends on" and the strings are package names
(minus their common prefix).

I can do all the building in a single jvm instance by invoking scalac
through scala.tools.nsc.Main and javac through com.sun.tools.javac.Main.
scalac is much faster if I compile as many packages as possible at once,
so it never invokes scalac and javac more than twice each, total.

The fewer interpackage dependencies I have, the faster my builds tend to
go, because fewer packages need rebuilding. So I have strong motivation
to cut dependencies, which is good for modularity anyway. I started
using PicoContainer for dependency injection and that helped me cut lots
of unnecessary interpackage dependencies.

I also use the same interpackage dependency data to generate a .ddf file
as input to Classycle, which our integration builder uses to verify that
the dependency structure I declared is not violated in the code.
(Classycle is a great thing.)

I have no plans to turn any of this into something other people could
use as-is, but I'd be happy to send the code to anyone who's curious to
look at it and/or tinker with it.

It's only about 100 lines of Scala, plus about 30 more for the optioanl
Classycle stuff.

It works on Cygwin as well as Mac OS X and Linux. (I call shell
commands like "find" and "touch", so it won't work on Windows without
Cygwin, writing your own platform-independent code that does what I'm
using "find" et al to do wouldn't be incredibly hard.)

On Tuesday March 24 2009, Christian Szegedy wrote:
> ...
>
> I agree with everyone in the thread: as long as this basic (looking)
> issue is not solved, scala is not really a mature environment for
> serious production.

Who said that? Certainly not I.

Randall Schulz

I think that a programming language that recompilation of the whole
project every compilation cycle can not be viewed as a mature
environment.

Even if David's plugin provides basic dependency tracking, AFAIK
(please correct me if I am wrong) it will not cope importing/shadowing
issues, so it hardly reliable solution.

requires
On 3/24/09, Randall R Schulz wrote:
> On Tuesday March 24 2009, Christian Szegedy wrote:
> > ...
>
> >
> > I agree with everyone in the thread: as long as this basic (looking)
> > issue is not solved, scala is not really a mature environment for
> > serious production.
>
>
> Who said that? Certainly not I.
>
>
>
> Randall Schulz
>

Dependency analysis and partial recompilation exists and works well. sbt does
it, Seth posted a process that he uses, and David's dependency analysis in
the compiler (not in a plugin) does/will do it in 2.8. (I'll let IDE users
comment on current IDE capabilities.) There is one corner case I know of
that is difficult to handle properly, but it is rare enough that I wouldn't
consider compilation in Scala "hardly reliable".

Thanks,
Mark

On Tuesday 24 March 2009, Christian Szegedy wrote:
> I think that a programming language that recompilation of the whole
> project every compilation cycle can not be viewed as a mature
> environment.
>
> Even if David's plugin provides basic dependency tracking, AFAIK
> (please correct me if I am wrong) it will not cope importing/shadowing
> issues, so it hardly reliable solution.
>
> requires
>
> On 3/24/09, Randall R Schulz wrote:
> > On Tuesday March 24 2009, Christian Szegedy wrote:
> > > ...
> > >
> > >
> > > I agree with everyone in the thread: as long as this basic (looking)
> > > issue is not solved, scala is not really a mature environment for
> > > serious production.
> >
> > Who said that? Certainly not I.
> >
> >
> >
> > Randall Schulz

"Rare enough": do you have any statistics? ;)

Interesting mindset.

I have no problem using these build tools in small hobby
projects.I admit, I like sbt.

However, I am not sure, these are generally acceptible solutions.
My main headache is that this "corner case" can cause
problems go unnoticed, causing strange runtime errors that
are hard to debug, maybe even compiler crashes, where
wrong assumptions are made on some classes, etc. To me
it's just plain wrong to let people believe that something works
well, when in fact it is known, it does not really.

I would say, I have similar opinion on scala's implementation of
pattern matching implementation. It's good enough to have fun
with it, but it crashed on me so often, I hardly dare to use it
anymore.

It is not that scala is not a great language or the whole concept
is unsound, but it's simply not mature, at least compared to
tools like gcc or even ocaml. E.g. ocaml never,ever crashed on
me or died with internal compiler error, while scala does that
almost every day moderate use.

Mark Harrah wrote:
> Dependency analysis and partial recompilation exists and works well. sbt does
> it, Seth posted a process that he uses, and David's dependency analysis in
> the compiler (not in a plugin) does/will do it in 2.8. (I'll let IDE users
> comment on current IDE capabilities.) There is one corner case I know of
> that is difficult to handle properly, but it is rare enough that I wouldn't
> consider compilation in Scala "hardly reliable".
>
> Thanks,
>
> Mark
>
>
> On Tuesday 24 March 2009, Christian Szegedy wrote:
> > I think that a programming language that recompilation of the whole
> > project every compilation cycle can not be viewed as a mature
> > environment.
> >
> > Even if David's plugin provides basic dependency tracking, AFAIK
> > (please correct me if I am wrong) it will not cope importing/shadowing
> > issues, so it hardly reliable solution.
> >
> > requires
> >
> > On 3/24/09, Randall R Schulz wrote:
> > > On Tuesday March 24 2009, Christian Szegedy wrote:
> > > > ...
> > > >
> > > >
> > > > I agree with everyone in the thread: as long as this basic (looking)
> > > > issue is not solved, scala is not really a mature environment for
> > > > serious production.
> > >
> > > Who said that? Certainly not I.
> > >
> > >
> > >
> > > Randall Schulz
>
>
>

2009/3/25 Christian Szegedy :
> "Rare enough": do you have any statistics? ;)
>
> Interesting mindset.

Rare enough that just about every build system on earth that doesn't
require the user to manually specify file dependencies or do something
even more flagrantly wrong behaves in essentially the same way.

In the interests of fairness, most compiler crashes I have found have
not been for code that should be valid; i.e., it's crashing when it
should have given an error message. I'd rather have a crash then
buggy .class files.

I think the situation is steadily improving, especially with the paulp
injection.

2009/3/25 Christian Szegedy :
> "Rare enough": do you have any statistics? ;)
>
> Interesting mindset.
>
> I have no problem using these build tools in small hobby
> projects.I admit, I like sbt.
>
> However, I am not sure, these are generally acceptible solutions.
> My main headache is that this "corner case" can cause
> problems go unnoticed, causing strange runtime errors that
> are hard to debug, maybe even compiler crashes, where
> wrong assumptions are made on some classes, etc. To me
> it's just plain wrong to let people believe that something works
> well, when in fact it is known, it does not really.
>
> I would say, I have similar opinion on scala's implementation of
> pattern matching implementation. It's good enough to have fun
> with it, but it crashed on me so often, I hardly dare to use it
> anymore.
>
> It is not that scala is not a great language or the whole concept
> is unsound, but it's simply not mature, at least compared to
> tools like gcc or even ocaml. E.g. ocaml never,ever crashed on
> me or died with internal compiler error, while scala does that
> almost every day moderate use.
>
> Mark Harrah wrote:
>> Dependency analysis and partial recompilation exists and works well.  sbt does
>>  it, Seth posted a process that he uses, and David's dependency analysis in
>>  the compiler (not in a plugin) does/will do it in 2.8.  (I'll let IDE users
>>  comment on current IDE capabilities.)  There is one corner case I know of
>>  that is difficult to handle properly, but it is rare enough that I wouldn't
>>  consider compilation in Scala "hardly reliable".
>>
>>  Thanks,
>>
>> Mark
>>
>>
>>  On Tuesday 24 March 2009, Christian Szegedy wrote:
>>  > I think that a programming language that  recompilation of the whole
>>  > project every compilation cycle can not be viewed as a mature
>>  > environment.
>>  >
>>  > Even if David's plugin provides basic dependency tracking, AFAIK
>>  > (please correct me if I am wrong) it will not cope importing/shadowing
>>  > issues, so it hardly reliable solution.
>>  >
>>  > requires
>>  >
>>  > On 3/24/09, Randall R Schulz wrote:
>>  > > On Tuesday March 24 2009, Christian Szegedy wrote:
>>  > >  > ...
>>  > >  >
>>  > >  >
>>  > >  > I agree with everyone in the thread: as long as this basic (looking)
>>  > >  > issue is not solved, scala is not really a mature environment for
>>  > >  > serious production.
>>  > >
>>  > > Who said that? Certainly not I.
>>  > >
>>  > >
>>  > >
>>  > >  Randall Schulz
>>
>>
>>
>

What is that injection about?

On 3/24/09, Ricky Clarkson wrote:
> In the interests of fairness, most compiler crashes I have found have
> not been for code that should be valid; i.e., it's crashing when it
> should have given an error message. I'd rather have a crash then
> buggy .class files.
>
> I think the situation is steadily improving, especially with the paulp
> injection.
>
>
> 2009/3/25 Christian Szegedy :
>
> > "Rare enough": do you have any statistics? ;)
> >
> > Interesting mindset.
> >
> > I have no problem using these build tools in small hobby
> > projects.I admit, I like sbt.
> >
> > However, I am not sure, these are generally acceptible solutions.
> > My main headache is that this "corner case" can cause
> > problems go unnoticed, causing strange runtime errors that
> > are hard to debug, maybe even compiler crashes, where
> > wrong assumptions are made on some classes, etc. To me
> > it's just plain wrong to let people believe that something works
> > well, when in fact it is known, it does not really.
> >
> > I would say, I have similar opinion on scala's implementation of
> > pattern matching implementation. It's good enough to have fun
> > with it, but it crashed on me so often, I hardly dare to use it
> > anymore.
> >
> > It is not that scala is not a great language or the whole concept
> > is unsound, but it's simply not mature, at least compared to
> > tools like gcc or even ocaml. E.g. ocaml never,ever crashed on
> > me or died with internal compiler error, while scala does that
> > almost every day moderate use.
> >
> > Mark Harrah wrote:
> >> Dependency analysis and partial recompilation exists and works well. sbt does
> >> it, Seth posted a process that he uses, and David's dependency analysis in
> >> the compiler (not in a plugin) does/will do it in 2.8. (I'll let IDE users
> >> comment on current IDE capabilities.) There is one corner case I know of
> >> that is difficult to handle properly, but it is rare enough that I wouldn't
> >> consider compilation in Scala "hardly reliable".
> >>
> >> Thanks,
> >>
> >> Mark
> >>
> >>
> >> On Tuesday 24 March 2009, Christian Szegedy wrote:
> >> > I think that a programming language that recompilation of the whole
> >> > project every compilation cycle can not be viewed as a mature
> >> > environment.
> >> >
> >> > Even if David's plugin provides basic dependency tracking, AFAIK
> >> > (please correct me if I am wrong) it will not cope importing/shadowing
> >> > issues, so it hardly reliable solution.
> >> >
> >> > requires
> >> >
> >> > On 3/24/09, Randall R Schulz wrote:
> >> > > On Tuesday March 24 2009, Christian Szegedy wrote:
> >> > > > ...
> >> > > >
> >> > > >
> >> > > > I agree with everyone in the thread: as long as this basic (looking)
> >> > > > issue is not solved, scala is not really a mature environment for
> >> > > > serious production.
> >> > >
> >> > > Who said that? Certainly not I.
> >> > >
> >> > >
> >> > >
> >> > > Randall Schulz
> >>
> >>
> >>
> >
>

Illegal in most countries, it's a cocktail of powerful performance enhancing drugs.

On Tue, Mar 24, 2009 at 6:10 PM, Christian Szegedy <christian.szegedy@gmail.com> wrote:

What is that injection about?

On 3/24/09, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
> In the interests of fairness, most compiler crashes I have found have
>  not been for code that should be valid; i.e., it's crashing when it
>  should have given an error message.  I'd rather have a crash then
>  buggy .class files.
>
>  I think the situation is steadily improving, especially with the paulp
>  injection.
>
>
>  2009/3/25 Christian Szegedy <christian.szegedy@gmail.com>:
>
> > "Rare enough": do you have any statistics? ;)
>  >
>  > Interesting mindset.
>  >
>  > I have no problem using these build tools in small hobby
>  > projects.I admit, I like sbt.
>  >
>  > However, I am not sure, these are generally acceptible solutions.
>  > My main headache is that this "corner case" can cause
>  > problems go unnoticed, causing strange runtime errors that
>  > are hard to debug, maybe even compiler crashes, where
>  > wrong assumptions are made on some classes, etc. To me
>  > it's just plain wrong to let people believe that something works
>  > well, when in  fact it is known, it does not really.
>  >
>  > I would say, I have similar opinion on scala's implementation of
>  > pattern matching implementation. It's good enough to have fun
>  > with it, but it crashed on me so often, I hardly dare to use it
>  > anymore.
>  >
>  > It is not that scala is not a great language or the whole concept
>  > is unsound, but it's simply not mature, at least compared to
>  > tools like gcc or even ocaml. E.g. ocaml never,ever crashed on
>  > me or died with internal compiler error, while scala does that
>  > almost every day moderate use.
>  >
>  > Mark Harrah <harrah@bu.edu> wrote:
>  >> Dependency analysis and partial recompilation exists and works well.  sbt does
>  >>  it, Seth posted a process that he uses, and David's dependency analysis in
>  >>  the compiler (not in a plugin) does/will do it in 2.8.  (I'll let IDE users
>  >>  comment on current IDE capabilities.)  There is one corner case I know of
>  >>  that is difficult to handle properly, but it is rare enough that I wouldn't
>  >>  consider compilation in Scala "hardly reliable".
>  >>
>  >>  Thanks,
>  >>
>  >> Mark
>  >>
>  >>
>  >>  On Tuesday 24 March 2009, Christian Szegedy wrote:
>  >>  > I think that a programming language that  recompilation of the whole
>  >>  > project every compilation cycle can not be viewed as a mature
>  >>  > environment.
>  >>  >
>  >>  > Even if David's plugin provides basic dependency tracking, AFAIK
>  >>  > (please correct me if I am wrong) it will not cope importing/shadowing
>  >>  > issues, so it hardly reliable solution.
>  >>  >
>  >>  > requires
>  >>  >
>  >>  > On 3/24/09, Randall R Schulz <rschulz@sonic.net> wrote:
>  >>  > > On Tuesday March 24 2009, Christian Szegedy wrote:
>  >>  > >  > ...
>  >>  > >  >
>  >>  > >  >
>  >>  > >  > I agree with everyone in the thread: as long as this basic (looking)
>  >>  > >  > issue is not solved, scala is not really a mature environment for
>  >>  > >  > serious production.
>  >>  > >
>  >>  > > Who said that? Certainly not I.
>  >>  > >
>  >>  > >
>  >>  > >
>  >>  > >  Randall Schulz
>  >>
>  >>
>  >>
>  >
>

I can see how that helps, but I hope there are lawful alternatives for
the rest of us... :)

On 3/24/09, James Iry wrote:
> Illegal in most countries, it's a cocktail of powerful performance enhancing
> drugs.
>
>
> On Tue, Mar 24, 2009 at 6:10 PM, Christian Szegedy
> wrote:
>
> > What is that injection about?
> >
> > On 3/24/09, Ricky Clarkson wrote:
> > > In the interests of fairness, most compiler crashes I have found have
> > > not been for code that should be valid; i.e., it's crashing when it
> > > should have given an error message. I'd rather have a crash then
> > > buggy .class files.
> > >
> > > I think the situation is steadily improving, especially with the paulp
> > > injection.
> > >
> > >
> > > 2009/3/25 Christian Szegedy :
> > >
> > > > "Rare enough": do you have any statistics? ;)
> > > >
> > > > Interesting mindset.
> > > >
> > > > I have no problem using these build tools in small hobby
> > > > projects.I admit, I like sbt.
> > > >
> > > > However, I am not sure, these are generally acceptible solutions.
> > > > My main headache is that this "corner case" can cause
> > > > problems go unnoticed, causing strange runtime errors that
> > > > are hard to debug, maybe even compiler crashes, where
> > > > wrong assumptions are made on some classes, etc. To me
> > > > it's just plain wrong to let people believe that something works
> > > > well, when in fact it is known, it does not really.
> > > >
> > > > I would say, I have similar opinion on scala's implementation of
> > > > pattern matching implementation. It's good enough to have fun
> > > > with it, but it crashed on me so often, I hardly dare to use it
> > > > anymore.
> > > >
> > > > It is not that scala is not a great language or the whole concept
> > > > is unsound, but it's simply not mature, at least compared to
> > > > tools like gcc or even ocaml. E.g. ocaml never,ever crashed on
> > > > me or died with internal compiler error, while scala does that
> > > > almost every day moderate use.
> > > >
> > > > Mark Harrah wrote:
> > > >> Dependency analysis and partial recompilation exists and works well.
> sbt does
> > > >> it, Seth posted a process that he uses, and David's dependency
> analysis in
> > > >> the compiler (not in a plugin) does/will do it in 2.8. (I'll let
> IDE users
> > > >> comment on current IDE capabilities.) There is one corner case I
> know of
> > > >> that is difficult to handle properly, but it is rare enough that I
> wouldn't
> > > >> consider compilation in Scala "hardly reliable".
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Mark
> > > >>
> > > >>
> > > >> On Tuesday 24 March 2009, Christian Szegedy wrote:
> > > >> > I think that a programming language that recompilation of the
> whole
> > > >> > project every compilation cycle can not be viewed as a mature
> > > >> > environment.
> > > >> >
> > > >> > Even if David's plugin provides basic dependency tracking, AFAIK
> > > >> > (please correct me if I am wrong) it will not cope
> importing/shadowing
> > > >> > issues, so it hardly reliable solution.
> > > >> >
> > > >> > requires
> > > >> >
> > > >> > On 3/24/09, Randall R Schulz wrote:
> > > >> > > On Tuesday March 24 2009, Christian Szegedy wrote:
> > > >> > > > ...
> > > >> > > >
> > > >> > > >
> > > >> > > > I agree with everyone in the thread: as long as this basic
> (looking)
> > > >> > > > issue is not solved, scala is not really a mature
> environment for
> > > >> > > > serious production.
> > > >> > >
> > > >> > > Who said that? Certainly not I.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Randall Schulz
> > > >>
> > > >>
> > > >>
> > > >
> > >
> >
>
>

Hi Christian,

> I think that a programming language that recompilation of the whole
> project every compilation cycle can not be viewed as a mature
> environment.

Does it really need that "every compilation cycle"?
Or from time to time?

> My main headache is that this "corner case" can cause
> problems go unnoticed, causing strange runtime errors that
> are hard to debug, maybe even compiler crashes, where
> wrong assumptions are made on some classes, etc.
> To me it's just plain wrong to let people believe that something
> works well, when in fact it is known, it does not really.

Sounds reasonable at first glance.
But in practice even Java is not mature then...
We have every now and then issues regarding some
dependent sources *not* recompiled by java/ant .
Final statics are a good example of a cornercase.

The simple solution is to do your coding work with simple
compilation and do a clean/compile of the project from
time to time.
(That is not really different to the fact that one does not
immediately update/merge the workarea when one of n colleagues
commits changes into the version system. You can simply do
your work and then there are time spots for such clearing tasks).

So *if* you have issues, try a clean/compile.
*When* you finish a task, do a clean/compile before check-in.

And if someone let stuff go into production directly out of
the workarea without a former clean/compile, better:
fresh checkout/compile/package/test,
I would consider the *process* as absolutely reckless, not
the fact that Scala and its compiler is used.

So such corner case may never be "unnoticed" but only
"unfortunately noticed later in the process".

> I would say, I have similar opinion on scala's implementation of
> pattern matching implementation. It's good enough to have fun
> with it, but it crashed on me so often, I hardly dare to use it
> anymore.

Concrete examples?
(BTW: Is that now mixing language features and compiler skills?)

> E.g. ocaml never,ever crashed on me or died with internal compiler
> error, while scala does that almost every day moderate use.

Question to the developers doing serious Scala work (David Pollak e.g.):

Is that your common experience?

KR
Det

>>>>> "Detering" == Detering Dirk writes:

Christian> E.g. ocaml never,ever crashed on me or died with internal
Christian> compiler error, while scala does that almost every day
Christian> moderate use.

Detering> Question to the developers doing serious Scala work (David
Detering> Pollak e.g.):

Detering> Is that your common experience?

No. A year ago, I was hitting several new bugs a week during active
coding, nearly all of which have now been fixed (in 2.7.x... or on the
trunk, thanks paulp!). These days I'm reporting a bug about every 2
weeks of active coding -- something like that. (These are just rough
estimates, I haven't gone over my old bug reports or anything like
that.)

I imagine some users are pushing Scala harder than I am, though.

I have a java co-worker who *always* does clean rebuilds. This is
because he's run into a few ant/maven issues and decided to take this
approach. So... Perhaps ant is not mature?

Also if you're running into compiler errors all the time, I would love
to see your code! Especially since we could add it to the compiler
testing suite.

On Mar 25, 2009, at 4:40 AM, "Detering Dirk"
wrote:

> Hi Christian,
>
>> I think that a programming language that recompilation of the whole
>> project every compilation cycle can not be viewed as a mature
>> environment.
>
> Does it really need that "every compilation cycle"?
> Or from time to time?
>
>> My main headache is that this "corner case" can cause
>> problems go unnoticed, causing strange runtime errors that
>> are hard to debug, maybe even compiler crashes, where
>> wrong assumptions are made on some classes, etc.
>> To me it's just plain wrong to let people believe that something
>> works well, when in fact it is known, it does not really.
>
> Sounds reasonable at first glance.
> But in practice even Java is not mature then...
> We have every now and then issues regarding some
> dependent sources *not* recompiled by java/ant .
> Final statics are a good example of a cornercase.
>
> The simple solution is to do your coding work with simple
> compilation and do a clean/compile of the project from
> time to time.
> (That is not really different to the fact that one does not
> immediately update/merge the workarea when one of n colleagues
> commits changes into the version system. You can simply do
> your work and then there are time spots for such clearing tasks).
>
> So *if* you have issues, try a clean/compile.
> *When* you finish a task, do a clean/compile before check-in.
>
> And if someone let stuff go into production directly out of
> the workarea without a former clean/compile, better:
> fresh checkout/compile/package/test,
> I would consider the *process* as absolutely reckless, not
> the fact that Scala and its compiler is used.
>
> So such corner case may never be "unnoticed" but only
> "unfortunately noticed later in the process".
>
>> I would say, I have similar opinion on scala's implementation of
>> pattern matching implementation. It's good enough to have fun
>> with it, but it crashed on me so often, I hardly dare to use it
>> anymore.
>
> Concrete examples?
> (BTW: Is that now mixing language features and compiler skills?)
>
>> E.g. ocaml never,ever crashed on me or died with internal compiler
>> error, while scala does that almost every day moderate use.
>
> Question to the developers doing serious Scala work (David Pollak
> e.g.):
>
> Is that your common experience?
>
> KR
> Det