Making Scala (more) portable - cutting ties with the JVM?

[sleepy daddy software]

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. 

[Naftoli Gugenheim]

On Sun, Oct 14, 2012 at 9:07 PM, sleepy daddy software <bell....@gmail.com> wrote:

been hampered primarily by Scala's dependencies on the JVM

On the JVM, or the Java standard library? If the latter, how would you change that?

[Den Shabalin]

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.

[Den Shabalin]

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.

[nicola...@gmail.com]

On Mon, Oct 15, 2012 at 10:39 AM, Den Shabalin <den.sh...@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.

[Hanns Holger Rutz]

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.

[sleepy daddy software]

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. 

[Rex Kerr]

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.
 

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

  --Rex

[Den Shabalin]

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. 

[Haoyi Li]

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.

[Den Shabalin]

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

[Hanns Holger Rutz]

?

[sleepy daddy software]

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.

 

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.

 

  --Rex

[ARKBAN]

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

ARKBAN

[Rich Oliver]

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.

[Naftoli Gugenheim]

On Mon, Oct 15, 2012 at 12:09 PM, sleepy daddy software <bell....@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.

[Rex Kerr]

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

 

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.

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

  --Rex

[Alex Cruise]

On Sun, Oct 14, 2012 at 6:07 PM, sleepy daddy software <bell....@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. 

https://github.com/greedy/scala/blob/llvm/src/llvm/runtime/object.c :)

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

-0xe1a

 

[Paul Phillips]

On Mon, Oct 15, 2012 at 9:55 AM, Rex Kerr <ich...@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.

[Rich Oliver]

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.

[Rex Kerr]

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

  --Rex

[Simon Ochsenreither]

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.

[Tomas Mikula]

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.

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

[sleepy daddy software]

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. 

[Kevin Wright]

On 15 October 2012 23:27, Tomas Mikula <tomas....@gmail.com> wrote:

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

[Rex Kerr]

On Mon, Oct 15, 2012 at 6:27 PM, Tomas Mikula <tomas....@gmail.com> wrote:

On Monday, October 15, 2012 12:55:39 PM UTC-4, Rex Kerr wrote:

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.

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.

My point was only that whether something is "dead" may change.  You can't be too sure you've "moved on".  There are various ways to resurrect something.

If you want another example, take Rails.  Ruby pre-Rails was not on most people's radar, and arguably people had "moved on" in that it wasn't a hot new up and coming thing.  But--killer app, and suddenly there's increased interest.  I'd argue that JRuby more than anything else contributed to invokedynamic on the JVM.
 

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.

Sure, but the cost isn't _that_ high.  The JVM just isn't that esoteric.  Android's outselling iPhones by a large margin.  If Scala becomes the Android-app-builder of choice, and people feel like porting, "Hey, let's just get the JVM working over there" is a pretty tempting alternative to "Hey, let's rewrite all the Java core libraries or throw away a huge chunk of our code".

  --Rex

[Alex Cruise]

On Mon, Oct 15, 2012 at 3:56 PM, Rex Kerr <ich...@gmail.com> wrote:

Sure, but the cost isn't _that_ high.  The JVM just isn't that esoteric.  Android's outselling iPhones by a large margin.  If Scala becomes the Android-app-builder of choice, and people feel like porting, "Hey, let's just get the JVM working over there" is a pretty tempting alternative to "Hey, let's rewrite all the Java core libraries or throw away a huge chunk of our code".

Also note that in this era of Zero and Shark (http://icedtea.classpath.org/wiki/ZeroSharkFaq), OpenJDK is very portable these days.  (Although as always, the performance isn't always there as quickly as you want it)

-0xe1a

[Tomas Mikula]

OK, but that doesn't really change my point.

> s/higher/lower on android and on many already deployed infrastructures

s/higher/higher (except on android and many already deployed infrastructures)/

I.e. not depending on JVM is never worse than depending on JVM, and
sometimes it's better.

[Tomas Mikula]

On Mon, Oct 15, 2012 at 6:56 PM, Rex Kerr <ich...@gmail.com> wrote:
> On Mon, Oct 15, 2012 at 6:27 PM, Tomas Mikula <tomas....@gmail.com>
> wrote:
>>
>>
>>
>> On Monday, October 15, 2012 12:55:39 PM UTC-4, Rex Kerr wrote:
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>
>> 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.
>
>
> My point was only that whether something is "dead" may change. You can't be
> too sure you've "moved on". There are various ways to resurrect something.
>
> If you want another example, take Rails. Ruby pre-Rails was not on most
> people's radar, and arguably people had "moved on" in that it wasn't a hot
> new up and coming thing. But--killer app, and suddenly there's increased
> interest. I'd argue that JRuby more than anything else contributed to
> invokedynamic on the JVM.

True, but I don't think it would now be wise for the Scala community
to either bet on applets' resurrection or directly aim at resurrecting
them. But sure, if they ever come back to life, Scala can benefit
greatly.

>
>>
>> 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.
>
>
> Sure, but the cost isn't _that_ high. The JVM just isn't that esoteric.
> Android's outselling iPhones by a large margin. If Scala becomes the
> Android-app-builder of choice, and people feel like porting, "Hey, let's
> just get the JVM working over there" is a pretty tempting alternative to
> "Hey, let's rewrite all the Java core libraries or throw away a huge chunk
> of our code".

That's a fair point, but once alternative Scala implementations exist,
the latter would be more like "Hey, let's recompile our code for
clr/llvm/JavaScript/... backend", which suddenly seems more viable
than porting the JVM.

The whole idea is about opening new possibilities, not dictating one.
And if it really was a "low hanging fruit" without distracting the
core team too much, it could be exciting to see if anyone grabs the
opportunity to provide alternative Scala implementation.

>
> --Rex
>

[Adam Jorgensen]

On 15 October 2012 03:07, 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). 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. 

I get what you're saying but think about the flip-side:

Cutting out the JVM cuts out all the libraries that the JVM provides.

As a Python developer I can say that many times I work with Python libraries that are, frankly, inferior to their Java counterparts and often terribly so.

For example, forget about doing anything useful with an MSSQL database from a Python application running on a Linux host. Java has a very nice platform-independent MSSQL connector

called jTDS. The corresponding python library is called pymssql and relies on FreeTDS. FreeTDS sucks and as a result pymssql is very weak compared to jTDS. Your only real option is

to use pyodbc which only works on Windows and has suffered from multiple memory-leak bugs over the past few years.

That's just one example.

Cutting the JVM out is a cute idea but I don't think it's really a good one. 

[Den Shabalin]

It's not (JVM XOR OTHER_PLATFORMS) it's (JVM OR OTHER_PLATFORMS). It's definitely possible to keep Scala as JVM compatible as it is now and have support for other platforms at the same time. People who use Scala on JVM won't and shouldn't notice anything.

If take parallel with Python world -- you can use it on JVM or CLR or CPython platforms. All of them have platform-specific parts. i.e. you can import C# code on CLR, Java code on JVM and C extensions on CPython. By doing so you'll make your code platform-dependant. On the other hand you can just use python's standard library and your application will work on any Python implementation, even on PyPy.

The existence of sane implementations of Scala beyond JVM are hardly possible as Scala standard library is extremely closely tied to JVM and is not sufficient to write even the simplest practical application (lack of any i/o, networking, concurrency, ...)

[Alex Repain]

Let's assume it just happened. Scala has been implemented outside the JVM. Well done, yet-unknown team ! So now what ? Now that the JVM is not a constraint anymore, a lot of changes that some wanted will find their way in (this might be gettind rid of type erasure, changing the garbage collection algorithm, etc). The standard API will get refactored. At the end, you will end up with two languages : Scala the JVM-bound and Scoola, the Scala that went out in the wild outter world. Probably, the latter will get its own VM, as its a provenly good choice for portability. At the end of the day, you have two languages that will fork farther away from each other tomorrow.

2012/10/18 Den Shabalin <den.sh...@gmail.com>

[Den Shabalin]

But why something like that never haven't happened to PyPy or Jython or IronPython or Mono or IronRuby or JRuby or LuaJIT or numerous implementations of common lisp or HipHop or ...?  All of them do lag behind corresponding official implementation but that doesn't make them less useful. Your argument is seriously flawed.

[Thorpe, Michael]

Or we get new users for Scala, who write new libraries and code - making the general Scala experience better for everyone!

There's more feedback on Stack Overflow - more universities might have a course on it. Sure, some things might have to be platform dependent, but most of it doesn't have to be.

[Adam Jorgensen]

I think you will find that compared to CPython, the alternative implementations see very little use.

That is a serious flaw.

Languages or language implementations that don't get used and/or gain a foothold tend to sink rather than swim.

[Alex Repain]

2012/10/18 Den Shabalin <den.sh...@gmail.com>

But why something like that never haven't happened to PyPy or Jython or IronPython or Mono or IronRuby or JRuby or LuaJIT or numerous implementations of common lisp or HipHop or ...?  All of them do lag behind corresponding official implementation but that doesn't make them less useful. Your argument is seriously flawed.

The main reasons why people often bring the subject of taking steps away from the JVM dependencies (and I did so myself before), is that they see limitations of the language consistency that are due to the JVM limitations. I think it's not far-fetched to conclude that a main advantage of doing so would be to be able to bring the consistency, by changing what needs to be changed. Porting Python to, say the JVM, with Jython, was the opposite way, adapt to a constrained platform. Going AWAY from the JVM means less constraints.

Besides, I didn't say that a Scala out of JVM would be useless, I think it's a great idea because there's a lot about the JVM I don't like. But chances are that would be a fork of Scala, rather than a port.

[John Nilsson]

On Thu, Oct 18, 2012 at 9:47 PM, Alex Repain <alex....@gmail.com> wrote:

The main reasons why people often bring the subject of taking steps away from the JVM dependencies (and I did so myself before), is that they see limitations of the language consistency that are due to the JVM limitations.

Another reason (as in my case) would be a migration path of C# into something more productive (like Scala)

However I see no benefit in burdening the Scala team with such portability. In my mind it would be a wast of effort.

a) You have to work around not being able to leverage the java ecosystem (which is provides much value compared to the .Net world...)
b) The result would basically be the intersection of features of the both platforms.

In other words, it would cost more, and do less.

Nah, I think it would be better if someone just implemented a Scala-like language for the .Net platform, playing to the strengths of that ecosystem.

[Ryan Schmitt]

I have to say, I agree very much with the idea of removing some of the bounds of Scala, although we should not expect an instant independence from Java as their are a large amount of libraries to convert. At the very least, we should make a "scala version" of every "mission critical" library.

Not only would this remove our binds from Java a bit, it would also allow us to give the user advantages such as foreach functions in the standard library. But again, it will not be easy to replace ALL of the java files.

[Suminda Dharmasena]

My take is that a Scala VM is a better option with a separate Java set of libraries compiled for the SVM like what IKVM does. Perhaps even with the option to use an embedded JDK when needed. Like wise the SVM format can be coveted to bytecode to be used in Java. You can add CLI to the mix also.

And a strong / user friendly foreign language interface for interop.

[Shelby]

If the main reason to pool scarce resources away from current Scala priorities, is to enable Scala programming the in browser for mobile, I say don't bother. The small screens on mobile are conducive to the browser and most prefer to run a dedicated app which is tuned to the device. Your app can access the internet and even embed rendered HTML.

I suppose Java and .NET are competing platforms, Microsoft is dying and Java is the chosen platform for the operating system with the most installed units and 79% global marketshare-- Android. ChromeOS is on the way to pick up from Microsoft's ashes on the desktop.

If ever there is a compelling reason to run Java in a mobile browser, it will get done.

Scala needs to stay focused on perfecting and refining the language and libraries.

[Shelby]

typos

On Saturday, September 7, 2013 6:01:23 AM UTC+8, Shelby wrote:

If the main reason to pool scarce resources away from current Scala priorities,

pull

 

is to enable Scala programming the in browser for mobile, I say don't bother. The small screens on mobile are conducive to the browser and most prefer to run a

in the browser

not conducive

[Shelby]

On Saturday, September 7, 2013 6:01:23 AM UTC+8, Shelby wrote:

I suppose Java and .NET are competing platforms, Microsoft is dying

Graphical evidence C# is dying (waiting for the other shoe to drop on Windows ecosystem no-show on mobile):

http://www.indeed.com/jobtrends?q=scala%2C+C%23&l= 

Soon to follow Actionscript's (Flash) demise:

http://www.indeed.com/jobtrends?q=scala%2C+actionscript&l=

[Suminda Dharmasena]

Hi,

Response is completely tangential to what I wrote. What I am saying is Scala should get its own VM perhaps based on LLVM.

The motivation is to make Scala more performance better for real time computing where realtime commitment matters. Also make it memory efficient (space + management overhead). 

S

[Shelby]

I wasn't reply to you, rather I had just read the entire thread for the first time and was replying to all the posts in the thread.

Real-time systems have different set of constraints that a GPL with opaque mark-and-sweep garbage collection is not best suited for, because for example real-time systems can't tolerate a lag. That is a complex discussion to make, nevertheless we can keep it short and sweet and say that (as far as I know) the focus of Scala's design and its community doesn't appear to be targeting real-time systems. Scala was designed to he a high-level semantics tool.

I suppose you are driving at SOFT-real-time not hard-real-time:

http://en.wikipedia.org/wiki/Soft_real-time#Criteria_for_real-time_computing

Erlang is in that niche.

[Suminda Dharmasena]

What ever reason makes sense to have own VM to support the language better and also help the language evolve better.

One area that can benefit is GC less operations and overall performance increase if the SVM is used.

[Shelby]

On Saturday, September 7, 2013 6:01:23 AM UTC+8, Shelby wrote:

I suppose Java and .NET are competing platforms...

I meant JVM and .NET are competing platforms. 

On Saturday, September 7, 2013 2:40:34 PM UTC+8, Suminda Dharmasena wrote:

What ever reason makes sense to have own VM to support the language better and also help the language evolve better.

One area that can benefit is GC less operations and overall performance increase if the SVM is used.

But we lose compatibility with Java and JVM, which I say is intolerable.

For example, right now I am coding a new general purpose language Copute which compiles to Scala (finally getting out of the design and into implementation stage after being very ill most of 2012). The aim is fix some of Scala's rough edges, while simplifying typeclasses and make the std library based on functor and applicative, as well supporting enforced pure functional programming in a much less obtuse manner than Scalaz. I expect this to be the next mainstream GPL. And I as one person, am able to code it, because I am using the Xtext (Eclipse's EMF/TMF) framework for rapidly prototyping parsers and the IDE comes nearly for free (except the debugger). I wouldn't be able to do that without JVM and Java compatibility.

