[OT] What are D's values? (page 6)

Settings

Help

Index » General » [OT] What are D's values? (page 6)

October 06, 2021

Re: [OT] What are D's values?

Posted by Walter Bright
in reply to Steven Schveighoffer

Permalink

Walter Bright

Posted in reply to Steven Schveighoffer

Permalink

We've known about this ambiguity issue for a long time. Unfortunately, we were never able to figure out a solution that would accommodate existing, extensive practice.

I.e. it's a design mistake I made early on that we're stuck with.

October 06, 2021

Re: [OT] What are D's values?

Posted by Tejas
in reply to Guillaume Piolat

Permalink

Tejas

Posted in reply to Guillaume Piolat

Permalink

On Tuesday, 5 October 2021 at 20:12:07 UTC, Guillaume Piolat wrote:

On Monday, 4 October 2021 at 23:10:27 UTC, Tejas wrote:

Even the d-idioms website doesn't have much.

Any text sources would be really appreciated.

Thank you for reading!

The construction of the allocator library in https://www.youtube.com/watch?v=LIb3L4vKZ7U is really quite the lesson.

Also "Functional image processing in D": https://blog.cy.md/2014/03/21/functional-image-processing-in-d/

With all the good thing that can be said about DbI, I don't think it is a defining feature of D. After using ae.utils.graphics for years, I turned 180° and now think generic programming typically get a few problems:

it's a bit remote from problem domains, meaning a bit less readable code, a bit harder to write, a bit longer to compile... in exchange for the expanded capabilities and genericity
the problem of having less specific identifiers
the problem of typically having poor information-hiding. Probably the idea was that the software artifact is so generic, it has to be made public. Leading to too much being public.

So apart from the plasticity that others mention, why do you feel D is better than the alternatives out there for your field of work?

Why do you continue to walk the path less travelled when others enjoy the advantages of mainstream languages like better tooling and greater stability, ie, fewer/no breaking changes with each release(and disadvantages like various janky workarounds for backwards compatibility, deigns/ideological constraints, etc)?

October 07, 2021

Re: [OT] What are D's values?

Posted by bauss
in reply to Walter Bright

Permalink

bauss

Posted in reply to Walter Bright

Permalink

On Wednesday, 6 October 2021 at 22:23:17 UTC, Walter Bright wrote:
> We've known about this ambiguity issue for a long time. Unfortunately, we were never able to figure out a solution that would accommodate existing, extensive practice.
>
> I.e. it's a design mistake I made early on that we're stuck with.

Well D makes up for it with its many other great features :) Tbh. it's a minor thing.

October 07, 2021

Re: [OT] What are D's values?

Posted by Guillaume Piolat
in reply to Tejas

Permalink

Guillaume Piolat

Posted in reply to Tejas

Permalink

On Wednesday, 6 October 2021 at 23:26:14 UTC, Tejas wrote:

So apart from the plasticity that others mention, why do you feel D is better than the alternatives out there for your field of work?

My field is largely dominated by C++. So I'll talk largely about that "obvious" alternative, that is C++.

I happen to have years of commercial experience in both. I feel qualified to have strong opinion in this case. So, what conclusion did I reach afters years of both C++ and D?

First of all:

They are very different universe; you really do live in a different universe when full-time. The culture is completely different.

Secondly:

D lets me do my best work.
C++ makes me very unlikely to do my best work.

But that description does not characterize mainstream C++. It's not at all what you describe once in the trenches.
In reality C++ doesn't compare favorably to D in pretty basic ways.

Tools in C++ are not much better for me (cmake vs dub, what would you really prefer?), build times are usually worse, compilers are also kinda crashy, STL is a lot less usable than Phobos. Would you rather read C++ or D all day long? Honestly.

Different, incompatible syntax to do things in different vendors. You absolutely do more backwards compatibility shenanigans in C++, if only because the standard advance so quickly, and the stdlib are made differently - at different stages of the newest standard.

And C++ is also a bad learning investment for anyone, since you cannot learn C++ as fast as the Standard Comittee makes changes. D changes a lot less and you can learn it in 3x less time. Practionners then get the strangest Stockholm syndrom and take pride in knowing C++ minutiae like if it mattered.

The real question is: why start a green C++ project today instead of D. Apart from: staffing, specific platforms, or legacy I don't think the positives outweight the negatives.

October 07, 2021

Re: [OT] What are D's values?

Posted by Imperatorn
in reply to Guillaume Piolat

Permalink

Imperatorn

Posted in reply to Guillaume Piolat

Permalink

On Thursday, 7 October 2021 at 13:29:34 UTC, Guillaume Piolat wrote:

On Wednesday, 6 October 2021 at 23:26:14 UTC, Tejas wrote:

[...]

My field is largely dominated by C++. So I'll talk largely about that "obvious" alternative, that is C++.

[...]

Interesting. I'm on the fence on if I should pick up C++ again or not.

