On Thu, Sep 05, 2019 at 07:33:05PM +0000, bachmeier via Digitalmars-d wrote: [...]
> It's true that Rust does appeal to the sliver of programmers that think memory management is an awesome way to spend Saturday night, but let's let Rust have those users and worry about a good experience for the rest.

+1, couldn't have said it better.  Coming from a C/C++ background, I'm well-versed in all-nighters spent debugging memory management problems, and personally I find D's GC a godsend.  I am *so* much more productive with the GC when performance isn't a big issue, and even when it is, there are ways to control the GC so that it stays out of the bottlenecks in the code.  It isn't as though this is Java where you are *forced* to use the GC, after all.  (In many cases the GC isn't a problem as long as you don't trigger it inside performance-sensitive inner loops.  Cutting out GC from the *entire* application as a knee-jerk reaction is, IMNSHO, premature optimization. Heck, even game engines these days support higher-level scripting in GC'd languages -- you just have to keep the GC out of the core performance sensitive code and it's Good Enough(tm).)


> > There's still room in the world for DasBetterC, so I hope the development continues. It's great that many of the annoying restrictions have been lifted.
> 
> Exactly. There's no reason to choose between D and betterC because we can have both.

+1.


T

-- 
Designer clothes: how to cover less by paying more.

On Thu, Sep 05, 2019 at 02:32:16PM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 2019-09-05 01:13, Walter Bright wrote:
> 
> > This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time.
> 
> I just going to leave this here for everyone:
> 
> https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s
[...]

So what happened since then that Walter is now staunchly against AST macros?


T

-- 
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

On 9/5/2019 3:06 AM, Russel Winder wrote:
> As are almost all programming language features.

Pedantically true, but carefully designing features so they do not encourage such excess is reasonably effective. For example, D's operator overloading is set up to make it hard to do abominations like C++ iostreams.


> The lesson from Groovy was to
> actively avoid doing stupid things and to trust programmers not to f### things
> up. Which they didn't.

All programmers agree with this sentiment, and create a hellish mess anyway.