http://copute.com/dev/docs/Copute/ref/compiler/Xtext/

I don't see how you can argue sanely to kill backwards compatibility with the most popular VM and language in the world with the most installed units. Not to mention defocusing the higher priority work that the limited resources that the Scala community and ecosystem needs to focus on first. Sorry if I am bit forcefully adamant, but I think Scala is at a critical stage in its development right now and there should be no major mistakes made on strategy.

The one glaring flaw I've found in Scala (besides the arguable point non-category theory design of the libraries) is the lack of a union (a.k.a. disjunction) type, which Ceylon has. That weaknesses forces all hetergeneously-typed collections to subsume to Any, which thus denegrates Scala to a uni-typed (not untyped) non-statically typed language. Scala has higher-kinded types which are absolutely necessary for supporting typeclasses required for a category theory correct type standard library, which the other JVM languages don't have. The only languages that I know of that have higher-kinds are the ML variants and Haskell. Haskell is a co-inductively typed language, which raises a lot of issues. ML is very powerful but I must admit even I don't entirely understand it, thus I think it has no chance of being a mainstream language. Scalaz code is very obtuse for me to read.

[Shelby]

On Saturday, September 7, 2013 11:02:45 PM UTC+8, Shelby wrote:

For example, right now I am coding a new general purpose language Copute which compiles to Scala (finally getting out of the design and into implementation stage after being very ill most of 2012). The aim is fix some of Scala's rough edges, while simplifying typeclasses and make the std library based on functor and applicative, as well supporting enforced pure functional programming in a much less obtuse manner than Scalaz. I expect this to be the next mainstream GPL. And I as one person, am able to code it, because I am using the Xtext (Eclipse's EMF/TMF) framework for rapidly prototyping parsers and the IDE comes nearly for free (except the debugger). I wouldn't be able to do that without JVM and Java compatibility.

http://copute.com/dev/docs/Copute/ref/compiler/Xtext/

P.S. If anyone is keen on helping me implement the compiler, I am eager to move this to Github and make it an open-source effort. Sorry I can't a post a new topic in scala-debate. I tried to post the following bug report as a new topic, but every time I post a new topic to scala-debate from Google Groups UI, the new topic is deleted after a few seconds.

https://issues.scala-lang.org/browse/SI-7819 (Shouldn't match be right-associative?)

