The Strange Loop conference

[Andrei Alexandrescu]

On 9/21/11 5:22 PM, bearophile wrote:
> This is why I have asked for functions like amap/afilter in Phobos,
> because in many situations in D you need an array instead of a lazy
> range.

I don't think that was being asked.

>> Of course, if every function that accepts a range becomes a
>> template then you have the practical problem of managing the number
>> of template instantiations. Code bloat is still a real problem with
>> heavy template usage.
>
> Haskell has used typeclasses to avoid this :-)

At the conference I discussed typeclasses at length with a Haskell 
connoisseur and he had to agree that D's template constraints are a 
suitable replacement, and also that template constraints can express 
requirements that type classes have difficulties with. This is because 
D's template constraints can involve several types simultaneously and 
can do arbitrary computations. (That's also what makes them less 
structured than typeclasses.)

>> Finally, map in Haskell just makes sense. You have a list of a's,
>> a function of 'a to b' and you get a list of b's out the other end.
>> It's simple, it's exactly what you want, and it just works. You
>> can't say the same in D.
>
> I agree. That has two good consequences: - It makes sense for the
> Haskell compiler too, so it is able to perform very complex
> optimizations that no D compiler today performs. - Being map so easy
> to write, to use and to understand, the programmer is able to write
> far more complex things. If writing a map requires a tens lines of
> complex D code, normal programmers usually don't want to write things
> much more complex (type-wise too) than a map.

I'm not sure how that assumption works. Implementing a regex engine is 
quite an endeavor, but that doesn't stop people from using it casually, 
and for higher-level things.

On the Haskell compiler being "... able to perform very complex 
optimizations that no D compiler today performs" I call bullshit. The 
two languages have very different approaches to computation and choose 
right off the bat very different corners of the PL design space. 
Consequently, the challenges met by the two languages are very different 
and the approaches to overcome those challenges are also very different.

Haskell starts with a computational model far removed from the reality 
of the computing fabric it works on. Therefore, it gains some in certain 
areas, but it loses some when it comes to efficiency. Naturally, it 
needs more sophisticated optimizations to overcome that handicap. That 
doesn't mean much in comparing Haskell to D or the quality of a Haskell 
compiler with that of a D compiler.

> Python lazy iterators syntax wins over both languages:
>
>>>> collection = xrange(20) [2 * x for x in collection if x<  5]  #
>>>> eager
> [0, 2, 4, 6, 8]
>>>> newcol = (2 * x for x in collection if x<  5)  # lazy
>>>> list(newcol)
> [0, 2, 4, 6, 8]

I guess I must act impressed.

>> We should probably add a specialized lambda syntax.
>
> Do you mean something like C# lambdas?

Per Walter's enumeration of syntax in various languages.

>> I wonder what Scala/Haskell idioms we should borrow for D.
>
> Haskell has several nice ideas, but I think it's not easy to copy
> them without changing D a lot. Still, being open toward this idea is
> an improvement for D designers :-)

Feel free to spare the patronizing part, it won't be missed.

>> You want Haskell capability with D performance. You can't have
>> that.
>
> We live in a world where JavaScript is sometimes only 3-4 times
> slower than D code, and where LuaJIT compiles dynamically typed Lua
> floating-point-heavy programs and runs them in a total amount of time
> lower than just running a binary produced by DMD. So be careful when
> you say something is impossible :-)
>
> In the works there is a dialect of Haskell meant for faster
> programs: http://www.haskell.org/haskellwiki/DDC

That wasn't my point.

>> D's map is superior to Haskell's. There is no contest.
>
> Some aspects of D map are superior, and some aspects of Haskell map
> are superior to D ones.
>
>
>> (In addition, Hakell's map forces ONE higher-order function
>> representation, whereas D works with a function alias, function,
>> or delegate.)
>
> I think this is an advantage of Haskell. I think Haskell doesn't need
> those things, it's more uniform.

It's also slower. Per the other half of your other posts, efficiency is 
a huge concern to you.

>> D also allows things that are essentially impossible in Haskell,
>> such as quicksort.
>
> The point of this discussion is to look for ways to improve D.
> bashing Haskell is off topic and bad.

Nobody's bashing Haskell. But we can't work from the assumption that 
everything in Haskell is non-critically good and has no downsides.


Andrei