4 ms·

I think i've been waiting for Chapel more than X10 or Fortress, but scala and clojure are assuming the mantles as general purpose languages. http://bartoszmile

by gtani 15y ago

I think i've been waiting for Chapel more than X10 or Fortress, but scala and clojure are assuming the mantles as general purpose languages. http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/ http://bartoszmilewski.wordpress.com/2011/11/07/supercomputi... http://lambda-the-ultimate.org/node/4405 http://lambda-the-ultimate.org/node/4405

dkarl 15y ago
Languages built on the JVM have to deal with boxing and unboxing. Scala still doesn't have efficient arrays of unboxed values. Progress here: http://docs.scala-lang.org/sips/pending/value-classes.html http://docs.scala-lang.org/sips/pending/value-classes.html After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult. For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages. (Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)
- pron 15y ago
  I agree, and I think Julia's designers have chosen correctly not to use the JVM (although, in the comments below you'll find that Julia uses boxed types for "structs" as well, though it would be far easier to build true array-embeddable complex types on LLVM than on the JVM). However, value types for the JVM are a work in progress (as well as tail-calls), and I think they might have already been implemented in the DaVinchi project (future JVM improvements), and so will find their way to the JVM in due time (see https://blogs.oracle.com/jrose/entry/tuples_in_the_vm https://blogs.oracle.com/jrose/entry/tuples_in_the_vm). Until then, scientific computing languages will most likely choose a different platform.
- deleted 15y ago
  [deleted]
- gtani 15y ago
  It's worth looking at the PPL project http://ppl.stanford.edu/main/publications.html http://ppl.stanford.edu/main/publications.html example, this scala DSL: http://liszt.stanford.edu/liszt_sc2011.pdf http://liszt.stanford.edu/liszt_sc2011.pdf

by gtani 15y ago

dkarl 15y ago

Languages built on the JVM have to deal with boxing and unboxing. Scala still doesn't have efficient arrays of unboxed values. Progress here: http://docs.scala-lang.org/sips/pending/value-classes.html http://docs.scala-lang.org/sips/pending/value-classes.html After that proposal is implemented (perhaps in version 3 of Scala, almost ten years after its first release, though granted it wasn't their top priority) they'll still have to write at least a little bit of boilerplate for each type they want to store in unboxed arrays, and they'll be limited to types that can be stored as Java primitive types under the covers. That seems like a pretty nasty limitation for a general-purpose scientific computing language, not only because it decreases native performance but because it makes C interop much more difficult. For a general-purpose scientific language, I think it is imperative to adopt the principle that any user-designed type should be able to achieve the same power, performance, and elegance as if it were a built-in type. To the best of my knowledge, that rules out JVM languages. (Scala was never meant to be a "JVM language," but in terms of its strengths, its weaknesses, its user base, and its future, it is very much a JVM language, and the obstacles to implementing efficient user-defined types is one of the trade-offs they accepted when they went with the JVM.)

pron 15y ago
I agree, and I think Julia's designers have chosen correctly not to use the JVM (although, in the comments below you'll find that Julia uses boxed types for "structs" as well, though it would be far easier to build true array-embeddable complex types on LLVM than on the JVM). However, value types for the JVM are a work in progress (as well as tail-calls), and I think they might have already been implemented in the DaVinchi project (future JVM improvements), and so will find their way to the JVM in due time (see https://blogs.oracle.com/jrose/entry/tuples_in_the_vm https://blogs.oracle.com/jrose/entry/tuples_in_the_vm). Until then, scientific computing languages will most likely choose a different platform.
deleted 15y ago
[deleted]
gtani 15y ago
It's worth looking at the PPL project http://ppl.stanford.edu/main/publications.html http://ppl.stanford.edu/main/publications.html example, this scala DSL: http://liszt.stanford.edu/liszt_sc2011.pdf http://liszt.stanford.edu/liszt_sc2011.pdf