Note I am already seeing the possibility of Copute being 2X more concise than Scala (and we know Scala is 2 - 3X more concise than Java. For example the following Scala code (from the Copute compiler):

def apply(file: java.lang.Object): String =
      file match {
      case File(pkgs,items) =>
         pkgs.foldLeft("")( (s,x) => s +
            (x match {
            case PackageChained(name) => "package " + name + "\n"
            })
         ) +
         packageOrImportOrTypedefOrObject(items, "")
      }

Can be code equivalently (will generate the same Scala code) in Copute as follows:

apply(file): java.lang.Object String =
   IF file IS File(pkgs,items) DO {
      (FROM "" DO (_ + IF _1 IS PackageChained(name) DO "package " + name + "\n") IN pkgs) +
      packageOrImportOrTypedefOrObject(items, "")
   }

My goal is that projects will be a mixture of Scala and Copute code, because Copute will be for the pure functioning sections, i.e. immutability across function calls (mutability allowed within functions that don't modify inputs nor reference external mutables).

So the thrust is not to replace Scala, yet to augment it, drive more use of Scala, do some experimentation on language design and libraries, and the best successes can be incorporated back into Scala if the community wishes. It is very much designed to boost Scala and be a cooperate effort.

I have some big goals for Copute which are not well articulated on the website yet (much of the websites is out-of-date and incorrect). The real goal is modularity and code-reuse to create a new open-source economy where we are paid by module, not by project.

[√iktor Ҡlang]

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[Shelby]

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Remember my goal is a language for the mainstream who apparently can't readily absorb all those special case variances from straightforward idiomatic Scala that create code that is often argued to be unreadable by anyone who is trying to grasp Scala quickly. Comparing straightfoward idiomatic Scala to straightfoward idiomatic Copute, the goal is for Copute to be more concise and regular (less ways to do the same thing). We will see... Note some features of Scala are not available, and thus I emphasize this is designed to be used in conjunction with Scala as one grows more savvy. It is also designed to be more than a stepping stone, as some features work more elegantly than in Scala (in my opinion). For example, I expect typeclasses and the std library I want use them for will demonstrate a large separation from Scala in terms of readability and ease-of-understanding.

One of the greatest points that Eric S. Raymond (author of The Art of Unix Programming and The Cathedral and The Bazaar that coined the term "open source" as an improvement from "free software" and who ostensibly jump started the open source revolution by clarifying the paradigm and its advantages) has made is that open source languages should be CONSISTENTLY readable, because the whole point of open source is more eyeballs. This is why he prefers Python, even though he originated from LISP and loves functional programming:

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

http://phillyjug.com/2012/04/18/esr/

http://www.linuxjournal.com/article/3882

I tried to nudge him on Scala on his blog and he has mentioned once to others in public that he is interested to look.

P.S. Apologies to take the thread on a tangent. I would start a new thread if I knew how.

[√iktor Ҡlang]

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

[Shelby]

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

On Sunday, September 8, 2013 5:36:06 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

 

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off. I can surmise from the code that it is doing a foldLeft, but only because I know that is what the code is supposed to be doing. Otherwise, I would be completely lost and googling (probably unsuccessfully) for `/:` (besides why should I need to google just to read code of a language I've started learning 2 years ago).

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

Note I am creating Copute for myself as a first motivation. Even if no one else ever uses it, I will write a lot of code with it. Thus I am very cautious about my time investment with the first iteration, and will not even attempt a debugger (can debug the Scala code output by the compiler). I intend to code using it, because I refuse to write "symbol soup" and implicit hell that is Scalaz and I need category theory to accomplish my goals of making a pure functional paradigm as modular as possible w.r.t. the Expression Problem:

http://copute.com/dev/docs/Copute/ref/Complete%20solutions%20to%20the%20%93Expression%20Problem.htm

[√iktor Ҡlang]

Hi Shelby,

Comments are inline

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

Would you so kindly sum it up for me?

 

On Sunday, September 8, 2013 5:36:06 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

 

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off. I can surmise from the code that it is doing a foldLeft, but only because I know that is what the code is supposed to be doing. Otherwise, I would be completely lost and googling (probably unsuccessfully) for `/:` (besides why should I need to google just to read code of a language I've started learning 2 years ago).

... and if you don't know what a foldLeft is, it's just as "obscure", which in this conversation seems to be applicable to everything one does not already know. Which doesn't really make for an interesting discussion; but for the sake of the discussion let's concede that /: is cryptic and replace it with foldLeft:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  pkgs.foldLeft("")({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

It adds a few characters extra, but if we think it's less obscure — then it's a gain, right?

 

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

 

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

 

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

My point was merely that your Scala code example could've been more interesting; and I offered up what I thought was an improvement.

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

Cheers,

√

 

Note I am creating Copute for myself as a first motivation. Even if no one else ever uses it, I will write a lot of code with it. Thus I am very cautious about my time investment with the first iteration, and will not even attempt a debugger (can debug the Scala code output by the compiler). I intend to code using it, because I refuse to write "symbol soup" and implicit hell that is Scalaz and I need category theory to accomplish my goals of making a pure functional paradigm as modular as possible w.r.t. the Expression Problem:

http://copute.com/dev/docs/Copute/ref/Complete%20solutions%20to%20the%20%93Expression%20Problem.htm

--

You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Shelby]

On Sunday, September 8, 2013 6:24:19 AM UTC+8, √iktor Klang wrote:

Hi Shelby,

Comments are inline

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

Would you so kindly sum it up for me?

Eric S Raymond said on April 18, 2012,

" I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none…"

" I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’" (he also mentioned he was one of the reviewers of the original Java language spec because "one of this friends was one of the principle designers")

"C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE."

" I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be."

"It’s [Scala] on my list of languages to learn.  I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it."

 

On Sunday, September 8, 2013 5:36:06 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

 

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off. I can surmise from the code that it is doing a foldLeft, but only because I know that is what the code is supposed to be doing. Otherwise, I would be completely lost and googling (probably unsuccessfully) for `/:` (besides why should I need to google just to read code of a language I've started learning 2 years ago).

... and if you don't know what a foldLeft is, it's just as "obscure", which in this conversation seems to be applicable to everything one does not already know. Which doesn't really make for an interesting discussion; but for the sake of the discussion let's concede that /: is cryptic and replace it with foldLeft:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  pkgs.foldLeft("")({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

It adds a few characters extra, but if we think it's less obscure — then it's a gain, right?

I agree foldLeft is cryptic for the mainstream. I prefer the FROM-DO-IN construct I've devised (sort of borrowed from Python). The user doesn't need to know what a fold is. They just know they want to iterate the thing(s) that follows IN.

 

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

Yes I know that, but the user who just wants match-case isn't required to know about extractors, unless he/she wants to create customized extractors. You have about 3 levels of abstraction for the user to grasp, whereas they just want to remember one thing.

When we target the immutability of pure functional programming, we can toss all the types of `class` (and `trait`) which are not ADTs. This simplifies the issue about construction and extraction, and will come automatically as it does for `case class` in Scala, but also for `interface` in Copute.

I am unifying and simplifying concepts, where it applies to the sweet spot I have identified. I think it will be hard to explain fully in this format. Will get to that later on the website if I complete the compiler.

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Not core for me. I avoid these confusing constructs, because they violate the "THE most important metric of a language, bar none" which is being able to read my code when I come back 6 months later. I've come across and learned something like that once, and chose to forget it.

I've read and agree that the measure of a great mainstream language is the ability to keep the whole thing in your head (forever). I am sure I have the IQ to learn and make such constructs permanently in my memory, but I purposely choose not to, because I am not writing code only for myself to see. And I want newcomers to my language to be able to read my code within a day (preferably an hour) of studying the language summary.

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

My point was merely that your Scala code example could've been more interesting; and I offered up what I thought was an improvement.

I want the language to be less interesting. ;) Yet just as expressive and Expression Problem extensible for the 80/90% of cases (Pareto principle).

 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

Any way, it is an experiment. I hope Typesafe appreciates that people are interested in experimenting on top of Scala. That exhibits Scala is achieving its goal of being a research into multi-paradigm. I know you are taking it commercial now, and I hope my experiment helps that cause.

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

I've seen you around, but didn't know you held that position. Cheers,

Shelby 

[Jason Zaugg]

On Sun, Sep 8, 2013 at 12:24 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Actually, it is a pattern matching anonymous function. If the expected type is PartialFunction, it compiles to one of those; otherwise if the expected type is FunctionN, that's what you get.

The difference isn't really that pertinent, but it does pay to be precise.

scala> { case x => x }: Any

<console>:8: error: missing parameter type for expanded function

The argument types of an anonymous function must be fully known. (SLS 8.5)

Expected type was: Any

              { case x => x }: Any

              ^

scala> { case x => x }: (Int => Int)

res7: Int => Int = <function1>

scala> classOf[PartialFunction[_, _]].isInstance(res7)

res8: Boolean = false

scala> { case x => x }: PartialFunction[Int, Int]

res9: PartialFunction[Int,Int] = <function1>

scala> classOf[PartialFunction[_, _]].isInstance(res9)

res10: Boolean = true

-jason

[√iktor Ҡlang]

Hi Shelby,

On Sat, Sep 7, 2013 at 6:58 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 6:24:19 AM UTC+8, √iktor Klang wrote:

Hi Shelby,

Comments are inline

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

Would you so kindly sum it up for me?

Eric S Raymond said on April 18, 2012,

" I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none…"

Absolutely, and this one is also highly individual IMO; writing clear code that doesn't do more than it should, paired with a nice set of feature tests (to make sure that the code enables what should be enabled) is key to this. (I have seen unreadable/unmaintainable/horrific code in all programming languages that I've used).

Also, expressivity is a key for this one, because if you can be expressive, you'll have to try to bend an inflexible environment to your will, therefor incurring a higher cost of maintenance. (more code, weird code, etc)

 

" I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’" (he also mentioned he was one of the reviewers of the original Java language spec because "one of this friends was one of the principle designers")

It's more of an opinion than an argument, don't you agree?

 

"C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE."

I'm not saying that I disagree with this, but doesn't that highly depend on what language features and libraries one uses? (plus code style, testing etc?)

 

" I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be."

This isn't really language-related, but a platform related argument, so lets just skip that one.

 

"It’s [Scala] on my list of languages to learn.  I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it."

Would be cool to hear if he has had time to take a look at it and what his takeaway is.

 

 

On Sunday, September 8, 2013 5:36:06 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

 

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off. I can surmise from the code that it is doing a foldLeft, but only because I know that is what the code is supposed to be doing. Otherwise, I would be completely lost and googling (probably unsuccessfully) for `/:` (besides why should I need to google just to read code of a language I've started learning 2 years ago).

... and if you don't know what a foldLeft is, it's just as "obscure", which in this conversation seems to be applicable to everything one does not already know. Which doesn't really make for an interesting discussion; but for the sake of the discussion let's concede that /: is cryptic and replace it with foldLeft:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  pkgs.foldLeft("")({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

It adds a few characters extra, but if we think it's less obscure — then it's a gain, right?

I agree foldLeft is cryptic for the mainstream.

But isn't it just as cryptic as "synchronized" if one doesn't know what it does? I think we'll have to assume that the person delving into new programming languages has some motivation to learn new things. And "folds" is a very useful concept to learn, don't you agree?

 

I prefer the FROM-DO-IN construct I've devised (sort of borrowed from Python). The user doesn't need to know what a fold is. They just know they want to iterate the thing(s) that follows IN.

Yes, but they have to know what iteration means. Just to clarify my point, learning about folds is quite universal and can be of great use no matter what language you use. (recognizing the "shape" of a fold in a problem etc) Learning Scala and functional programming in general has really improved the way I program C, Javascript and other languages.

 

 

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

Yes I know that, but the user who just wants match-case isn't required to know about extractors, unless he/she wants to create customized extractors. You have about 3 levels of abstraction for the user to grasp, whereas they just want to remember one thing.

They just need to remember one thing, the Scala syntax :)

Jokes aside, do you have a reference to that statement ("Programmers just want to remember one thing")?

 

When we target the immutability of pure functional programming, we can toss all the types of `class` (and `trait`) which are not ADTs. This simplifies the issue about construction and extraction, and will come automatically as it does for `case class` in Scala, but also for `interface` in Copute. 

I am unifying and simplifying concepts, where it applies to the sweet spot I have identified. I think it will be hard to explain fully in this format. Will get to that later on the website if I complete the compiler.

I'm all for unification and simplification, and I find this discussion interesting, so thanks for that!

 

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Not core for me. I avoid these confusing constructs, because they violate the "THE most important metric of a language, bar none" which is being able to read my code when I come back 6 months later. I've come across and learned something like that once, and chose to forget it.

It is confusing because you choose to forget what it means? Given that you remember folds (which should be applicable in any PL that you use, no matter what) then wouldn't you say it's quite obvious what happens in the code with the PartialFunction?

 

I've read and agree that the measure of a great mainstream language is the ability to keep the whole thing in your head (forever). I am sure I have the IQ to learn and make such constructs permanently in my memory, but I purposely choose not to, because I am not writing code only for myself to see. And I want newcomers to my language to be able to read my code within a day (preferably an hour) of studying the language summary.

Can you name one such language? (keep in mind that there are very dark corners in the Javascript spec, the Java spec, the C spec, the C++ spec etc)

 

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

My point was merely that your Scala code example could've been more interesting; and I offered up what I thought was an improvement.

I want the language to be less interesting. ;) Yet just as expressive and Expression Problem extensible for the 80/90% of cases (Pareto principle).

I totally understand that, and I hope you get to the place you want to go with that :)

 

 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

 

Any way, it is an experiment. I hope Typesafe appreciates that people are interested in experimenting on top of Scala. That exhibits Scala is achieving its goal of being a research into multi-paradigm. I know you are taking it commercial now, and I hope my experiment helps that cause.

I sincerely hope I didn't come across as criticizing your project, to my knowledge I haven't said much about it at all :). (As I said, I was more interested in improving the Scala example you gave.)

Personally I am all for research, experimentation and the broaden of one's horizons, so I wish you the best of times hacking on your project.

Cheers,

√

 

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

I've seen you around, but didn't know you held that position. Cheers,

Shelby 

--

You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[√iktor Ҡlang]

On Sat, Sep 7, 2013 at 7:12 PM, Jason Zaugg <jza...@gmail.com> wrote:

On Sun, Sep 8, 2013 at 12:24 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Actually, it is a pattern matching anonymous function. If the expected type is PartialFunction, it compiles to one of those; otherwise if the expected type is FunctionN, that's what you get.

The difference isn't really that pertinent, but it does pay to be precise.

Interesting. But since that is only observable with introspection (isInstanceOf / asInstanceOf) then it is more of an optimization? (Let's assume that PartialFunction was no costlier to generate/execute than Function1)

 

scala> { case x => x }: Any

<console>:8: error: missing parameter type for expanded function

The argument types of an anonymous function must be fully known. (SLS 8.5)

Expected type was: Any

              { case x => x }: Any

              ^

scala> { case x => x }: (Int => Int)

res7: Int => Int = <function1>

scala> classOf[PartialFunction[_, _]].isInstance(res7)

res8: Boolean = false

scala> { case x => x }: PartialFunction[Int, Int]

res9: PartialFunction[Int,Int] = <function1>

scala> classOf[PartialFunction[_, _]].isInstance(res9)

res10: Boolean = true

-jason

[Jason Zaugg]

On Sun, Sep 8, 2013 at 1:29 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Sat, Sep 7, 2013 at 7:12 PM, Jason Zaugg <jza...@gmail.com> wrote:

On Sun, Sep 8, 2013 at 12:24 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Actually, it is a pattern matching anonymous function. If the expected type is PartialFunction, it compiles to one of those; otherwise if the expected type is FunctionN, that's what you get.

The difference isn't really that pertinent, but it does pay to be precise.

Interesting. But since that is only observable with introspection (isInstanceOf / asInstanceOf) then it is more of an optimization? (Let's assume that PartialFunction was no costlier to generate/execute than Function1)

For one thing, if it *only* ever created PartialFunction, you wouldn't be able to use if for Function2 and above.

scala> { case (true, false) => "a"; case _ => "b" } : ((Boolean, Boolean) => String)

res1: (Boolean, Boolean) => String = <function2>

scala> (res1(true, false), res1(true, true))

res3: (String, String) = (a,b) 

There is an optimization, too: one doesn't need to generate the `isDefinedAt` method for FunctionN.

[√iktor Ҡlang]

On Sat, Sep 7, 2013 at 7:38 PM, Jason Zaugg <jza...@gmail.com> wrote:

On Sun, Sep 8, 2013 at 1:29 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Sat, Sep 7, 2013 at 7:12 PM, Jason Zaugg <jza...@gmail.com> wrote:

On Sun, Sep 8, 2013 at 12:24 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Actually, it is a pattern matching anonymous function. If the expected type is PartialFunction, it compiles to one of those; otherwise if the expected type is FunctionN, that's what you get.

The difference isn't really that pertinent, but it does pay to be precise.

Interesting. But since that is only observable with introspection (isInstanceOf / asInstanceOf) then it is more of an optimization? (Let's assume that PartialFunction was no costlier to generate/execute than Function1)

For one thing, if it *only* ever created PartialFunction, you wouldn't be able to use if for Function2 and above.

Of course you could, if Function2 was expected you could box calls in a Tuple2 and pass that in (and pray that allocation elision would kick in).

 

scala> { case (true, false) => "a"; case _ => "b" } : ((Boolean, Boolean) => String)

res1: (Boolean, Boolean) => String = <function2>

scala> (res1(true, false), res1(true, true))

res3: (String, String) = (a,b) 

There is an optimization, too: one doesn't need to generate the `isDefinedAt` method for FunctionN.

There is one potential expectation violation though, consider this:

def foo(f: Int => String): Unit = f match {

  case p: PartialFunction[Int, String] => p.applyOrElse(magicNumber, whathaveyou)

  case fun => fun(magicNumber)

}

Now, passing in a known-to-be-PartialFunction would have different semantics than calling the method with a partial function literal.

("As described in section 15.7, a partial function literal is expressed as a series of match alternatives or "cases". It looks like a match expression without the match keyword." - p587 in Programming in Scala)

The encoding of the PFL is more of an optimization detail rather than a language feature, or is it specced?

Cheers,

√

[Shelby]

Hi Victor,

On Sunday, September 8, 2013 7:22:41 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 6:58 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 6:24:19 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

Would you so kindly sum it up for me?

Eric S Raymond said on April 18, 2012,

" I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none…"

Absolutely, and this one is also highly individual IMO; writing clear code that doesn't do more than it should, paired with a nice set of feature tests (to make sure that the code enables what should be enabled) is key to this. (I have seen unreadable/unmaintainable/horrific code in all programming languages that I've used).

Also, expressivity is a key for this one, because if you can be expressive, you'll have to try to bend an inflexible environment to your will, therefor incurring a higher cost of maintenance. (more code, weird code, etc)

Agreed on your points. There is a balance between levels (degrees-of-freedom) of abstraction (thus expressiveness) and regularity. Apparently man-years of experience went into the balance in Python. I surmise Eric is pointing the regularity of Python more than anything else, which I will elaborate on below. Eric has also said that Guido wanted to remove the functional programming parts of Python and Eric said "over his dead body" or something like that.

  

" I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’" (he also mentioned he was one of the reviewers of the original Java language spec because "one of this friends was one of the principle designers")

It's more of an opinion than an argument, don't you agree?

I doubt you'd find any Scala-head who thinks Scala is not less verbose than Java. Write an anonymous function in Java for example.

"C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE."

I'm not saying that I disagree with this, but doesn't that highly depend on what language features and libraries one uses? (plus code style, testing etc?)

Higher-kinded types in C++ (templates) are convoluted:

http://stackoverflow.com/a/2565191/615784

I guess you can use auto_ptr to achieve some of the managed code safety and brevity.

But the real issue is you can't express modularity as orthogonally in C++ as you can in Scala (and Python) with mixins, higher-kinds for typeclasses for functors, etc.. Thus maintainability is lost because refactoring is required where high-level abstractions would have afforded extensibility instead. This is the one the key reasons I am doing Copute (so I get benefits of Scalaz without the obtuseness):

http://esr.ibiblio.org/?p=4824&cpage=1#comment-396626

 

" I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be."

This isn't really language-related, but a platform related argument, so lets just skip that one.

Okay but I want a real unsigned type! I've seen Odersky's library for UInt, but I don't think that it quite same.

 

"It’s [Scala] on my list of languages to learn.  I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it."

Would be cool to hear if he has had time to take a look at it and what his takeaway is.

He did write up his On Learning Haskell:

http://esr.ibiblio.org/?p=1796

He also wrote about performance tuning with Python:

http://esr.ibiblio.org/?p=4861

Tangentially, Eric banned me 3 times, i.e. 2 pseudonyms:

http://esr.ibiblio.org/?p=4946&cpage=1#comment-404269

 

On Sunday, September 8, 2013 5:36:06 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 5:23 PM, Shelby <she...@coolpage.com> wrote:

Yeah I was expecting someone might show the clever way to use Scala's obscure coding constructs to pack it. Thank you.

Could you please add some arguments as to what is "clever" and "obscure coding constructs"?

(I could have packed it a lot if I wanted to sacrifice readability)

 

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off. I can surmise from the code that it is doing a foldLeft, but only because I know that is what the code is supposed to be doing. Otherwise, I would be completely lost and googling (probably unsuccessfully) for `/:` (besides why should I need to google just to read code of a language I've started learning 2 years ago).

... and if you don't know what a foldLeft is, it's just as "obscure", which in this conversation seems to be applicable to everything one does not already know. Which doesn't really make for an interesting discussion; but for the sake of the discussion let's concede that /: is cryptic and replace it with foldLeft:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  pkgs.foldLeft("")({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

It adds a few characters extra, but if we think it's less obscure — then it's a gain, right?

I agree foldLeft is cryptic for the mainstream.

But isn't it just as cryptic as "synchronized" if one doesn't know what it does? I think we'll have to assume that the person delving into new programming languages has some motivation to learn new things. And "folds" is a very useful concept to learn, don't you agree?

I am coming at concurrency from the angle of immutability, so I might have a whole different perspective on whether the user ever needs to learn synchronized. I am not sure yet, but I even want to change the way we write event handling code.

I've been told we won't pull Python developers (mainstream) for as long as we require they learn folds (elaborates on upthread point on regularity):

http://esr.ibiblio.org/?p=4824&cpage=1#comment-395993

(just keep reading from the comment forward as far as you want to go into the discussion I had)

I prefer the FROM-DO-IN construct I've devised (sort of borrowed from Python). The user doesn't need to know what a fold is. They just know they want to iterate the thing(s) that follows IN.

Yes, but they have to know what iteration means. Just to clarify my point, learning about folds is quite universal and can be of great use no matter what language you use. (recognizing the "shape" of a fold in a problem etc) Learning Scala and functional programming in general has really improved the way I program C, Javascript and other languages.

I agree functional programmer is a more general abstraction, but I learned a lot about existing programmers in the aforementioned linked discussion.

I think hooking them first with something that appears to be imperative, yet underneath is really declarative, is the way to coax them over the hump.

Scala has tried to do that too to some extent, e.g. the for-comprehension. I am attempting to unify more.

 

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

Yes I know that, but the user who just wants match-case isn't required to know about extractors, unless he/she wants to create customized extractors. You have about 3 levels of abstraction for the user to grasp, whereas they just want to remember one thing.

They just need to remember one thing, the Scala syntax :)

Jokes aside, do you have a reference to that statement ("Programmers just want to remember one thing")?

I forgot. I've read so much on Lambda-the-ultimate. Perhaps is was Guy Steele.

When we target the immutability of pure functional programming, we can toss all the types of `class` (and `trait`) which are not ADTs. This simplifies the issue about construction and extraction, and will come automatically as it does for `case class` in Scala, but also for `interface` in Copute. 

I am unifying and simplifying concepts, where it applies to the sweet spot I have identified. I think it will be hard to explain fully in this format. Will get to that later on the website if I complete the compiler.

I'm all for unification and simplification, and I find this discussion interesting, so thanks for that!

I am trying to coax them over to Scala-world. They can go deeper into Scala syntax by studying what is output from a simpler syntax. Also I want to pick off some things I can't express elegantly in Scala w.r.t. to category theory.

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Not core for me. I avoid these confusing constructs, because they violate the "THE most important metric of a language, bar none" which is being able to read my code when I come back 6 months later. I've come across and learned something like that once, and chose to forget it.

It is confusing because you choose to forget what it means? Given that you remember folds (which should be applicable in any PL that you use, no matter what) then wouldn't you say it's quite obvious what happens in the code with the PartialFunction?

Honestly I didn't (yet) try to study how the PartialFunction is working. It deviates from the simple concept of "I pass in a function" to I guess something like "I pass in the remaining partial application of a function". I'd probably rather see the partial application done explicitly using closures. My current belief is that abstractions which hide what is really going on, really confuse people who can't reason down the levels of abstractions to get a mental picture of what is invisible to their eyes. Too many of those hiding abstractions chained into an expression can make it insurmountable for many people. Not for me, yet I choose not to go there unless there is a very compelling reason to do so. Hope I didn't put my foot in my mouth, which happens when I comment on some syntax I haven't taken the time to understand. Perhaps it is absolutely necessary I learn it.

This is also why I don't allow using method names as binary, infix operators as Scala does. It is cute the way expressions will read like english statements, yet I think it is confusing for users to visualize the associativity.

I've read and agree that the measure of a great mainstream language is the ability to keep the whole thing in your head (forever). I am sure I have the IQ to learn and make such constructs permanently in my memory, but I purposely choose not to, because I am not writing code only for myself to see. And I want newcomers to my language to be able to read my code within a day (preferably an hour) of studying the language summary.

Can you name one such language? (keep in mind that there are very dark corners in the Javascript spec, the Java spec, the C spec, the C++ spec etc)

I suppose K&R C. Some dark corners but for the 80% sweet spot, they mostly don't come up.

Ditto HTML.

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

My point was merely that your Scala code example could've been more interesting; and I offered up what I thought was an improvement.

I want the language to be less interesting. ;) Yet just as expressive and Expression Problem extensible for the 80/90% of cases (Pareto principle).

I totally understand that, and I hope you get to the place you want to go with that :)

Thanks very much for the sentiments.

I am not aiming to make money on Copute, rather to make money on what I can code with it. I have many other projects I would like to be working on.

Any one that wants to "steal" ideas is more than welcome.

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

I think Java had this one correct. I did consider allowing the well known operators to be overloaded and enforcing their behavior. For the moment that is on the back burner.

 

Any way, it is an experiment. I hope Typesafe appreciates that people are interested in experimenting on top of Scala. That exhibits Scala is achieving its goal of being a research into multi-paradigm. I know you are taking it commercial now, and I hope my experiment helps that cause.

I sincerely hope I didn't come across as criticizing your project, to my knowledge I haven't said much about it at all :). (As I said, I was more interested in improving the Scala example you gave.)

Personally I am all for research, experimentation and the broaden of one's horizons, so I wish you the best of times hacking on your project.

Oh I never thought you were. I was just hoping to hear that Typesafe likes to see this sort of experimentation. So I am happy to read.

Cheers,

Shelby

[Shelby]

Noting you did write "Personally". 

[√iktor Ҡlang]

On Sat, Sep 7, 2013 at 8:42 PM, Shelby <she...@coolpage.com> wrote:

Hi Victor,

On Sunday, September 8, 2013 7:22:41 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 6:58 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 6:24:19 AM UTC+8, √iktor Klang wrote:

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 5:23:19 AM UTC+8, Shelby wrote: 

http://java.dzone.com/articles/lessons-jug-talk-eric-esr

That link above apparently has his comments about Scala, also enumerates why he thinks functional programming languages such as Haskell will not likely gain mainstream adoption. Yet I am trying to address the reason he provided. 

Would you so kindly sum it up for me?

Eric S Raymond said on April 18, 2012,

" I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none…"

Absolutely, and this one is also highly individual IMO; writing clear code that doesn't do more than it should, paired with a nice set of feature tests (to make sure that the code enables what should be enabled) is key to this. (I have seen unreadable/unmaintainable/horrific code in all programming languages that I've used).

Also, expressivity is a key for this one, because if you can be expressive, you'll have to try to bend an inflexible environment to your will, therefor incurring a higher cost of maintenance. (more code, weird code, etc)

Ack, omitted the very important "not" as in " if you cannot be" in the sentence above.

Agreed on your points. There is a balance between levels (degrees-of-freedom) of abstraction (thus expressiveness) and regularity. Apparently man-years of experience went into the balance in Python. I surmise Eric is pointing the regularity of Python more than anything else, which I will elaborate on below. Eric has also said that Guido wanted to remove the functional programming parts of Python and Eric said "over his dead body" or something like that.

  

" I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’" (he also mentioned he was one of the reviewers of the original Java language spec because "one of this friends was one of the principle designers")

It's more of an opinion than an argument, don't you agree?

I doubt you'd find any Scala-head who thinks Scala is not less verbose than Java. Write an anonymous function in Java for example.

Well, Intellij IDEA does "fold" anon inner classes into a more readable format. (Java devs often use code generation from within their IDE to do these things), but I agree with your point :)

 

"C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE."

I'm not saying that I disagree with this, but doesn't that highly depend on what language features and libraries one uses? (plus code style, testing etc?)

Higher-kinded types in C++ (templates) are convoluted:

http://stackoverflow.com/a/2565191/615784

I guess you can use auto_ptr to achieve some of the managed code safety and brevity.

But the real issue is you can't express modularity as orthogonally in C++ as you can in Scala (and Python) with mixins, higher-kinds for typeclasses for functors, etc.. Thus maintainability is lost because refactoring is required where high-level abstractions would have afforded extensibility instead. This is the one the key reasons I am doing Copute (so I get benefits of Scalaz without the obtuseness):

http://esr.ibiblio.org/?p=4824&cpage=1#comment-396626

 

" I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be."

This isn't really language-related, but a platform related argument, so lets just skip that one.

Okay but I want a real unsigned type! I've seen Odersky's library for UInt, but I don't think that it quite same.

I guess a more general idea is to be able to constrain the size/range of numeric types and have the good ol' compiler help you out. 

My point is, if you want to learn Java (the full language spec) you'll need to learn the semantics of the "synchronized" keyword.

 

I've been told we won't pull Python developers (mainstream) for as long as we require they learn folds (elaborates on upthread point on regularity):

http://esr.ibiblio.org/?p=4824&cpage=1#comment-395993

(just keep reading from the comment forward as far as you want to go into the discussion I had)

I prefer the FROM-DO-IN construct I've devised (sort of borrowed from Python). The user doesn't need to know what a fold is. They just know they want to iterate the thing(s) that follows IN.

Yes, but they have to know what iteration means. Just to clarify my point, learning about folds is quite universal and can be of great use no matter what language you use. (recognizing the "shape" of a fold in a problem etc) Learning Scala and functional programming in general has really improved the way I program C, Javascript and other languages.

I agree functional programmer is a more general abstraction, but I learned a lot about existing programmers in the aforementioned linked discussion.

I think hooking them first with something that appears to be imperative, yet underneath is really declarative, is the way to coax them over the hump.

Scala has tried to do that too to some extent, e.g. the for-comprehension. I am attempting to unify more.

 

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

Yes I know that, but the user who just wants match-case isn't required to know about extractors, unless he/she wants to create customized extractors. You have about 3 levels of abstraction for the user to grasp, whereas they just want to remember one thing.

They just need to remember one thing, the Scala syntax :)

Jokes aside, do you have a reference to that statement ("Programmers just want to remember one thing")?

I forgot. I've read so much on Lambda-the-ultimate. Perhaps is was Guy Steele.

I would definitely have preferred some kind of study :)

 

When we target the immutability of pure functional programming, we can toss all the types of `class` (and `trait`) which are not ADTs. This simplifies the issue about construction and extraction, and will come automatically as it does for `case class` in Scala, but also for `interface` in Copute. 

I am unifying and simplifying concepts, where it applies to the sweet spot I have identified. I think it will be hard to explain fully in this format. Will get to that later on the website if I complete the compiler.

I'm all for unification and simplification, and I find this discussion interesting, so thanks for that!

I am trying to coax them over to Scala-world. They can go deeper into Scala syntax by studying what is output from a simpler syntax. Also I want to pick off some things I can't express elegantly in Scala w.r.t. to category theory.

I'm not sure that studying the generated output will be all that beneficial for understanding.

 

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Not core for me. I avoid these confusing constructs, because they violate the "THE most important metric of a language, bar none" which is being able to read my code when I come back 6 months later. I've come across and learned something like that once, and chose to forget it.

It is confusing because you choose to forget what it means? Given that you remember folds (which should be applicable in any PL that you use, no matter what) then wouldn't you say it's quite obvious what happens in the code with the PartialFunction?

Honestly I didn't (yet) try to study how the PartialFunction is working. It deviates from the simple concept of "I pass in a function" to I guess something like "I pass in the remaining partial application of a function".

Partial application is something completely different; a Partial Function is a function which is not defined for the full domain of its possible inputs.

 

I'd probably rather see the partial application done explicitly using closures. My current belief is that abstractions which hide what is really going on, really confuse people who can't reason down the levels of abstractions to get a mental picture of what is invisible to their eyes. Too many of those hiding abstractions chained into an expression can make it insurmountable for many people. Not for me, yet I choose not to go there unless there is a very compelling reason to do so. Hope I didn't put my foot in my mouth, which happens when I comment on some syntax I haven't taken the time to understand. Perhaps it is absolutely necessary I learn it.

Clearly one cannot expect to understand something without having attempted to learn, right?

 

This is also why I don't allow using method names as binary, infix operators as Scala does. It is cute the way expressions will read like english statements, yet I think it is confusing for users to visualize the associativity.

Is this based on hunch or study?

 

I've read and agree that the measure of a great mainstream language is the ability to keep the whole thing in your head (forever). I am sure I have the IQ to learn and make such constructs permanently in my memory, but I purposely choose not to, because I am not writing code only for myself to see. And I want newcomers to my language to be able to read my code within a day (preferably an hour) of studying the language summary.

Can you name one such language? (keep in mind that there are very dark corners in the Javascript spec, the Java spec, the C spec, the C++ spec etc)

I suppose K&R C. Some dark corners but for the 80% sweet spot, they mostly don't come up.

Considering how many people who seem to have huge issues understanding pointers and pointer arithmetics I'd tend to disagree with that.

 

Ditto HTML.

Test: Which HTML elements do not have an end tag? Do you remember?

 

Besides, that simple case I provided doesn't even get into the meat of the differences. The further we dig into examples (let's not do it in this thread please), the more obvious my point should become.

My point was merely that your Scala code example could've been more interesting; and I offered up what I thought was an improvement.

I want the language to be less interesting. ;) Yet just as expressive and Expression Problem extensible for the 80/90% of cases (Pareto principle).

