August 20

On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

>

On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

>

I'm starting to learn the D language and started reading the Language Reference.

I've never read the reference, but I can tell you that The Book (over-hyped or not) gives you a solid grounding. It's the only D reference/tutorial that's kept more-or-less up-to-date (I say at the risk of excessive hyphenation). You may or may not find it slow going, depending on your taste, but at this point, it's the best we have for getting in there are getting your feet wet.

If you're new to computer science, it covers basics I first learned back in the mid-1980's, the kind of stuff rarely mentioned these days that lends one a solid understanding of these machines we all love to tinker with.

If you like to stay on the bleeding edge then it’s… certainly out of date.

The book also says slices are reference types, which is completely erroneous. Where associative array or class variables are simply a pointer that is not semantically treated as one (i.e. no dereferencing is required), slices are more complicated.
Here’s the book’s example of a value type:

void reduceEnergy(double energy) {
    energy /= 4;
}

As you can see, since we only modified a value type—even though its new value was derived from the old one—nothing happens and this function is actually useless. Now, let’s see their deceptive presentation of slices as reference types:

void makeFirstLetterDot(dchar[] str) {
    str[0] = '.';
}

Oh, see? It’s totally a reference type, because this modifies the same data as at the caller site. But hang on, by that logic this is also a ‘reference type’:

struct DCharArray{
  dchar* ptr;
  size_t length;
}
void makeFirstLetterDot(DCharArray str){
    str[0] = '.';
}

What the book misses is the proper explanation that despite containing a pointer—which is a reference by its very nature—slices are still value types because they also incorporate a length, which is copied:

void reduceLength(dchar[] str){
    str = str[0..$-1];
}

This does nothing, because we modified the slice’s length, and the slice’s length is copied rather than referenced. Notice that the pointer remains the same, which distinguishes this from the behaviour of reassigning to an associative array or class variable; wherein a new instance will be distinct from the old one, and writing to its value fields will not directly affect the old instance.

August 20

On Monday, 19 August 2024 at 16:03:59 UTC, Nick Treleaven wrote:

>

On Sunday, 18 August 2024 at 01:31:37 UTC, monkyyy wrote:

>

spec is full of lies and slaunder

If you know of specific inaccuracies or omissions, please file bugs.

Honestly, all examples should be runnable, except for good reasons when they can’t.

August 20

On Tuesday, 20 August 2024 at 13:04:08 UTC, Quirin Schroll wrote:

>

Honestly, all examples should be runnable, except for good reasons when they can’t.

Just to note: aside from incomplete snippets, they can't be runnable at the moment if:

  • They need -preview switches
  • If they depend on a higher compiler version than run.dlang.org has (which should only be unreleased versions).
  • If they need multiple modules

There are still some which could be made runnable, although I think we've been making quite a lot of progress in recent years.

August 20

On Monday, 19 August 2024 at 19:02:06 UTC, monkyyy wrote:

>

You should only ask for bug reports of people who dont have active year old ones;

Spec bugs are usually easy to fix. Even if a bug doesn't get fixed, it's still valuable to have bugs filed.

August 20

On Tuesday, 20 August 2024 at 16:27:35 UTC, Nick Treleaven wrote:

>

On Monday, 19 August 2024 at 19:02:06 UTC, monkyyy wrote:

>

You should only ask for bug reports of people who dont have active year old ones;

Spec bugs are usually easy to fix. Even if a bug doesn't get fixed, it's still valuable to have bugs filed.

https://issues.dlang.org/show_bug.cgi?id=24205

my spec bugs dont get fixed either

August 21

On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

>

If you like to stay on the bleeding edge then it’s… certainly out of date.
Yeah, yeah...
I didn't say it was perfect. Read this carefully (I'll repeat myself):

It's the only D reference/tutorial that's kept more-or-less up-to-date.

Prove me wrong by citing something more up-to-date and I'll gladly retract. Otherwise, go find someone else to troll.

August 21

On Wednesday, 21 August 2024 at 06:45:38 UTC, Ron Tarrant wrote:

>

On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

>

