On Tuesday, 30 August 2016 at 18:22:59 UTC, Walter Bright wrote:
> On 8/30/2016 3:42 AM, Chris wrote:
>> [...]
>
> I agree it's time to remove comparisons with C++, although there is room for a "D for C++ Programmers" section and, of course, "Interfacing D to C++".

I think this will do D good in the long run.

On 8/31/2016 2:17 AM, Seb wrote:
> Done (FYI the translations aren't officially published yet) ;-)

Danke schoen!

On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH wrote:
> I am going to vote with Adam here.  If memory serves me correctly what initially drew me in to the D language was a statement on the main page that "D is not a religion".  I think at the time I had been doing some work with Java, where everything had to be an object. Man, I hate Java for that.

Many of the inconsitencies and problems in Java come from basic types not being objects. Everything being objects is a great way to keep things easy to understand, consistent and clean. It has some impact on performance, but a lot can be done here which is more than sufficient for application programming. Hot Spot runtime code optimization in Java is very effective.

> Also, I think saying if you don't like functional programming you will miss 'most' of what D has to offer is really selling the language short.  After all you can write C or C++ style code in D if you want, which may be very attractive to some folks.

D has a lot to offer with regard to functional programming. It has pure functions and true immutable classes (true = also sub objects become immutable), which Scala all doesn't have (because of restrictions of the JVM). Does D have tail call recursion optimization? I don't know, actually. If D had that and pattern matching, it would beat Scala with all it's hype by a big leap.

On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:
> Am Fri, 19 Aug 2016 13:36:05 +0000
> schrieb Adam D. Ruppe <destructionator@gmail.com>:
>
>> On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
>> > If we hypothetically switched to a ubyte+ubyte=ubyte semantic, then code like this breaks silently:
>> 
>> However, if it took the entire statement into account, it could handle that... by my rule, it would see there's a float in there and thus automatically cast a and b to float before doing anything.
>
> Float math is slow compared to integer math and precision loss
> occurs when this rule is also applied to (u)int and (u)long
> with only the deprecated (as per amd64 spec) real type being
> large enough for 64-bit integers.

Try multiplications and divisions.

On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
> D has a lot to offer with regard to functional programming. It has pure functions and true immutable classes (true = also sub objects become immutable), which Scala all doesn't have (because of restrictions of the JVM). Does D have tail call recursion optimization? I don't know, actually. If D had that and pattern matching, it would beat Scala with all it's hype by a big leap.

D does not guarantee tail calls, but the compiler might sometimes decide to do it. Functional programmer usually want to guarantee, so they don't have to write a loop. The downside of TCO is that the stack trace is missing frames, which can be very confusing.

D has no syntax for pattern matching, but some library support:
https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching

On Thursday, 1 September 2016 at 12:04:51 UTC, qznc wrote:
> On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
>> D has a lot to offer with regard to functional programming. It has pure functions and true immutable classes (true = also sub objects become immutable), which Scala all doesn't have (because of restrictions of the JVM). Does D have tail call recursion optimization? I don't know, actually. If D had that and pattern matching, it would beat Scala with all it's hype by a big leap.
>
> D does not guarantee tail calls, but the compiler might sometimes decide to do it. Functional programmer usually want to guarantee, so they don't have to write a loop. The downside of TCO is that the stack trace is missing frames, which can be very confusing.

There's a DIP about adding a TCO attribute/pragma:
https://github.com/dlang/DIPs/pull/6

FYI: There's some discussion about it's benefit in comparison to functional language D does have loops and it's a lot easier to write and read them.
If you want to chime in, please do so at the PR discussion.

> D has no syntax for pattern matching, but some library support:
> https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching

Yep it's pretty easy to do within library code, if you use an object chain you might also want to have a look at castSwitch.

https://dlang.org/phobos/std_algorithm_comparison.html#.castSwitch

On Thursday, 1 September 2016 at 17:10:00 UTC, Seb wrote:

> FYI: There's some discussion about it's benefit in comparison to functional language D does have loops and it's a lot easier to write and read them.

Some are of that opinion. However, this is D, not Python or Go, so claims about the one true preference is not a valid argument against a particular feature.