I totally understand that, and I hope you get to the place you want to go with that :)

Thanks very much for the sentiments.

I am not aiming to make money on Copute, rather to make money on what I can code with it. I have many other projects I would like to be working on.

Any one that wants to "steal" ideas is more than welcome.

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

Is % well-known? How about ^, ||, &&, ~, ;, :, etc?

 

I think Java had this one correct. I did consider allowing the well known operators to be overloaded and enforcing their behavior. For the moment that is on the back burner.

I would disagree with that, Java operators aren't really "intuitive".

I think we'll need to agree that understanding the semantics and name of a symbol requires learning.

Learning is good. Ideally things you learn should be something that allows you to reuse that knowledge.

Cheers,

√

 

 

Any way, it is an experiment. I hope Typesafe appreciates that people are interested in experimenting on top of Scala. That exhibits Scala is achieving its goal of being a research into multi-paradigm. I know you are taking it commercial now, and I hope my experiment helps that cause.

I sincerely hope I didn't come across as criticizing your project, to my knowledge I haven't said much about it at all :). (As I said, I was more interested in improving the Scala example you gave.)

Personally I am all for research, experimentation and the broaden of one's horizons, so I wish you the best of times hacking on your project.

Oh I never thought you were. I was just hoping to hear that Typesafe likes to see this sort of experimentation. So I am happy to read.

Cheers,

Shelby

--

You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Shelby]

On Sunday, September 8, 2013 9:05:11 AM UTC+8, √iktor Klang wrote: 

" I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’" (he also mentioned he was one of the reviewers of the original Java language spec because "one of this friends was one of the principle designers")

It's more of an opinion than an argument, don't you agree?

I doubt you'd find any Scala-head who thinks Scala is not less verbose than Java. Write an anonymous function in Java for example.

Well, Intellij IDEA does "fold" anon inner classes into a more readable format. (Java devs often use code generation from within their IDE to do these things), but I agree with your point :)

I thought about tricks like that too, but what pushed me over the edge to create a new language, was how to do typeclasses with a SPOT (single-point-of-truth), i.e. have them integrated in subtyping hierarchy.

Also if you notice the uppercase keywords, I wanted the readability to apply even when sharing code on the internet not viewed in the IDE.

Popularity of HTML is partially due to accessibility, i.e. only need to fire-up Notepad on Windows and go. Ditto Javascript.

  

" I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be."

This isn't really language-related, but a platform related argument, so lets just skip that one.

Okay but I want a real unsigned type! I've seen Odersky's library for UInt, but I don't think that it quite same.

I guess a more general idea is to be able to constrain the size/range of numeric types and have the good ol' compiler help you out.

Sure I've seen that mentioned, but how far into dependent typing is the sweet spot? Unsigned is critical. Beyond that I don't know.

Indeed what is not a library yet instead in the language spec, is forced on everyone who wants to read code in that language. Thats why I am attempting to prune for the sweet spot.

I guess your point is that anonymous case matches is in the spec, thus it is allowable when comparing relative verbosity in the example I provided. My point is that I am comparing what (I think in my opinion) the mainstream could readily grasp of Scala and read. So I want to compare apples-to-apples, which is the idiomatic fold, pattern match, and anonymous function.

Both of our points are valid I think.

I've been told we won't pull Python developers (mainstream) for as long as we require they learn folds (elaborates on upthread point on regularity):

http://esr.ibiblio.org/?p=4824&cpage=1#comment-395993

(just keep reading from the comment forward as far as you want to go into the discussion I had)

I prefer the FROM-DO-IN construct I've devised (sort of borrowed from Python). The user doesn't need to know what a fold is. They just know they want to iterate the thing(s) that follows IN.

Yes, but they have to know what iteration means. Just to clarify my point, learning about folds is quite universal and can be of great use no matter what language you use. (recognizing the "shape" of a fold in a problem etc) Learning Scala and functional programming in general has really improved the way I program C, Javascript and other languages.

I agree functional programmer is a more general abstraction, but I learned a lot about existing programmers in the aforementioned linked discussion.

Ack typo, "functional programming is a...".

The `val File(pkgs, items) = file` is a syntactical sugar shortcut for a match with one case, so it won't apply generally to examples I can provide. I argue such special cases are irregular (i.e. obscure coding constructs), because they are more things the user has to learn and remember which deviate from the main idiom of match-case.

It's an extractor, could you elaborate what is special/obscure about it? (apply/unapply are core Scala language concepts)

Yes I know that, but the user who just wants match-case isn't required to know about extractors, unless he/she wants to create customized extractors. You have about 3 levels of abstraction for the user to grasp, whereas they just want to remember one thing.

They just need to remember one thing, the Scala syntax :)

Jokes aside, do you have a reference to that statement ("Programmers just want to remember one thing")?

I forgot. I've read so much on Lambda-the-ultimate. Perhaps is was Guy Steele.

I would definitely have preferred some kind of study :)

I believe in the scientific method too. It is not true that the evidence is that the simpler (and more constrained) languages are more popular?

1. HTML popular.

2. Javascript popular.

3. Java more popular than C++ (due to GC and simplicity).

4. Python more popular than Perl, where even the line indenting must be regular.

#1 & #2 due to ubiquitous availability of the interpreter in every browser, and being relatively simple to learn. #3 due to ubiquitous availability of the JVM and relatively simple to learn. #4 due to best regularity and continuity of concepts from other languages (OO, iterators, etc) in an interpreted language.

