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

On Thursday, 3 April 2014 at 11:19:14 UTC, Bienlein wrote:
> 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

I think you missed the post date.

On Thursday, 3 April 2014 at 13:23:16 UTC, Paulo Pinto wrote:

> I think you missed the post date.

I think so too ...

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.

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.

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

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);
}

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.

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

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.