Am 17.02.2012 15:02, schrieb James Miller:
> On 18 February 2012 02:35, David<d@dav1d.de>  wrote:
>>> Python also uses "&" for set intersection afaik.
>>
>>
>> Yes, but that's an overload of the&-Operator and it makes sense.
>>
>>
>> We should add "and" and "or" this makes the Code way more readable, imo.
>
> But I spent years learning&&  and ||, when I read code, these patterns
> jump out at me. Sure they aren't as "readable" but we're writing a
> program here, not the Illiad. I write in a programming language, not
> english, if I wanted to write in english, I'd go be an author, or a
> journalist.
>
> As people have mentioned, it only makes the code more readable (and
> even that is under debate) for english-speaking users, foreign
> language users are at even more of a disadvantage, since the have an
> extra step of analysis to figure out what it means, especially since
> there might not always be a simple translation.
>
> Don't think of&&  and || as `and` and `or`, think of them more as
> logical conjuction and disjunction, they are predicate operators.
>
> And if we want to get into "proper" symbols for logic, we should be
> using ∧, ∨, ⊕, ¬ for and, or, exclusive or and not, since those are
> the proper boolean algebra symbols.
>
> --
> James Miller
Then use Haskell :P. http://www.haskell.org/haskellwiki/Unicode-symbols

Everyone who codes in the "D programming language" knows english, since the whole internetz is english, like the D documentation, so it shouldn't be a problem to get the meaning of "and" and "or".

Timon Gehr wrote:
> The contract syntax is wrong, because it conceptually has to belong to the function declaration, not the function body.

I'm not so convinced. I just hate how in/out are shoved up against the name of the function. I was thinking about using '.' to reference the current function with each sequencial '.' meaning parentage. if that was the case, ".conctract in {}" would refer to the function, though I'm not sure how to resolve the naming conflicts of incoming parameters. Maybe '@' for attribute? I've the same dilemma for properties (aliases):

     Vector2: class
     {
         x, y: float private

         X: alias
         {
             @get: x
             @set: ( val:float )
             {
                 case val != 0 { x = val }
             }
         }

         this( x, y:float, contract:int )
         {
             @contract.in
             {
                 assert( contract != 0 )
             }

             x = .x // set this.x to params.x
             ..x = .x // same as above
             y = ...y // sets this.y to super.y

             ret .. // returns this
         }
     }

Am 17.02.2012, 15:02 Uhr, schrieb James Miller <james@aatch.net>:

> On 18 February 2012 02:35, David <d@dav1d.de> wrote:
>>> Python also uses "&" for set intersection afaik.
>>
>>
>> Yes, but that's an overload of the &-Operator and it makes sense.
>>
>>
>> We should add "and" and "or" this makes the Code way more readable, imo.
>
> But I spent years learning && and ||, when I read code, these patterns
> jump out at me. Sure they aren't as "readable" but we're writing a
> program here, not the Illiad. I write in a programming language, not
> english, if I wanted to write in english, I'd go be an author, or a
> journalist.
>
> As people have mentioned, it only makes the code more readable (and
> even that is under debate) for english-speaking users, foreign
> language users are at even more of a disadvantage, since the have an
> extra step of analysis to figure out what it means, especially since
> there might not always be a simple translation.
>
> Don't think of && and || as `and` and `or`, think of them more as
> logical conjuction and disjunction, they are predicate operators.
>
> And if we want to get into "proper" symbols for logic, we should be
> using ∧, ∨, ⊕, ¬ for and, or, exclusive or and not, since those are
> the proper boolean algebra symbols.
>
> --
> James Miller

The only thing that I still mix up is = and ==. I wonder if it is just me or people who are used to Pascal syntax. I sometimes miss

	if a = 1 then a := 2;

which results in my bad mental C/D translation: if (a = 1) ...;

Nick Sabalausky wrote:
> "F i L" <witte2008@gmail.com> wrote in message news:jzkatvnibtjkcafqsibf@forum.dlang.org...
>>> All of the syntaxes you're advocating are every bit as arbitrary as the ones you're against.
>>
>> Programming is logic largely based around math.
>
> Yes, it's *based* around math, but it *isn't* math.
>
> English is based largely around German and Latin, and yet it's neither German nor Latin, nor a mere conjunction of them, nor can one say that it *should* be. Of course, you can pick that analogy to death, but the point is, things don't have to maintain a heavy resemblance to their origin.
>
>> Seeing as how we're all educated around with mathematic symbols as children, a language design which reflects what is most familiar will be the easiest to initially understand. Less friction means more productivity.
>>
>
> You're talking about very minor details that are trivial to learn (I was only about 12 or 13 when I learned C). The prodictivity drop in these cases is *purely* a *minor* upfront cost, and with no ongoing cost (but does have ongoing *benefits* because it's designed specifically with *it's own* domain in mind instead being hampered by unnecessary ties to some other domain).

I just don't see an argument for why we *shouldn't* make mathematical operations in code match those we where taught as children as close as possible.


