Jump to page: 1 211  
Page
Thread overview
[OT] What are D's values?
Oct 04
jfondren
Oct 04
russhy
Oct 04
jfondren
Oct 04
russhy
Oct 04
Dukc
Oct 05
Dukc
Oct 04
Tejas
Oct 05
Tejas
Oct 05
Tejas
Oct 05
Tejas
Oct 05
Tejas
Oct 05
Matheus
Oct 05
zjh
Oct 06
Tejas
Oct 07
Dukc
Oct 07
IGotD-
Oct 08
Tejas
Oct 08
IGotD-
Oct 08
bauss
Oct 08
IGotD-
Oct 09
russhy
Oct 09
russhy
Oct 10
Dukc
Oct 10
Dukc
Oct 09
IGotD-
Oct 09
russhy
Oct 08
Tejas
Oct 10
Dukc
Oct 08
Tejas
Oct 05
jfondren
Oct 06
bauss
Oct 07
bauss
Oct 08
Arjan
Oct 11
Arjan
Oct 10
Ki Rill
October 04

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.

October 04

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!

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

[...]

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.

October 04

On Monday, 4 October 2021 at 13:23:40 UTC, 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

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:

>

Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't
I think having the two choices side-by-side just requires programmers to think about making a choice that's irrelevant for their program; not having the choice streamlines the thought process.

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.

October 04

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

>

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:

>

Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't
I think having the two choices side-by-side just requires programmers to think about making a choice that's irrelevant for their program; not having the choice streamlines the thought process.

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.

October 04

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

October 04

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

>

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

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

October 04

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

October 04

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

>

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

>

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

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

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

My game/engine is the perfect example

October 04
On 10/4/21 6:23 AM, Paul Backus wrote:
> In ["Rust and Other Interesting Things"][1], Bryan Cantrill talks about the importance of a programming language's *values*
[...]

> [1]: https://www.youtube.com/watch?v=2wZ1pCpJUIM


This thread is on-topic. :)

As Mike Parker hinted in his report on the past DLang Foundation meeting, I talked to a professional (in a non-professional setting) who works for a branding agency. She told me that the branding process can involve the following steps:

1. Competitor audit - What do e.g. C++ and Rust say about themselves? What do we say? How do we speak? What do we talk about? How do we look?

2. Immersion meetings - What is the difference of D lang? What features are prominent? How is it superior to its competition? What does the audience expect from D lang and the competition? How does or can D lang respond to these expectations?

3. Positioning discussion - What is the purpose of D lang? Who does it target? What does it offer them? The strategy must be determined according to this.

4. Brand identity - messaging (What points should be brought forward when talking about D lang?), voice (How are we going to speak when talking about D lang? Professional? Friendly? Comedic? Expertly? etc), visual (How should D lang be seen? logo, colors, font, images, etc)

Apparently, in general, the first 3 steps take a month and the fourth step takes 2-3 months. Everybody is like us: It is hard to identify what a product actually is and how it can be branded most effectively.

Seeing how involved branding is, to be able to get to a level with our (supposed ;) ) competitors, I think we must work with professionals. We programmers are smart people and I appreciate our efforts to come up with tag lines, logos, web site designs, etc. but our smarts do not necessarily work well for branding.

So, I appreciate this timely thread very much, which should help answer the questions above.

Ali
October 04

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.

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.

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11