October 04, 2021

On Monday, 4 October 2021 at 13:23:40 UTC, Paul Backus wrote:

>

I thought it might be fun to ask the D community: which of the above values do you think are the most important to D? Choose no more than 5, and reply with your answer!

enum msg =
"CkkgdGhpbmsgaXQncyAoaW4gbm8gcGFydGljdWxhciBvcmRlcikgY29tcG9zYWJpbGl0eSwgaW50ZX"
~"JvcGVyYWJpbGl0eSwgc2FmZXR5CmFuZCBwZXJmb3JtYW5jZS4gU2FmZXR5IGFuZCBwZXJmb3JtYW5"
~"jZSBhcmUgaW1wb3J0YW50IHRoZSBzYW1lIHdheSBhcyB0aGV5IGFyZSB0bwpSdXN0LCBidXQgY29t"
~"cG9zYWJpbGl0eSBhbmQgaW50ZXJvcGVyYWJpbGl0eSBhcmUgd2hlcmUgd2UgZGlmZmVyIGZyb20gd"
~"Ghlbi4KCkQgdHJpZXMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIGFzIG1hbnkgbGFuZ3VhZ2VzIGFzIH"
~"Bvc3NpYmxlLCBoZW5jZQppbnRlcm9wZXJhYmlsaXR5LiBJbiBBdGlsYSdzIHdvcmRzLCBpdCBhaW1"
~"zIHRvIGJlIHRoZSBkZWZhdWx0IGltcGxlbWVudGF0aW9uCmxhbmd1YWdlLiBJdCBhbHNvIHRyaWVz"
~"IHRvIGF2b2lkIHJlaW52ZW50aW5nIHRoZSBzeW50YXggbW9yZSB0aGFuIFJ1c3QgZG9lcy4KCkFuZ"
~"CBJIHRoaW5rIEQgYWxzbyBmb2xsb3dzIHRoZSBVbml4IHBoaWxvc29waHkgb2YgY29tcG9zYWJpbG"
~"l0eSB0byBhIGhpZ2gKZGVncmVlLiBJdCdzIGRlc2lnbmVkIGVxdWFsbHkgZm9yIHN5c3RlbXMgcHJ"
~"vZ3JhbW1pbmcsIGFwcGxpY2F0aW9uIHByb2dyYW1taW5nCmFuZCBzY3JpcHRpbmcsIGFuZCBpcyB0"
~"b3RhbGx5IG11bHRpLXBhcmFkaWdtLgo="
;

void main()
{ import std.stdio;
  import std.base64;

  writeln(cast(char[])Base64.decode(msg));
}
October 04, 2021
On 10/4/21 1:24 PM, Dukc wrote:
> On Monday, 4 October 2021 at 13:23:40 UTC, Paul Backus wrote:
> 
>> I thought it might be fun to ask the D community: **which of the above values do you think are the most important to D? Choose no more than 5, and reply with your answer!**
> 
> ```d
[snip]
> ```

This message was a reference type containing protected values.
October 04, 2021

On Monday, 4 October 2021 at 19:35:08 UTC, jfondren wrote:

>

...

Definitely a more fun way to look at things :)

However trying to get things like this across to people who don't really use D would be tricky.

"Why choose D over Python for quick scripts?"

"Why choose D over C/C++ for low level code, also something something GC"

"Why choose D over Go or Java or even Javascript for backend web dev?"

Low level code in particular can be a bit annoying, since D doesn't provide standard collections and lifetime containers for a decent 'get stuff done' @nogc experience, but I've ranted about that enough. This is mainly a major issue to me from a library perspective, since libraries don't have a singular interface to rally around.

I really wish I could use D everywhere, but I sometimes I just feel more comfortable in say, C# for backend servers due to the excellent Asp Core and EF Core. Standard configuration interface, standard logging interface, standard dependency injection, which all the other libraries I want will integrate with flawlessly(tm).

Since D can technically cover most major aspects of programming, coming up with an answer of these "why" questions, especially when performing comparisons to other languages, is pretty hard due to the broad surface area to cover.

Also something something libraries >;3

I definitely do wonder what D would look like with an "insert popular language" user base, from discussions, to ecosystem, and certainly the pain points and pros that people find with the language.

But "why" use D? "What" do we offer language wise, ecosystem wise, etc.

I feel the "ecosystem" part is the larger part to focus on IMO.