Programmers typically graduate from the simpler languages, thus continuity of concepts is important, as evident by #2, #3, and #4 deriving from C-like and OO before them. Scala follows this, yet deviates significantly in some areas, e.g. functional programming and weirdly obtuse constructs such as that anonymous case-match. That I argue will block Scala from the mainstream. Yet some key library (which is essentially almost what Copute is) can do for example what Ruby on Rails did, or Grails for Groovy.

 

When we target the immutability of pure functional programming, we can toss all the types of `class` (and `trait`) which are not ADTs. This simplifies the issue about construction and extraction, and will come automatically as it does for `case class` in Scala, but also for `interface` in Copute. 

I am unifying and simplifying concepts, where it applies to the sweet spot I have identified. I think it will be hard to explain fully in this format. Will get to that later on the website if I complete the compiler.

I'm all for unification and simplification, and I find this discussion interesting, so thanks for that!

I am trying to coax them over to Scala-world. They can go deeper into Scala syntax by studying what is output from a simpler syntax. Also I want to pick off some things I can't express elegantly in Scala w.r.t. to category theory.

I'm not sure that studying the generated output will be all that beneficial for understanding.

Fair point. Devil is in the details. We will see... Side-by-side (Copute code and generated Scala code) debugging might also help. It is an experiment.

 

I don't even understand the `case` without a preceding match in the (one many Scala variants for) anonymous function construct you employed. Clever but obscure. In Copute, there is usually just one construct, e.g. for the way to write an anonymous function.

It's a PartialFunction literal, a basic Scala language construct (about as core as a function literal): http://www.scala-lang.org/api/current/index.html#scala.PartialFunction

Not core for me. I avoid these confusing constructs, because they violate the "THE most important metric of a language, bar none" which is being able to read my code when I come back 6 months later. I've come across and learned something like that once, and chose to forget it.

It is confusing because you choose to forget what it means? Given that you remember folds (which should be applicable in any PL that you use, no matter what) then wouldn't you say it's quite obvious what happens in the code with the PartialFunction?

Honestly I didn't (yet) try to study how the PartialFunction is working. It deviates from the simple concept of "I pass in a function" to I guess something like "I pass in the remaining partial application of a function".

Partial application is something completely different; a Partial Function is a function which is not defined for the full domain of its possible inputs.

I assume meaning that the partial function requires partial application of its possible inputs, to remove the ones for which it is not defined, which is what I meant. Any way, I was just guessing.

 

I'd probably rather see the partial application done explicitly using closures. My current belief is that abstractions which hide what is really going on, really confuse people who can't reason down the levels of abstractions to get a mental picture of what is invisible to their eyes. Too many of those hiding abstractions chained into an expression can make it insurmountable for many people. Not for me, yet I choose not to go there unless there is a very compelling reason to do so. Hope I didn't put my foot in my mouth, which happens when I comment on some syntax I haven't taken the time to understand. Perhaps it is absolutely necessary I learn it.

Clearly one cannot expect to understand something without having attempted to learn, right?

I've read this line-of-argument from Scala supporters when ever anyone makes the point that Scala can be difficult to read, if the code uses constructs which are not readily understood due to not having analogous constructs in languages they already know, e.g. Java.

Fact is that many people are only willing to learn so much before they expect to be productive.

Language designers have to carefully weigh the advantages a feature brings against the disadvantage it adds to the learning curve.

Programmers seems to move in steps, from one language they can readily grasp to the next step up. They typically can't leap all the way to something like Haskell in one step. Haskell was difficult for me, because it was so different than the programming I had done since I was 17 in 1983. Eric Raymond was able to learn Haskell faster partially because it comes from LISP.

 

This is also why I don't allow using method names as binary, infix operators as Scala does. It is cute the way expressions will read like english statements, yet I think it is confusing for users to visualize the associativity.

Is this based on hunch or study?

As far as I know, no other mainstream languages do that, except as keywords in Python.

I have 30 years of programming experience, Fortran, Pascal, BASIC, assembly, DBase, C, C++, PHP, HaXe, Haskell, Scala, HTML, CSS, Javascript, ActionScript, Flash server, Xtext, MySQL, OCaml, ML, etc..

 

I've read and agree that the measure of a great mainstream language is the ability to keep the whole thing in your head (forever). I am sure I have the IQ to learn and make such constructs permanently in my memory, but I purposely choose not to, because I am not writing code only for myself to see. And I want newcomers to my language to be able to read my code within a day (preferably an hour) of studying the language summary.

Can you name one such language? (keep in mind that there are very dark corners in the Javascript spec, the Java spec, the C spec, the C++ spec etc)

I suppose K&R C. Some dark corners but for the 80% sweet spot, they mostly don't come up.

Considering how many people who seem to have huge issues understanding pointers and pointer arithmetics I'd tend to disagree with that.

I mentioned C from the perspective of mainstream for systems programmers, not for the general public.

If you can't master pointers, you can't be a low-level programmer.

 

Ditto HTML.

Test: Which HTML elements do not have an end tag? Do you remember?

Without consulting a resource, off the top-of-my-head, <img>, <input> are the 80% sweet spot.

This was one of the sections of my one page HTML tutorial:

http://copute.com/edu/HTML%20Intro.html#Unpaired_Tags_and_Spaces

 

 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

> Is % well-known? How about ^, ||, &&, ~, ;, :, etc?

All that were in K&R C. I sat down with that book and within probably a day (I know it was not more than couple of days), I was coding in C and being productive. Many have said it was perhaps the best language documentation ever written. Eric S Raymond I believe has said that, if I am not mistaken.

 

I think Java had this one correct. I did consider allowing the well known operators to be overloaded and enforcing their behavior. For the moment that is on the back burner.

> I would disagree with that, Java operators aren't really "intuitive".

> I think we'll need to agree that understanding the semantics and name of a symbol requires learning.

Here is what I had written on my copute.com site in 2011.

Precedence Operators Arity Fixity Associativity Description

5 * / % binary infix left multiply, divide, modulo3

6 + - binary infix left add, substract3

7 < <= > >= binary infix left relational4

³User-defined with these suggested meanings. Must output the same type as one of the operands, to reduce confusion as to what overloaded operators do.

⁴User-defined with suggested relational meaning. Must output the same type as the equality operator.

> Learning is good. Ideally things you learn should be something that allows you to reuse that knowledge.

I am not arguing against learning new paradigms. I arguing for unification of concepts. Also the number of concepts that have to be learned in each step to graduate and be productive with that step up, must be FINITE and carefully weighed.

Many people have a project they want to accomplish pronto and not be in learning mode with no productive output for too long of a period of time.

This has a social wave effect. The higher the bar, the less mass in the market, thus the less job offerings, thus the more risky to take time away from being productive to learn.

[Shelby]

On Sunday, September 8, 2013 10:38:22 AM UTC+8, Shelby wrote: 

one step. Haskell was difficult for me, because it was so different than the programming I had done since I was 17 in 1983. Eric Raymond was able to learn Haskell faster partially because it comes from LISP.

Typo: because HE comes from LISP

 

> Without consulting a resource, off the top-of-my-head, <img>, <input> are the 80% sweet spot.

I had written &lt;img/>, &lt;input/>, &lt;br/> yet the Google editor ate the br tag.

[Shelby]

On Sunday, September 8, 2013 9:05:11 AM UTC+8, √iktor Klang wrote:

I think Java had this one correct. I did consider allowing the well known operators to be overloaded and enforcing their behavior. For the moment that is on the back burner.

I would disagree with that, Java operators aren't really "intuitive".

I think we'll need to agree that understanding the semantics and name of a symbol requires learning.

Learning is good. Ideally things you learn should be something that allows you to reuse that knowledge.

Well you have Unicode symbols in your name ;) (thus I can't save your name in Notepad)

The official Scala style guide says do not use symbolic names:

http://docs.scala-lang.org/style/naming-conventions.html#symbolic_method_names

[Shelby]

With your point about non-paired tags in HTML, it seems you are equating all syntax as equivalent in difficulty. I am expressing the opinion that abstractions which hide from our eyes what is really going on, are much more difficult. My opinion is backed by my experience learning numbers languages over 30 years and finding Scala and Haskell (and ML languages) to be 10 to 100 times more time-consuming and difficult to master than any others I tried to learn. Part of that was I didn't have access to the Programming in Scala book from Odersky, Spoon, and Venners when I started. Even so, that is a 700+ page read and (at least the version I have) doesn't appear to cover that anonymous case function construct you employed, and other esoteric (and newer) features lurking in Scala.

When I don't see an end tag and I see the /> at the end of the opening tag, I have a visual cue as to what is going on. Whereas, when I see a case inside of a Unit block with a anonymous function embedded inside of it, I am wondering where is the containing match, why is that Unit appearing there, how does that anonymous function get called from within a dangling Unit. Any way, in Copute I throw away the entire concept of Unit, because I don't want to support DSLs and Unit isn't allowed in a pure function. Simplifying and unifying concepts.

[Shelby]

On Sunday, September 8, 2013 11:34:04 AM UTC+8, Shelby wrote: 

my experience learning numbers languages over 30 years

s/numbers/numerous

Getting sleepy. 

[Suminda Dharmasena]

Apologies for the cross posting. I am posting my previous reply as the conversation is fragmented over 3 thread.

__________________________________________________________________________

Instead of us us arguing this out best is to let typesafe figure it out. What we can do is provide some input.

They can do a survey of features which different businesses and industries want and then perhaps add this. Their marketing team most likely to this on and off

My concerns are:

1. Low latency and throughput commitment at high rates of data with hard realtime commitment
2. GC pause or GC overhead at un predicable times
3. High performance Foreign language Interface (maintain interop with Java and also add a few other languages to the mix. Java interop can be perhaps maintained by compiling OpenJDK classes to the new format if native or a Scala Specific IR is chosen. Similarly for .NET with mono.)
4. Perhaps move away from the JVM if it is viable and the level of influence typesafe has in the JCP to push options that improve Scala performance
   
1. http://www.infoworld.com/d/application-development/java-faces-tough-climb-catch-net-224372
2. http://www.infoworld.com/d/application-development/love-and-hate-java-8-223200
3. The JVM Updates are far apart and with very little innovative additions in them
4. If Oracle does not pull their socks up in a few years the JVM may not be a viable platform in the future. This may not be the case now but this might ineveitably happen looking at the pace of innovation happening.
5. Explore alternatives like the work from LLVM project
6. Ask questions and explore whether:
1. Memory management that might work well for Scala work loads
1. Can there be improvements and if so what
2. My take is as a functional language it is easy to impliment Automatic Reference Counting (ARC) like tha is available in Objective C
2. Better tail call trampolining support
3. Language level support for Actors while being able to produce Java Bytecode also for Java interop
7. Java interop
1. Emitting Java bytecode for interop with java also 
2. Efficient JNI support if part of the code in run in another VM or compiled natively 

S

[Jason Zaugg]

On Sun, Sep 8, 2013 at 1:45 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

There is one potential expectation violation though, consider this:

def foo(f: Int => String): Unit = f match {

  case p: PartialFunction[Int, String] => p.applyOrElse(magicNumber, whathaveyou)

  case fun => fun(magicNumber)

}

Now, passing in a known-to-be-PartialFunction would have different semantics than calling the method with a partial function literal.

("As described in section 15.7, a partial function literal is expressed as a series of match alternatives or "cases". It looks like a match expression without the match keyword." - p587 in Programming in Scala)

The encoding of the PFL is more of an optimization detail rather than a language feature, or is it specced?

PiS is wrong on this one. There is no such thing as a Partial Function Literal. Section 8.5 of the Scala Reference is the definitive source.

-jason

[Jason Zaugg]

On Sun, Sep 8, 2013 at 7:49 AM, Suminda Dharmasena <sirina...@gmail.com> wrote:

Instead of us us arguing this out best is to let typesafe figure it out. What we can do is provide some input.

They can do a survey of features which different businesses and industries want and then perhaps add this. Their marketing team most likely to this on and off

I would invite to you get in touch with us directly: http://typesafe.com/company/contact

My take is that we've got our hands full building Scala, Akka and Play for the JVM. What we've learned from the market is that not only is the JVM a great platform for a broad range of applications/industries, many of those are even quite conservative in dropping JDK6, which delays our ability to exploit things like MethodHandles by default.

This also makes it difficult for us to prioritize activities around influencing the JCP: if we can only take advantage of the results in 4-8 years (time to spec, integrate and stabilize a feature in a new JDK and then to wait for enough of the market to adopt that JDK.) The best sort of new JDK features are of course new optimizations that just kick in for users of the new platform without changes to scalac (tail call elimination, better inlining of closure-like patterns in code, etc), which might land closer to the 4 year mark. These are the areas that we get the most bang for our buck in advocacy.

One platform will never suit *all* applications, and High Frequency Trading and similar apps with near-real-time requirements are still something of a niche (albeit a sometimes hugely profitable niche!) Scala-the-language might still have a role to play as a staging language, one could express algorithms in Scala and use techniques like Lightweight Modular Staging and Macros to emit code that ends up running on another platform (GPU / C++ / LLVM).

Finally, Javascript definitely has been deemed the next interesting backend for Scala, so we at Typesafe eagerly awaiting and, in small ways, supporting the research at EPFL that is pushing in that direction. But this isn't diluting our work that targets the JVM.

-jason

[Suminda Dharmasena]

Actually this is much more viable and promising technology than having a SVM.

Perhaps Typesafe can accelerate the development of Delite and LMS.

Some of the Opt* DSLs look a bit neglected and Alpa quality. 

 

[Shelby]

Btw I agree also with the desired JVM improvements you mentioned. I add an unsigned type. There are serious problems with the JVM numerical stack.

On Sunday, September 8, 2013 3:35:24 PM UTC+8, Jason Zaugg wrote:

> Finally, Javascript definitely has been deemed the next interesting backend for Scala, so we at Typesafe

> eagerly awaiting and, in small ways, supporting the research at EPFL that is pushing in that direction.

> But this isn't diluting our work that targets the JVM.

I love that we can talk about these sort of projections with you guys here. Thanks for being so open.

Per the opinion or point I wrote upthread:

On Saturday, September 7, 2013 6:01:23 AM UTC+8, Shelby wrote:

If the main reason to pool scarce resources away from current Scala priorities, is to enable Scala programming the in browser for mobile, I say don't bother. The small screens on mobile are conducive to the browser and most prefer to run a dedicated app which is tuned to the device. Your app can access the internet and even embed rendered HTML.

...

 

If ever there is a compelling reason to run Java in a mobile browser, it will get done.

Scala needs to stay focused on perfecting and refining the language and libraries.

The desktop is a stagnant platform, if not shrinking. Mobile is the future. Thus it appears to me the apps-in-the-browser is a dying trajectory, unless the browser platform (APIs) will be optimized for writing GUIs on small screens. Honestly I haven't looked too closely at HTML5, maybe it already has the necessary APIs? (Ian Hickson, Daniel Glazman, and I go way back as nemesis any way, not my fault they got offended from my input and called me a kook)

For me it boils down to economics perspective. HTML5 is designed by committee, which means it will never keep pace with libraries designed by competing entities in the free market. Thus for highest performant apps, we will be writing native apps, e.g. Davlik.

If you ask me where Typesafe should spending its money, off the top-of-my-head it should be on writing such an open-source library (then selling consulting). Perhaps that is the way to make Scala as popular as Objective-C. Anyway, I am headed that direction if I succeed, but I am only one person working on my project so far and haven't yet completed Copute's compiler. Perhaps I will be open to my project later enveloped into Typesafe if I succeed and we agree on objectives.

If you make it work on iOS, Davlik, and ChromeOS, I would expect to see massive adoption.

[Shelby]

tl;dr F$ck the browser (as an app engine), I don't need my programmatic world top-down controlled.

On Sunday, September 8, 2013 3:35:24 PM UTC+8, Jason Zaugg wrote:

This also makes it difficult for us to prioritize activities around influencing the JCP: if we can only take advantage of the results in 4-8 years (time to spec, integrate and stabilize a feature in a new JDK and then to wait for enough of the market to adopt that JDK.) The best sort of new JDK features are of course new optimizations that just kick in for users of the new platform without changes to scalac (tail call elimination, better inlining of closure-like patterns in code, etc), which might land closer to the 4 year mark. These are the areas that we get the most bang for our buck in advocacy.

Early adopters ignite fledgling marketshare. Don't be too afraid to push faster on features we can enable optionally if we are movers and shakers in this world. Of course, don't kill the conservative markets (corporations) by moving too fast on what is the default.

[Suminda Dharmasena]

Perhaps you can use the libs @Jason pointed out and macros to implement this. This might generate more interest from Typesafe and Scala community. Perhaps you can present it in some conferences also.

@Jason, we will get in touch with Typesafe when we are something concrete. At this point it is planning.

[Justin du coeur]

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off.

Um -- seriously, not a strong argument.  I am far from a deep Scala expert (been working really seriously in it for about a year), and I use /: literally all the time -- it's one of the most useful tools in the Scala toolbelt, the one you usually reach for when one of the built-in transformations doesn't suffice.  Not only is it described in every Scala book I've read, the rationale for *why* it is called "/:" shows up in pretty much all of them.

The "symbol soup" argument is fair, and is one reason why I find scalaz daunting, but this time it's off-base: this is a dead-standard operator, used so often that having a concise version of it is simply sensible...

[Shelby]

I respect your right to express your opinion (so I am not saying with certainty you are wrong), but my goal is to prove you wrong and the market place will make that judgement for us.

Just because you say it is standard, doesn't mean it is the standard that the marketplace will readily grasp. That a strawman. What comes first, the chicken or the egg. How can it be a mainstream standard, when only a fractional of programmers use the language.

Tangentially note that I have been on stackoverflow reading Scala Q&A, read the tour intro at scala-lang.org, read the Programming in Scala book by the creator of Scala, and never did I come across that. Perhaps it is buried in that 700 page book?

I once tried to read the Scala spec, and quickly abandoned that as too verbose.

I don't know if this is unique to me (or my recent illness), but seems I am getting old enough now (48.5) where my brain filters non-words (that weren't learned and embedded long ago) as noise. In fact, my brain wants to filter anything that is not direct-to-the-point and intuitively, readily grasped. I figure if the author didn't have the clarity-of-thought to communicate clearly to me, then I shouldn't waste my time. I am getting older and running out-of-time to be productive.