> I've always agreed with the usual reasoning behind ":= and = instead of = and ==", but in practice I don't like it becase assignment is so *incredibly* common I don't want it to be a 2-handed 3-keypress "Shift+Keypress and then another keypress". Just one keypress, thank you. And yes, equality is fairly common, too, but *UNLIKE MATH*, equality isn't quite *as* common as assignment. Plus, "==" is even a little easier than "two keypresses" since it's the same key, not two different keys.

yes i agree. I'm not really a fan of using ':=' for assignment because of it's keystroke length, even if it *does* make more sense. Still, I don't see why '==' couldn't be 'is' and '!=' couldn't be 'not'. Thought this might get hard to read with all the 'and'/'or's everywhere:

    a: = 0
    b: = new Foo
    c: = "Bar"

    case a is 0 and b not null and c is "Bar" { ... } // hard to read
    case a == 0 and b !is null and c == "Bar" { ... } // better than:
    case a == 0 && b !is null && c == "Bar" { ... }

"F i L" <witte2008@gmail.com> wrote in message news:iylkhrwcbscmfwsdxljg@forum.dlang.org...
> Nick Sabalausky wrote:
>>
>> You're talking about very minor details that are trivial to learn (I was only about 12 or 13 when I learned C). The prodictivity drop in these cases is *purely* a *minor* upfront cost, and with no ongoing cost (but does have ongoing *benefits* because it's designed specifically with *it's own* domain in mind instead being hampered by unnecessary ties to some other domain).
>
> I just don't see an argument for why we *shouldn't* make mathematical operations in code match those we where taught as children as close as possible.
>

When all else is equal, yes, certainly. Which is why we use + as addition, for example. But all else is often not equal. For instance, ";" is much more noticable than "." so it's a much better choice for large-grained separation (ie, separating statements).

>
> yes i agree. I'm not really a fan of using ':=' for assignment because of it's keystroke length, even if it *does* make more sense. Still, I don't see why '==' couldn't be 'is' and '!=' couldn't be 'not'. Thought this might get hard to read with all the 'and'/'or's everywhere:
>
>     a: = 0
>     b: = new Foo
>     c: = "Bar"
>
>     case a is 0 and b not null and c is "Bar" { ... } // hard to read
>     case a == 0 and b !is null and c == "Bar" { ... } // better than:
>     case a == 0 && b !is null && c == "Bar" { ... }

I find:

   case a == 0 && b !is null && c == "Bar" { ... }

much easier to read than:

   case a == 0 and b !is null and c == "Bar" { ... }

Since the former uses a totally different character set for the operators, my eyes can parse it at a glance. With the latter, I have to actually go through and read it. The "and" and "or" just visually blend together with all the other words and variables.

Am 17.02.2012, 16:08 Uhr, schrieb Nick Sabalausky <a@a.a>:

> I've always agreed with the usual reasoning behind ":= and = instead of =
> and ==", but in practice I don't like it becase assignment is so
> *incredibly* common I don't want it to be a 2-handed 3-keypress
> "Shift+Keypress and then another keypress". Just one keypress, thank you.
> And yes, equality is fairly common, too, but *UNLIKE MATH*, equality isn't
> quite *as* common as assignment. Plus, "==" is even a little easier than
> "two keypresses" since it's the same key, not two different keys.

Why didn't I think of that before! The perceived ease of use depends - in parts - on the spoken language you use, because different keyboard layouts are used. To pick up your example, I don't mind := because I have to hold [shift] already for a normal =. I just compared the default US and DE layouts. Here are some characters that can be achieved with one key stroke in either layout exclusively:
US: =[];'\/`
DE: #+^´