We can boast all we want about great native performance; some of the strongest metaprogramming available, all with an easy and clean syntax. But if people can't just 'get things done' then the friction of setting up/writing/creating a binding for the code they need might be too much, so they leave for a different language with everything they need all ready to go, all integrated together, etc.

But enough rambling, I'm not even close to an expert on these subjects >:D

Anyway, as an attempt to stay on topic, my values from that selection are:

  1. Performance
  2. Interoperability
  3. Robustness
  4. Extensibility++++
  5. Expressiveness
October 04, 2021
On 10/4/2021 6:23 AM, Paul Backus wrote:
> One slide in his presentation contains a list of things that a programming language might value:
> 
>      Approachability   Integrity        Robustness
>      Availability      Maintainability  Safety
>      Compatibility     Measurability    Security
>      Composability     Operability      Simplicity
>      Debuggability     Performance      Stability
>      Expressiveness    Portability      Thoroughness
>      Extensibility     Resiliency       Transparency
>      Interoperability  Rigor            Velocity

Interestingly, left off is one thing that D does very well at: plasticity. What do I mean by that?

I've been developing code for a loooong time. I've noticed a couple long term trends with C and C++ code. One is brittleness.

This manifests itself in the strange characteristic that no matter how many years I work on a piece of code, the very first organization of it and the structure of it never fundamentally changes. Oh, I endlessly tweak it and optimize it and enhance it, but it's still the original design under the hood.

I.e. it is brittle.

With D code, however, I've found it to be far easier to change the design. Optimization becomes not so much sweating the details, but lowered barriers to trying out different designs to see what works better. I did this extensively on the Warp preprocessor project.

I discovered a key component of this is D's use of . instead of ->. One can easily test drive with classes, structs, pointers, and values, interchanging them as one would try on a shirt. It's such a frackin' nuisance to do that in C and C++, one just doesn't bother.

This is plasticity, the opposite of brittleness.

What are your experiences with this?
October 04, 2021
On Monday, 4 October 2021 at 22:15:33 UTC, Walter Bright wrote:
> What are your experiences with this?

I find code that does Design by Introspection tends to be very resilient to additions, modifications, and removals.

For example, I have a library that makes heavy use of introspection, and I completely changed the way the introspection was being handled without having to touch the way the user code was designed.

This was done without breakage (well... there was one break due to a language limitation), and with very minor behavioral differences. It was definitely quite magical.

Adding things is as simple as making a new UDA, slapping in some glue code for the introspect layer, and then applying it where relevant.

Modifications don't really break anything unless the UDA itself is changed.

Removals technically don't break much since the user part of the code is just ignored and non-functional now.

DbI can be pretty awesome.
October 04, 2021

On Monday, 4 October 2021 at 23:01:31 UTC, SealabJaster wrote:

>

On Monday, 4 October 2021 at 22:15:33 UTC, Walter Bright wrote:

>

What are your experiences with this?

I find code that does Design by Introspection tends to be very resilient to additions, modifications, and removals.

For example, I have a library that makes heavy use of introspection, and I completely changed the way the introspection was being handled without having to touch the way the user code was designed.

This was done without breakage (well... there was one break due to a language limitation), and with very minor behavioral differences. It was definitely quite magical.

Adding things is as simple as making a new UDA, slapping in some glue code for the introspect layer, and then applying it where relevant.

Modifications don't really break anything unless the UDA itself is changed.

Removals technically don't break much since the user part of the code is just ignored and non-functional now.

DbI can be pretty awesome.

Can you please list any resources on DbI?

I've been finding it pretty hard to grasp, and I only managed to find a few videos by Andrei on the subject.

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

Any text sources would be really appreciated.

Thank you for reading!

October 04, 2021
On Mon, Oct 04, 2021 at 07:35:08PM +0000, jfondren via Digitalmars-d wrote:
> On Monday, 4 October 2021 at 18:23:24 UTC, SealabJaster wrote:
> > On Monday, 4 October 2021 at 18:03:58 UTC, Steven Schveighoffer wrote:
> > > You have to be very religious about what templates you use in order to keep this compile time.
> > 
> > A sad truth about D.

To be fair, though, even with extensive template use, compile times generally aren't horrible, unless you happen to use code that abuses recursive templates (e.g., certain Phobos modules like std.format, or (ack) std.regex, where the mere act of importing it adds about 1-2 seconds to your compile time).  For simple metaprogramming with templates, compile-times are generally still within the realm of <5 seconds or so, which is still magnitudes faster than any non-trivial C++ project I've ever had to deal with.


