In "Rust and Other Interesting Things", Bryan Cantrill talks about the importance of a programming language's values.

Values, he says, are the things a language prioritizes--the things it chooses when difficult tradeoffs have to be made. For example: everyone agrees that both "safety" and "performance" are valuable, but when forced to choose, some languages (Java, Python) are willing to trade away some performance for additional safety, whereas others (C, C++) would rather give up safety to gain performance.

When we're choosing a programming language, Cantrill tells us, choosing one with the right values is just as important as choosing one with the right features and ecosystem--because values are what determine how those features and ecosystem will develop over time.

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

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!

I've put my answer below, encoded using ROT13. Try to come up with your own answer before you read mine, to avoid biasing yourself.

V guvax Q'f svir zbfg vzcbegnag inyhrf ner

• Nccebnpunovyvgl - obgu Q'f flagnk naq ynathntr srngherf ner qrfvtarq gb or snzvyvne gb hfref bs bgure cbchyne ynathntrf (r.t., P, Wnin, Clguba, Wninfpevcg). gbhe.qynat.bet zragvbaf n "tenqhny yrneavat pheir" nf na rkcyvpvg qrfvta tbny.

• Rkcerffvirarff - jvgu srngherf yvxr grzcyngrf, zvkvaf, naq bcrengbe bireybnqvat (vapyhqvat bcQvfcngpu), Q vf bar bs gur zbfg rkcerffvir ynathntrf guvf fvqr bs Yvfc.

• Fnsrgl - abg whfg @fnsr, ohg nyfb qrsnhyg vavgvnyvmngvba bs inevnoyrf, obhaqf-purpxvat sbe neenlf, rkprcgvbaf sbe reebe unaqyvat, naq ybgf bs bgure yvggyr qrpvfvbaf.

• Cresbeznapr - angvir pbzcvyngvba, bs pbhefr, cyhf ybj-yriry srngherf yvxr enj cbvagref, vayvar nfz, naq ohvyg-va FVZQ bcrengvbaf.

• Vagrebcrenovyvgl - abg bayl qbrf Q unir orfg-va-pynff P vagrebc, naq gur qvfgvapgvba bs orvat bar bs gur bayl ynathntrf gb rira nggrzcg P++ vagrebc, vg nyfb unf fhccbeg sbe Bowrpgvir-P pynffrf naq PBZ vagresnprf.

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

I have thought about it and think (ROT13):

1. Vagrebcrenovyvgl - Q chgf znwbe rssbeg vagb orvat pbzcngvoyr jvgu bgure ynathntrf naq rkvfgvat P pbqr
2. Fnsrgl - vg unf n ybg bs sbphf ba fnsrgl ol pbeerpgarff
3. Irybpvgl - orvat cebqhpgvir naq pbqvat pbqr snfgre vf n ovt cneg bs Q'f punez
4. Rkcerffvirarff - Q pbqr pna ryrtnagyl ercerfrag n ybg bs ceboyrzf va fubeg, rnfl-gb-ernq pbqr
5. Cresbeznapr - Qrfvta bs fghss yvxr enatrf naq znal fgqyvo hgvyf srryf yvxr gurl ner rfcrpvnyyl znqr sbe trarengvat cresrpg pbqr yvxr vg'f unaqjevggra naq jvgu gung tbbq cresbeznapr

V unq lbhe svefg cbvag nf zl 6gu pubvpr, ohg qvqa'g guvax vg jnf gung ovt bs n qrfvta tbny, orpnhfr vg'f whfg nobhg snzvyvnevgl naq abg nobhg nccebnpunovyvgl sbe arjpbzref ernyyl.

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

Approachability   Integrity        Robustness
Availability      Maintainability  Safety
Compatibility     Measurability    Security
Composability     Operability      Simplicity
Debuggability     Performance      Stability
Expressiveness    Portability      Thoroughness
Extensibility     Resiliency       Transparency
Interoperability  Rigor            Velocity

The explanation for why a language might have X as its #1 value but then fall short on X will be that the language is pulled back from full-X by its other values. Someone might argue that Python values Expressiveness, but that its other value of Approachability keeps it from having proper closures.

But the actual reason that Python doesn't have proper closures is that Guido thinks they're weird and confusing:

Does a competing value keep Go from permitting an unused module import? When I looked at this and other quirks of go the language seemed to me like the product of Rob Pike deciding that he's had well enough of some specifically unpleasant experiences with code and was just going to make a language where they aren't possible. (I think he could list the names of coworkers next to features of the language. "And I told Jim, 'if I see any go from you it's going to be go without your habit of importing the entire world. You know how I know that?'")

Does a competing value keep D from supporting boolean expressions in version() tests, or keep D from having AST macros? It's rather that Walter is familiar with the hazards in those directions and wants to stay away from them.

So I don't think listing values is enough to describe a language's development. There's also the hazards that the language developers are especially concerned with. D probably has lots of design decisions that can be explained by "we're avoiding this bad outcome of C++". The other day on the discord it was mentioned that C++ will implicitly create a struct as a function parameter but that D doesn't because C++ does that way too much in practice. You could twist this specific antipathy into a value like 'Transparency', but that doesn't explain the design as neatly.

And it's not as entertaining to read about. "D has BetterC because we value Interoperability, and because we don't value Integrity that much." is less interesting than "just look at this madness that snuck into dmd when I permitted boolean versions:". Both imagined quotes.

On Monday, 4 October 2021 at 14:30:20 UTC, jfondren wrote:

I would say that it is overly reductive to insist that there is only one "actual reason" behind any given decision. Most outcomes have many causes, direct and indirect.

The direct, stated reason for Python's lack of closures is that Guido thinks they're weird and confusing. But are other, indirect reasons implied by his argument, like "Python shouldn't have language features that most users are unfamiliar with", and "Python shouldn't have two ways to do the same thing".

These indirect reasons are, more or less, expressions of values like Approachability and Simplicity.

Obviously you cannot completely reduce a language's development process down to a list of values--that would be ridiculous. But it does help to be aware of them.

With D is get insanely quick iteration time, my project rebuilds in 0.7 seconds (full clean rebuild)

None of the existing natively compiled language can offer this, NONE!!

This is something people forget to mention, but this is very valuable

On 10/4/21 1:13 PM, russhy wrote:

As you add more templates and CTFE, this quickly goes away though.

You have to be very religious about what templates you use in order to keep this compile time.

-Steve

On Monday, 4 October 2021 at 18:03:58 UTC, Steven Schveighoffer wrote:

A sad truth about D. Hopefully core.reflect will help alleviate some of these issues in the long run.

Also, I believe the person you're responding to is a pure -betterC user (or along those lines? he can correct me if not), so likely don't touch Phobos' templates all too much, which tend to be real time slogs.

On Monday, 4 October 2021 at 18:03:58 UTC, Steven Schveighoffer wrote:

You don't need to abuse any of them to build nice program

My game/engine is the perfect example

On Monday, 4 October 2021 at 18:23:24 UTC, SealabJaster wrote:

You can have a shockingly fast compiler if you want it. You can have fully manual memory with RAII and shared/unique pointers if you want them. You can have code that looks like a scripting language and relies heavily on the GC if you want it. You can have code that looks like it's in an FP language if you want it. You can have monadic error handling if you want it a lot. You can have borrow-checked pointers if you want them.

But you can't have it all at once. Not in D, where sublanguages containing each of these features is available, and not in any other language, where some features aren't available and others are inescapable.

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".

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