So while the US layout lacks XOR and even + (wow), I'm a bit jealous on =, array operations [], end of statement ;, division /, character delimiter ', and raw string delimiter `.

Then I remembered what happened when I enabled Pascal as a language for aichallenge.org: http://aichallenge.org/language_profile.php?language=Pascal
A flood of users from countries with a Cyrillic keyboard layout joined the competition using Pascal. Back then I thought it was just a random prevalence of Pascal for reasons like, that being the language taught in schools. Now I wonder if - aside from what is taught at schools and aside the fact that they mostly use English layouts to write code - it is the lack of keys for | and & on a typical keyboard that makes Pascal look more appealing: http://en.wikipedia.org/wiki/Keyboard_layout#Cyrillic That's just a wild theory.

I might look into tuning a keyboard layout towards D programming a bit. :)

On Fri, Feb 17, 2012 at 08:56:58AM +0100, F i L wrote: [...]
> Thought to be honest I doubt we'll all still be designing applications in text (only) editors, even fancy ones, in the next 10-15 years.

I know I still will be. I have never liked IDE's, and probably never will.


> Software design is very modular, and even arbitrary logic tools could be better at presenting this data. Simple things like code-completion has gone a long way flatten the learning curve, and that can only get better when visual and audio logic can be manipulated in like-fashion.
[...]

True, but the initial learning curve *is* only just the initial learning curve. Programming is essentially difficult, and whether the initial learning curve was easy or not, sooner or later you will still have to come to grips with the same difficult programming problems that will require a lot of effort and ingenuity to solve.

Unless you're talking about trivial things like writing GUI interfaces and stuff like that, which require no more than the usual manipulation of arrays and lists and simple stuff like that.

Once you get past these trivial things, and get to non-trivial problems like finding a good approximation for the travelling salesman problem, or computing higher-dimensional convex hulls, say, you'll have to think in the abstract anyway, so the representation really doesn't matter that much.  Might as well stick with text-only representation so that you can focus on the actual problem instead of being distracted by pretty graphics.


T

-- 
Caffeine underflow. Brain dumped.

On Fri, Feb 17, 2012 at 06:30:09PM +0100, Marco Leise wrote: [...]
> Why didn't I think of that before! The perceived ease of use depends -
> in parts - on the spoken language you use, because different keyboard
> layouts are used. To pick up your example, I don't mind := because I
> have to hold [shift] already for a normal =. I just compared the
> default US and DE layouts. Here are some characters that can be
> achieved with one key stroke in either layout exclusively:
> US: =[];'\/`
> DE: #+^´
> 
> So while the US layout lacks XOR and even + (wow), I'm a bit jealous on =, array operations [], end of statement ;, division /, character delimiter ', and raw string delimiter `.

You're right! The keyboard layout matters a lot. I remember on older keyboards [] and {} were in hard-to-reach places and require holding down the shift key. Today at least [] are easy to reach, so D's array notation is very convenient.


> Then I remembered what happened when I enabled Pascal as a language
> for aichallenge.org:
> http://aichallenge.org/language_profile.php?language=Pascal
> A flood of users from countries with a Cyrillic keyboard layout joined
> the competition using Pascal. Back then I thought it was just a random
> prevalence of Pascal for reasons like, that being the language taught
> in schools. Now I wonder if - aside from what is taught at schools and
> aside the fact that they mostly use English layouts to write code - it
> is the lack of keys for | and & on a typical keyboard that makes
> Pascal look more appealing:
> http://en.wikipedia.org/wiki/Keyboard_layout#Cyrillic That's just a
> wild theory.

I think that theory has some truth to it. For example, I learned Cyrillic keyboard layout as part of learning Russian, and I felt the inconvenience of certain symbols like / (needs a shift and located in an awkward corner), esp. when typing paths in Unix. Basic things like ; requires a shift key and reaching to the upper number row, which makes typing statements quite awkward. I still don't know how to make certain symbols in Cyrillic layout. (Good thing I configured X11 to switch between EN and RU in a single keystroke: makes a huge difference in usability.) Imagine if your programming language required those hard-to-type symbols in the most common places.  It would be a great turn off.


> I might look into tuning a keyboard layout towards D programming a bit. :)

I thought the US/English keyboard layout is already very well suited to D.


T

-- 
Ruby is essentially Perl minus Wall.

Nick Sabalausky wrote:
> I find:
>
>    case a == 0 && b !is null && c == "Bar" { ... }
>
> much easier to read than:
>
>    case a == 0 and b !is null and c == "Bar" { ... }
>
> Since the former uses a totally different character set for the operators, my eyes can parse it at a glance. With the latter, I have to actually go through and read it. The "and" and "or" just visually blend together with all the other words and variables.

I've set up some custom keywords in Notepad++ which I use to test this stuff out. 'null' and 'is' are separate colors from case/and/or so it's easier to parse-at-a-glance since &&/|| are colored the same as operators and conflict with the '=='/'!is'. But I guess this is largely syntax-highlighting issue. Still, I find 'and'/'or' quicker to type, but I'm not strongly against using either one or both for that matter.

On Fri, Feb 17, 2012 at 09:58:06AM -0500, Nick Sabalausky wrote:
> "F i L" <witte2008@gmail.com> wrote in message
[...]
> > Seeing as how we're all educated around with mathematic symbols as children, a language design which reflects what is most familiar will be the easiest to initially understand. Less friction means more productivity.
> >
> 
> You're talking about very minor details that are trivial to learn (I was only about 12 or 13 when I learned C). The prodictivity drop in these cases is *purely* a *minor* upfront cost, and with no ongoing cost (but does have ongoing *benefits* because it's designed specifically with *it's own* domain in mind instead being hampered by unnecessary ties to some other domain).
[...]

That's not 100% true, though. Programming has always had close ties with math, even though, as you said, they aren't the same thing. In fact, computing came out of math, if you want to be historically accurate. I mean, the symbols chosen do have *some* ties with other domains, even if the mapping is not 1-to-1. If it were truly completely arbitrary, why don't we use $ for assignment, ` for equality, and % for addition? After all, we're writing a programming language, not math, so we can just assign arbitrary symbols to mean whatever we want, right?

And as for C syntax, I have to admit that I'm most comfortable with C (or C-like) syntax, too. Even though it has its own flaws, I have become accustomed to its quirks, and I spontaneously type C syntax when I think of code. But that doesn't mean we shouldn't step back and re-examine the system to see if there are better ways of doing things. I find Pascal syntax, for example, truly painful. But if I were to disregard my background in C (and its derivatives), perhaps there is something to be learned from Pascal syntax.


T

-- 
Once bitten, twice cry...