[...]
> For branding, put a smiley face on this instead of calling it a sad truth.  Need to write a tiny static executable to do a single thing fast using low-level OS APIs so that it can achieve paranoid security for the sake of Perl or Python or bash scripts that call this program? Good candidate for BetterC. Want to write a near-throwaway script? Good candidate for 'import std' and tons of allocation. Want to write a daemon to replace a golang server that's too resource intensive? Better candidate for scoped imports and careful design with @nogc and nothrow helping you control where work is happening.
> 
> All that with the 'same' language, rather than "oh I'll use C", "oh I'll use Python", "oh now I can finally use my systems language".

+1, D is so versatile that it easily lends itself to all these diverse use cases.  Sometimes it can even adapt itself across these use cases, e.g., a number of my personal projects started out as throwaway single-file, script-like hacks, but eventually developed into full-fledged multi-module, multi-package programs.  If I had done this in any other language, it'd have involved rewriting the program from scratch at least 3-4 times.  With D, it can gradually and smoothly morph itself from a one-off script into a full-fledged, properly-encapsulated program without missing a beat.

Man, I love D.


> Of course I still want faster compilation of std.regex.

:-D


T

-- 
Кто везде - тот нигде.
October 04, 2021
On Monday, 4 October 2021 at 22:15:33 UTC, Walter Bright wrote:
> Interestingly, left off is one thing that D does very well at: plasticity. What do I mean by that?
>
> I've been developing code for a loooong time. I've noticed a couple long term trends with C and C++ code. One is brittleness.
>
> This manifests itself in the strange characteristic that no matter how many years I work on a piece of code, the very first organization of it and the structure of it never fundamentally changes. Oh, I endlessly tweak it and optimize it and enhance it, but it's still the original design under the hood.
>
> I.e. it is brittle.
>
> With D code, however, I've found it to be far easier to change the design. Optimization becomes not so much sweating the details, but lowered barriers to trying out different designs to see what works better. I did this extensively on the Warp preprocessor project.
>
> I discovered a key component of this is D's use of . instead of ->. One can easily test drive with classes, structs, pointers, and values, interchanging them as one would try on a shirt. It's such a frackin' nuisance to do that in C and C++, one just doesn't bother.
>
> This is plasticity, the opposite of brittleness.
>
> What are your experiences with this?

I've experienced this too.

In D, with a little ingenuity, it is possible to make almost any surface-level syntax "desugar" to almost anything you want. Which means that when you want to change how some part of your program is implemented, you can almost always keep the original syntactic "interface" stable while doing so.

There are a lot of little language features that add up to make this possible. Implicit pointer dereferencing (as you mention), UFCS, optional parentheses, IFTI, operator overloading...probably some more that I'm forgetting.

I think this "plasticity" is probably closely related to "expressiveness", because the language features that contribute to one tend to also contribute to the other. Depending on how you interpret "expressiveness", they might even be the same thing (something like, "number of possible 'implementations' for a given piece of syntax").
October 04, 2021

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

>

...

I'm not actually too sure about anything specifically on DbI.

Anything to do with using UDAs would be pretty close:

  1. http://ddili.org/ders/d.en/uda.html
  2. https://bradley.chatha.dev/blog/dlang-json-serialiser-5 (is part of a multi-part blog series, so might be hard to follow by itself)

You've motivated me to add a bit about DbI onto my upcoming DConf talk (assuming it's not too late for me to make changes)! So hopefully that'll be a bit of help as well.

Generally a pairing of static if, static foreach, and anything to do with __traits is what I'd define as DbI.

October 04, 2021
On 10/4/21 4:16 PM, H. S. Teoh wrote:

> a number of my personal projects started out as throwaway
> single-file, script-like hacks, but eventually developed into
> full-fledged multi-module, multi-package programs.

That comes up often. (Fresh case: One of my colleagues who had to adopt D programs I had written, tells me he is finding it very easy to morph the code.)

Perhaps we should sell D's "morphability", likely with a better marketing name.

> Man, I love D.

You said it right after talking about being able to morph D code. :) I have the same feeling: I secretly wish my colleagues will come up with new requirements so that I will write more fun D code.

An anecdote from a past project: A hardware colleague of mine once asked "How come when I ask HW engineers to improve the HW design, they go right ahead and start implementing it but SW people always whine and want to keep the SW design as is?" (The programming languages were C and C++ at that time.)

Ali