On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:
> On 07/07/2016 10:25 PM, Andrew Godfrey wrote:
>> D's "static if" - which is a killer feature if I ignore the keyword -
>> gives me a similar feeling (though it's much less egregious than
>> "return" in monads). "static" is a terribly non-descriptive name because
>> there are so many senses in which a thing could be "dynamic".
>
> You may well be literally the only person on Earth who dislikes the use of "static" in "static if". -- Andrei

Aha! But I don't! It feels intuitive, possibly the best use of "static". But that is immaterial, what matters is the sum of all meanings of "static" in this language. The "single instance per class" meaning of "static" is just bonkers. I've had that meaning burned into my brain for a couple of decades, from C++. But I don't have to like it!
I could stomach it, though, if that was the only use of the keyword. (Or if the other meanings couldn't be used in the same contexts).

On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:
> On 08.07.2016 04:25, Andrew Godfrey wrote:
>>
>> Another example is "return" used for monads in eg Haskell - even if it
>> only has one meaning in Haskell, it is too mixed up with a different
>> meaning in other common languages. D's "static if" - which is a killer
>> feature if I ignore the keyword - gives me a similar feeling (though
>> it's much less egregious than "return" in monads).
>
> 'return' in Haskell is perfectly fine.

This (long) talk does a good job of explaining the problem with using the name 'return' in monads.

https://www.infoq.com/presentations/functional-pros-cons#downloadPdf

Others have said it shorter. I took this example because it crosses languages. Of course we can't avoid clashing with other languages, there are only so many keywords to use. But there's definitely a principle here worth considering, that is if you care about D adoption.

C# vs C++ have an example of a keyword clash too ("volatile" I think?)

On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:

> Aha! But I don't! It feels intuitive, possibly the best use of "static". But that is immaterial, what matters is the sum of all meanings of "static" in this language. The "single instance per class" meaning of "static" is just bonkers. I've had that meaning burned into my brain for a couple of decades, from C++. But I don't have to like it!
> I could stomach it, though, if that was the only use of the keyword. (Or if the other meanings couldn't be used in the same contexts).

The name is fine. It comes from 'statically bound/dispatched', that is 'resolved at compile time'.

On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:
> On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
>> On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
>>> All useful computer languages are unprincipled and complex due to a number of
>>> factors:
>>
>> I think this is a very dangerous assumption. And also not true.
>
> Feel free to post a counterexample. All you need is one!

Scheme.

>> What is true is that it is difficult to gain traction if a language does not
>> look like a copy of a pre-existing and fairly popular language.
>
> I.e. Reason #2:
>
> "what programmers perceive as logical and intuitive is often neither logical nor intuitive to a computer"

I don't understand what you mean by this. If they are programmers they should know the von Neumann architecture. I don't think that is the same as having a strong preference for what they already know...

On 7/9/2016 12:37 AM, Ola Fosheim Grøstad wrote:
> On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:
>> On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
>>> On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
>>>> All useful computer languages are unprincipled and complex due to a number of
>>>> factors:
>>>
>>> I think this is a very dangerous assumption. And also not true.
>>
>> Feel free to post a counterexample. All you need is one!
>
> Scheme.

I know little about Scheme, so I googled it.

  https://en.wikipedia.org/wiki/Scheme_(programming_language)

And the money shot:

"The elegant, minimalist design has made Scheme a popular target for language designers, hobbyists, and educators, and because of its small size, that of a typical interpreter, it is also a popular choice for embedded systems and scripting. This has resulted in scores of implementations, most of which differ from each other so much that porting programs from one implementation to another is quite difficult, and the small size of the standard language means that writing a useful program of any great complexity in standard, portable Scheme is almost impossible."

Seems that in order to make it useful, users had to extend it. This doesn't fit the criteria.

Wirth's Pascal had the same problem. He invented an elegant, simple, consistent, and useless language. The usable Pascal systems all had a boatload of dirty, incompatible extensions.


>>> What is true is that it is difficult to gain traction if a language does not
>>> look like a copy of a pre-existing and fairly popular language.
>>
>> I.e. Reason #2:
>>
>> "what programmers perceive as logical and intuitive is often neither logical
>> nor intuitive to a computer"
>
> I don't understand what you mean by this.

What programmers think of as "intuitive" is often a collection of special cases.

On Friday, 8 July 2016 at 20:57:39 UTC, Walter Bright wrote:
> On 7/7/2016 7:25 PM, Andrew Godfrey wrote:
>> "static" is a terribly non-descriptive name
>
> That's why it's the go-to keyword for any functionality we can't think of a good name for, or if the name would be too long such as "launch_nucular_missiles".

For a moment I thought Walter was being comical.  But then I looked
at the Index in TDPL, and I see static class constructor, static class
destructor, static if, static import, static this, and just plain static.

Also, Andrei, if you're listening, I've spotted another TDPL errata.
On page 459, the Index entry for "static, obligatory joke about overuse
of" lists page 345, but in fact the joke is in the footnote at the bottom
of page 68.

As for me, the main thing I dislike about static if is that it blends in
visually a bit too well with run-time code segments.  C's #if structure
has its own problems, but I like the distinctiveness.

An earlier comment about wanting a different name got me to thinking.
For naming variables, I own two copies of a high-quality thesaurus.
One copy I keep at work, one copy I keep at home.  It's invaluable when
you get stuck at naming things.  Why not apply that same tool to naming
keywords as well?  So I looked.  I didn't see anything precisely on
target; maybe these come closest:

    constant if
    durable if
    persistent if
    adamant if
    unalterable if
    immutable if

Okay, that last one is a joke, considering that we're talking about
keyword overloading.  But the effort did spark some other brain cells
to fire.  So we could have had any of these:

    exactly if
    strictly if
    only if

I do like the creative use of an adverb instead of an adjective in these
choices; the code reads like standard English instead of a clunky made-up
phrase.  I also especially like the briefness and precision of "only if",
and that may become my favorite way to think about this in the future.
(Is there some way I can "#define only static" to get this effect?)
In fact, it is presaged on page 48 of TDPL, from whence I quote:  "the
basic plot is simple -- static if evaluates a compile-time expression and
compiles the controlled statement only if the expression is true".  So you
the language designers had the idea in hand, but then sadly overlooked it.

On 7/9/2016 1:57 AM, Observer wrote:
> As for me, the main thing I dislike about static if is that it blends in
> visually a bit too well with run-time code segments.  C's #if structure
> has its own problems, but I like the distinctiveness.

Ironically, "static if" has entered the C++ lexicon from D.

On Saturday, 9 July 2016 at 08:57:18 UTC, Observer wrote:
>     constant if
>     durable if
>     persistent if
>     adamant if
>     unalterable if
>     immutable if
>
> Okay, that last one is a joke, considering that we're talking about keyword overloading. But the effort did spark some other brain cells to fire. So we could have had any of these:
>
>     exactly if
>     strictly if
>     only if

I'm sorry, but these examples are horrible, except maybe "constant if", because none give a clue about compile-time and they are not even synonyms. The last three are just plain nonsense, especially "strictly if" which implies that ordinary "if" is somehow not reliable. You didn't even think about it, just picked the words from a book.

"static if" is perfectly fine, if you just try to imagine what in "if" could be dynamic, because the only meaningful answer is: "The condition". If there is a context where "static" really needs to be replaced by a synonym, it's definitely not "static if".

On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
> All useful computer languages are unprincipled and complex due to a number of factors:
>
> 1. the underlying computer is unprincipled and complex (well known issues with integer and floating point arithmetic)
>
> 2. what programmers perceive as logical and intuitive is often neither logical nor intuitive to a computer (even Haskell has wackadoodle features to cater to illogical programmers)
>
> 3. what the language needs to do changes over time - the programming world is hardly static
>
> 4. new features tend to be added as adaptations of existing features (much like how evolution works)
>
> 5. new features have to be worked in without excessively breaking legacy compatibility
>
> 6. no language is conceived of as a whole and then implemented
>
> 7. the language designers are idiots and make mistakes
>
>
> Of course, we try to minimize (7), but 1..6 are inevitable.

Letting consequences of those just happen is like a being a sailor and happily going the wrong way when the wind is not perfect. There are techniques both from the project management point of view and from language design point of view that can be applied to minimize and prevent those effects and aren't applied.

So, some examples:

About 6, 3 and 4. There's a thing called the MVP (minimal viable product) approach. You implement the minimally useful bare bones and leave as much wiggle room as possible for future changes. This doesn't need to be applied to the whole language, it can be applied per feature as well. Yes, you can't predict the future, that's not an excuse for not preparing for it and for possible change. When you're happy with the MVP you can accept it and do more experimentation with the knowledge you got from doing the MVP. See also: agile methodologies.

About 2 and 7. Some positive changes happen here, still listing possible solutions won't hurt. Have more peer review. Release more often, so people won't be bothered if their feature won't make it (it's weird that Andrei worked at facebook, yet he doesn't push for faster, less feature heavy releases). Release new features under feature gates (like -dip25 and std.experimetal), don't stabilize until people provide feedback and are happy with the result (yes there's an issue with people not testing the feature because of small D adoption - don't include the feature for it's own sake if people can't be bothered to test it). We're all idiots - so we need to experiment before we commit to something.

About 4 and 5. Those are partially combated by the MVP approach mentioned earlier- leaving as much as possible flexibility for as long as possible, so you can make decisions when you have the most information(i.e. as late as possible).

Another way to combat this is to build language from independent parts that can be composed together. As an example of this done right: concrete code, templating mechanisms and conditional compilation are all independent parts of the language that can be put together, so the effective number of features is a cross product of those 3. Deadalnix gave some examples of that done wrong in this thread - as he's implementing a D compiler from scratch he can see the unorthogonal parts easily. SDC is probably worth looking into. With independent features it's much easier to keep the feature set adaptable.

Another language design trick is to look at the whole language and try to hit as many birds as possible with as few (but not too few) stones as possible. There are numerous cases of problems being solved using different means each time a problem comes up. Look for a way to merge these categories of solutions into something coherent and deprecate the old mess. You don't have to drop the old ways, but new users will be glad to have a simpler model to learn, as old "special" solutions can be defined in terms of the new one. Do you really need pragmas, special variables and special constants when you could have nice namespaced intrinsics modules defined with existing and understood language rules? Do you need alias this when you could have opImplicitCast returning ref?

I didn't just make those up, there are languages which do all of those and more and they work within the same domain as D.

On Saturday, 9 July 2016 at 11:49:49 UTC, burjui wrote:
> I'm sorry, but these examples are horrible, except maybe "constant if", because none give a clue about compile-time and they are not even synonyms. ... You didn't even think about it, just picked the words from a book.

It's a process.  One comes up with an idea, mulls it over, tries
it out, evaluates, revises.  I'm not saying that any one of these
choices is definitely better.  What I'm saying is that someone
claimed earlier that "static" wasn't a good choice, but gave no
examples of possible alternatives, or how to find one.  The point
is, an attempt to follow a process that often yields good results
for variable naming seems to not give great results in this case,
which I suppose argues for the status quo.