On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff wrote:
>> "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*

Depends on the parser-tech. Modern parsers (GLR?) can handle complex grammars. In D template syntax looks like it has been added as an afterthought.

> I haven't found the !() syntax for D templates to be a problem though and prefer it to <> from C++ and Java. If I were searching for D blemishes, I wouldn't look there first.

I am not talking about it "being a problem", but about not being user-friendly when you are faced with unknown code where you do not know the symbols, it will slow you down.  "<>" is much more visually distinct, but I know the reasoning of keeping the parser simple. I just disagree with the solution. It is not  as comprehensible as it should be.

I also think D goes a bit too far in reusing symbols/keywords in general, sacrificing reader comprehension (reading speed). The grammar is not as clean as it should be for a new language IMHO. It has unnecessary clutter and lacks some visual cognitive support (for a clumsy human, not a compiler). It isn't worse than C++ though, but C++ is in whole an afterthought put in cement by the original c-front.

O.

On Saturday, 14 December 2013 at 20:37:21 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff wrote:
>>> "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*
>
> Depends on the parser-tech. Modern parsers (GLR?) can handle complex grammars. In D template syntax looks like it has been added as an afterthought.

I'm kind of taking this as "I don't know of any specific better alternative, but I'm not 100% satisfied in this and we have awesome technology, so a better solution must exist". I don't really know how else to interpret that.

On Saturday, 14 December 2013 at 20:37:21 UTC, Ola Fosheim Grøstad wrote:
> I am not talking about it "being a problem", but about not being user-friendly when you are faced with unknown code where you do not know the symbols, it will slow you down.  "<>" is much more visually distinct, but I know the reasoning of keeping the parser simple. I just disagree with the solution. It is not  as comprehensible as it should be.

Also, I'm not sure I agree with any of this. You are minimally required to have some understanding of what symbols mean to use any programming language (Who would guess that blah<int> is a template instantiation in C++ or generic in other languages without being familiar with what <>s mean in that context?). Plus, even if your point is "just don't know that one symbol but don't want to spend time learning it", still, I've shown some D code to someone who actually didn't know D code but they fully understood and comprehended what "memoize!myFunc(a)" did despite not understanding the intricacies of its implementation.

> Also, I'm not sure I agree with any of this. You are minimally required to have some understanding of what symbols mean to use any programming language (Who would guess that blah<int> is a

No, if you have strong distinct visual cues the brain does not have to reason but you will use the pattern-recognition that your brain supports for classifying visual cues in our natural environment. The moment you have to think about what an identifier means you have started to strain the brain. You are being slowed down and will become more tired and make more mistakes because you can only "juggle" a limited set of symbols/challenges at the same time.

Basically if you should visually "feel" that something is an array etc. "int" is so common so that symbol is not read but instantly recognised. Colours in an editor might also help. Layout helps. Redundant cues help.  The basic goal should be that the logical structure of the program should be available as visual patterns that can be directly detected without reasoning, not as indirection (like names with no visual cues) that requires interpretation and conscious cognitive effort.

Ola.

On Saturday, 14 December 2013 at 21:47:52 UTC, Ola Fosheim Grøstad wrote:
> No, if you have strong distinct visual cues the brain does not have to reason but you will use the pattern-recognition that your brain supports for classifying visual cues in our natural environment. The moment you have to think about what an identifier means you have started to strain the brain. You are being slowed down and will become more tired and make more mistakes because you can only "juggle" a limited set of symbols/challenges at the same time.
>
> Basically if you should visually "feel" that something is an array etc. "int" is so common so that symbol is not read but instantly recognised. Colours in an editor might also help. Layout helps. Redundant cues help.  The basic goal should be that the logical structure of the program should be available as visual patterns that can be directly detected without reasoning, not as indirection (like names with no visual cues) that requires interpretation and conscious cognitive effort.

FWIW, I understand some what you're saying. I get your point that it'd be nice if some visual cue existed that made it obvious that it was a template instantiation without learning the meaning. What I don't understand is why you think that such a thing must exist. I suspect such a thing doesn't exist, but I, obviously, cannot prove that. Again, I'd love to see your idea of the syntax you're describing.

From my perspective, I think that the "transparent instant recognition" thing you describe is learned. It's not unreasonable to require someone to learn the new syntax and now that I'm comfortable with D, infix !s (which are actually very distinct from prefix !s) give me the exact same visual feeling you're saying they should. I suspect you'd get comfortable with it over time as well. You should realize that your brain is far more powerful than you're giving it credit for. It's specifically designed to adapt over time to the environment and the pattern-recognition your brain has is more than capable of adapting to distinguishing the difference between an infix ! and a prefix !.

That said, I'm not suggesting the syntax is perfect. I'd _still_ like to hear your ideas for better syntaxes ...

