Re: Interesting rant about Scala's issues
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.
Re: Interesting rant about Scala's issues
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!
Re: Interesting rant about Scala's issues
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 ;-).
Re: Interesting rant about Scala's issues
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
Re: Interesting rant about Scala's issues
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
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 08:43:33 UTC, Bienlein wrote: 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. Sounds like a lot has changed since I was in it then. 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 ;-). Yes Akka is definitely a rather neat and great technology. Also would be great to have in D. I would love to help get something like this working in D. But time. Its bad enough with Cmsed in its current state. Let alone if I were to meet its goals of providing pretty much everything under the sun. Like node communication between frontend and backend for a web service. That also would be rather a killer feature. But in saying this it would actually probably be better if it was built like Akka. So on second thoughts guess what I'll be working on soon. Something like Akka. If you hear from me within a week in the format of an announcement please help :)
It's official: Sociomantic Labs has been acquired by dunnhumby Ltd
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 13:23:16 UTC, Paulo Pinto wrote: I think you missed the post date. I think so too ...
Re: It's official: Sociomantic Labs has been acquired by dunnhumby Ltd
On 4/3/14, Don x...@nospam.com wrote: https://www.sociomantic.com/dunnhumby-acquires-sociomantic/ Congrats! I don't suppose there will be a blog post showcasing a successful exit of a startup that used D as its core technology? It could be a nice advertisement for D. :)
Re: 1st draft of complete class-based std.random successor
On Tuesday, 25 March 2014 at 00:08:27 UTC, bearophile wrote: I don't mind, I am happy :-) Thank you for adding a sorely needed function. It's been merged :-)
Re: Interesting rant about Scala's issues
I notice that he mentioned the objection to defining equality and so on for the root object. I have heard this before from Philip Wadler, and the more I think about it, the more it makes sense. This is essentially the idea of removing every method from Object, which we have dicussed before.
Re: Interesting rant about Scala's issues
On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg Andrei His examination of the compare function was interesting. I think, though, that it's misguided, and not one of Scala's problems. Returning an int to denote less than, equal, and greater than is a very small complexity, and makes it very fast to check the result.
Re: Interesting rant about Scala's issues
A more interesting point of his is the limitation of Scala's ability to optimize functions like filter... This is also a problem in D, but not as visible as we do not have macros to perform the sort of transformation he describes (turning filter f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should think about enforcing that lambas passed to higher order functions are pure, when we can (not in the compiler, of course. In the library.)
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:14:37 UTC, Meta wrote:
A more interesting point of his is the limitation of Scala's
ability to optimize functions like filter... This is also a
problem in D, but not as visible as we do not have macros to
perform the sort of transformation he describes (turning filter
f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should
think about enforcing that lambas passed to higher order
functions are pure, when we can (not in the compiler, of
course. In the library.)
And unfortunately, his next example also compiles in D. At least
D has some rationale for allowing this in the fact that it's a
systems-level language, but this is still awful.
import std.stdio;
void main()
{
float f = long.max;
int n = int.max;
auto x = f - n;
writeln(typeof(x).stringof, , x);
}
Re: Interesting rant about Scala's issues
Whoops, should be:
import std.stdio;
void main()
{
float x1 = long.max;
float x2 = long.max - int.max;
writeln(typeof(x2).stringof, , x2);
}
Not that it makes a difference.
Re: Interesting rant about Scala's issues
Meta: Returning an int to denote less than, equal, and greater than is a very small complexity, and makes it very fast to check the result. The point of that part of the rant is that using an integer is very not-precise, typing-wise. Having more precise typing sometimes helps. In a little higher level language using a 3-value enum (as in Haskell, more or less) is still sufficiently efficient. And Ada language shows that often you can have both precise types (strong typing) and almost C-like efficiency. Bye, bearophile
Re: Interesting rant about Scala's issues
On Fri, Apr 04, 2014 at 00:59:23 +, Meta wrote:
His examination of the compare function was interesting. I think,
though, that it's misguided, and not one of Scala's problems.
Maybe not major, but it's not completely ignorable.
Returning an int to denote less than, equal, and greater than is a
very small complexity, and makes it very fast to check the result.
See, this is *exactly* his point. You're basically putting the well, C
does it and int is fast as your rationale. I think by this point, we
(as a collective community) have seen that C has some serious flaws when
you start allowing user input from untrusted sources into your code. The
latter is easily classified as premature optimization.
There is *zero* rationale as to why this would be a compilable
implementation of comparison:
int compare(int a, int b) {
return a * b;
}
The fact that this compiles when used as a comparison is *insane* when
you take a fresh look at how you can construct a language.
If you have sum types, you can both deny the above silliness and
represent it as an integer and be just fine. In fact, you're possibly
better off since you can now do:
add $offset $compare_result
jmp *$offset
rather than doing 2 comparisons and a branch since you *know* the result
will never be more than 2.
--Ben
Re: Interesting rant about Scala's issues
On 4/3/2014 6:14 PM, Meta wrote: A more interesting point of his is the limitation of Scala's ability to optimize functions like filter... This is also a problem in D, but not as visible as we do not have macros to perform the sort of transformation he describes (turning filter f1, filter f2, filter f3 into filter f1 f2 f3). Maybe we should think about enforcing that lambas passed to higher order functions are pure, when we can (not in the compiler, of course. In the library.) Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:31:20 UTC, bearophile wrote:
The point of that part of the rant is that using an integer is
very not-precise, typing-wise. Having more precise typing
sometimes helps.
In a little higher level language using a 3-value enum (as in
Haskell, more or less) is still sufficiently efficient. And Ada
language shows that often you can have both precise types
(strong typing) and almost C-like efficiency.
Bye,
bearophile
I would agree if D actually had type-safe enums.
enum a
{
val = 1
}
enum b
{
val = 1
}
assert(a.val - b.val == 0);
Re: Interesting rant about Scala's issues
On Thu, Apr 03, 2014 at 18:51:56 -0700, Walter Bright wrote: Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure. Is there a built-in compose operator or function (Haskell's (.) operator)? How would you copy the common attributes of the composed functions to the new function (if not builtin)? --Ben
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 01:51:58 UTC, Walter Bright wrote: Since in D you can detect if a function is pure, and specialize accordingly, it is not necessary to require that the filter function be pure. That's true, but then somebody somewhere accidentally passes in a delegate that references some outside state, and performance is suddenly shot for no apparent reason. The upside in D is that you can explicitly mark delegates as pure and have the compiler check for you, but that still puts the onus on the user to be disciplined and not forget.
Re: Interesting rant about Scala's issues
Meta:
I would agree if D actually had type-safe enums.
enum a
{
val = 1
}
enum b
{
val = 1
}
assert(a.val - b.val == 0);
C enums are mostly type unsafe. C++11 has enum class that is
strongly typed. D enums are intermediate (and it has final
switches). I have asked for fully typesafe enums in D, but in
several years I think Walter has never answered, nor he has
explained why D has chosen such intermediate point. I presume
this choice is based on practical reasons, but I don't know
exactly what they are (perhaps to minimize the number of casts).
D used to have several corners of weak typing (like a partial
confusion between pointers and dynamic arrays) that later have
being (painfully and slowly) fixed (and this despite D Zen is
supposed to prefer a strict design first, followed by some
relaxations later).
Bye,
bearophile
Re: It's official: Sociomantic Labs has been acquired by dunnhumby Ltd
On 4/3/14, 7:04 AM, Don wrote: https://www.sociomantic.com/dunnhumby-acquires-sociomantic/ Congratulations to all involved! How will this impact the use of D at dunnhumby? Andrei
Re: Interesting rant about Scala's issues
On 4/3/2014 7:01 PM, Ben Boeckel wrote: Is there a built-in compose operator or function (Haskell's (.) operator)? How would you copy the common attributes of the composed functions to the new function (if not builtin)? The compiler does attribute inference for template functions and lambdas.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:00 PM, Meta wrote: The upside in D is that you can explicitly mark delegates as pure and have the compiler check for you, but that still puts the onus on the user to be disciplined and not forget. It's really like everything else in programming - at some point, if you don't avail yourself of the checking features, you have to check it yourself.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:19 PM, bearophile wrote: I have asked for fully typesafe enums in D, but in several years I think Walter has never answered, nor he has explained why D has chosen such intermediate point. I presume this choice is based on practical reasons, but I don't know exactly what they are (perhaps to minimize the number of casts). Because every cast breaks the type system. A type system that requires too many casts for normal things is NOT a type safe system. I have explained this on numerous occasions.
Re: Interesting rant about Scala's issues
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to create a type that
overrides selected behaviors of any other type.
Re: Interesting rant about Scala's issues
On Friday, 4 April 2014 at 04:31:41 UTC, Walter Bright wrote:
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you can use this construct to
create a type that overrides selected behaviors of any other
type.
Combined with your other post about casts, I'm not sure we're
talking about the same kind of type-safety. In the case of your
example, alias this does not make it typesafe, as a MyInt can
still be implicitly converted to int.
struct MyInt
{
int x;
alias x this;
}
void takesInt(int n)
{
}
void main()
{
//Fine
takesInt(MyInt(1));
}
Implicit conversions are generally not a facet of type-safe
systems. Saying that too-strong typing is bad because casts break
the type system is a strawman, although I agree that there is a
balance that must be struck.
