I love Scala. It is my favorite programming language, among the 15 or so I've had the pleasure and/or pain of writing code in. The problem is, I can't use it in the places I want to use it - like the browser, or in a mobile app (outside of Android of course). I've followed the discussions thus far on side projects like Scala+GWT and Scala.NET which are meant to help push Scala into new places, but most of these efforts have thus far been hampered primarily by Scala's dependencies on the JVM. The most successful approaches in these two projects have been to use an existing java-to-* tool (IKVM for Scala.NET and GWT for Scala-to-JS) and hacking together a toolchain to make that tool do something it wasn't designed for originally.
I could be wrong (likely, given I'm not an expert on compilers or language design), but it seems this indirect approach to getting scala onto a non-JVM runtime is not going to work reliably or optimally in the long term. It seems like directly translating scala to a target runtime format, using the full information available inside the scala compiler itself has the potential to be far more optimal than translating from java bytecode or some java-based intermediate representation (as was suggested for Scala+GWT). From the discussions I've read so far, it seems that Scala's dependencies on the JVM and the libraries therein make this route impossible, or at least very difficult.
Should there be talk of a long term project to eliminate or reduce Scala's dependencies on the JVM or JVM libraries, so that it would be much easier to write compiler plugins to output something that could be used on a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it might lower the barrier of entry for these non-JVM runtime targets.
Currently it's hard-to-impossible to create portable meaningful application that uses only scala.* packages. At the moment it lacks so many basic abstractions that are required for every-day usage: file I/O, networking, concurrency, ... Instead usage of java.* classes is encouraged. This basically means that in order to perfectly implement Scala on a new platform from scratch you have to implement: scala language itself, scala standard library, java language, java standard library and probably jvm's byte-code parser/compiler in order to be compatible with binary-only libraries. Only this way you can be sure that application that is currently working on current JVM implementation of Scala will work on the new platform. And that's a complete hell from implementation stand-point.
So "the solution" at the moment is to just use jvm bytecode translation. But that limits your optimization capabilities as you'll have a lot of information lost during Scala -> bytecode translation. Also jvm-optimized representation of Scala code might not suit another platform at all. For example some operation can be really cheap on JVM but extremely expensive on your target platform (e.g. javascript.)
And even in scala.* some libraries are hardly portable. Take Scala Swing for example. It doesn't make any sense beyond JVM as it's definitely not the most expressive way to write gui applications and it's not worth it to re-implement it on another platform. Something much more expressive can definitely be possible in Scala. ScalaFX might or might not be the answer to the question of expressibility but it doesn't help with portability at all.
Scala's deep integration with Java is both a strong benefit and a unpleasant flaw of the current implementation.
On Monday, October 15, 2012 3:07:13 AM UTC+2, sleepy daddy software wrote:
> I love Scala. It is my favorite programming language, among the 15 or so > I've had the pleasure and/or pain of writing code in. The problem is, I > can't use it in the places I want to use it - like the browser, or in a > mobile app (outside of Android of course). I've followed the discussions > thus far on side projects like Scala+GWT and Scala.NET which are meant to > help push Scala into new places, but most of these efforts have thus far > been hampered primarily by Scala's dependencies on the JVM. The most > successful approaches in these two projects have been to use an existing > java-to-* tool (IKVM for Scala.NET and GWT for Scala-to-JS) and hacking > together a toolchain to make that tool do something it wasn't designed for > originally.
> I could be wrong (likely, given I'm not an expert on compilers or language > design), but it seems this indirect approach to getting scala onto a > non-JVM runtime is not going to work reliably or optimally in the long > term. It seems like directly translating scala to a target runtime format, > using the full information available inside the scala compiler itself has > the potential to be far more optimal than translating from java bytecode or > some java-based intermediate representation (as was suggested for > Scala+GWT). From the discussions I've read so far, it seems that Scala's > dependencies on the JVM and the libraries therein make this route > impossible, or at least very difficult.
> Should there be talk of a long term project to eliminate or reduce Scala's > dependencies on the JVM or JVM libraries, so that it would be much easier > to write compiler plugins to output something that could be used on a > non-JVM formats like JavaScript or .Net or LLVM? At the very least, it > might lower the barrier of entry for these non-JVM runtime targets.
A work that can be done to improve Scala's portability:
1) Add a new scala.core package which will contain I/O, networking, concurrency primitives, ... This can be as simple as aliasing Java classes. 2) Make scala compiler and standard library not to use java.* packages but scala.core only. 3) Mark all libraries that doesn't make sense beyond jvm as platform-dependant. (e.g. scala.swing) 4) Add standard FFI capabilities.
In such a way implementation of scala.core and language itself should be sufficient for compiler and (most of) standard library to just work on a new platform. This will also make a strict separation between portable and non-portable scala code.
FFI is also extremely important beyond jvm as there are lots of libraries that can be just wrapped around if there is no pure *portable* scala solution. This can almost instantly allow support for some useful libraries such as GTK which has proven to be easiliy ffi-able. scala.core can also be implemented using ffi on low-level compiled platforms such as llvm.
There are some java-specific ways to do FFI but they don't really work if we are talking about portability.
On Monday, October 15, 2012 11:39:29 AM UTC+2, Den Shabalin wrote:
> I can't agree enough with what are you saying.
> Currently it's hard-to-impossible to create portable meaningful > application that uses only scala.* packages. At the moment it lacks so many > basic abstractions that are required for every-day usage: file I/O, > networking, concurrency, ... Instead usage of java.* classes is encouraged. > This basically means that in order to perfectly implement Scala on a new > platform from scratch you have to implement: scala language itself, scala > standard library, java language, java standard library and probably jvm's > byte-code parser/compiler in order to be compatible with binary-only > libraries. Only this way you can be sure that application that is currently > working on current JVM implementation of Scala will work on the new > platform. And that's a complete hell from implementation stand-point.
> So "the solution" at the moment is to just use jvm bytecode translation. > But that limits your optimization capabilities as you'll have a lot of > information lost during Scala -> bytecode translation. Also jvm-optimized > representation of Scala code might not suit another platform at all. For > example some operation can be really cheap on JVM but extremely expensive > on your target platform (e.g. javascript.)
> And even in scala.* some libraries are hardly portable. Take Scala Swing > for example. It doesn't make any sense beyond JVM as it's definitely not > the most expressive way to write gui applications and it's not worth it to > re-implement it on another platform. Something much more expressive can > definitely be possible in Scala. ScalaFX might or might not be the answer > to the question of expressibility but it doesn't help with portability at > all.
> Scala's deep integration with Java is both a strong benefit and a > unpleasant flaw of the current implementation.
> On Monday, October 15, 2012 3:07:13 AM UTC+2, sleepy daddy software wrote:
>> I love Scala. It is my favorite programming language, among the 15 or so >> I've had the pleasure and/or pain of writing code in. The problem is, I >> can't use it in the places I want to use it - like the browser, or in a >> mobile app (outside of Android of course). I've followed the discussions >> thus far on side projects like Scala+GWT and Scala.NET which are meant to >> help push Scala into new places, but most of these efforts have thus far >> been hampered primarily by Scala's dependencies on the JVM. The most >> successful approaches in these two projects have been to use an existing >> java-to-* tool (IKVM for Scala.NET and GWT for Scala-to-JS) and hacking >> together a toolchain to make that tool do something it wasn't designed for >> originally.
>> I could be wrong (likely, given I'm not an expert on compilers or >> language design), but it seems this indirect approach to getting scala onto >> a non-JVM runtime is not going to work reliably or optimally in the long >> term. It seems like directly translating scala to a target runtime format, >> using the full information available inside the scala compiler itself has >> the potential to be far more optimal than translating from java bytecode or >> some java-based intermediate representation (as was suggested for >> Scala+GWT). From the discussions I've read so far, it seems that Scala's >> dependencies on the JVM and the libraries therein make this route >> impossible, or at least very difficult.
>> Should there be talk of a long term project to eliminate or reduce >> Scala's dependencies on the JVM or JVM libraries, so that it would be much >> easier to write compiler plugins to output something that could be used on >> a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it >> might lower the barrier of entry for these non-JVM runtime targets.
On Mon, Oct 15, 2012 at 10:39 AM, Den Shabalin <den.shaba...@gmail.com> wrote:
> I can't agree enough with what are you saying.
> Currently it's hard-to-impossible to create portable meaningful application
> that uses only scala.* packages. At the moment it lacks so many basic
> abstractions that are required for every-day usage: file I/O, networking,
> concurrency, ... Instead usage of java.* classes is encouraged.
Wrapping everything seems complicated. My feeling is that the good
solution is to introduce
expressive features for conditional compilation and then the user
would have to write low-level things
like that for the platform he uses. (Javascript concurrency and IO
have very little in common to JVM.)
If it is possible, there soon would be third-parties libraries for
abstracting over what can be abstracted,
with different backends.
My main concern is how much of the scala semantics is tied to the JVM,
or at least inspired by it and what can be made fast on it.
what is the advantage of creating wrappers around GTK, a framework which truely sucks in terms of user experience on anything than linux, versus maintaining Scala-Swing as a separate library, where Java-Swing is still the most productive, easy-to-use and x-platform UI framework (at least on the desktop -- but then to my knowledge also GTK is made for the desktop??). that clearly sucks and should be left to third party libraries.
the better approach would be---but that's a huge project---to create a UI library which can abstract from underlying kits such as AWT/Swing, OpenGL or HTML5. Although we can hope that projects such as CacioCavallo might be faster ( http://openjdk.java.net/projects/caciocavallo/ ) in decoupling Java2D or Swing from being tied to one back-end. My knowledge of JavaFX is limited, but I don't know if that is the future, really; it seems Oracle now gave up the idea to run that on phones for example, plus it's still far from fully open-source and true x-platform. (Some interesting thoughts : https://blogs.oracle.com/geertjan/entry/yes_but_that_s_niche )
all in all, being able to leverage the Java SE libraries is a huge plus for Scala; I think it's also part of the DRY. And what would be a reasonable framework to use in place of Java (N)I/O for example? but I agree that the visibility should be minimal in the standard Scala library.
> A work that can be done to improve Scala's portability:
> 1) Add a new scala.core package which will contain I/O, networking, concurrency primitives, ... This can be as simple as aliasing Java classes.
> 2) Make scala compiler and standard library not to use java.* packages but scala.core only. > 3) Mark all libraries that doesn't make sense beyond jvm as platform-dependant. (e.g. scala.swing)
> 4) Add standard FFI capabilities.
> In such a way implementation of scala.core and language itself should be sufficient for compiler and (most of) standard library to just work on a new platform. This will also make a strict separation between portable and non-portable scala code.
> FFI is also extremely important beyond jvm as there are lots of libraries that can be just wrapped around if there is no pure portable scala solution. This can almost instantly allow support for some useful libraries such as GTK which has proven to be easiliy ffi-able. scala.core can also be implemented using ffi on low-level compiled platforms such as llvm.
> There are some java-specific ways to do FFI but they don't really work if we are talking about portability.
> On Monday, October 15, 2012 11:39:29 AM UTC+2, Den Shabalin wrote:
> I can't agree enough with what are you saying.
> Currently it's hard-to-impossible to create portable meaningful application that uses only scala.* packages. At the moment it lacks so many basic abstractions that are required for every-day usage: file I/O, networking, concurrency, ... Instead usage of java.* classes is encouraged. This basically means that in order to perfectly implement Scala on a new platform from scratch you have to implement: scala language itself, scala standard library, java language, java standard library and probably jvm's byte-code parser/compiler in order to be compatible with binary-only libraries. Only this way you can be sure that application that is currently working on current JVM implementation of Scala will work on the new platform. And that's a complete hell from implementation stand-point.
> So "the solution" at the moment is to just use jvm bytecode translation. But that limits your optimization capabilities as you'll have a lot of information lost during Scala -> bytecode translation. Also jvm-optimized representation of Scala code might not suit another platform at all. For example some operation can be really cheap on JVM but extremely expensive on your target platform (e.g. javascript.)
> And even in scala.* some libraries are hardly portable. Take Scala Swing for example. It doesn't make any sense beyond JVM as it's definitely not the most expressive way to write gui applications and it's not worth it to re-implement it on another platform. Something much more expressive can definitely be possible in Scala. ScalaFX might or might not be the answer to the question of expressibility but it doesn't help with portability at all.
> Scala's deep integration with Java is both a strong benefit and a unpleasant flaw of the current implementation.
> On Monday, October 15, 2012 3:07:13 AM UTC+2, sleepy daddy software wrote:
> I love Scala. It is my favorite programming language, among the 15 or so I've had the pleasure and/or pain of writing code in. The problem is, I can't use it in the places I want to use it - like the browser, or in a mobile app (outside of Android of course). I've followed the discussions thus far on side projects like Scala+GWT and Scala.NET which are meant to help push Scala into new places, but most of these efforts have thus far been hampered primarily by Scala's dependencies on the JVM. The most successful approaches in these two projects have been to use an existing java-to-* tool (IKVM for Scala.NET and GWT for Scala-to-JS) and hacking together a toolchain to make that tool do something it wasn't designed for originally.
> I could be wrong (likely, given I'm not an expert on compilers or language design), but it seems this indirect approach to getting scala onto a non-JVM runtime is not going to work reliably or optimally in the long term. It seems like directly translating scala to a target runtime format, using the full information available inside the scala compiler itself has the potential to be far more optimal than translating from java bytecode or some java-based intermediate representation (as was suggested for Scala+GWT). From the discussions I've read so far, it seems that Scala's dependencies on the JVM and the libraries therein make this route impossible, or at least very difficult.
> Should there be talk of a long term project to eliminate or reduce Scala's dependencies on the JVM or JVM libraries, so that it would be much easier to write compiler plugins to output something that could be used on a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it might lower the barrier of entry for these non-JVM runtime targets.
Just to clarify: the goal I would like to see accomplished in a hypothetical "portable scala" project is primarily to support the use case of writing new scala code on a non-JVM runtime or environment. I feel this is a less ambitious goal than attempting to make huge swaths of existing code written in scala portable to other platforms (although that's a good secondary goal too), but it makes a good starting point that I think is more achievable.
As the project matures, more and more scala core libraries might be included in that "portable scala" core set, to make it easier to write portable scala libraries. But, at least at first, it's not so much a big deal for my use case if I have to write platform-specific networking or file IO code using that platform's native libraries. It may be that there's no efficient way to wrap those native libraries anyway, so it might be counter-productive to try. I can get useful work done, as long as platform interop is relatively painless - preferably as easy as Java interop is currently, although JavaScript or native code interop may be more of a challenge. That said, I'm ok with having to write by hand or maybe auto-generating scala proxies for dynamic language runtime or native code runtime interop. That's not unusual for these sorts of things.
There are some libraries in scala that have platform specific implementations, such as those that involve threading, file IO, or networking. I would leave implementation of these libraries up to the compiler for the new platform. I'm not sure how much work could be done to make multiple platform implementations of these APIs easier, so that might be something to research, but for the most part I think each platform is going to want a shot at tailoring their implementation to be the best it can for the platform.
Also, I'm not so much concerned that scala takes on some of the semantics of the Java runtime. I realize portability to non-JVM runtimes wasn't really a focus of the initial design of the scala language, so some JVM idiosyncrasies can be forgiven.
On Monday, October 15, 2012 6:36:28 AM UTC-4, Nicolas Oury wrote:
> On Mon, Oct 15, 2012 at 10:39 AM, Den Shabalin <den.sh...@gmail.com<javascript:>> > wrote: > > I can't agree enough with what are you saying.
> > Currently it's hard-to-impossible to create portable meaningful > application > > that uses only scala.* packages. At the moment it lacks so many basic > > abstractions that are required for every-day usage: file I/O, > networking, > > concurrency, ... Instead usage of java.* classes is encouraged.
> Wrapping everything seems complicated. My feeling is that the good > solution is to introduce > expressive features for conditional compilation and then the user > would have to write low-level things > like that for the platform he uses. (Javascript concurrency and IO > have very little in common to JVM.) > If it is possible, there soon would be third-parties libraries for > abstracting over what can be abstracted, > with different backends.
> My main concern is how much of the scala semantics is tied to the JVM, > or at least inspired by it and what can be made fast on it.
On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <
bell.jer...@gmail.com> wrote:
> I love Scala. It is my favorite programming language, among the 15 or so
> I've had the pleasure and/or pain of writing code in. The problem is, I
> can't use it in the places I want to use it - like the browser, or in a
> mobile app (outside of Android of course).
You can't use Java in the browser? I've been doing that since 1997.
> Should there be talk of a long term project to eliminate or reduce Scala's
> dependencies on the JVM or JVM libraries, so that it would be much easier
> to write compiler plugins to output something that could be used on a
> non-JVM formats like JavaScript or .Net or LLVM? At the very least, it
> might lower the barrier of entry for these non-JVM runtime targets.
Personally, I think this is backwards. The JVM is already a great platform
library. It's a bit heavyweight, which for the next couple of years will
make it an awkward fit on smartphones, but basically we _already have the
cross-platform tool you're talking about_. Making good cross-platform
tools is hard work, and I'd rather have Scala development efforts go
towards doing what Scala does uniquely well, not retreading the "let's make
it cross-platform, too, for my favorite definition of platform!" road that
has been walked so many times before, usually unsuccessfully.
Let's ask about the solution in each case.
(1) .NET. The JVM works just fine on every machine I know of where .NET
works at all. So you can certainly use Scala on the hardware. Maybe you
need an interoperability layer to existing .NET stuff, but that's different
(and should be considerably easier) than jettisoning all traces of Java/JVM
dependence from Scala.
(2) LLVM. Why? The JVM is highly optimized for what it (and Scala, for
the most part) needs. You already can call native code with JNA and JNI.
(3) JavaScript. Many key advantages of Scala (e.g. type safety,
performance) are lost by going to JavaScript as an intermediate, and most
anything that runs JavaScript could now or will soon be able to run a JVM
as well/instead. Rather than doing lots of work to end up with an improved
but ultimately sub-standard solution, why not instead try to get the JVM to
work in more places? Between Dalvik and the Oracle JVM for ARM, there
isn't much that seems out of reach.
So although it is nice to know that Scala is not in principle wholly
dependent on the JVM and Java libraries, in practice I don't think trying
to divorce them is a good use of effort. It's a _huge_ amount of work, and
then you put yourself in the position of having to chase a bunch of
different developments, giving you a much higher ongoing maintenance cost.
In the very long term, if Scala becomes one of the top handful of
languages, I could see something like this happening. Right now, I think
using other more general tools as bridges (like GWT) is by far the most
effective way to go. (And if Scala does become that popular, I think it's
at least as likely that browsers will pick up the JVM as a core part of
their functionality than that Scala will end up running well on a
JavaScript engine.)
You've missed my point. It's absolutely not about GTK vs Swing. I don't really like GTK myself. It was there just as an example of a library that can be ffi-ed to.
I was actually talking about mere ability to have sane non-jvm implementation(s) of Scala and to make it possible to write code that will be portable between those implementations. E.g. if you write http server in Scala it should "just work" on any implementation of scala (JVM, .NET, LLVM, …) without any modifications in code base. And those .NET and LLVM implementations should not re-implement whole JVM to archive that.
There is no need actually to re-implement or wrap anything. In the simplest scenario we can have very same interface as java's i/o libraries but have it standardized as part of Scala language/runtime/standard library.
This way there is clean split between portable and non-portable Scala code i.e. if you only use scala.* your code should just work on any complete Scala implementation. And tools provided in scala.* should be sufficient to do anything meaningful.
On Monday, October 15, 2012 4:34:56 PM UTC+2, Hanns Holger Rutz wrote:
> what is the advantage of creating wrappers around GTK, a framework which > truely sucks in terms of user experience on anything than linux, versus > maintaining Scala-Swing as a separate library, where Java-Swing is still > the most productive, easy-to-use and x-platform UI framework (at least on > the desktop -- but then to my knowledge also GTK is made for the > desktop??). that clearly sucks and should be left to third party libraries.
> the better approach would be---but that's a huge project---to create a UI > library which can abstract from underlying kits such as AWT/Swing, OpenGL > or HTML5. Although we can hope that projects such as CacioCavallo might be > faster ( http://openjdk.java.net/projects/caciocavallo/ ) in decoupling > Java2D or Swing from being tied to one back-end. My knowledge of JavaFX is > limited, but I don't know if that is the future, really; it seems Oracle > now gave up the idea to run that on phones for example, plus it's still far > from fully open-source and true x-platform. (Some interesting thoughts : > https://blogs.oracle.com/geertjan/entry/yes_but_that_s_niche )
> all in all, being able to leverage the Java SE libraries is a huge plus > for Scala; I think it's also part of the DRY. And what would be a > reasonable framework to use in place of Java (N)I/O for example? but I > agree that the visibility should be minimal in the standard Scala library.
> best, .h.h.
> On 15 Oct 2012, at 12:27, Den Shabalin wrote:
> > A work that can be done to improve Scala's portability:
> > 1) Add a new scala.core package which will contain I/O, networking, > concurrency primitives, ... This can be as simple as aliasing Java classes. > > 2) Make scala compiler and standard library not to use java.* packages > but scala.core only. > > 3) Mark all libraries that doesn't make sense beyond jvm as > platform-dependant. (e.g. scala.swing) > > 4) Add standard FFI capabilities.
> > In such a way implementation of scala.core and language itself should be > sufficient for compiler and (most of) standard library to just work on a > new platform. This will also make a strict separation between portable and > non-portable scala code.
> > FFI is also extremely important beyond jvm as there are lots of > libraries that can be just wrapped around if there is no pure portable > scala solution. This can almost instantly allow support for some useful > libraries such as GTK which has proven to be easiliy ffi-able. scala.core > can also be implemented using ffi on low-level compiled platforms such as > llvm.
> > There are some java-specific ways to do FFI but they don't really work > if we are talking about portability.
> > On Monday, October 15, 2012 11:39:29 AM UTC+2, Den Shabalin wrote: > > I can't agree enough with what are you saying.
> > Currently it's hard-to-impossible to create portable meaningful > application that uses only scala.* packages. At the moment it lacks so many > basic abstractions that are required for every-day usage: file I/O, > networking, concurrency, ... Instead usage of java.* classes is encouraged. > This basically means that in order to perfectly implement Scala on a new > platform from scratch you have to implement: scala language itself, scala > standard library, java language, java standard library and probably jvm's > byte-code parser/compiler in order to be compatible with binary-only > libraries. Only this way you can be sure that application that is currently > working on current JVM implementation of Scala will work on the new > platform. And that's a complete hell from implementation stand-point.
> > So "the solution" at the moment is to just use jvm bytecode translation. > But that limits your optimization capabilities as you'll have a lot of > information lost during Scala -> bytecode translation. Also jvm-optimized > representation of Scala code might not suit another platform at all. For > example some operation can be really cheap on JVM but extremely expensive > on your target platform (e.g. javascript.)
> > And even in scala.* some libraries are hardly portable. Take Scala Swing > for example. It doesn't make any sense beyond JVM as it's definitely not > the most expressive way to write gui applications and it's not worth it to > re-implement it on another platform. Something much more expressive can > definitely be possible in Scala. ScalaFX might or might not be the answer > to the question of expressibility but it doesn't help with portability at > all.
> > Scala's deep integration with Java is both a strong benefit and a > unpleasant flaw of the current implementation.
> > On Monday, October 15, 2012 3:07:13 AM UTC+2, sleepy daddy software > wrote: > > I love Scala. It is my favorite programming language, among the 15 or so > I've had the pleasure and/or pain of writing code in. The problem is, I > can't use it in the places I want to use it - like the browser, or in a > mobile app (outside of Android of course). I've followed the discussions > thus far on side projects like Scala+GWT and Scala.NET which are meant to > help push Scala into new places, but most of these efforts have thus far > been hampered primarily by Scala's dependencies on the JVM. The most > successful approaches in these two projects have been to use an existing > java-to-* tool (IKVM for Scala.NET and GWT for Scala-to-JS) and hacking > together a toolchain to make that tool do something it wasn't designed for > originally.
> > I could be wrong (likely, given I'm not an expert on compilers or > language design), but it seems this indirect approach to getting scala onto > a non-JVM runtime is not going to work reliably or optimally in the long > term. It seems like directly translating scala to a target runtime format, > using the full information available inside the scala compiler itself has > the potential to be far more optimal than translating from java bytecode or > some java-based intermediate representation (as was suggested for > Scala+GWT). From the discussions I've read so far, it seems that Scala's > dependencies on the JVM and the libraries therein make this route > impossible, or at least very difficult.
> > Should there be talk of a long term project to eliminate or reduce > Scala's dependencies on the JVM or JVM libraries, so that it would be much > easier to write compiler plugins to output something that could be used on > a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it > might lower the barrier of entry for these non-JVM runtime targets.
There are huge advantages to running on the JVM, but I sympathize with the
desire to run off of it.
Java in the browser doesn't exist on mobile devices, which are an
increasing fraction of the world's browsers. There is no reason why
compiling to javascript should lose type safety, any more the GWT loses
type safety (i.e. you can't do fancy reflection stuff, but you still get
some compile time checks), although you'd probably slow to a crawl.
I don't believe the JVM will run on Windows 8 Metro or Windows Phone 8,
which supports .NET, and I think will make up a non-trivial fraction of
devices in future.
Overall, I don't think it's going to happen any time soon, but just because
it's hard (i.e. impossible) to move off the JVM doesn't mean that can't
dream about the advantages that such a herculean task would bring (Scala on
iOS please!). Alas, the world is fragmented, and it doesn't look like it's
going to happen any time soon.
On Mon, Oct 15, 2012 at 11:17 AM, Rex Kerr <icho...@gmail.com> wrote:
> On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <
> bell.jer...@gmail.com> wrote:
>> I love Scala. It is my favorite programming language, among the 15 or so
>> I've had the pleasure and/or pain of writing code in. The problem is, I
>> can't use it in the places I want to use it - like the browser, or in a
>> mobile app (outside of Android of course).
> You can't use Java in the browser? I've been doing that since 1997.
>> Should there be talk of a long term project to eliminate or reduce
>> Scala's dependencies on the JVM or JVM libraries, so that it would be much
>> easier to write compiler plugins to output something that could be used on
>> a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it
>> might lower the barrier of entry for these non-JVM runtime targets.
> Personally, I think this is backwards. The JVM is already a great
> platform library. It's a bit heavyweight, which for the next couple of
> years will make it an awkward fit on smartphones, but basically we _already
> have the cross-platform tool you're talking about_. Making good
> cross-platform tools is hard work, and I'd rather have Scala development
> efforts go towards doing what Scala does uniquely well, not retreading the
> "let's make it cross-platform, too, for my favorite definition of
> platform!" road that has been walked so many times before, usually
> unsuccessfully.
> Let's ask about the solution in each case.
> (1) .NET. The JVM works just fine on every machine I know of where .NET
> works at all. So you can certainly use Scala on the hardware. Maybe you
> need an interoperability layer to existing .NET stuff, but that's different
> (and should be considerably easier) than jettisoning all traces of Java/JVM
> dependence from Scala.
> (2) LLVM. Why? The JVM is highly optimized for what it (and Scala, for
> the most part) needs. You already can call native code with JNA and JNI.
> (3) JavaScript. Many key advantages of Scala (e.g. type safety,
> performance) are lost by going to JavaScript as an intermediate, and most
> anything that runs JavaScript could now or will soon be able to run a JVM
> as well/instead. Rather than doing lots of work to end up with an improved
> but ultimately sub-standard solution, why not instead try to get the JVM to
> work in more places? Between Dalvik and the Oracle JVM for ARM, there
> isn't much that seems out of reach.
> So although it is nice to know that Scala is not in principle wholly
> dependent on the JVM and Java libraries, in practice I don't think trying
> to divorce them is a good use of effort. It's a _huge_ amount of work, and
> then you put yourself in the position of having to chase a bunch of
> different developments, giving you a much higher ongoing maintenance cost.
> In the very long term, if Scala becomes one of the top handful of
> languages, I could see something like this happening. Right now, I think
> using other more general tools as bridges (like GWT) is by far the most
> effective way to go. (And if Scala does become that popular, I think it's
> at least as likely that browsers will pick up the JVM as a core part of
> their functionality than that Scala will end up running well on a
> JavaScript engine.)
> (1) .NET. The JVM works just fine on every machine I know of where .NET > works at all. So you can certainly use Scala on the hardware. Maybe you > need an interoperability layer to existing .NET stuff, but that's different > (and should be considerably easier) than jettisoning all traces of Java/JVM > dependence from Scala.
.NET is superior platform for Desktop applications in just about any way. Libraries are better. Memory allocation/gc is much more appropriate for the task. Have you ever seen any other editors beside those written in Java that require 512+ MB of RAM just to start-up?
JVM is not tuned to desktop applications. I would love to see desktop-optimized version of JVM, really, but that never happened.
> (2) LLVM. Why? The JVM is highly optimized for what it (and Scala, for > the most part) needs. You already can call native code with JNA and JNI.
At least one benefit is almost certain -- startup time. Everything else might or not might be better and that will depend on quality of implementation. Theoretically you can have runtime that is more aware of Scala code and it's primitives and will optimize them accordingly. JVM has no idea about Scala-specific semantics (e.g. Traits) at all.
> (3) JavaScript. Many key advantages of Scala (e.g. type safety, > performance) are lost by going to JavaScript as an intermediate, and most > anything that runs JavaScript could now or will soon be able to run a JVM > as well/instead. Rather than doing lots of work to end up with an improved > but ultimately sub-standard solution, why not instead try to get the JVM to > work in more places? Between Dalvik and the Oracle JVM for ARM, there > isn't much that seems out of reach.
Haskell is compiled to binary code which doesn't have any idea about type safety whatsover. Does it make compiled Haskell code unsafe?
Both JVM and Flash have lost as in-browser runtimes. Looking into the future JavaScript is the only way to go if you want to create interactive web pages.
On Monday, October 15, 2012 11:17:36 AM UTC-4, Rex Kerr wrote:
> On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <bell....@gmail.com<javascript:> > > wrote:
>> I love Scala. It is my favorite programming language, among the 15 or so >> I've had the pleasure and/or pain of writing code in. The problem is, I >> can't use it in the places I want to use it - like the browser, or in a >> mobile app (outside of Android of course).
> You can't use Java in the browser? I've been doing that since 1997.
The web has moved on. You cannot use the Java plugin on any mobile browser, even on Android, and there is zero chance that this will be added in the future. If I proposed a new enterprise application web application that required a browser plugin, I would be laughed at, then probably fired.
> Should there be talk of a long term project to eliminate or reduce Scala's >> dependencies on the JVM or JVM libraries, so that it would be much easier >> to write compiler plugins to output something that could be used on a >> non-JVM formats like JavaScript or .Net or LLVM? At the very least, it >> might lower the barrier of entry for these non-JVM runtime targets.
> Personally, I think this is backwards. The JVM is already a great > platform library. It's a bit heavyweight, which for the next couple of > years will make it an awkward fit on smartphones, but basically we _already > have the cross-platform tool you're talking about_. Making good > cross-platform tools is hard work, and I'd rather have Scala development > efforts go towards doing what Scala does uniquely well, not retreading the > "let's make it cross-platform, too, for my favorite definition of > platform!" road that has been walked so many times before, usually > unsuccessfully.
> Let's ask about the solution in each case.
> (1) .NET. The JVM works just fine on every machine I know of where .NET > works at all. So you can certainly use Scala on the hardware. Maybe you > need an interoperability layer to existing .NET stuff, but that's different > (and should be considerably easier) than jettisoning all traces of Java/JVM > dependence from Scala.
I can't use Scala for windows 8 store applications, windows phone applications, netduino applications, SQL Server CLR code, ASP.NET applications, WPF applications, etc.... I could go on. Also, this long term project isn't specific to any one runtime - it's meant as a long term project to bring the core scala language to more runtimes. Each runtime has its own use cases. If they're compelling enough, a scala compiler extension for them will be written and maintained by the community. But these projects need some help, which is what I'm proposing we do.
> (2) LLVM. Why? The JVM is highly optimized for what it (and Scala, for > the most part) needs. You already can call native code with JNA and JNI.
This is how the Mono compiler targets native iOS application development (for ahead of time compilation), so I brought it up as a possibility.
> (3) JavaScript. Many key advantages of Scala (e.g. type safety, > performance) are lost by going to JavaScript as an intermediate, and most > anything that runs JavaScript could now or will soon be able to run a JVM > as well/instead. Rather than doing lots of work to end up with an improved > but ultimately sub-standard solution, why not instead try to get the JVM to > work in more places? Between Dalvik and the Oracle JVM for ARM, there > isn't much that seems out of reach.
See my response earlier to your comment on the Java plugin. This is not true. If you are targeting android native development, you get an easy route to use scala code because android happens to support the JDK in its dalvik runtime. This is great, but this is a completely different thing from open web development.
Also, type safety is a feature of the language, not the runtime. When you compile scala to java bytecode, you lose information. You lose even more information when that bytecode gets JIT compiled to machine code. In the case of a JavaScript targeting scala compiler, it would be generating JavaScript as if it were a kind of high level assembly language, complete with Chrome-compatible javascript source maps so you can debug your scala code right in the browser.
> So although it is nice to know that Scala is not in principle wholly > dependent on the JVM and Java libraries, in practice I don't think trying > to divorce them is a good use of effort. It's a _huge_ amount of work, and > then you put yourself in the position of having to chase a bunch of > different developments, giving you a much higher ongoing maintenance cost.
> In the very long term, if Scala becomes one of the top handful of > languages, I could see something like this happening. Right now, I think > using other more general tools as bridges (like GWT) is by far the most > effective way to go. (And if Scala does become that popular, I think it's > at least as likely that browsers will pick up the JVM as a core part of > their functionality than that Scala will end up running well on a > JavaScript engine.)
I agree that bridge tools are the best option in the short term. This discussion is explicitly about the long term future of scala, and in the long term I think we should be working towards transitioning away from these tools and towards direct scala-to-* targeting, and making that a more feasible solution. None of this could be implemented overnight obviously. But I think the project benefits the language as a whole. Making it easier to write scala compiler plugins to directly target a different runtime improves scala adoption.
> .NET is superior platform for Desktop applications in just about any way.
> Libraries are better. Memory allocation/gc is much more appropriate for the task.
I don't quite agree, I found the Java libraries much better, especially when you include the open-source ecosystem. (I would love an Apache Commons .NET). But I agree about memory and such.
> Have you ever seen any other editors beside those written in Java that require 512+ MB of RAM just to start-up?
Visual Studio 2002 through 2008. (I'm not MS bashing, there's a lot I like about Visual Studio.)
> JVM is not tuned to desktop applications. I would love to see
> desktop-optimized version of JVM, really, but that never happened.
Isn't that the point of the --client flag is? I know its there, but I don't know much about it.
I think the discussion about .NET being a better platform for the client is a bit skewed -- I can't reasonably write a .NET desktop application for Linux/MacOS without eschewing parts of the .NET libraries and Visual Studio. (And I honestly I wish I could.) And I think its distracting from the main topic of Scala-JVM dependency.
> (1) .NET. The JVM works just fine on every machine I know of
> where .NET works at all. So you can certainly use Scala on the
> hardware. Maybe you need an interoperability layer to existing
> .NET stuff, but that's different (and should be considerably
> easier) than jettisoning all traces of Java/JVM dependence from Scala.
> .NET is superior platform for Desktop applications in just about any > way. Libraries are better. Memory allocation/gc is much more > appropriate for the task. Have you ever seen any other editors beside > those written in Java that require 512+ MB of RAM just to start-up?
> JVM is not tuned to desktop applications. I would love to see > desktop-optimized version of JVM, really, but that never happened.
> (2) LLVM. Why? The JVM is highly optimized for what it (and
> Scala, for the most part) needs. You already can call native code
> with JNA and JNI.
> At least one benefit is almost certain -- startup time. Everything > else might or not might be better and that will depend on quality of > implementation. Theoretically you can have runtime that is more aware > of Scala code and it's primitives and will optimize them accordingly. > JVM has no idea about Scala-specific semantics (e.g. Traits) at all.
> (3) JavaScript. Many key advantages of Scala (e.g. type safety,
> performance) are lost by going to JavaScript as an intermediate,
> and most anything that runs JavaScript could now or will soon be
> able to run a JVM as well/instead. Rather than doing lots of work
> to end up with an improved but ultimately sub-standard solution,
> why not instead try to get the JVM to work in more places? > Between Dalvik and the Oracle JVM for ARM, there isn't much that
> seems out of reach.
> Haskell is compiled to binary code which doesn't have any idea about > type safety whatsover. Does it make compiled Haskell code unsafe?
> Both JVM and Flash have lost as in-browser runtimes. Looking into the > future JavaScript is the only way to go if you want to create > interactive web pages.
Obviously a virtual machine built for Scala could be way better than the JVM. However to attempt such a project now would be futile. Scala hasn't even got a full GUI api of its own, at the moment. The one possibility I can see is a machine code compiler for Linux. There might be sufficient open source community energy for such a project and given Linux's domination on the server market and its heavy inroads into the mobile market, there could be serious potential commercial backing as well. With Windows 8 Microsoft has broadcast loud and clear that its no longer interested in the Desktop. I shall be going over to Linux. I doubt I'm the only one. I think Linux could make make big inroads into the developer environment market.
On Mon, Oct 15, 2012 at 12:09 PM, sleepy daddy software <
bell.jer...@gmail.com> wrote:
> The web has moved on. You cannot use the Java plugin on any mobile
> browser, even on Android, and there is zero chance that this will be added
> in the future. If I proposed a new enterprise application web application
> that required a browser plugin, I would be laughed at, then probably fired.
How would you make a cross-platform webapp that can get an image from a
scanner? I had the requirement, and the only solution seemed to be an
applet (which ultimately calls into native code). Similarly I needed to
record audio from a webapp and upload it, and although I found a flash
component (WAMI recorder) that supposedly did it, I couldn't get it to
work. Again, I ended up writing an applet.
A technology is outdated when there's an adequate replacement, not when
people simply declare it dead.
I don't think you're thinking about this on the right timescale. If there
were the manpower to make something big happen in a year or so, sure. But
if you are talking about reallocating already scarce resources to this, I
think the picture changes.
On Mon, Oct 15, 2012 at 12:09 PM, sleepy daddy software <
bell.jer...@gmail.com> wrote:
> See my comments below:
> On Monday, October 15, 2012 11:17:36 AM UTC-4, Rex Kerr wrote:
>> On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <
>> bell....@gmail.com> wrote:
>>> I love Scala. It is my favorite programming language, among the 15 or so
>>> I've had the pleasure and/or pain of writing code in. The problem is, I
>>> can't use it in the places I want to use it - like the browser, or in a
>>> mobile app (outside of Android of course).
>> You can't use Java in the browser? I've been doing that since 1997.
> The web has moved on. You cannot use the Java plugin on any mobile
> browser, even on Android, and there is zero chance that this will be added
> in the future. If I proposed a new enterprise application web application
> that required a browser plugin, I would be laughed at, then probably fired.
Oh, yes. And Objective-C is a dead language, by the way. Programming has
moved on.
Except, oops.
If you have a killer application (i.e. that you are the favored language to
write the killer applications for the killer devices), historical trends
can reverse dramatically.
If you ask as a technical matter whether a modestly enhanced Java plugin is
competitive with JavaScript capabilities and implementable on mobile
devices available in a couple of years (or the highest end ones now), the
answer is "yes"; in some ways it's probably better.
So, I advise being the killer app over changing the framework (and using
generic tools like GWT in the meantime).
>> Should there be talk of a long term project to eliminate or reduce
>>> Scala's dependencies on the JVM or JVM libraries, so that it would be much
>>> easier to write compiler plugins to output something that could be used on
>>> a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it
>>> might lower the barrier of entry for these non-JVM runtime targets.
>> Personally, I think this is backwards. The JVM is already a great
>> platform library. It's a bit heavyweight, which for the next couple of
>> years will make it an awkward fit on smartphones, but basically we _already
>> have the cross-platform tool you're talking about_. Making good
>> cross-platform tools is hard work, and I'd rather have Scala development
>> efforts go towards doing what Scala does uniquely well, not retreading the
>> "let's make it cross-platform, too, for my favorite definition of
>> platform!" road that has been walked so many times before, usually
>> unsuccessfully.
>> Let's ask about the solution in each case.
>> (1) .NET. The JVM works just fine on every machine I know of where .NET
>> works at all. So you can certainly use Scala on the hardware. Maybe you
>> need an interoperability layer to existing .NET stuff, but that's different
>> (and should be considerably easier) than jettisoning all traces of Java/JVM
>> dependence from Scala.
> I can't use Scala for windows 8 store applications, windows phone
> applications, netduino applications, SQL Server CLR code, ASP.NETapplications, WPF applications, etc.... I could go on.
Well, a lot of these are software not hardware limitations, which is why I
said _machine_ and mentioned interoperability layers. I'm not sure I'd
look forward to running Scala on uJ on an arduino board, though. My point
is that "I-can-call-X" and "I-am-implemented-natively-inside-X-framework"
are completely different levels of effort.
> If they're compelling enough, a scala compiler extension for them will be
> written and maintained by the community. But these projects need some help,
> which is what I'm proposing we do.
Well, fair enough. But they're a LOT of work. If people want to, I don't
see why they shouldn't, but I don't think it should distract from core
Scala development at this point.
>> (3) JavaScript. Many key advantages of Scala (e.g. type safety,
>> performance) are lost by going to JavaScript as an intermediate, and most
>> anything that runs JavaScript could now or will soon be able to run a JVM
>> as well/instead. Rather than doing lots of work to end up with an improved
>> but ultimately sub-standard solution, why not instead try to get the JVM to
>> work in more places? Between Dalvik and the Oracle JVM for ARM, there
>> isn't much that seems out of reach.
> See my response earlier to your comment on the Java plugin. This is not
> true. If you are targeting android native development, you get an easy
> route to use scala code because android happens to support the JDK in its
> dalvik runtime. This is great, but this is a completely different thing
> from open web development.
Agreed; that would require something important enough that JVM-in-browser
becomes worthwhile. (The entry barrier is pretty low; the technology is
mostly there, it's just "not cool" right now, and Sun/Oracle lack-of-vision
has not helped matters.)
> Also, type safety is a feature of the language, not the runtime. When you
> compile scala to java bytecode, you lose information. You lose even more
> information when that bytecode gets JIT compiled to machine code. In the
> case of a JavaScript targeting scala compiler, it would be generating
> JavaScript as if it were a kind of high level assembly language, complete
> with Chrome-compatible javascript source maps so you can debug your scala
> code right in the browser.
I agree, of course, about type-safety but since you can translate JVM
bytecode to JS, there are considerations beyond just whether it's
possible. And here it's nice to have support in the bytecode/assembly so
you can do your runtime type checks; JS engines have an idea of _object
shape_ that is much more like structural typing in Scala and much less like
objects with an exact type in the JVM. Maybe I'm mistaken, but my
impression was that the blazing-fast JVM instanceof style checks--a core
component of pattern matching for instance--would be drastically slower on
a JS engine. And there's also the limited number of primitive types, which
would be a headache even conceptually.
Anyway, my point is not very strong here since I am only passingly familiar
with the relevant implementation details.
> I agree that bridge tools are the best option in the short term. This
> discussion is explicitly about the long term future of scala, and in the
> long term I think we should be working towards transitioning away from
> these tools
Well, it's hard to argue with the long term since a lot can happen in the
long term. In the short term, absent resources to make a major effort, I'm
not sure it's worth it. In the long term, maybe JS engines will become
more and more like the JVM/CLR for performance reasons, and then porting
for speed will make more sense (as the features required for speed will be
there already).
On Sun, Oct 14, 2012 at 6:07 PM, sleepy daddy software <
bell.jer...@gmail.com> wrote:
> Should there be talk of a long term project to eliminate or reduce Scala's
> dependencies on the JVM or JVM libraries, so that it would be much easier
> to write compiler plugins to output something that could be used on a
> non-JVM formats like JavaScript or .Net or LLVM? At the very least, it
> might lower the barrier of entry for these non-JVM runtime targets.
I'm sure Geoff will tell you that it's very early days, he doesn't have
much time to work on it, it's nowhere near ready, etc., but you're not the
only one having these thoughts. :)
On Mon, Oct 15, 2012 at 9:55 AM, Rex Kerr <icho...@gmail.com> wrote:
> Well, fair enough. But they're a LOT of work. If people want to, I don't
> see why they shouldn't, but I don't think it should distract from core
> Scala development at this point.
Yes, this is the main thing. The interesting question is not whether it's
a good idea, but whether it's a good idea in light of the resources which
are available and the resources it would require. I'm all for it
happening, but it seems like a clear "no" in that context. Anyone who
thinks otherwise most likely massively misjudges the true values of
"available", "require", or both.
I would also council caution from a political perspective. At the moment Scala poses no threat to Oracle. Scala is arguably a modest contributor to the value and status of the JVM. However if Oracle thought that there was a serious threat of Scala developing a credible alternative to the JVM, I imagine they might find ways to make life difficult for Scala.
I seriously doubt they would bother. What they could do technically or
legally would be weak to nonexistent given the licensing of the JVM / Java
standard library (that they cannot do this is a big part of the point of
having such licenses and a big part of the appeal of targeting the JVM!),
and they have better things to worry about, like Dalvik. Besides, who's to
say that having better CLR support with Scala wouldn't produce a net
movement of developers from CLR to JVM over time rather than the reverse?
(Or a net movement to both at the expense of PHP or whatever.)
On Mon, Oct 15, 2012 at 5:01 PM, Rich Oliver <richaoli...@yahoo.com> wrote:
> I would also council caution from a political perspective. At the moment
> Scala poses no threat to Oracle. Scala is arguably a modest contributor to
> the value and status of the JVM. However if Oracle thought that there was a
> serious threat of Scala developing a credible alternative to the JVM, I
> imagine they might find ways to make life difficult for Scala.
I think a reasonable way would be better participation in the JEP/JSR committees or hiring an VM engineer to work on JVM stuff Scala considers important.
On Monday, October 15, 2012 12:55:39 PM UTC-4, Rex Kerr wrote:
> I don't think you're thinking about this on the right timescale. If there > were the manpower to make something big happen in a year or so, sure. But > if you are talking about reallocating already scarce resources to this, I > think the picture changes.
> On Mon, Oct 15, 2012 at 12:09 PM, sleepy daddy software < > bell....@gmail.com <javascript:>> wrote:
>> See my comments below:
>> On Monday, October 15, 2012 11:17:36 AM UTC-4, Rex Kerr wrote:
>>> On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software < >>> bell....@gmail.com> wrote:
>>>> I love Scala. It is my favorite programming language, among the 15 or >>>> so I've had the pleasure and/or pain of writing code in. The problem is, I >>>> can't use it in the places I want to use it - like the browser, or in a >>>> mobile app (outside of Android of course).
>>> You can't use Java in the browser? I've been doing that since 1997.
>> The web has moved on. You cannot use the Java plugin on any mobile >> browser, even on Android, and there is zero chance that this will be added >> in the future. If I proposed a new enterprise application web application >> that required a browser plugin, I would be laughed at, then probably fired.
> Oh, yes. And Objective-C is a dead language, by the way. Programming has > moved on.
> Except, oops.
> If you have a killer application (i.e. that you are the favored language > to write the killer applications for the killer devices), historical trends > can reverse dramatically.
> If you ask as a technical matter whether a modestly enhanced Java plugin > is competitive with JavaScript capabilities and implementable on mobile > devices available in a couple of years (or the highest end ones now), the > answer is "yes"; in some ways it's probably better.
> So, I advise being the killer app over changing the framework (and using > generic tools like GWT in the meantime).
Objective-C did not become popular because it was the killer language, but because it was endorsed by Apple. Scala is not in a similar position. The Objective-C case shows that mobile/web app developers will use whatever tools are easily available for the target platforms. Mobile/web development will thrive for the next couple of years with or without Scala. Having the dependency of JVM only makes the cost of adopting Scala higher.
Similarly, I think many .NET developers would pick up Scala if there was a .NET implementation, many less so if they had to abandon .NET and switch to JVM.
That said, I still would rather have the Scala development team focus on the language than anything else.
>>> Should there be talk of a long term project to eliminate or reduce >>>> Scala's dependencies on the JVM or JVM libraries, so that it would be much >>>> easier to write compiler plugins to output something that could be used on >>>> a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it >>>> might lower the barrier of entry for these non-JVM runtime targets.
>>> Personally, I think this is backwards. The JVM is already a great >>> platform library. It's a bit heavyweight, which for the next couple of >>> years will make it an awkward fit on smartphones, but basically we _already >>> have the cross-platform tool you're talking about_. Making good >>> cross-platform tools is hard work, and I'd rather have Scala development >>> efforts go towards doing what Scala does uniquely well, not retreading the >>> "let's make it cross-platform, too, for my favorite definition of >>> platform!" road that has been walked so many times before, usually >>> unsuccessfully.
>>> Let's ask about the solution in each case.
>>> (1) .NET. The JVM works just fine on every machine I know of where .NET >>> works at all. So you can certainly use Scala on the hardware. Maybe you >>> need an interoperability layer to existing .NET stuff, but that's different >>> (and should be considerably easier) than jettisoning all traces of Java/JVM >>> dependence from Scala.
>> I can't use Scala for windows 8 store applications, windows phone >> applications, netduino applications, SQL Server CLR code, ASP.NETapplications, WPF applications, etc.... I could go on.
> Well, a lot of these are software not hardware limitations, which is why I > said _machine_ and mentioned interoperability layers. I'm not sure I'd > look forward to running Scala on uJ on an arduino board, though. My point > is that "I-can-call-X" and "I-am-implemented-natively-inside-X-framework" > are completely different levels of effort.
>> If they're compelling enough, a scala compiler extension for them will be >> written and maintained by the community. But these projects need some help, >> which is what I'm proposing we do.
> Well, fair enough. But they're a LOT of work. If people want to, I don't > see why they shouldn't, but I don't think it should distract from core > Scala development at this point.
>>> (3) JavaScript. Many key advantages of Scala (e.g. type safety, >>> performance) are lost by going to JavaScript as an intermediate, and most >>> anything that runs JavaScript could now or will soon be able to run a JVM >>> as well/instead. Rather than doing lots of work to end up with an improved >>> but ultimately sub-standard solution, why not instead try to get the JVM to >>> work in more places? Between Dalvik and the Oracle JVM for ARM, there >>> isn't much that seems out of reach.
>> See my response earlier to your comment on the Java plugin. This is not >> true. If you are targeting android native development, you get an easy >> route to use scala code because android happens to support the JDK in its >> dalvik runtime. This is great, but this is a completely different thing >> from open web development.
> Agreed; that would require something important enough that JVM-in-browser > becomes worthwhile. (The entry barrier is pretty low; the technology is > mostly there, it's just "not cool" right now, and Sun/Oracle lack-of-vision > has not helped matters.)
>> Also, type safety is a feature of the language, not the runtime. When you >> compile scala to java bytecode, you lose information. You lose even more >> information when that bytecode gets JIT compiled to machine code. In the >> case of a JavaScript targeting scala compiler, it would be generating >> JavaScript as if it were a kind of high level assembly language, complete >> with Chrome-compatible javascript source maps so you can debug your scala >> code right in the browser.
> I agree, of course, about type-safety but since you can translate JVM > bytecode to JS, there are considerations beyond just whether it's > possible. And here it's nice to have support in the bytecode/assembly so > you can do your runtime type checks; JS engines have an idea of _object > shape_ that is much more like structural typing in Scala and much less like > objects with an exact type in the JVM. Maybe I'm mistaken, but my > impression was that the blazing-fast JVM instanceof style checks--a core > component of pattern matching for instance--would be drastically slower on > a JS engine. And there's also the limited number of primitive types, which > would be a headache even conceptually.
> Anyway, my point is not very strong here since I am only passingly > familiar with the relevant implementation details.
>> I agree that bridge tools are the best option in the short term. This >> discussion is explicitly about the long term future of scala, and in the >> long term I think we should be working towards transitioning away from >> these tools
> Well, it's hard to argue with the long term since a lot can happen in the > long term. In the short term, absent resources to make a major effort, I'm > not sure it's worth it. In the long term, maybe JS engines will become > more and more like the JVM/CLR for performance reasons, and then porting > for speed will make more sense (as the features required for speed will be > there already).
I am not proposing that we write a scala VM. I'm just proposing that we have a very small, core subset of the scala standard library that doesn't depend on the JDK or any particular platform in general (core types, strings, collections, compiler infrastructure), and make small incremental adjustments to the compiler infrastructure such that a compiler plugin can directly translate that subset to another runtime format in the final compiler stages, and without relying on "ports" of large parts of the JVM to the target environment, like IKVM or GWT.
Everything else, like anything related to networking or IO or threading, would remain tied to the JVM for now (or else the compiler plugin would have to do some platform specific type transformations and/or simulate parts of the JDK in the target runtime). And, to be clear, the only things in this small "portable scala" subset would be things that are truly platform agnostic in nature, but just happen to currently make use of JVM types/apis because it was convenient at the time. Low-hanging fruit only in other words. The rest would be up to the tool for that platform to implement, or for the app developer to just use the platform native APIs through some interop mechanism (hopefully one as easy as the java interop mechanism, but not necessarily).
Anyway, it seems like this isn't in the cards, which is fair I suppose given the resources available.
On Monday, October 15, 2012 5:01:04 PM UTC-4, Rich Oliver wrote:
> I would also council caution from a political perspective. At the moment > Scala poses no threat to Oracle. Scala is arguably a modest contributor to > the value and status of the JVM. However if Oracle thought that there was a > serious threat of Scala developing a credible alternative to the JVM, I > imagine they might find ways to make life difficult for Scala.
> On Monday, October 15, 2012 12:55:39 PM UTC-4, Rex Kerr wrote:
>> I don't think you're thinking about this on the right timescale. If
>> there were the manpower to make something big happen in a year or so,
>> sure. But if you are talking about reallocating already scarce resources
>> to this, I think the picture changes.
>> On Mon, Oct 15, 2012 at 12:09 PM, sleepy daddy software <
>> bell....@gmail.com> wrote:
>>> See my comments below:
>>> On Monday, October 15, 2012 11:17:36 AM UTC-4, Rex Kerr wrote:
>>>> On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <
>>>> bell....@gmail.com> wrote:
>>>>> I love Scala. It is my favorite programming language, among the 15 or
>>>>> so I've had the pleasure and/or pain of writing code in. The problem is, I
>>>>> can't use it in the places I want to use it - like the browser, or in a
>>>>> mobile app (outside of Android of course).
>>>> You can't use Java in the browser? I've been doing that since 1997.
>>> The web has moved on. You cannot use the Java plugin on any mobile
>>> browser, even on Android, and there is zero chance that this will be added
>>> in the future. If I proposed a new enterprise application web application
>>> that required a browser plugin, I would be laughed at, then probably fired.
>> Oh, yes. And Objective-C is a dead language, by the way. Programming
>> has moved on.
>> Except, oops.
>> If you have a killer application (i.e. that you are the favored language
>> to write the killer applications for the killer devices), historical trends
>> can reverse dramatically.
>> If you ask as a technical matter whether a modestly enhanced Java plugin
>> is competitive with JavaScript capabilities and implementable on mobile
>> devices available in a couple of years (or the highest end ones now), the
>> answer is "yes"; in some ways it's probably better.
>> So, I advise being the killer app over changing the framework (and using
>> generic tools like GWT in the meantime).
> Objective-C did not become popular because it was the killer language, but
> because it was endorsed by Apple. Scala is not in a similar position. The
> Objective-C case shows that mobile/web app developers will use whatever
> tools are easily available for the target platforms. Mobile/web development
> will thrive for the next couple of years with or without Scala. Having the
> dependency of JVM only makes the cost of adopting Scala higher.
s/endorsed/mandated
s/easily available/mandated
s/higher/lower on android and on many already deployed infrastructures
> Similarly, I think many .NET developers would pick up Scala if there was a
> .NET implementation, many less so if they had to abandon .NET and switch to
> JVM.
> That said, I still would rather have the Scala development team focus on
> the language than anything else.
> Tomas
>>>> Should there be talk of a long term project to eliminate or reduce
>>>>> Scala's dependencies on the JVM or JVM libraries, so that it would be much
>>>>> easier to write compiler plugins to output something that could be used on
>>>>> a non-JVM formats like JavaScript or .Net or LLVM? At the very least, it
>>>>> might lower the barrier of entry for these non-JVM runtime targets.
>>>> Personally, I think this is backwards. The JVM is already a great
>>>> platform library. It's a bit heavyweight, which for the next couple of
>>>> years will make it an awkward fit on smartphones, but basically we _already
>>>> have the cross-platform tool you're talking about_. Making good
>>>> cross-platform tools is hard work, and I'd rather have Scala development
>>>> efforts go towards doing what Scala does uniquely well, not retreading the
>>>> "let's make it cross-platform, too, for my favorite definition of
>>>> platform!" road that has been walked so many times before, usually
>>>> unsuccessfully.
>>>> Let's ask about the solution in each case.
>>>> (1) .NET. The JVM works just fine on every machine I know of where
>>>> .NET works at all. So you can certainly use Scala on the hardware. Maybe
>>>> you need an interoperability layer to existing .NET stuff, but that's
>>>> different (and should be considerably easier) than jettisoning all traces
>>>> of Java/JVM dependence from Scala.
>>> I can't use Scala for windows 8 store applications, windows phone
>>> applications, netduino applications, SQL Server CLR code, ASP.NETapplications, WPF applications, etc.... I could go on.
>> Well, a lot of these are software not hardware limitations, which is why
>> I said _machine_ and mentioned interoperability layers. I'm not sure I'd
>> look forward to running Scala on uJ on an arduino board, though. My point
>> is that "I-can-call-X" and "I-am-implemented-natively-**inside-X-framework"
>> are completely different levels of effort.
>>> If they're compelling enough, a scala compiler extension for them will
>>> be written and maintained by the community. But these projects need some
>>> help, which is what I'm proposing we do.
>> Well, fair enough. But they're a LOT of work. If people want to, I
>> don't see why they shouldn't, but I don't think it should distract from
>> core Scala development at this point.
>>>> (3) JavaScript. Many key advantages of Scala (e.g. type safety,
>>>> performance) are lost by going to JavaScript as an intermediate, and most
>>>> anything that runs JavaScript could now or will soon be able to run a JVM
>>>> as well/instead. Rather than doing lots of work to end up with an improved
>>>> but ultimately sub-standard solution, why not instead try to get the JVM to
>>>> work in more places? Between Dalvik and the Oracle JVM for ARM, there
>>>> isn't much that seems out of reach.
>>> See my response earlier to your comment on the Java plugin. This is not
>>> true. If you are targeting android native development, you get an easy
>>> route to use scala code because android happens to support the JDK in its
>>> dalvik runtime. This is great, but this is a completely different thing
>>> from open web development.
>> Agreed; that would require something important enough that JVM-in-browser
>> becomes worthwhile. (The entry barrier is pretty low; the technology is
>> mostly there, it's just "not cool" right now, and Sun/Oracle lack-of-vision
>> has not helped matters.)
>>> Also, type safety is a feature of the language, not the runtime. When
>>> you compile scala to java bytecode, you lose information. You lose even
>>> more information when that bytecode gets JIT compiled to machine code. In
>>> the case of a JavaScript targeting scala compiler, it would be generating
>>> JavaScript as if it were a kind of high level assembly language, complete
>>> with Chrome-compatible javascript source maps so you can debug your scala
>>> code right in the browser.
>> I agree, of course, about type-safety but since you can translate JVM
>> bytecode to JS, there are considerations beyond just whether it's
>> possible. And here it's nice to have support in the bytecode/assembly so
>> you can do your runtime type checks; JS engines have an idea of _object
>> shape_ that is much more like structural typing in Scala and much less like
>> objects with an exact type in the JVM. Maybe I'm mistaken, but my
>> impression was that the blazing-fast JVM instanceof style checks--a core
>> component of pattern matching for instance--would be drastically slower on
>> a JS engine. And there's also the limited number of primitive types, which
>> would be a headache even conceptually.
>> Anyway, my point is not very strong here since I am only passingly
>> familiar with the relevant implementation details.
>>> I agree that bridge tools are the best option in the short term. This
>>> discussion is explicitly about the long term future of scala, and in the
>>> long term I think we should be working towards transitioning away from
>>> these tools
>> Well, it's hard to argue with the long term since a lot can happen in the
>> long term. In the short term, absent resources to make a major effort, I'm
>> not sure it's worth it. In the long term, maybe JS engines will become
>> more and more like the JVM/CLR for performance reasons, and then porting
>> for speed will make more sense (as the features required for speed will be
>> there already).