A point of argument is that the more constructs there are, the more difficult it is it to make sure people know about them. I like to get my information online in what will quickly and without cost load into my computer (no Kindle readers). Accessibility is very important.

I want the language to get out-of-my-way. I want to focus on the semantics I am creating, my plans to impact the world. I have very little patience for anything these days.

[Shelby]

On Monday, September 9, 2013 12:27:37 AM UTC+8, Justin du Coeur wrote:

On Sat, Sep 7, 2013 at 6:05 PM, Shelby <she...@coolpage.com> wrote:

That is the first time I have seen `/:` even I have been fiddling with Scala for more than 2 years on and off.

Um -- seriously, not a strong argument.  I am far from a deep Scala expert (been working really seriously in it for about a year), and I use /: literally all the time -- it's one of the most useful tools in the Scala toolbelt, the one you usually reach for when one of the built-in transformations doesn't suffice.  Not only is it described in every Scala book I've read, the rationale for *why* it is called "/:" shows up in pretty much all of them.

If I am not mistaken in assuming (haven not taken the time to go study that symbol), its special amorphic capabilities are due to implicit conversions in the design of the std library? In that case, I don't want to learn it, because I don't think that is the correct way to design the std library.

And I wish the Scala compiler was less tied to the standard library, so there can be more experimentation on libraries. Libraries are what make or break the popularity of the language, e.g. Ruby on Rails. For example, Option and Seq infects everything.

[Shelby]

On Sunday, September 8, 2013 9:05:11 AM UTC+8, √iktor Klang wrote: 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

Is % well-known? How about ^, ||, &&, ~, ;, :, etc?

My current rule is don't add any more EMOTICON operators that don't have an intuitive meaning, i.e. /: or /:\ or those lower/upper bounds I always get transposed in my mind <: and >: (Copute uses `in` and `io` with covariant as the default). I mean really the code looks comical. For example +, -, <, >, & are intuitive.

As for * and /, I would prefer × and ÷ if unicode is ubiquitous and they could always be typed easily, neither of which is the case. More dubious is ⊕ instead of ^. Thus, for now, these preferences can be automatically displayed by the IDE and/or special rendering for HTML.

Modulo % is reasonably well known to those who need to use it.

I think I would prefer the more intuitive ! instead of ~, where ! has different meanings when applied to booleans and integers. This will still give the desired result for if (!integer).

And the ? is unused and intuitive, so I will put it to good use in Copute, dealing with the Option both on types and on a syntactical sugar for unboxing Option in an if-else expression.

Well ; almost disappears both in Scala and Copute thank you Lord. And : follows its grammatical meaning reasonably intuitively.

In short, no more dual character symbols, except the obvious one <=, >=, ==, !=, and single char symbol with =, e.g. +=.

[Miles Sabin]

On Sat, Sep 7, 2013 at 11:24 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
> Would you so kindly sum it up for me?

"Your ideas are intriguing to me and I wish to subscribe to your newsletter" ;-)

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Shelby]

On Monday, September 9, 2013 4:57:50 PM UTC+8, Miles Sabin wrote:

On Sat, Sep 7, 2013 at 11:24 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
> Would you so kindly sum it up for me?

"Your ideas are intriguing to me and I wish to subscribe to your newsletter" ;-)

Please don't tell me I am going to get that same sh$t here. Cripes, it is scala-DEBATE.

Stuff your ego dude. Sorry if I criticized your Shapeless in the other thread ;) 

[Shelby]

Or we can make everything one symbol:

http://en.wikipedia.org/wiki/Brainfuck#Hello_World.21

+++++ +++++             initialize counter (cell #0) to 10
[                       use loop to set the next four cells to 70/100/30/10
    > +++++ ++              add  7 to cell #1
    > +++++ +++++           add 10 to cell #2 
    > +++                   add  3 to cell #3
    > +                     add  1 to cell #4
    <<<< -                  decrement counter (cell #0)
]                   
> ++ .                  print 'H'
> + .                   print 'e'
+++++ ++ .              print 'l'
.                       print 'l'
+++ .                   print 'o'
> ++ .                  print ' '
<< +++++ +++++ +++++ .  print 'W'
> .                     print 'o'
+++ .                   print 'r'
----- - .               print 'l'
----- --- .             print 'd'
> + .                   print '!'
> .                     print '\n'

[Miles Sabin]

On Mon, Sep 9, 2013 at 10:13 AM, Shelby <she...@coolpage.com> wrote:
> On Monday, September 9, 2013 4:57:50 PM UTC+8, Miles Sabin wrote:
>
>> On Sat, Sep 7, 2013 at 11:24 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
>> > Would you so kindly sum it up for me?
>>
>> "Your ideas are intriguing to me and I wish to subscribe to your
>> newsletter" ;-)
>
>
> Please don't tell me I am going to get that same sh$t here. Cripes, it is
> scala-DEBATE.

Exactly ... I think you're looking for scala-troll.

> Stuff your ego dude. Sorry if I criticized your Shapeless in the other
> thread ;)

You did? I didn't notice.

[√iktor Ҡlang]

On Mon, Sep 9, 2013 at 10:47 AM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 9:05:11 AM UTC+8, √iktor Klang wrote: 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

Is % well-known? How about ^, ||, &&, ~, ;, :, etc?

My current rule is don't add any more EMOTICON operators that don't have an intuitive meaning, i.e. /: or /:\ or those lower/upper bounds I always get transposed in my mind <: and >: (Copute uses `in` and `io` with covariant as the default). I mean really the code looks comical. For example +, -, <, >, & are intuitive.

In what way are they intuitive? I had to learn the meaning of all of those.

 

As for * and /, I would prefer × and ÷ if unicode is ubiquitous and they could always be typed easily, neither of which is the case. More dubious is ⊕ instead of ^. Thus, for now, these preferences can be automatically displayed by the IDE and/or special rendering for HTML. 

Modulo % is reasonably well known to those who need to use it.

Doesn't that depend on what you have learned previously? A new programmer that tries to use Copute won't "intuitively" know what % does. Also, is the semantics of / "intuitive"? What about integer /? What about floats and doubles, they are hardly "intuitive".

 

I think I would prefer the more intuitive ! instead of ~, where ! has different meanings when applied to booleans and integers. This will still give the desired result for if (!integer).

Is ! intuitive? If I ask my friend who's not a programmer what "!foo" means, will he intuitively know?

 

And the ? is unused and intuitive, so I will put it to good use in Copute, dealing with the Option both on types and on a syntactical sugar for unboxing Option in an if-else expression.

Well ; almost disappears both in Scala and Copute thank you Lord. And : follows its grammatical meaning reasonably intuitively.

In short, no more dual character symbols, except the obvious one <=, >=, ==, !=, and single char symbol with =, e.g. +=.

Universal equality? Universal comparison (Comparable and friends)?

Cheers,

√

 

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Shelby]

On Monday, September 9, 2013 5:34:48 PM UTC+8, Miles Sabin wrote:

On Mon, Sep 9, 2013 at 10:13 AM, Shelby <she...@coolpage.com> wrote:
> On Monday, September 9, 2013 4:57:50 PM UTC+8, Miles Sabin wrote:
>
>> On Sat, Sep 7, 2013 at 11:24 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
>> > Would you so kindly sum it up for me?
>>
>> "Your ideas are intriguing to me and I wish to subscribe to your
>> newsletter" ;-)
>
>
> Please don't tell me I am going to get that same sh$t here. Cripes, it is
> scala-DEBATE.

Exactly ... I think you're looking for scala-troll.

Why does it harm you that I want to elaborate on my thoughts about symbols, responding to two people who were discussing that with me?

Why do you wish to discourage open discussion about Scala?

I was not rude to anyone, yet you were rude to me.

Thus I conclude you have an anti-social personality.

According to the rules that govern this forum, you should now receive a warning, because you violated two of the rules:

1. Being discourteous

2. Using the "troll" word.

You were also rude to me on your blog, where I posted to share some ideas about simulating disjunctions in Scala.

Your behavior is not what the Scala community wants.

 

> Stuff your ego dude. Sorry if I criticized your Shapeless in the other
> thread ;)

You did? I didn't notice. 

Childish, like two kids arguing about sand in the sandbox. 

I am discussing opinions about design of the language and about direction of the output targets.

You are free to speak your opinions, address facts, be courteous, and ignore what you don't want to read.

[Justin du coeur]

On Sun, Sep 8, 2013 at 1:34 PM, Shelby <she...@coolpage.com> wrote:

Tangentially note that I have been on stackoverflow reading Scala Q&A, read the tour intro at scala-lang.org, read the Programming in Scala book by the creator of Scala, and never did I come across that. Perhaps it is buried in that 700 page book?

I don't know about "buried", but yes, that's where I first came across it.  A quick Google turns it up on page 347 of the first edition -- admittedly a goodly ways in, but it's far from the densest technical manual I've read (even in the past year).

And it does have the rationale behind the specific symbol right there, at the first usage of that symbol.  Frankly, I found that *remarkably* useful -- I have always had trouble keeping "foldleft" and "foldright" straight, but the symbol actually makes it much easier for me to reason about how to write my code, since the symbol is essentially a picture of what it's doing.

(Although really, the *main* place I come across it is in the API docs: it's near the top of every Collection AFAIK, so I stumbled across it very early just looking things up, and see it there pretty much every day.  Since it is one of the very few symbols in the Collections library, it is *really* conspicuous to me.)

 

I once tried to read the Scala spec, and quickly abandoned that as too verbose.

I can certainly understand that.  But Programming in Scala is relatively well-written as language books go, and Scala for the Impatient is an absolute delight.  (It repeats the same explanation in Chapter 13.)

 

I don't know if this is unique to me (or my recent illness), but seems I am getting old enough now (48.5) where my brain filters non-words (that weren't learned and embedded long ago) as noise.

My sympathies about the illness, but I'm just about precisely the same age (one month older than you, if your 48.5 is exact), and every bit as focused on making my mark.  And yes, non-words can be tricky -- but new concepts are trickier, and a symbol that inherently *explains* the new concept is totally a win in my experience.

 

In fact, my brain wants to filter anything that is not direct-to-the-point and intuitively, readily grasped.

I can entirely understand that, but I don't think it's an excuse.  This stuff *is* deep, and excelling at it requires a time investment to understand it.  And yes, that does mean reading the documentation -- not every detail of the spec, but at least the good overview books like the ones I mention above.

I really do get what you're saying.  But I think you're just plain taking the argument to the point of reductio ad absurdam -- it's coming across as "I don't personally get that symbol immediately, so it is Bad", which is subjective to the point of useless.  And I find it poorly aimed, given that we're talking about one of the few invented symbols I have *ever* come across that actually has clear, commonly-documented and easy to remember logic behind it, instead of being the usual arbitrarily-chosen string of characters...

