A lot of them could apply to us as well.

https://www.youtube.com/watch?v=TS1lpKBMkgg


Andrei

Andrei Alexandrescu:

> A lot of them could apply to us as well.
>
> https://www.youtube.com/watch?v=TS1lpKBMkgg

The slides:
http://www.slideshare.net/extempore/keynote-pnw-scala-2013

Bye,
bearophile

On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote:
> A lot of them could apply to us as well.
>
> https://www.youtube.com/watch?v=TS1lpKBMkgg

Reminds me of our empty-front-popFront discussion. Trying to support all kinds of variations on that results in unoptimizable code.

On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote:
> A lot of them could apply to us as well.
>
> https://www.youtube.com/watch?v=TS1lpKBMkgg


at about 44:00: "I begged them not to do them [AST macros]." :-)

Andrei Alexandrescu:

> A lot of them could apply to us as well.
>
> https://www.youtube.com/watch?v=TS1lpKBMkgg

I agree that D language/compiler could improve its integration with versioning systems (slide 31). How to design this?

Bye,
bearophile

My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala.

D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits.

The presentation by Paul Phillips was discussed in the Scala forums at great length:

What's up with Paul Phillips?
https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA
54 replies

What's up with Paul Phillips?
https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false]
201 replies

Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a "real" language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year.

To get a plus for your skill set when applying for Java jobs you will have to learn Scala. For a Java developer like me any chances for a job doing D are very slim. But I keep looking into D just out of interest and to get some food for my mind. There is so much to learn from looking at D and playing with it that I keep doing it just on a fun & interest basis.

On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote:
> My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala.
>
> D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits.
>
> The presentation by Paul Phillips was discussed in the Scala forums at great length:
>
> What's up with Paul Phillips?
> https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA
> 54 replies
>
> What's up with Paul Phillips?
> https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false]
> 201 replies
>
> Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a "real" language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year.
>
> To get a plus for your skill set when applying for Java jobs you will have to learn Scala. For a Java developer like me any chances for a job doing D are very slim. But I keep looking into D just out of interest and to get some food for my mind. There is so much to learn from looking at D and playing with it that I keep doing it just on a fun & interest basis.

If I remember what the state of Groovy is (around 2012). The compiler devs focussed quite heavily on functionality not performance. Even refused to go that direction.
It was quite bad.

Its a real shame. I liked it. Although if they had and had unsigned types I probably wouldn't be in D!

> If I remember what the state of Groovy is (around 2012). The compiler devs focussed quite heavily on functionality not performance. Even refused to go that direction.
> It was quite bad.
>
> Its a real shame. I liked it. Although if they had and had unsigned types I probably wouldn't be in D!

Since Groovy 2.0 there is optional static type checking and when using it performance is much better. When Groovy is run over the Havlak benchmark it is only 10% behind in speed compared to Java with static typing and only about 40% in behind when purely dynamic as with pre-2.0 Groovy. See the bottom most paragraph in the readme of https://github.com/oplohmann/havlak-jvm-languages

The benchmark in this article (http://java.dzone.com/articles/groovy-20-performance-compared) only measures method invocation time, but it also gives some idea that performance in Groovy is really good now.

What Scala is really good at is concurrency. You must give them that. Akka (akka.io) and new ideas about futures and promises really started in the Scala community. Some of that stuff also made it into JDK8. Something like Akka for D will be a killer app for D. It can't be done as a spare time activity, otherwise I would already have embarked on it ;-).

On Thursday, 3 April 2014 at 08:18:01 UTC, Bienlein wrote:
> My knowledge of compiler constructions is fairly limited and I might be wrong, but it seems to me that the Scala compiler is broken. Scala has gained some bad reputation for long build times (just google for Scala and build time) which IMHO cannot be explained by the large number of language features. D has a comparable large number of language features and compiles much faster than Scala.
>
> D has been designed from the beginning with caution on compilation speed and thinking about how to keep it slow to begin with. D not only in that way is a language that was thought out. On the contrary, Scala seems to me to be a language where many features of various languages were thrown into one and then a compiler was built for it. The incremental Scala compiler pretty much rescues the build time problem, though, and they are mostly lucky now. Also, IMHO, implicits are really crazy and it should have been clear from the beginning that they will become a problem for scalable build times, see http://java.dzone.com/articles/implicits-scala-conversion. Interestingly. Martin Odersky got his Ph.D. from Niklaus Wirth at the ETH and I don't want to know what Wirth would say about implicits.
>
> The presentation by Paul Phillips was discussed in the Scala forums at great length:
>
> What's up with Paul Phillips?
> https://groups.google.com/forum/?hl=de#!topic/scala-debate/IgrKCdConlA
> 54 replies
>
> What's up with Paul Phillips?
> https://groups.google.com/forum/?hl=de#!topic/scala-user/ImqlClXTrS4[201-225-false]
> 201 replies
>
> Sadly, the only serious language on the JVM besides Java8 is Scala. Ceylon has not taken off at all after becoming 1.0. Groovy's language extensions are basically AST transformations and not truly baked into a "real" language. Nobody knows how Kotlin will be doing when it turns 1.0 maybe somewhen in autumn/winter this year.

What about Clojure? It is getting real world use. The recent
release makes it easier to call Clojure from Java. Example:

IFn map = Clojure.var("clojure.core", "map");
IFn inc = Clojure.var("clojure.core", "inc");
map.invoke(inc, Clojure.read("[1 2 3]"));

is all you need to use Clojure's map from a Java program.

https://github.com/clojure/clojure/blob/master/changes.md

On Thursday, 3 April 2014 at 11:03:56 UTC, bachmeier wrote:
> What about Clojure? It is getting real world use. The recent
> release makes it easier to call Clojure from Java. Example:
>
> IFn map = Clojure.var("clojure.core", "map");
> IFn inc = Clojure.var("clojure.core", "inc");
> map.invoke(inc, Clojure.read("[1 2 3]"));
>
> is all you need to use Clojure's map from a Java program.
>
> https://github.com/clojure/clojure/blob/master/changes.md

Yeah, you might be right. I was maybe too much focused on imperative/OO languages. It is now especially easy to call Closure from Kotlin. Have a look: http://blog.jetbrains.com/kotlin/2014/04/kotlin-gets-support-for-s-expressions