On 12/12/2012 5:51 PM, Timon Gehr wrote:
> A significant part of the D code is spent arranging data into the right layout,
> while the Haskell code does nothing like that.

So, please take the bait :-) and write a Haskell version that runs faster than the D one.

On 12/12/2012 5:32 PM, bearophile wrote:
> One "important" firm uses OcaML for high speed trading because it's both very
> fast (C++-class fast, faster than Java on certain kinds of code, if well used)
> and apparently quite safer to use than C/C++. And it's harder to find OcaML
> programmers than C++ ones.

Fair enough, so I challenge you to write an Ocaml version of the input sorting program I presented in this thread in Haskell and D versions.

On 12/12/2012 5:16 PM, Timon Gehr wrote:
> On 12/13/2012 12:43 AM, Walter Bright wrote:
>> On 12/12/2012 3:23 PM, Timon Gehr wrote:
>>> It is somewhat similar to (the still quite broken) 'pure' in D,
>>
>> Broken how?
>>
>
> - There is no way to specify that a delegate is strongly pure without resorting
> to type deduction, because

Are these in bugzilla?

On Wednesday, 12 December 2012 at 21:05:05 UTC, Walter Bright wrote:
> On 12/12/2012 2:53 AM, foobar wrote:
>> One example that comes to mind is the
>> future version of JavaScript is implemented in ML.
>
> Um, there are many implementations of Javascript. In fact, I have implemented it in both C++ and D.

Completely besides the point.
The discussion was about using ML in real life, not what you specifically chose to use. The fact that you use D has no baring on your own assertion that ML is effectively dead. Fact is _other people and organizations_ do use it to great effect.
Also, I said _future version_ of JS, meaning the next version of the ECMAscript standard. ML was specifically chosen as it allows to both be efficient and verify the correctness of the implementation.

> it's both very fast (C++-class fast, faster than Java on certain kinds of code, if well used) and apparently quite safer

Last I tried OCaml, "well used" in context of performance would mean avoiding many useful abstractions. One thing I remember is that using functors always has run time cost and I don't see why it should.

On Wednesday, 12 December 2012 at 08:25:04 UTC, Han wrote:
> Walter Bright wrote:
>> Overlooked is the previous 10 years the band struggled in
>> obscurity.
>
> You KNOW that D has not been "overlooked". Developers and users with
> applications give it a look (the former mostly) and then choose something else.

Overlooked ? No. Using ? No. Disliked and abandoned ? No.

Quite a few times I've seen on the web people saying something like:
"D looks *really* nice, can't use it right now, but definitely keeping eye on it"

Same with myself. Keeping eye on it since mid-2010.


> Do you really think that D will ever have popularity to the level of The Beatles?

From what I've seen so far, I'd say that's quite possible.


> Do you have a "Moses complex" (psychological) a little bit maybe?

You do understand this doesn't add anything to the discussion, right ?

On 12/13/2012 04:54 AM, Walter Bright wrote:
> On 12/12/2012 5:16 PM, Timon Gehr wrote:
>> On 12/13/2012 12:43 AM, Walter Bright wrote:
>>> On 12/12/2012 3:23 PM, Timon Gehr wrote:
>>>> It is somewhat similar to (the still quite broken) 'pure' in D,
>>>
>>> Broken how?
>>>
>>
>> - There is no way to specify that a delegate is strongly pure without
>> resorting
>> to type deduction, because
>
> Are these in bugzilla?
>

Now they certainly are.

http://d.puremagic.com/issues/show_bug.cgi?id=9148

The following you can close if you think 'const' should not guarantee no mutation. It does not break other parts of the type system:
http://d.puremagic.com/issues/show_bug.cgi?id=9149

On Wednesday, 12 December 2012 at 20:01:43 UTC, Timon Gehr wrote:
> On 12/12/2012 03:45 AM, Walter Bright wrote:
>> On 12/11/2012 5:05 PM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> ML has been around for 30-40 years, and has failed to catch on.
>>>
>>> OcaML, Haskell, F#, and so on are all languages derived more or less
>>> directly
>>> from ML, that share many of its ideas. Has Haskell caught on? :-)
>>
>> Haskell is the language that everyone loves to learn and talk about, and
>> few actually use.
>>
>> And it's significantly slower than D,
>
> (Sufficiently sane) languages are not slow or fast and I think the factor GHC/DMD cannot be more than about 2 or 3 for roughly equivalently written imperative code.
>
> Furthermore no D implementation has any kind of useful performance for lazy functional style D code.
>
> In some ways, D is very significantly slower than Haskell. The compilers optimize specific coding styles better than others.
>
>> in unfixable ways.
>>
>
> I disagree. That is certainly fixable. It is a mere QOI issue.

Actually, a factor of 2 to 3 can be huge. Consider that java is around a factor 2 or less to C++ in the Computer Languages Benchmark Game, and yet, you easily feel the difference everyday on your desktop applications.
But although the pure computation power is not very different, the real difference I believe lies the memory management, which is probably far less efficient in Java than in C++.

On Thursday, 13 December 2012 at 01:32:23 UTC, bearophile wrote:
> Walter Bright:
>
>> Java makes no attempt to detect integer overflows.
>
> There are various kinds of code. In some kinds of programs you want to be more sure that the result is correct, while other kinds of programs this need is less strong.
>
>
>> I personally know people who write high speed trading software. These people are concerned with nanosecond delays. They write code in C++. They even hack on the compiler trying to get it to generate faster code.
>>
>> It doesn't surprise me a bit that some people who operate server farms use slow languages like Ruby, Python, and Perl on them. This does cost them money for extra hardware. There are always going to be businesses that have inefficient operations, poorly allocated resources, and who leave a lot of money on the table.
>
> One "important" firm uses OcaML for high speed trading because it's both very fast (C++-class fast, faster than Java on certain kinds of code, if well used) and apparently quite safer to use than C/C++. And it's harder to find OcaML programmers than C++ ones.
>
> Bye,
> bearophile


According to the Benchmark game, performance of Ocaml is good, but not fantstic. And certainly not "C++-class" fast. It's more like "Java-class" fast. (in fact it's slower than Java 7 on most tests, but uses much more memory).
Unfortunately, D hasn't been on the game for a long time, but last time it was, it was effectively faster than g++.

So really, we are not talking the same kind of performance here. D is likely to be MUCH faster than Ocaml.

On Thursday, 13 December 2012 at 01:51:27 UTC, Timon Gehr wrote:
>
> Certainly, you can argue that the faster version should be in a prominent place in the standard library, but the fact that it is not does not indicate a fundamental performance problem in the Haskell language. Also, note that I am completely ignoring what kind of code is idiomatic in both languages. Fast Haskell code often looks similar to C code.
>
Well, you can write C code in D.
You can compare top performance for both languages, but the fact is, if you write Haskell code extensively, you aren't going to write it like C, so comparing idiomatic Haskell vs idiomatic D does make sense. And comparing programs using the standard libraries also makes sense because that's how languages are used. It probably doesn't make much sense in a microbenchmark, but in a larger program it certainly does. And if the standard library is twice as slow in implementation A than in implemention B, then most programs will feel *at least* twice as slow, and usually more, because if you call a function f that's twice as slow in A than in B from another function that's also twice as slow in A than in B, then the whole thing is 4 times slower.