August 08, 2021
On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:

First and foremost ... thanks for D; your language seems superb :) !

Second: you all are a welcoming community to outsiders/newbies, something not seen very often on these kind of projects.

> All he said was "thank god for mom!"

I am not complaining nor anything like it, I think you know what should have been done and proceeded accordingly giving your vast and indisputable experience and track record, but, as usual, there are two points-of-view for any given problem:

I think I have a better analogy to the car-one:

- NASA/JPL/Boeing/et-al vs SpaceX

For instance JPL won't even let you a minor-minor-minor-deviation on any given issue and so their track record is almost astounding to say the least (let's forget about that *minor* issue involving a metric/imperial conversion). Think mom. Same for NASA/Boeing/and-family ... superb engineers thinking contingencies against the impossible. You got excellent track records but ...

On the other side, when you let loose available unrestricted tools on the wild, you end up with things like SpaceX. The progress we are having right now in a very short span of time (I mean, we, as humanity, not as a SpaceX employee of course) is unheard off. Lots of out-of-the-box-thinkers and what-not at the expense of taking increased risk in order to succeed. And the whole establishment frantically playing catch-up.

Which approach is better ?

Both and neither one; it depends on the point-of-view.

Why do I bring back this analogy ? Because when you give users unrestricted tools/hardware they'll surely find ways of doing things you can never dreamed of. That's how innovation works. At the expense of risk, of course, you can't have both at the same time.

And in our tech-sphere, same with hardware vendors: they want you to use their products the way they suit them for whatever reasons ($) and people always find ways to build superb things out-of-the-intended use-case ... just think google and hardware vendors on the beginnings before this hyper-scale thing became into existence.

Again: I am not complaining, I am very happy with D so far, it is your project, your language, you can do whatever you want with it the way you like :)

It is just I found this such a goood topic !
August 08, 2021
On Sunday, 8 August 2021 at 14:30:29 UTC, Max Samukha wrote:
> On Sunday, 8 August 2021 at 08:59:16 UTC, Walter Bright wrote:
>
>>
>> I replaced it all with versions, and the problems went away.
>
> You have just dismissed the problems caused by your solution, as you often do.

Why the personal attack? What does it add here?

I see these from time to time and they distract from the topic at hand. Sometimes even souring the discussion.

August 08, 2021
On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:
> Why the personal attack?

That's directly addressing the argument, not a personal attack.

Imagine going to a mechanic and saying "my car shakes and thumps" and getting the answer "just don't drive it then, no more shaking!"

True, but presumably you were driving the car for a reason, like maybe you had some place to be and that's not going to change. So you need some kind of solution. Maybe it is to ride a bike or take the bus, but you can't just ignore that need while saying "the problems went away".
August 08, 2021
On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:

>
> Why the personal attack? What does it add here?

I did it out of frustration with an issue that has a long history. Shouldn't have done that, sorry. I promise not to post here again.

August 08, 2021
On Sunday, 8 August 2021 at 16:38:41 UTC, Adam D Ruppe wrote:
> On Sunday, 8 August 2021 at 16:15:00 UTC, Kyle Ingraham wrote:
>> Why the personal attack?
>
> That's directly addressing the argument, not a personal attack.
>
> Imagine going to a mechanic and saying "my car shakes and thumps" and getting the answer "just don't drive it then, no more shaking!"