If you like to stay on the bleeding edge then it’s… certainly out of date.
Yeah, yeah...
I didn't say it was perfect. Read this carefully (I'll repeat myself):

It's the only D reference/tutorial that's kept more-or-less up-to-date.

Prove me wrong by citing something more up-to-date and I'll gladly retract. Otherwise, go find someone else to troll.

I agree that the D Book is great. I don't understand why criticize it for tiny inaccuracies among a sea of great content, no book is perfect. Why not contribute to the book instead of rant about it here. Such negativity seems to come from a place of anger, not genuinely from trying to help the discussion and the correctness of general content about D.

August 21

On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

>

On Monday, 19 August 2024 at 06:47:10 UTC, Ron Tarrant wrote:

>

On Saturday, 17 August 2024 at 22:17:59 UTC, Pete wrote:

>

I'm starting to learn the D language and started reading the Language Reference.

I've never read the reference, but I can tell you that The Book (over-hyped or not) gives you a solid grounding. It's the only D reference/tutorial that's kept more-or-less up-to-date (I say at the risk of excessive hyphenation). You may or may not find it slow going, depending on your taste, but at this point, it's the best we have for getting in there are getting your feet wet.

If you're new to computer science, it covers basics I first learned back in the mid-1980's, the kind of stuff rarely mentioned these days that lends one a solid understanding of these machines we all love to tinker with.

If you like to stay on the bleeding edge then it’s… certainly out of date.

The book also says slices are reference types, which is completely erroneous.

That terminology didn't originate with Ali. You don't like it, fine, but he's not wrong based on the usage I've seen here in the last decade.

August 21

On Wednesday, 21 August 2024 at 06:45:38 UTC, Ron Tarrant wrote:

>

On Tuesday, 20 August 2024 at 04:53:16 UTC, IchorDev wrote:

>

If you like to stay on the bleeding edge then it’s… certainly out of date.
It's the only D reference/tutorial that's kept more-or-less up-to-date.

Prove me wrong by citing something more up-to-date and I'll gladly retract.

A much more up-to-date reference would be… well, the language reference??
After skimming a few relevant chapters, it seems that the book doesn’t mention IES, doesn’t mention named function arguments, doesn’t mention shortened function declaration, doesn’t mention the more sensible new alias this syntax, and refers to cent/ucent as ‘reserved for future use’ rather than ‘deprecated keywords’. And don’t try to weasel out of this by saying that the official D language reference—the only D reference I use on a regular basis—isn’t what you meant by a ‘reference’ after telling me to ‘read carefully’. The word read carefully is presumed written carefully.

August 21

On Wednesday, 21 August 2024 at 06:53:24 UTC, Renato Athaydes wrote:

>

I agree that the D Book is great. I don't understand why criticize it for tiny inaccuracies among a sea of great content, no book is perfect.

So, your logic is that criticism of something that is mostly great does not make sense? Now, apply this logic to another situation and perhaps you’ll see how it’s this logic that does not make sense. You can’t tell me you’ve never seen a great TV show that had a couple of bad episodes, eaten something delicious that left behind a much less pleasant aftertaste, or had a friend who was mostly very kind except for occasionally being racist. Overlooking flaws simply because they do not represent a sufficient percentage of a whole is foolish if not dangerous.

>

Why not contribute to the book instead of rant about it here.

It’s not a public git repository with issues & PRs open, it’s a book with a single author. I’m not responsible for the publication of some random person and they’re not exactly asking for help on their website. If anything, I think it would be quite rude to contact them unsolicited to request that they change their book based on what I think. The book is allowed to be wrong, and I’m allowed to say that it’s wrong so that people know.

>

Such negativity seems to come from a place of anger, not genuinely from trying to help the discussion and the correctness of general content about D.

You think that disagreeing with the book for explaining slices in a way that’s bound to cause confusion and frustration for learners is ‘not […] trying to help the discussion’? So you are criticising me for criticising something because you think criticism is unproductive? What a self-defeating argument. If you think criticism is ‘negativity’ and ‘angry’, then you must say nothing unfavourable of such criticism; lest you participate in the very same activity. Yet the true struggle is for the superiority of ideas, and you have added nothing to this conversation of any value.