On 2014-09-09, 6:55 AM, ketmar via Digitalmars-d wrote:
> On Tue, 09 Sep 2014 13:15:55 +0000
> AsmMan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>>> in : templatename‹params›
>>> out: templatename!(params)
>> Why dou want to turn it into C++'s style?
> look carefully: it's not "<", it's completely different unicode char.

Isn't that kind of a problem that you had to point that out?  If the code isn't readable, I'd count that as a con.  And as someone else mentioned elsewhere.. how would you type that?  As I recall, Ada had a special keyboard... are you suggesting that we (programmers) go down that path again?

On Tuesday, 9 September 2014 at 13:56:10 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 09 Sep 2014 13:15:55 +0000
> AsmMan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> > in : templatename‹params›
>> > out: templatename!(params)
>> Why dou want to turn it into C++'s style?
> look carefully: it's not "<", it's completely different unicode char.

*do you
I hadn't noticied.

>> > in : templatename«params»
>> > out: templatename!"params"
>> Why quote a paramter as string?
> it looks prettier.

How will it works to multiple parameters?

There's a programming language (I don't recall its name now) that you need to a "special" keyboard just to type its operators. Looks like it is the case. Remember C# is called so and not C♯ because not everyone can type ♯ symbol easily in its keyboards. Such an operators in a programming language may be cool (like the pow one, in special) but don't expect it's going to be much successfully.

On Tuesday, 9 September 2014 at 14:50:37 UTC, Andre Kostur wrote:
> On 2014-09-09, 6:55 AM, ketmar via Digitalmars-d wrote:
>> On Tue, 09 Sep 2014 13:15:55 +0000
>> AsmMan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>>> in : templatename‹params›
>>>> out: templatename!(params)
>>> Why dou want to turn it into C++'s style?
>> look carefully: it's not "<", it's completely different unicode char.
>
> Isn't that kind of a problem that you had to point that out?  If the code isn't readable, I'd count that as a con.  And as someone else mentioned elsewhere.. how would you type that?  As I recall, Ada had a special keyboard... are you suggesting that we (programmers) go down that path again?

IIRC, Ada operators are plain US-ASCII. The programming language (which I was trying to call name in above post) and you're probably talking about is APL:

http://en.wikipedia.org/wiki/APL_%28programming_language%29

On Tue, 09 Sep 2014 07:50:37 -0700
Andre Kostur via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

it's not my patches, i'm strongly against unicode chars. ask the author instead. ;-)

On Tuesday, 9 September 2014 at 15:00:05 UTC, AsmMan wrote:
> There's a programming language (I don't recall its name now)

"A programming language", you say? Wouldn't you know it, that's the one! ;)

> that you need to a "special" keyboard just to type its operators.

APL actually has really neat semantics (seriously, every programmer would do well to at least learn _how APL works_) but, yeah, the keymap is kind of a bit much.  An IME would work well, though....

-Wyatt

On Monday, 8 September 2014 at 08:51:10 UTC, Ola Fosheim Grøstad wrote:
>
> What kind of syntactical sugar do you feel is missing in D?

Sort of in the vein of this discussion, one thing I'd like to see is a (smallish) set of special operators that have no meaning unless explicitly overloaded.  I've considered writing a DIP for it, but I simply don't have the time to work out all the kinks and give it due diligence. (For example my thought of just using the extant operators surrounded with parentheses (e.g. foo (+) bar) probably wouldn't fly for some reason or another.)

-Wyatt

On 9/9/14, 8:00 AM, AsmMan wrote:
> There's a programming language (I don't recall its name now) that you
> need to a "special" keyboard just to type its operators.

APL

On 2014-09-09, 8:07 AM, AsmMan wrote:

> IIRC, Ada operators are plain US-ASCII. The programming language (which
> I was trying to call name in above post) and you're probably talking
> about is APL:
>
> http://en.wikipedia.org/wiki/APL_%28programming_language%29

You're right.  I've been programming a while and even that language predates me :)

On 09/09/2014 07:05 PM, Wyatt wrote:
>
> APL actually has really neat semantics (seriously, every programmer
> would do well to at least learn _how APL works_) ...

One can do this quite efficiently e.g. here: http://tryapl.org/

On Monday, 8 September 2014 at 16:47:15 UTC, Marco Leise wrote:
> And now we all calm down a little, ok? The D community is as
> diverse as the language and even if three people yell in the
> same tone, it doesn't mean everyone else believes the same.

I know that, but newbies don't know that. So it is important that you voice your opinion.

It is important to nurture. That means understand why new people are engaged and back it up if it is constructive. With 25+ years of experience with online communities and 3+ years of full time studies of creativity/motivation in online communities I believe the following is close to the truth:

1. Recruiting newbies is even more important than retaining oldbies.

- Retention is important, but most oldbies will leave (after ~3 years). This is natural and healthy.

- Some of the oldbies that stay, some do it for the wrong reasons (e.g. the online community being their main source of self worth), this can lead to dysfunctional situations.

2. Newbie bashing is common. Backing and understanding what drives motivated newbies is important for growth. You need to sustain that motivation to grow.

3. People generally don't want more work in their spare time. They want fun, freedom and a go-happy friendly environment. So you need to provide that atmosphere for newbies.

4. Newbies sometimes come with a fresh outlook and are a source for understanding what aspects of the culture hold back growth and performance.

A bunch of unwritten rules tend to lead to unpleasant situations. It is important for a development community to align their attitudes to the freedoms implied by the license. A Boost license comes with a set of freedoms that I would expect the community to back fully.

Undermining the license by unwritten rules is counter productive for the following reasons:

1. Commercial entities will not "read" the unwritten rules. They will look at the source code, the change log and the license. There is no good reason for having forum members adhere to a separate set of rules where they have their freedom restricted.

2. Unwritten rules lead to newbie bashing, because newbies cannot possibly know the unwritten rules, which in turn leads to recruitment problems.

The main branch is not inviting since it should aim for stability, contributing to it is more likely to lead to frustration than gratification.

Making your own mods is motivating since it is gratifying to be able to add a new feature in 3 hours. Exchanging mods with other newbies (which I am in a way) increase the motivation.

Basically, group formation nurture participation and involvement. It is important to encourage that when opportunities arise. E.g. when new people arrive and express enthusiasm.

> that is understood by the front-end like "!" or "~". Also you
> might want to consider adding .opSqrt for consistency.

Yes, that would probably be the more consistent way to do it in the long run.

> very unusual. Well, it is your fork I'd say. If you ever make
> any pull requests be sure to propose one feature at a time,

I don't have any plans to make pull requests atm, I only have a few hours per week to spend on this. However, I try to keep changes local (which is not all that easy in parser.c).