Or rather, imagine going to a mechanic and saying "my engine heats up and stops", and getting the answer "yep, I checked it out and the radiator's busted. I replaced it for you. You won't be having them heat-ups anymore." And then, because the mechanic didn't go into sufficiently tedious detail to deflect uncharitable criticism, you blow up at him: "why are you COVERING UP the problem with my engine by replacing some random part?!"
August 08, 2021
On 8/8/2021 6:57 AM, user1234 wrote:
> [indeed](https://youtu.be/HNMlooJeJ2M?t=2453)

Nice!
August 08, 2021
On 8/8/2021 7:30 AM, Max Samukha wrote:
>> I replaced it all with versions, and the problems went away.
> 
> You have just dismissed the problems caused by your solution, as you often do.

The static if solution was written by people who asserted I was wrong, that they needed that power. I got involved in it is because the static if solution resulted in the predicted bugs, and it fell into my lap to fix the bugs.

No programming technique is without problems, but it's better to use the technique with fewer problems.

I cannot transfer my experience to others, I can only explain. If people want to do things their way on their projects, that's ok, but with the D project we need to follow best practices.

Over time, as people gain experience with D and get comfortable with D best practices, the desire for #if expressions tends to fade, and the value in D's version system becomes evident.
August 08, 2021

On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

>

...
Language designers seem to have a big brother attitude towards programmers and think they will save the world by introducing limitations.

Examples.
...
2.
Somewhat related. when Java was designed, the designer (James Gosling I believe) claimed that programmers were too stupid to understand the difference between signed and unsigned math (despite often several years of university education) and removed signed math entirely from the language. The impact is that when unsigned math is required, you are forced to conversions and library solutions. Not ideal when an HW APIs deals with unsigned numbers for example.

You are welcome to add any other examples that you find significant for the discussion.

This partially applies to D in some extent but can often be found in other languages and mentality of several language designers.

The question is, do you think language designers go to far when trying to "save" programmers from misuse or not?
Do you think there can be approaches that both prevent bugs at the same time do not limit the language?

Just to point out that using Java as a sample seems a bit off. Java (well, the JVM) is the ultimate in restrictive. It's a compiler that doesn't emit CPU code, but safe(r) emulation in a sandbox. Java stormed the Enterprise world because Business managers wanted safer code, and are willing to slow everything down for an extra margin of safety. The JVM was not accepted en masse because bosses didn't trust users, but because they didn't trust the programmers. It kept those pesky cubicle workers one level away from their hardware. They were promised less show-stopping mistakes while still allowing the hiring of all the coders they need to help automate everyone else out of work. That James and the other Java designers decided to lessen signed/unsigned transition errors by simply removing unsigned, is just par for the JVM course.

Walter seems to be trying to lead D development down paths he sees as smarter, and wiser in the large. I don't get the sense that D is being designed for stupid programmers, or limited because of stupid. At least nowhere near the same league as with the JVM decisions which was purposely built because non-technical people don't trust programmers (lacking the skills to quickly determine if one is foolish or wise, but still want to hire them all while pursuing business goals).

Just about everyone thinks they are a good driver, or they wouldn't drive. But seat belts still save a lot of lives. Would probably save even more, if we didn't all drive that little bit faster feeling safer behind a seat belt, in cars now designed to crumple more for less crumpling of passengers. They don't install guard rails on highways because everyone misses the turn, but some few might on a bad day, so there is a guard rail to limit the damage.

I've always viewed the JVM as programming in bumper cars. There is a lot of fun to be had in bumper cars. You can learn a lot about yourself and others. Business leaders, particularly the non-technical, seem to agree.

I'm still new to D, but see it's present and future as an easy to read and write feels safer, is safer programming environment, at speed, en masse.

Have good, make well.

August 09, 2021

On Saturday, 7 August 2021 at 12:15:15 UTC, IGotD- wrote:

>

Array indexes should be signed instead of unsigned because somehow programmers mess up loops among other things.

This bugs me to no end. It is not hard to understand the concept of idx < size() and anyone using idx < size() - 1 should take a remedial course in basic Algebra, rather than fixing my language by not allowing me to say unsigned things. It's just not hard to remember to always use "less than" and "size" in your for loops. Reverse for loops are really the only exception, and that's just 1 more thing to remember for(top=size(), top > 0; --top) { auto idx = top - 1; ... } repeat for every program ever exactly the same way.

I can accept a language that doesn't let me use unsigned arithmetic though, even if I grumble about it. I do approve of stuff that limits subtle errors in rarely encountered, esoteric situations, like how you can't have a multi-byte character inside a 1 byte literal. What really is a bad idea is stupid, fake encapsulation, that doesn't encapsulate anything and is just encouraging programmers to make things hard for other programmers purely for ego stroking, with no savings in complexity.

So basically I think the private: keyword needs to go die in a fire.

>

The question is, do you think language designers go to far when trying to "save" programmers from misuse or not?

I believe the technical term these days for when language designers go too far trying to save programmers from misuse is "rust."

August 09, 2021

On Monday, 9 August 2021 at 01:37:09 UTC, cy wrote:

>

for(top=size(), top > 0; --top) { auto idx = top - 1; ... }

Oh, and I really appreciate languages that don't allow me to use for loops with a single semicolon, refusing to assume that I meant to type a comma there.