On Friday, 17 February 2012 at 07:21:32 UTC, Nick Sabalausky wrote:
> "F i L" <witte2008@gmail.com> wrote in message news:simejelbyihexcsbkoyl@forum.dlang.org...
>>I would use them over '||' and '&&' for the reasons bearophile gave. Highlighted as keywords, they're easily set appart, easier to type, and more distinguished... then again if I had my way I'd remove the '('/')' brackets, ending marks, and auto keyword; switched the definition name-type placement and change if/else/return/contract syntax...
>>
>>     foo( a, b: float ): int
>
> In other languages, I can live with JS-style "var:Type" but I've never really liked it. Just seems totally backwards to me:
>
> 1. When I declare a variable, I normally know the type I want before I know what to name it, so just typing it in is backwards.

This usually happens to me if I've been coding a lot of C# or Javascript then switch to the other; but i usually get accustom to the change pretty quick. However, I do agree some people feel more natural thinking in one way, so for readability, identifiers should be listed first, while the IDE should allow either to be typed first; rearranging the syntax as you type intelligently. Possibly the syntax should accommodate both, though I'm not sure of any conflicts that way.


> 2. With function definitions, why is the return type so rediculously far away from the function name? Should be "foo:int( a, b: float )". Besides, when you call the func and assign the return value to a variable, the return value is going to the left, not the right. In C-style, return values/types move "left". In JS-style, it's all willy-nilly.

I was thinking this would conflict with template derivitives, but on second thought, I think it would work better the way you say.

    Foo(T): struct { ... }
    Bar(U): Foo!U { ... }

Thanks!


> 3. Makes it harder to distinguish declarations from assignments at a glance. You have to look in the middle of the statement to see what the heck it is. With C-style you only have to look at the beginning (which are conveniently all lined up): Starts with a variable? Assignment. Starts with a type or attribute? Declaration. Starts with colored text? *Definitely* declaration. Don't see why languages keep trying to marginalize the idea of declarations.

Fair point. Though I personally don't find it difficult at all and think it lines up nicely with sequencial property sets:

    bar: = new Bar!int
    bar.name = "bar"
    bar.value = 10


> 4. Initializers are just downright goofy:
>
> a:int = 5;
>
> Looks like it's assigning 5 to "int" instead of to "a", which is completely nonsensical.

I think it makes sense. Just takes some getting use to if you're use to writing C-style code.

The better question is why is there no 'any' and 'all' template in Phobos!

On Friday, February 17, 2012 09:47:50 Andrej Mitrovic wrote:
> The better question is why is there no 'any' and 'all' template in Phobos!

You mean as in a function which returns whether any element in a range matches a predicate and a function which returns whether all elements in a range match a predicate?

Well, canFind gives you any functionality-wise. There's some debate as to whether there should be an alias to any or if the one overload of canFind that arguably should be any should just be changed to any. So, I'm not quite sure what's going to happen there, but there's at least a decent chance that we'll end up with a function actually called any.

There _is_ a pull request for all though.

- Jonathan M Davis

On 2/17/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Well, canFind gives you any functionality-wise.

Good point! I tend to forget about canFind.

On 02/17/2012 06:47 AM, F i L wrote:
> I would use them over '||' and '&&' for the reasons bearophile gave.
> Highlighted as keywords, they're easily set appart, easier to type, and
> more distinguished... then again if I had my way I'd remove the '('/')'
> brackets, ending marks, and auto keyword; switched the definition
> name-type placement and change if/else/return/contract syntax...
>
>      foo( a, b: float ): int
>      {
>          contract in
>          {
>              assert( a != 0 and b != 0 )
>          }
>
>          result: = a + b
>
>          case a >= b { ret result }
>          else b > a { ret a }
>
>          ret 0
>      }
>
>      writeLine: alias writeln
>
>      main()
>      {
>          a, b: float = 10.2, 5.0
>
>          writeLine( foo( a, b ) )
>      }
>
> Tell me that's not beautiful code! :D
>

This looks a lot like rust. :o)
The contract syntax is wrong, because it conceptually has to belong to the function declaration, not the function body.

On 02/17/2012 08:44 AM, F i L wrote:
>
> Yep! Though, I like D's '~' as append operator for arrays. Though I i'm
> not sure this wouldn't work better:
>
> a, b: [1, 2, 3, 4, 5]
>
> a += b[2] // appends b[0] to a
> a[] += b[2] // adds b[0]'s value to all of a
>

'+' means addition! Concatenation is not even commutative. Having '+' mean concatenation is operator abuse.

> Seeing as how your right, '~' means "about" in math.
>

It means "proportional", or "similar". What you want is \approx.

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

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

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

"F i L" <witte2008@gmail.com> wrote in message news:ycdqoufsbftcccpekdpx@forum.dlang.org...
> On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
>> On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
>>> I would use them over '||' and '&&' for the reasons bearophile gave. Highlighted as keywords, they're easily set appart, easier to type, and more distinguished... then again if I had my way I'd remove the '('/')' brackets, ending marks, and auto keyword; switched the definition name-type placement and change if/else/return/contract syntax...
>>
>> Well, if you're going to reinvent the language syntax, I'd like to replace:
>>
>> = with :=
>> == with =
>
> I would agree with this, only there should be a distinction between assignment and declaration. Which in my syntax is ':'. Maybe the keyword 'is' could apply to runtime conditions.. might go nicely with the 'not' statement.
>

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.