[Shelby]

On Monday, September 9, 2013 5:46:49 PM UTC+8, √iktor Klang wrote:

On Mon, Sep 9, 2013 at 10:47 AM, Shelby <she...@coolpage.com> wrote:

On Sunday, September 8, 2013 9:05:11 AM UTC+8, √iktor Klang wrote: 

Completely ignoring Copute for a second (which I have not commented on at all AFAICT), I'm interested in hearing more about what makes something "obscure"/"clever".

 

In my opinion, the number of concepts one has to know in order to grasp the code. For this example, one way to write an anonymous function (actually two, the (param) => or the _ for params) and one construct for match-case and one construct for iterating. And avoiding symbols like the plague, instead using short informational english keywords.

So no + - / * etc for numerical operations?

Except of course the well known operators.

Is % well-known? How about ^, ||, &&, ~, ;, :, etc?

My current rule is don't add any more EMOTICON operators that don't have an intuitive meaning, i.e. /: or /:\ or those lower/upper bounds I always get transposed in my mind <: and >: (Copute uses `in` and `io` with covariant as the default). I mean really the code looks comical. For example +, -, <, >, & are intuitive.

In what way are they intuitive? I had to learn the meaning of all of those.

We all learned +, -, <, > in grade school. Thus everyone already knows them. They don't have to learn them.

I can't remember when I learned &, perhaps it was high school. The point is that these already have meaning in the general society.

Sorry I thought that was so obvious why most humans already know those, that is why I didn't state the obvious earlier. I am very surprised that you never realized that? Why?

Or is it because our public education system different in the USA than Europe?

I know geeks (like me, hehe) are often out-of-touch with humanity-at-large, but really that far out-of-touch?

 

As for * and /, I would prefer × and ÷ if unicode is ubiquitous and they could always be typed easily, neither of which is the case. More dubious is ⊕ instead of ^. Thus, for now, these preferences can be automatically displayed by the IDE and/or special rendering for HTML. 

Modulo % is reasonably well known to those who need to use it.

Doesn't that depend on what you have learned previously? A new programmer that tries to use Copute won't "intuitively" know what % does. Also, is the semantics of / "intuitive"? What about integer /? What about floats and doubles, they are hardly "intuitive".

These operators (unlike the +, -, <, >, & above) are not exactly what we were taught in primary school. Yet the first language most people are taught is C, and these are standard in C. Also humans will normally ask "Ok I see how to express + and -, but how do I write divide and multiply"? So it is something they are expecting to learn, and in some degree demanding to know.

Also now due to email, many people in the broad population have adopted these operators when writing math in ASCII.

Contrast this against /: and :\, which someone in the broad population or even the mainstream programming languages have no exposure to or even near to. Besides, the other significant problem with those two operators (as well <: and >:) is that (besides looking like facial expression, hehe) there is no way to easily remember which is for which (foldRight and foldLeft, upper and lower bound). Everything I tried to come up with a logic as to why one direction or the other would help me remember, I would find another logic which refuted it.

Thus, although I use ":" for both type and subtype/lower (what the thing is, its definition) and >: for supertype/upper bound. I prefer sub and super than lower and upper, because the latter again are ambiguous when trying to think of a general logic which supports their meaning corresponding to their English definitions.

In Copute, instead of those fold operators, I have the FROM expr DO expr IN expr, with an optional IN REV expr.  I don't know how to define right and left unambiguously w.r.t. to any kind of type that can be a Foldable, thus forward and reverse seem to be more meaningful.

See my my next reply to Justin for another point on this ambiguity of direction.

I think I would prefer the more intuitive ! instead of ~, where ! has different meanings when applied to booleans and integers. This will still give the desired result for if (!integer).

Is ! intuitive? If I ask my friend who's not a programmer what "!foo" means, will he intuitively know?

No it is not to the general population. But it is in every C-derived language I have encountered. And when trying to be a mainstream programming language that is good enough for me.

Academics understand the importance of respecting the work of people who have gone before them, of citing their work, or reusing terminology and syntax.

Why do you think otherwise when it comes to programming languages? I am looking at the most popular programming languages today for OO.

 

And the ? is unused and intuitive, so I will put it to good use in Copute, dealing with the Option both on types and on a syntactical sugar for unboxing Option in an if-else expression.

Well ; almost disappears both in Scala and Copute thank you Lord. And : follows its grammatical meaning reasonably intuitively.

In short, no more dual character symbols, except the obvious one <=, >=, ==, !=, and single char symbol with =, e.g. +=.

Universal equality? Universal comparison (Comparable and friends)?

Equality and comparison has corner cases yes. Some languages even have === and ==!.

We need to hit the sweet spot that does what most people expect, and when it doesn't do what they expect, it doesn't do so silently.

This is something I need to study more so I am not saying I can solve it. I am hoping immutability is going to help me.

[Shelby]

On Tuesday, September 10, 2013 9:44:37 AM UTC+8, Justin du Coeur wrote:

On Sun, Sep 8, 2013 at 1:34 PM, Shelby <she...@coolpage.com> wrote:

Tangentially note that I have been on stackoverflow reading Scala Q&A, read the tour intro at scala-lang.org, read the Programming in Scala book by the creator of Scala, and never did I come across that. Perhaps it is buried in that 700 page book?

I don't know about "buried", but yes, that's where I first came across it.  A quick Google turns it up on page 347 of the first edition -- admittedly a goodly ways in, but it's far from the densest technical manual I've read (even in the past year). And it does have the rationale behind the specific symbol right there, at the first usage of that symbol.

I see it, and now I vaguely remember reading that section and remembering my eyes glossed over when I saw the symbols and the tree diagrams providing an *arbitrary* logic (assuming recursion as an implementation method) as to how I should remember which way the slash leans in order to select foldLeft or foldRight. Also see my prior reply to Victor, that I think left and right are ambiguous too. Upper and lower bounds are not ambiguous w.r.t. to top and bottom types, yet in Scala they are not so named instead are Any and Nothing. Most programmers don't know what top and bottom types are, yet more know what iteration forward, reverse, subtype, and supertype are, e.g, iterators are known to have next and previous methods.

Frankly, I found that *remarkably* useful -- I have always had trouble keeping "foldleft" and "foldright" straight, but the symbol actually makes it much easier for me to reason about how to write my code, since the symbol is essentially a picture of what it's doing.

Recursion is not the way mainstream programmers visualize iteration. Take a survey C, C++, C#, PHP, Java, etc programmers. I am confident about predicting the result ;)

 

(Although really, the *main* place I come across it is in the API docs: it's near the top of every Collection AFAIK, so I stumbled across it very early just looking things up, and see it there pretty much every day.  Since it is one of the very few symbols in the Collections library, it is *really* conspicuous to me.)

Understood. If you get too close to the current standard library, you begin to think it is the same as Scala. For me, Scala is the compiler and I love it! I can't heap enough gratitude on Martin and the others who built this. You guys are awesome! (including Miles Sabin who has apparently contributed) But the standard library has thorns I don't like, although there is a lot of code and ideas in it I like.

 

I once tried to read the Scala spec, and quickly abandoned that as too verbose.

I can certainly understand that.  But Programming in Scala is relatively well-written as language books go, and Scala for the Impatient is an absolute delight.  (It repeats the same explanation in Chapter 13.)

Agreed. Very well written.

 

I don't know if this is unique to me (or my recent illness), but seems I am getting old enough now (48.5) where my brain filters non-words (that weren't learned and embedded long ago) as noise.

My sympathies about the illness, but I'm just about precisely the same age (one month older than you, if your 48.5 is exact), and every bit as focused on making my mark.

Then come help me ;) Joke.

Good luck too. Mine is auto-immunity (not cured, possibly progressive) and was complications from simultaneous dengue and acute h.pylori (now cured I hope).

 

 And yes, non-words can be tricky -- but new concepts are trickier, and a symbol that inherently *explains* the new concept is totally a win in my experience.

 

In fact, my brain wants to filter anything that is not direct-to-the-point and intuitively, readily grasped.

I can entirely understand that, but I don't think it's an excuse.  This stuff *is* deep, and excelling at it requires a time investment to understand it.  And yes, that does mean reading the documentation -- not every detail of the spec, but at least the good overview books like the ones I mention above.

Oh yeah there are going to be deep issues, yet to the extent we can eliminate unnecessary consternation, the better.

One of my main fears with the Copute experiment is either a) I won't create any significant value-added, or b) I will remove generality instead of adding functionality.

Also the tradeoff of losing some features of the excellent IDE while coding in Copute, then needing to work with the Scala output to get them back. Sort of defeats some of the advantage.

But without experimenting, we can't prove some issues one way or the other in the marketplace.

I really do get what you're saying.  But I think you're just plain taking the argument to the point of reductio ad absurdam -- it's coming across as "I don't personally get that symbol immediately, so it is Bad", which is subjective to the point of useless.

Here I must strongly disagree with all you Scala heads that think this way. And I plan on proving you all wrong in spades.

I am a Scala head of sorts, but I think you all entirely don't understand the little ways you throw roadblocks in front of rapid adoption of the language, which you don't need to do.

But that is okay, you've left an opportunity for me to work on. And that is what makes free markets great.

(If one is correct, they usually experience...) First they ignore you, then they ban you, then they copy or join you.

 And I find it poorly aimed, given that we're talking about one of the few invented symbols I have *ever* come across that actually has clear, commonly-documented and easy to remember logic behind it, instead of being the usual arbitrarily-chosen string of characters...

 I disagree of course. I think the symbol is ambiguous and unclear.

I think you are missing the point that Eric S Raymond made, which is that the more eyeballs that can readily read your source code, the more performant open-source is.

The languages that become popular were ones you grabbed and they just flowed from your priority experience, e.g. PHP. I was coding in PHP about 15 minutes after picking it up. Not too many nasty surprises and head-scratching moments.

[Shelby]

On Sunday, September 8, 2013 4:14:32 AM UTC+8, √iktor Klang wrote:

The Scala code isn't really neat and tidy.

Compare against:

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) => s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

On Sat, Sep 7, 2013 at 11:22 AM, Shelby <she...@coolpage.com> wrote:

Note I am already seeing the possibility of Copute being 2X more concise than Scala (and we know Scala is 2 - 3X more concise than Java. For example the following Scala code (from the Copute compiler):

def apply(file: java.lang.Object): String =
      file match {
      case File(pkgs,items) =>
         pkgs.foldLeft("")( (s,x) => s +
            (x match {
            case PackageChained(name) => "package " + name + "\n"
            })
         ) +
         packageOrImportOrTypedefOrObject(items, "")
      }

Can be code equivalently (will generate the same Scala code) in Copute as follows:

apply(file): java.lang.Object String =
   IF file IS File(pkgs,items) DO {
      (FROM "" DO (_ + IF _1 IS PackageChained(name) DO "package " + name + "\n") IN pkgs) +
      packageOrImportOrTypedefOrObject(items, "")
   }

I didn't like what was happening above with DO and parenthesis, as DO was supposed to get rid of parenthesis, so I changed the grammar to allow DO to be optionally replaced by paired braces.

apply(file): java.lang.Object String =

   IF file IS File(pkgs,items) {

      IN pkgs FROM "" {

         _ + IF _1 IS PackageChained(name) DO "package " + name + "\n"

      } +

      packageOrImportOrTypedefOrObject(items, "")

   }

So now compare that to the recommended Scala code.

def apply(file: java.lang.Object): String = {

  val File(pkgs, items) = file

  ("" /: pkgs)({ case (str, PackageChained(name)) =>

     s"${str}package ${name}\n" }) + packageOrImportOrTypedefOrObject(items, "")

}

Now which one do you think a person unfamiliar with both will more readily grasp without reading to page 342 in Programming in Scala?

I support a more generalized language concept than the methods exists and find, which requires a generalized foldLeft and foldRight variant (which Scala's std library doesn't have yet):

IN expr WHILE expr DO expr

where the DO expr returns a tuple of the result and a boolean. For example to implement exists:

IN collection WHILE false { IF _1 == thing DO (true,false) ELSE (false,true) }

Of course it is still good to provide the exists and find methods to make the code clearer and more concise, while the above can be used for more generalized needs.

[Bienlein]

If Scala had not to be interoperable with the JVM it could also support pure functions and immutable objects like D. That would be kinda nice.

-- Bienlein

[Kevin Wright]

That's a false argument though!

You could just as easily find an example from differential calculus that you explain more "clearly" by avoiding Leibniz's notation, and it would truly be clearer to somebody who hadn't studied established conventions in that particular branch of mathematics.  To people who DO work with calculus on a regular basis, it would just come across as verbose and cluttered, obscuring the essential complexity of the problem.

The same is true here.  foldLeft (and the symbolic representation thereof) are an established convention for collapsing some collection of values into a single output, just as pattern matching in a val assignment is an established pattern for deconstructing a tuple.

It's often clearer to explain things by avoiding symbolic notation, but only to those people who don't frequently work with the concepts those symbols represent; so you're helping the people who least need it!

This isn't *quite* so useless as fitting your car dashboard with a braille speedometer to make it more accessible to blind drivers, but you get the idea :)

I support a more generalized language concept than the methods exists and find, which requires a generalized foldLeft and foldRight variant (which Scala's std library doesn't have yet):

IN expr WHILE expr DO expr

where the DO expr returns a tuple of the result and a boolean. For example to implement exists:

IN collection WHILE false { IF _1 == thing DO (true,false) ELSE (false,true) }

Of course it is still good to provide the exists and find methods to make the code clearer and more concise, while the above can be used for more generalized needs.

--

You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Shelby]

On Tuesday, September 10, 2013 4:56:46 PM UTC+8, Kevin Wright wrote:

Now which one do you think a person unfamiliar with both will more readily grasp without reading to page 342 in Programming in Scala?

 

That's a false argument though!

You could just as easily find an example from differential calculus that you explain more "clearly" by avoiding Leibniz's notation, and it would truly be clearer to somebody who hadn't studied established conventions in that particular branch of mathematics.  To people who DO work with calculus on a regular basis, it would just come across as verbose and cluttered, obscuring the essential complexity of the problem.

The same is true here.  foldLeft (and the symbolic representation thereof) are an established convention for collapsing some collection of values into a single output, just as pattern matching in a val assignment is an established pattern for deconstructing a tuple.