But the sad truth is that there still is really not an alternative when it comes to embedded, especially not regarding functional safety :´(

But, to use C++ for "normal" stuff seems just like torture. Why do it when you have D or C# or some sane language ;)

October 07, 2021

Re: [OT] What are D's values?

Posted by Paulo Pinto
in reply to Imperatorn

Permalink

Paulo Pinto

Posted in reply to Imperatorn

Permalink

On Thursday, 7 October 2021 at 14:41:26 UTC, Imperatorn wrote:

On Thursday, 7 October 2021 at 13:29:34 UTC, Guillaume Piolat wrote:

On Wednesday, 6 October 2021 at 23:26:14 UTC, Tejas wrote:

[...]

My field is largely dominated by C++. So I'll talk largely about that "obvious" alternative, that is C++.

[...]

Interesting. I'm on the fence on if I should pick up C++ again or not.

But the sad truth is that there still is really not an alternative when it comes to embedded, especially not regarding functional safety :´(

But, to use C++ for "normal" stuff seems just like torture. Why do it when you have D or C# or some sane language ;)

Metal Shading Language, CUDA, working on LLVM or GCC internals, the Android or Windows stuff that only has C++ bindings available, Arduino, ARM mbed, high integrity computing standards like AUTOSAR, macOS drivers, game consoles SDKs, Swift, .NET and Java runtimes,...

There are plenty of places where it would be nice to use something else, but C++ is the name of the game, and adding extra layers to debugging is not getting the buy-in from most folks.

October 07, 2021

Re: [OT] What are D's values?

Posted by H. S. Teoh
in reply to WebFreak001

Permalink

H. S. Teoh

Posted in reply to WebFreak001

Permalink

On Wed, Oct 06, 2021 at 05:47:43AM +0000, WebFreak001 via Digitalmars-d wrote: [...]
> a thing I notice from the C code where I work is that there is a lot of copy paste when things are done in a hurry - a thing that imo happens a lot less with D because of its wide set of compile time features.

I also noticed from the C code at my job that there's a lot of copy-n-paste.  Some of the worst instances include buggy static functions that are copied all over the place, with the bug fixed in some copies but not the others.  IIRC there was even one instance where two different bugfixes were applied to two different copies of the same function, each causing it to behave differently from the other copy. It's an utter maintenance nightmare.

This is why I love the way D lets you eliminate duplicate code and other such boilerplate.  Repetition in code is, as a rule, a code smell that inevitably leads to later maintenance problems.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr

October 07, 2021

Re: [OT] What are D's values?

Posted by H. S. Teoh
in reply to Steven Schveighoffer

Permalink

H. S. Teoh

Posted in reply to Steven Schveighoffer

Permalink

On Wed, Oct 06, 2021 at 11:59:46AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> There is one place where I have struggled though, and D might be able to do better. And that is with optional parentheses and taking the address. When a property can be either an accessor or a field, then `obj.prop` can work the same. However, `&obj.prop` is not the same.
> 
> I have solved it by using this stupid function:
> 
> ```d
> auto ref eval(T)(auto ref T t) { return t; }
> 
> // instead of &obj.prop
> auto ptr = &eval(obj.prop);
> ```

IMO, taking the address of something is a low-level operation that doesn't really belong in higher-level logic.  Unsurprisingly, therefore, it doesn't lend itself well to the malleability that generally applies in D code.

The fact of taking the address of something imposes the implicit assumption that that object has an address to be taken in the first place.  Meaning that once you use such an operation, the target object is no longer Liskov-substitutable with anything else that may not have an address (e.g. an accessor function).  So this imposes limitations on what kinds of refactoring the code will be amenable to.

Generally, I like to think of unary & as something that should only be used in lower-level modules in the code, where it's acceptable to have to rewrite some more code in order to make & work nicely.  For higher-level modules I prefer to stay away from such operations, because they make the code less refactorable.

[...]
> While it's nice D has a mechanism to work around this difference, I find having to use such shims a bit awkward. And it's a direct consequence of hiding the implementation of a field/property behind the same syntax. You can find other cases where D can be awkward (such as `typeof(obj.prop)` or checking types regardless of mutability).
> 
> What is the "better" answer though? I don't know.
[...]

Not necessarily a better answer: static if to discover whether something is a field or an accessor, and extract the address appropriately, possibly encapsulated in a utility function?  Not much different from your .eval hack, though.

The C++ answer is to allow overloading of unary &.  However, that opens up a whole 'nother can o' worms that I would not recommend.

T

-- 
This is not a sentence.

October 07, 2021

Re: [OT] What are D's values?

Posted by Imperatorn
in reply to Paulo Pinto

Permalink

Imperatorn

Posted in reply to Paulo Pinto

Permalink

On Thursday, 7 October 2021 at 17:21:16 UTC, Paulo Pinto wrote:

On Thursday, 7 October 2021 at 14:41:26 UTC, Imperatorn wrote:

[...]

There are plenty of places where it would be nice to use something else, but C++ is the name of the game, and adding extra layers to debugging is not getting the buy-in from most folks.

Yep, that's the unfortunate truth

October 07, 2021

Re: [OT] What are D's values?

Posted by Dukc
in reply to Guillaume Piolat

Permalink

Dukc

Posted in reply to Guillaume Piolat

Permalink

On Thursday, 7 October 2021 at 13:29:34 UTC, Guillaume Piolat wrote:

First of all:

They are very different universe; you really do live in a different universe when full-time. The culture is completely different.

Interesting! How do D and C++ cultures differ?

Wow, are modern C++ compilers crashy when compared to D? I definitely agree that D compilers nowadays are more than stable enough for production, but do they really rival the most common C++ ones? And is this when using recent C++ features or also with older codebases?

To be fair this is probably because all the widely used D compilers have the same frontend. If SDC was in production too it would be a fairer comparison.

More news for me, if you really mean that. C++ does add features fast for such an old language. But changing faster than D, considering they tend to keep the old features around where we deprecate them? Really?

The real question is: why start a green C++ project today instead of D. Apart from: staffing, specific platforms, or legacy I don't think the positives outweight the negatives.

I sign that one (to surprise of none I guess).

Top | Forum index | About this forum

Forums