(I can't comment on Groovy, since I know too little about it or its community.)

On 9/4/2019 5:32 PM, Laeeth Isharc wrote:
> What's your take on Rust macros?  I am not familiar with them so I don't know myself.

I know they exist and Rust relies on them as a substitute for language features common in other languages, but I don't know much about them beyond that.

DSLs can be (and are) done in D using string mixins. What you can't do is hijack D's syntax for the DSL, which is what AST macros enable.

On 9/5/2019 1:21 PM, H. S. Teoh wrote:
> Coming from a C/C++ background, I'm
> well-versed in all-nighters spent debugging memory management problems,

I just spend three days trying to track down memory corruption problems in CTFE.

On Thu, Sep 05, 2019 at 01:50:03PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/5/2019 3:06 AM, Russel Winder wrote:
[...]
> > The lesson from Groovy was to actively avoid doing stupid things and to trust programmers not to f### things up. Which they didn't.

Sorry to say, having worked in the industry for a few decades, I have exactly the opposite sentiment.  Perhaps things aren't that way where you are, and that's good for you.  Where I am, the worst possible code gets written because the language allowed it, and it falls upon my shoulders to fix the inscrutable problems therein long after the original author has moved on to greener pastures.  "Trust the programmer" is an attitude I used to subscribe to, but these days it leaves a bitter taste in my mouth.


> All programmers agree with this sentiment, and create a hellish mess anyway.
[...]

Yep.  Especially when there's a deadline and the customer is being unreasonable, and your job is on the line, then anything goes. Unreadable hacks using C macros?  Sure, if it gets the job done before you're fired.  Operator overload abuse? Sure, if it gets the job done before you're fired.  Inscrutable pointer casting hacks?  Oh yes, if it gets the product shipped by the deadline.  Making things easier for the poor sod who'll be maintaining your code a decade later?  That's not even a consideration when the deadline is looming, the customer is demanding, and the project manager is angry.

Some things should not be allowed by the language, or at least should be harder to do compared to the "right" way. The incentives need to be right. Free-for-all usually means lowest common denominator, and believe me, when it comes to average code quality in your typical "enterprise" code, that denominator is low indeed.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

On Thu, 2019-09-05 at 14:29 -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Sep 05, 2019 at 01:50:03PM -0700, Walter Bright via Digitalmars-d wrote:
> > On 9/5/2019 3:06 AM, Russel Winder wrote:
> [...]
> > > The lesson from Groovy was to actively avoid doing stupid things and to trust programmers not to f### things up. Which they didn't.
> 
> Sorry to say, having worked in the industry for a few decades, I have exactly the opposite sentiment.  Perhaps things aren't that way where you are, and that's good for you.  Where I am, the worst possible code gets written because the language allowed it, and it falls upon my shoulders to fix the inscrutable problems therein long after the original author has moved on to greener pastures.  "Trust the programmer" is an attitude I used to subscribe to, but these days it leaves a bitter taste in my mouth.

I too have worked in the industry for decades, perhaps I just employed good programmers as opposed to crap ones. There is clearly a distribution of ability (a truly complicated concept I agree) as programmers amongst programmers and to be honest most people below the median are really not very good at all. Many can and do get better, far too many just take the money and ignore any notion of personal or organisational betterment.

For the best programmers programming language features are enabling. For the worst programmers the constraints and dictats of programming languages rarely stop them creating truly crap code.

If you cannot trust your programmers then change the programmers or close the organisation.

> 
> > All programmers agree with this sentiment, and create a hellish mess anyway.
> [...]
> 
> Yep.  Especially when there's a deadline and the customer is being unreasonable, and your job is on the line, then anything goes. Unreadable hacks using C macros?  Sure, if it gets the job done before you're fired.  Operator overload abuse? Sure, if it gets the job done before you're fired.  Inscrutable pointer casting hacks?  Oh yes, if it gets the product shipped by the deadline.  Making things easier for the poor sod who'll be maintaining your code a decade later?  That's not even a consideration when the deadline is looming, the customer is demanding, and the project manager is angry.

Isn't this really a description of a crap organisation using crap programmers?

If this is the way software industry is always going to behave maybe the whole thing should be culled and restarted.

> Some things should not be allowed by the language, or at least should be harder to do compared to the "right" way. The incentives need to be right. Free-for-all usually means lowest common denominator, and believe me, when it comes to average code quality in your typical "enterprise" code, that denominator is low indeed.

Clearly the building of abstractions inherently means some restriction on what can be done with the machine. Programming language enshrine this, along with the prejudices of the language developer. The question is all to often are the prejudices of the language designer copeable with by programmers or will they choose another language. Lack of operator overloading in D as is present in C++ and Python still irritates me (it constrains making nice abstraction, which are internal DSLs) but clearly the operator creation of Algol68 and Scala clearly leads to incomprehensible babble very quickly given the way the official examples suggest using it.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 2019-09-05 12:06, Russel Winder wrote:

> As are almost all programming language features. The lesson from Groovy was to
> actively avoid doing stupid things and to trust programmers not to f### things
> up. Which they didn't.

Well, in D you can do a lot of stupid things as well. Different kind of stupid things, like corrupting the memory. But everyone seems to think that is perfectly fine.

-- 
/Jacob Carlborg

On Thursday, 5 September 2019 at 20:21:12 UTC, H. S. Teoh wrote:
> On Thu, Sep 05, 2019 at 07:33:05PM +0000, bachmeier via Digitalmars-d wrote: [...]
>> It's true that Rust does appeal to the sliver of programmers that think memory management is an awesome way to spend Saturday night, but let's let Rust have those users and worry about a good experience for the rest.
>
> +1, couldn't have said it better.  Coming from a C/C++ background, I'm well-versed in all-nighters spent debugging memory management problems, and personally I find D's GC a godsend.  I am *so* much more productive with the GC when performance isn't a big issue, and even when it is, there are ways to control the GC so that it stays out of the bottlenecks in the code.  It isn't as though this is Java where you are *forced* to use the GC, after all.  (In many cases the GC isn't a problem as long as you don't trigger it inside performance-sensitive inner loops.  Cutting out GC from the *entire* application as a knee-jerk reaction is, IMNSHO, premature optimization. Heck, even game engines these days support higher-level scripting in GC'd languages -- you just have to keep the GC out of the core performance sensitive code and it's Good Enough(tm).)
>
>
>> > There's still room in the world for DasBetterC, so I hope the development continues. It's great that many of the annoying restrictions have been lifted.
>> 
>> Exactly. There's no reason to choose between D and betterC because we can have both.
>
> +1.
>
>
> T

There two situations here when it comes memory management. When programming near hardware or OS level stuff you often want to manage your memory yourself. These are often very specialized allocators in order to optimize the usage and fragmentation. Here you deal with the memory management manually anyway. The other side to this are applications where I don't really care about the memory that much, in this case GC is king and that Rust way of manage memory is just annoying at least for my projects. I want to go from A to B as easily as possible and GC is usually the best approach for this. Computers are supposed to work for us, not the other way around.

I think that D have the opportunity to provide both scenarios. Most of the library can be GC but there are exceptions. String manipulations should avoid GC as this is often done in an OS less or real time environment as well. IO should avoid to too, for performance reasons as well.

I also say, keep the GC. Remove the GC where it makes sense. -betterC should continue to evolve and I would actually like to see classes with polymorphism (both GC and manually allocated) with betterC as well.

On 9/5/2019 2:29 PM, H. S. Teoh wrote:
> Yep.  Especially when there's a deadline and the customer is being
> unreasonable, and your job is on the line, then anything goes.
> Unreadable hacks using C macros?  Sure, if it gets the job done before
> you're fired.  Operator overload abuse? Sure, if it gets the job done
> before you're fired.  Inscrutable pointer casting hacks?  Oh yes, if it
> gets the product shipped by the deadline.  Making things easier for the
> poor sod who'll be maintaining your code a decade later?  That's not
> even a consideration when the deadline is looming, the customer is
> demanding, and the project manager is angry.
> 
> Some things should not be allowed by the language, or at least should be
> harder to do compared to the "right" way. The incentives need to be
> right. Free-for-all usually means lowest common denominator, and believe
> me, when it comes to average code quality in your typical "enterprise"
> code, that denominator is low indeed.

I have a slight disagreement with this. Too often the mess is created by programmers who sincerely believe they *are* doing the right thing. They're proud of it. Being able to recognize this unfortunately only comes via a lot of experience.