It's often clearer to explain things by avoiding symbolic notation, but only to those people who don't frequently work with the concepts those symbols represent; so you're helping the people who least need it!

Sorry sir, but I understand *all* programmars are doing folds.

Logic.

 

This isn't *quite* so useless as fitting your car dashboard with a braille speedometer to make it more accessible to blind drivers, but you get the idea :)

I don't believe that you are doing rocket science with Scala, you mostly just want to think you are. :-P 

Okay I have new one for Victor w.r.t. match-case. One of the reasons I want to merge match-case into IF-IS-ELSE is I often come across situations like the following.

// Any are named?

if (typerefs.exists(

         _ match {

         case NamedTupleRef(Some(_),_) => true

         case _                        => false

         }

      )) ... 

In my planned syntax, I can write instead.

// Any are named?

IF typerefs.exists( IF _ IS NamedTupleRef(Some(_),_) DO true ELSE false ) ...

If that isn't a slamdunk, then I am very curious to hear why.

[Shelby]

On Tuesday, September 10, 2013 5:13:10 PM UTC+8, Shelby wrote:

// Any are named?

IF typerefs.exists( IF _ IS NamedTupleRef(Some(_),_) DO true ELSE false ) ...

Typo:

 IF typerefs.exists( IF _ IS NamedTupleRef(Some(?),?) DO true ELSE false ) ...

[Alec Zorab]

if (typerefs.exists { case NamedTupleRef(Some(_),_) => true; case _ => false })

--

[√iktor Ҡlang]

On Tue, Sep 10, 2013 at 5:38 AM, Alec Zorab <alec...@gmail.com> wrote:

if (typerefs.exists { case NamedTupleRef(Some(_),_) => true; case _ => false })

Thanx Alec, was just going to reply just that.

Cheers,

√

 

On 10 September 2013 10:19, Shelby <she...@coolpage.com> wrote:

On Tuesday, September 10, 2013 5:13:10 PM UTC+8, Shelby wrote:

// Any are named?

IF typerefs.exists( IF _ IS NamedTupleRef(Some(_),_) DO true ELSE false ) ...

Typo:

 IF typerefs.exists( IF _ IS NamedTupleRef(Some(?),?) DO true ELSE false ) ...

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Justin du coeur]

On Tue, Sep 10, 2013 at 1:03 AM, Shelby <she...@coolpage.com> wrote:

Recursion is not the way mainstream programmers visualize iteration. Take a survey C, C++, C#, PHP, Java, etc programmers. I am confident about predicting the result ;)

True, but not very useful.  You're indirectly arguing, "most programmers are too dumb to use the language, so the language is wrong".  (Since effective use of recursion is important to using Scala effectively.)  And I can't agree with that.  As a team lead, I spend a *lot* of my effort educating my programmers -- I consider that a key part of my job.  Yes, it's a lot of effort, but I get *vastly* better code as a result.

No, that doesn't mean demanding that every right-out-of-college engineer can use all of scalaz.  (Hell, I don't understand most of scalaz yet.)  But I *do* expect anybody working for me to be a decently quick study, and I expect them to pick up the basic tools when I teach them.  And yes, recursion is a basic tool that I expect any serious modern programmer to learn.  I teach it to them when I'm running a project in C# (along with "this is what a closure is, and this is why we use them frequently"); I expect it all the more in a more functionally-oriented language like Scala.

Thinking in recursion instead of iteration is a major part of switching from procedural to functional programming.  Hell, I'd probably say it is the *most* important part (although, again, closures probably tie with it).  If somebody's going to work for me today, I demand that ability -- I run startups, and I just can't afford engineers who can't keep up with the major trends in programming.  If you aren't grokking at least these basics, then I'd say you're pretty much wasting your time using Scala -- you're just going to wind up writing Java with a different syntax.

And back to the point: once you *do* understand recursion, I think the symbolic explanation is quite natural.  (And really, I'm not likely to try to have somebody use foldLeft, by whichever name, until they grok recursion properly.)

 

Understood. If you get too close to the current standard library, you begin to think it is the same as Scala. For me, Scala is the compiler and I love it! I can't heap enough gratitude on Martin and the others who built this. You guys are awesome! (including Miles Sabin who has apparently contributed) But the standard library has thorns I don't like, although there is a lot of code and ideas in it I like.

That's true, and I think everyone broadly agrees with that.  (See, for example, the argument about views going on in scala-language.)  But in this particular case I don't agree that that's a thorn -- I find the symbolic form considerably more glanceable and understandable than the "foldLeft" version.  Given this argument, though, it suggests to me that they were dead-on correct having both in the library, which allows projects to establish their own coding standards.

 

I don't know if this is unique to me (or my recent illness), but seems I am getting old enough now (48.5) where my brain filters non-words (that weren't learned and embedded long ago) as noise.

My sympathies about the illness, but I'm just about precisely the same age (one month older than you, if your 48.5 is exact), and every bit as focused on making my mark.

Then come help me ;) Joke.

Heh.  *Way* too busy bootstrapping my own startup.

 

Good luck too. Mine is auto-immunity (not cured, possibly progressive) and was complications from simultaneous dengue and acute h.pylori (now cured I hope).

Sympathies, and hope that it doesn't go further.

 

Oh yeah there are going to be deep issues, yet to the extent we can eliminate unnecessary consternation, the better.

That's fair, and I understand the desire *extremely* well.  I'm in the middle of writing my own language, QL, which is actually intended for layman's use -- a language that is so simple that most of the time you don't even think of it as a "language".  It's a spectacularly challenging project, but rather fun -- I am finding that writing a language that DWIMs as much as possible is leading towards *extremely* deep functional design: a language that, for example, is not only pure-functional but has continuations as the *main* form of parameter.  It's turning out to be crazy-powerful and ridiculously expressive, albeit limited in focus.

The point is, eliminating consternation is all about making things obvious -- and that requires understanding the audience you are writing for.  Using Martin's "levels" (which I continue to find an excellent tool), an A1 programmer may find /: completely mystifying -- but I'm not going to be asking most A1 programmers to be doing foldLeft in the first place.  By the time they get to A3 (or maybe even A2), I expect them to have enough background that the usual explanation of /: becomes more logical to them.

 

But without experimenting, we can't prove some issues one way or the other in the marketplace.

Yep.  Ultimately, these arguments are irrelevant -- you have to see what actually works.

 

The languages that become popular were ones you grabbed and they just flowed from your priority experience, e.g. PHP. I was coding in PHP about 15 minutes after picking it up. Not too many nasty surprises and head-scratching moments.

Oh, that is *such* a bad example to use with me right now.  For one of my clubs, I am currently repurposing a body of PHP code that we got from another group.  The code was chosen by a friend of mine, and when I first looked it over (having never programmed in PHP in my life) I *thought* I understood what was going on, and gave it a thumbs-up.

Eight months on, and that decision has proven to be a disaster.  The code that looked like it made sense turned out to be *horrifyingly* badly factored, and riddled with major security problems.  Yes, it was glanceable -- but the bad practices riddled through it were buried in the verbiage.  It's unambiguously clear that we would have done much better if I'd simply started from scratch myself.

And that matters.  Yes, it is easier to understand *small-scale* PHP than Scala.  But it is much, much, much harder to understand what is going on at the *large* scale, because the language encourages bad habits.  Scala is much more expressive, and vastly more concise (and yes, has a far more powerful function library) -- the result is that *reasoning* about well-written Scala is much easier.

Yes, that does require learning some stuff, and yes, that will slow down adoption.  But ultimately, it's going to lead to more project leads like me *demanding* Scala.  In my current project, I am literally doing single-handedly what I would have expected to require a ten-person team just a few years ago.  *That* is what is going to drive adoption in the long run.  It requires an investment, but it pays off.

One more point: I remember *exactly* this argument being leveled at Java in the early days.  (I was one of the earliest hardcore adopters, back when everyone knew that Java was only intended for client plugins.)  This whole "object-oriented" thing was weird and confusing, and nobody understood it, as opposed to C, which was nicely comprehensible.  So the language clearly wasn't going to go anywhere.

It takes time, but folks *do* eventually catch up...

[Cédric Beust ♔]

On Tue, Sep 10, 2013 at 1:56 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

The same is true here.  foldLeft (and the symbolic representation thereof) are an established convention for collapsing some collection of values into a single output, just as pattern matching in a val assignment is an established pattern for deconstructing a tuple.

Folds are fairly established but I disagree that its symbolic representation is as well. Take a look at this list of fold functions in various languages and you won't find :/ anywhere. Not even on the Scala row!

I think it's disingenuous to suggest that :/ is as universally established as + or - (not saying you did but a few other participants in the discussion did earlier, and I've heard it many times in the past years). By definition, symbols every student who graduates from high school is familiar with will be more universally recognized than those that are taught in college (or in the case of :/, beyond college).

Either way, I think discussing this point is somewhat moot since even early proponents of such symbols (scalaz, spray) are now moving toward offering aliases for such symbols, so the point seems to be generally conceded.

-- 

Cédric

[Rex Kerr]

It's /: and :\.  There is no :/.  The \ or / is the toppling-over domino that is going to consume the rest of the list (which is on the : side).

It's almost a pictograph.  Trying to decipher what the parser combinators are doing is maybe a bit of a challenge.  Folds really aren't, not if the person learning is paying attention and the person teaching can explain clearly.

Why aren't people complaining about def main(args: Array[String])?  Compared to /: that is absolute gibberish, and you need it in every program that doesn't use extends App (and knowing what extends App really means is quite a challenge itself).

  --Rex

[Erik Osheim]

On Tue, Sep 10, 2013 at 12:47:20PM -0700, Rex Kerr wrote:
> It's /: and :\. There is no :/. The \ or / is the toppling-over domino
> that is going to consume the rest of the list (which is on the : side).

Although the :/ operator does exist!

In Spire this is the "right scalar division" operator for a vector
space, the inverse of :*. So you can say:

import spire.implicits._

Array(1.0, 2.0) :/ 3.0 // Array(0.3333333333333333, 0.6666666666666666)
Array(1.0, 2.0) :* 3.0 // Array(3.0, 6.0)

While this wasn't directly relevant to the foldLeft discussion it may
shed some light on my feelings about the issue. :)

-- Erik

[Cédric Beust ♔]

On Tue, Sep 10, 2013 at 1:20 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

On Tue, Sep 10, 2013 at 12:47:20PM -0700, Rex Kerr wrote:
> It's /: and :\.  There is no :/.  The \ or / is the toppling-over domino
> that is going to consume the rest of the list (which is on the : side).

Although the :/ operator does exist!

Yes, it's a smiley :) (muscle memory is a funny thing that will often preempt your brain)

-- 

Cédric

[Shelby]

On Tuesday, September 10, 2013 5:38:29 PM UTC+8, AlecZorab wrote:

if (typerefs.exists { case NamedTupleRef(Some(_),_) => true; case _ => false })

Too many constructs, not necessary.

But that is fine with me that you all think that is acceptable. Perfect. Like taking candy from babies...to make a simpler and more consistent syntax.

[Shelby]

On Tuesday, September 10, 2013 11:59:01 PM UTC+8, Justin du Coeur wrote:

On Tue, Sep 10, 2013 at 1:03 AM, Shelby <she...@coolpage.com> wrote:

Recursion is not the way mainstream programmers visualize iteration. Take a survey C, C++, C#, PHP, Java, etc programmers. I am confident about predicting the result ;)

True, but not very useful.  You're indirectly arguing, "most programmers are too dumb to use the language, so the language is wrong".  (Since effective use of recursion is important to using Scala effectively.)  And I can't agree with that.  As a team lead, I spend a *lot* of my effort educating my programmers -- I consider that a key part of my job.  Yes, it's a lot of effort, but I get *vastly* better code as a result.

Rather I am arguing that people (even smart ones) can learn faster when we don't ***UNNECESSARILY*** complicate.

 

Thinking in recursion instead of iteration is a major part of switching from procedural to functional programming.  Hell, I'd probably say it is the *most* important part (although, again, closures probably tie with it).  If somebody's going to work for me today, I demand that ability -- I run startups, and I just can't afford engineers who can't keep up with the major trends in programming.  If you aren't grokking at least these basics, then I'd say you're pretty much wasting your time using Scala -- you're just going to wind up writing Java with a different syntax.

Thinking in recursion is orthogonal to choosing recursion as that way everyone from levels A1 to A666 must remember how to iterate a fold.

 

And back to the point: once you *do* understand recursion, I think the symbolic explanation is quite natural.  (And really, I'm not likely to try to have somebody use foldLeft, by whichever name, until they grok recursion properly.)

I don't and I use recursion.

  

Understood. If you get too close to the current standard library, you begin to think it is the same as Scala. For me, Scala is the compiler and I love it! I can't heap enough gratitude on Martin and the others who built this. You guys are awesome! (including Miles Sabin who has apparently contributed) But the standard library has thorns I don't like, although there is a lot of code and ideas in it I like.

That's true, and I think everyone broadly agrees with that.  (See, for example, the argument about views going on in scala-language.)  But in this particular case I don't agree that that's a thorn -- I find the symbolic form considerably more glanceable and understandable than the "foldLeft" version.  Given this argument, though, it suggests to me that they were dead-on correct having both in the library, which allows projects to establish their own coding standards.

Eric S Raymond makes the argument that for open-source you program to the widest audience.

You could set up your IDE to show foldLeft as an operator, so you don't burden the A1 reader.

I see widespread of "I don't care" (selfishness) when it comes to making sure code is as widely understood as possible.

 It's turning out to be crazy-powerful and ridiculously expressive, albeit limited in focus.

I expect my effort to roughly no less expressive than Scala for levels up to but not including A666, and more expressive in some key areas. I may fail, but that is my goal.

  

But without experimenting, we can't prove some issues one way or the other in the marketplace.

Yep.  Ultimately, these arguments are irrelevant -- you have to see what actually works.

+1!

 

One more point: I remember *exactly* this argument being leveled at Java in the early days.  (I was one of the earliest hardcore adopters, back when everyone knew that Java was only intended for client plugins.)  This whole "object-oriented" thing was weird and confusing, and nobody understood it, as opposed to C, which was nicely comprehensible.  So the language clearly wasn't going to go anywhere.

That is not what I heard. I heard everyone loving Java and jumping from C++ like they were running from the plague. The controversial issues were more that Java was too simple, i.e. that it removed features C++ could do. 

Thanks for the discussion. Best Regards.