On Saturday, 14 December 2013 at 20:00:30 UTC, Brian Rogoff wrote:
> Composite brackets, a-la the SPECS 'C++ Resyntaxed' ** proposal, would work. <[]>, <[<[]>]> may be a bit heavy but not too bad.
>
> I haven't found the !() syntax for D templates to be a problem though and prefer it to <> from C++ and Java. If I were searching for D blemishes, I wouldn't look there first.
>
> -- Brian
>
> ** http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html

I'd like to note that I _loved_ that paper the first time I read it. I actually saved it to my Dropbox to refer back to if I ever decided to write my own language. But composite brackets honestly seem a bit too heavy, like you said. When I saw D's usage of an infix !, I was more intrigued. Especially after the ()s were made optional when the template instantiation was a single token long. Very convenient to type and, more importantly, read IMO.

On 12/14/13 11:46 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Saturday, 14 December 2013 at 18:46:50 UTC, Joseph Rushton Wakeling
> wrote:
>> Very curious about what you mean here -- I think most of us find that
>> D's template syntax is much superior to C++, so I'd really like to
>> understand what you find problematic.
>
> I dislike the syntax. :-)

It should be mentioned that years ago I proposed using '.' instead of '!' for templates. Walter actually gave me a patched compiler that I used for a few weeks.

The code didn't look much better, but one important simplification did result from that push: we eliminated parens wherever only one argument was involved. That turned out to be a good thing.

> And well, as far as I can tell I also dislike
> the semantics, but it is no worse than C++. I would like to see a modern
> language with templates to do it well. That is to be more in the
> direction of readable term-rewriting, pattern-matching with constraints
> that will make it possible to do clean operator-overloading etc.  More
> in the direction of legible Pure, Haskell etc.

This is vague, and as many cool while vague things, may turn out to be less attractive when the details are worked out. In particular "clean operator-overloading" has been discussed in this group as a distinct non-goal and potential anti-pattern if taken too far.

>> I don't think things are actually as spread out as you think. In
>> reality, there is one compiler frontend that everyone collaborates on.
>
> You could be right, I am only talking about the impression I am getting.

Well he is factually right. And facts are prone to changing impressions.

> "The smoke-signals being received from a distance". When you don't have
> one excellent compiler, but three in-the-works, it sends signals of a
> lack of direction and implies a lack of a leader that can rally everyone
> into something cohesive. This is not a critique of anyone, most
> programmers want to be creative and argumentative, not to "nurture",
> "manipulate" and "wave the whip" ( I am not even sure I like people who
> are "great leaders" ;^).

One lone compiler that everybody hangs on for dear life would be a distinctly bad place to be. A mishmash of a dozen alpha-state compilers would be just as bad. Three compilers that share the core language and complement it with distinct backends is quite the sweet spot to be in. I had no idea one could frame it as a bad thing.

>> I think it might be worth giving things another spin.  If the last
>> time you tried using D was a couple of years ago, you will find that
>> things have changed a great deal in terms of performance, features and
>> general quality.
>
> Let me rephrase what I am perceiving like this: for me D is currently a
> solution without a problem.

[snip]

> Do you think I am unfair?

Fairness has little to do with it. By and large I'd say, if you don't have a problem for which D is the best or at least a advantageous solution, it's entirely reasonable to not reach for it.


Andrei

On 12/14/2013 11:46 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> You could be right, I am only talking about the impression I am getting. "The
> smoke-signals being received from a distance". When you don't have one excellent
> compiler, but three in-the-works, it sends signals of a lack of direction and
> implies a lack of a leader that can rally everyone into something cohesive. This
> is not a critique of anyone, most programmers want to be creative and
> argumentative, not to "nurture", "manipulate" and "wave the whip" ( I am not
> even sure I like people who are "great leaders" ;^).

Back when there was only one D compiler, people said they wouldn't use it because there was only one. Now people won't use it because there are 3.

Essentially, if you want to find a reason not to use D, you'll find one. But if you want to use D, there are lots of reasons to. I personally find D to be satisfying and exciting to program in. I can get the code to look like the way the algorithm works in my head, and it runs fast, too.

On 12/14/2013 11:32 AM, Chris Cain wrote:
> I'm just curious, not trying to say you're wrong. I do think it's a huge step up
> from C++'s templates and, personally, I love the new syntax with an infix ! for
> instantiating templates. But if something better could be used, I'm interested
> in hearing the ideas too.

There have been a lot of proposals here over the years for a "something better" template syntax, and they were all worse.

On 12/14/2013 12:37 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> "<>" is much more visually distinct,

Only in trivial code. If it is mixed up with shifting and comparison operators, which are hardly rare, it becomes hellish.