www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is there no or or and ?

reply Caligo <iteronvexor gmail.com> writes:
C++ has this and it makes code little more readable in certain cases:

if(something() or foo() and bar()){  ... }

instead of this in D:

if(something() || foo() && bar()){ ... }


possible enhancement request?  or is there a good reason it is not in
the language?
Feb 16 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Caligo:

 possible enhancement request?  or is there a good reason it is not in
 the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++. ---------------- Jonathan M Davis:
 And I'm actually mildly shocked that anyone (at least any programmer) would
 think that "or" and "and" were more readable. The fact that operators aren't
 words is a _major_ boon to code readibility.
This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND". "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise & |. This avoids some bugs where people use "&&" where they want to use "&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them. Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation. Bye, bearophile
Feb 16 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 16, 2012 23:53:34 bearophile wrote:
 And I'm actually mildly shocked that anyone (at least any programmer)
 would
 think that "or" and "and" were more readable. The fact that operators
 aren't words is a _major_ boon to code readibility.
This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND". "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise & |. This avoids some bugs where people use "&&" where they want to use "&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them. Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation.
Seriously? && and || are _way_ more readible, because they're obviously not functions or variables. It's immediately obvious what the operators are when scanning code. That's not the case when the operators are words instead of symbols. I'm certain that you'd have quite a few programmers up in arms if you tried to change && to "and" and || to "or." And having multiple operators which do exactly the same thing is a horrible idea which reduces code readibility. So, even adding them as alternate options is a really bad idea IMHO. I'm surprised that anyone would think that and was better than &&. - Jonathan M Davis
Feb 16 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/17/2012 06:02 AM, Jonathan M Davis wrote:
 On Thursday, February 16, 2012 23:53:34 bearophile wrote:
 And I'm actually mildly shocked that anyone (at least any programmer)
 would
 think that "or" and "and" were more readable. The fact that operators
 aren't words is a _major_ boon to code readibility.
This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND". "or" and "and" are about as long as those symbols in char count, quicker to write because they are lowercase letters instead of symbols, and they are much simpler told apart from bitwise& |. This avoids some bugs where people use "&&" where they want to use"&" or the other way around. Such bugs are so common that D have had to introduce one or two rules to help avoid them. Python got this waaaaay much better than D. Using "&" for (uncommon, in Python) binary ops, and "and" for the common logic boolean operation.
Seriously?&& and || are _way_ more readible, because they're obviously not functions or variables. It's immediately obvious what the operators are when scanning code. That's not the case when the operators are words instead of symbols. I'm certain that you'd have quite a few programmers up in arms if you tried to change&& to "and" and || to "or." And having multiple operators which do exactly the same thing is a horrible idea which reduces code readibility. So, even adding them as alternate options is a really bad idea IMHO. I'm surprised that anyone would think that and was better than&&. - Jonathan M Davis
The editor would highlight the keywords, so you definitely would not confuse them for variables. This is already true for 'is' and 'in'. I don't need any alternative operators though, I'd rather introduce some new ones, like the implication operator '==>'.
Feb 16 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.450.1329455016.20196.digitalmars-d puremagic.com...
 Seriously? && and || are _way_ more readible, because they're obviously 
 not
 functions or variables. It's immediately obvious what the operators are 
 when
 scanning code. That's not the case when the operators are words instead of
 symbols. I'm certain that you'd have quite a few programmers up in arms if 
 you
 tried to change && to "and" and || to "or." And having multiple operators
 which do exactly the same thing is a horrible idea which reduces code
 readibility. So, even adding them as alternate options is a really bad 
 idea
 IMHO.

 I'm surprised that anyone would think that and was better than &&.
This is why I think people are nuts when they claim that english-like VB-style syntax is more readable than C-style. (Yea, to a grandmother with zero programming experience english-like languages are more readable. For a programmer it's worse becase code != english.)
Feb 16 2012
next sibling parent Caligo <iteronvexor gmail.com> writes:
On Thu, Feb 16, 2012 at 11:16 PM, Nick Sabalausky <a a.a> wrote:
 This is why I think people are nuts when they claim that english-like
 VB-style syntax is more readable than C-style.

 (Yea, to a grandmother with zero programming experience english-like
 languages are more readable. For a programmer it's worse becase code !=
 english.)
This is not about having an English-like syntax. Not every programmer speaks English, but nearly every programming language uses English words. At least for them 'and' and && are about the same. I can agree that having multiple operators that do the exact same thing can be problematic, so such a change might be too late for D (unless we replace &&, ||, etc. with 'and', 'or', etc.). But at the same time, when I was new to D I found things like 'is' and '==' confusing, and I'm sure I'm not the only one. Another thing, most editors render keywords with a different colour than, say, the logical operators. So in if(a or b and c){ } the 'if', 'and', and 'or' are the same colour.
Feb 16 2012
prev sibling parent reply bcs <bcs example.com> writes:
On 02/16/2012 09:16 PM, Nick Sabalausky wrote:
 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.450.1329455016.20196.digitalmars-d puremagic.com...
 Seriously?&&  and || are _way_ more readible, because they're obviously
 not
 functions or variables. It's immediately obvious what the operators are
 when
 scanning code. That's not the case when the operators are words instead of
 symbols. I'm certain that you'd have quite a few programmers up in arms if
 you
 tried to change&&  to "and" and || to "or." And having multiple operators
 which do exactly the same thing is a horrible idea which reduces code
 readibility. So, even adding them as alternate options is a really bad
 idea
 IMHO.

 I'm surprised that anyone would think that and was better than&&.
This is why I think people are nuts when they claim that english-like VB-style syntax is more readable than C-style. (Yea, to a grandmother with zero programming experience english-like languages are more readable. For a programmer it's worse becase code != english.)
Any language that is designed to be easy for amateurs to use will be used by amateurs, and only by amateurs. Yes, avoid making the language unnecessarily hard for beginners, but don't in any way compromises the language to do so.
Feb 16 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 17/02/2012 06:09, bcs wrote:
<snip>
 Any language that is designed to be easy for amateurs to use will be used by
amateurs, and
 only by amateurs.
<snip> Do you consider either VB or Python to fall under that category? Stewart.
Feb 19 2012
parent reply Kevin Cox <kevincox.ca gmail.com> writes:
Vb yes, python kinda.  Vb is designed for people who don't want to
program.  The idea is to create a quick application that gets two job
done.  Python is slightly different.  It has a ton of syntax and all the
libraries that it needs to be used in moderately sized project.  Python
comes across as being easy to learn because it is simple in the most
beautiful way.  I doubt many large programs are written in python but of
course it is finding a home on the web.  I think that python stretches
close to the line but I doubt it was designed for beginners.
On Feb 19, 2012 10:20 AM, "Stewart Gordon" <smjg_1998 yahoo.com> wrote:

 On 17/02/2012 06:09, bcs wrote:
 <snip>

 Any language that is designed to be easy for amateurs to use will be used
 by amateurs, and
 only by amateurs.
<snip> Do you consider either VB or Python to fall under that category? Stewart.
Feb 19 2012
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Kevin Cox:

 I think that python stretches
 close to the line but I doubt it was designed for beginners.
Python partially comes from ABC, a language that was designed to teach programming. So originally Python was meant (unlike ABC) to be practically useful, but also to avoid being unnecessarily hard to learn and use, retaining ABC ideas and simplicity where possible. In the last years they have added more features to Python (Unicode on default, lazyiness on default in many places, decorators, and so on and on), to make it more efficient and more fit to write larger programs. So now Python is large enough, and despite being simpler than several other languages, it's not so simple to be a first language. The problem with languages to teach programming to people that don't know how to program, is that if you design them to be simple and good for teaching, no one uses it for practical purposes, so it ends being useless outside schools, and very few people write patches or libraries for it. So it often dies. If you use a language used for real use, you have many libraries and a good compiler/interpreter, but the language is large, often full of legacy, warts, or backwards compatible things, and the language itself is often not easy to learn and understand. Apparently there is no way out of this dilemma. I have seen that today Python is good enough to teach programming, but you can't teach static typing well with it. D is too much complex for young newbies. Racket Scheme has a very good editor, it has good documentation, and so on, but in my opinion Python is better as first language, despite Racket contains a typed scheme too. Bye, bearophile
Feb 19 2012
prev sibling parent bcs <bcs example.com> writes:
On 02/19/2012 07:25 AM, Kevin Cox wrote:
 Vb yes, python kinda.  Vb is designed for people who don't want to
 program.  The idea is to create a quick application that gets two job
 done.  Python is slightly different.  It has a ton of syntax and all the
 libraries that it needs to be used in moderately sized project.  Python
 comes across as being easy to learn because it is simple in the most
 beautiful way.  I doubt many large programs are written in python but of
 course it is finding a home on the web.  I think that python stretches
 close to the line but I doubt it was designed for beginners.
What he said.
 On Feb 19, 2012 10:20 AM, "Stewart Gordon" <smjg_1998 yahoo.com
 <mailto:smjg_1998 yahoo.com>> wrote:

     On 17/02/2012 06:09, bcs wrote:
     <snip>

         Any language that is designed to be easy for amateurs to use
         will be used by amateurs, and
         only by amateurs.

     <snip>

     Do you consider either VB or Python to fall under that category?

     Stewart.
Feb 19 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/17/2012 05:53 AM, bearophile wrote:
 Caligo:

 possible enhancement request?  or is there a good reason it is not in
 the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++. ---------------- Jonathan M Davis:
 And I'm actually mildly shocked that anyone (at least any programmer) would
 think that "or" and "and" were more readable. The fact that operators aren't
 words is a _major_ boon to code readibility.
This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND".
In what way is '&&' meaningless or unrelated to 'AND' ?
 "or" and "and" are about as long as those symbols in char count, quicker to
write because they are lowercase letters instead of symbols,
Valid point.
 and they are much simpler told apart from bitwise&  |. This avoids some bugs
where people use "&&" where they want to use"&" or the other way around. Such
bugs are so common that D have had to introduce one or two rules to help avoid
them.
&& and & don't look the same to me. Furthermore, I have never run into any parser special cases except if(x=y()) and x | b<c, and then the error messages were actually annoying and meaningless.
 Python got this waaaaay much better than D. Using "&" for (uncommon, in
Python) binary ops, and "and" for the common logic boolean operation.

 Bye,
 bearophile
Python also uses "&" for set intersection afaik.
Feb 16 2012
parent reply David <d dav1d.de> writes:
 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.
Feb 17 2012
parent reply James Miller <james aatch.net> writes:
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 =E2=88=A7, =E2=88=A8, =E2=8A=95, =C2=AC for and, or, exclusive or and= not, since those are the proper boolean algebra symbols. -- James Miller
Feb 17 2012
next sibling parent David <d dav1d.de> writes:
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".
Feb 17 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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, i=
mo.
 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 =E2=88=A7, =E2=88=A8, =E2=8A=95, =C2=AC for and, or, exclusive o=
r and not, since those are
 the proper boolean algebra symbols.

 --
 James Miller
The only thing that I still mix up is =3D and =3D=3D. I wonder if it is = just me or people who are used to Pascal syntax. I sometimes miss if a =3D 1 then a :=3D 2; which results in my bad mental C/D translation: if (a =3D 1) ...;
Feb 17 2012
prev sibling parent bcs <bcs example.com> writes:
On 02/16/2012 08:53 PM, bearophile wrote:
 Caligo:

 possible enhancement request?  or is there a good reason it is not in
 the language?
I have asked for them, but Walter doesn't want, he thinks C/C++ programmers will not use them... :-( Despite D != C/C++. ---------------- Jonathan M Davis:
 And I'm actually mildly shocked that anyone (at least any programmer) would
 think that "or" and "and" were more readable. The fact that operators aren't
 words is a _major_ boon to code readibility.
This is very very wrong. Of course that "or" and "and" are more readable. When you read "and" it's immediate to think it's probably related to the AND logical or binary operation more than meaningless symbols that are unrelated to "AND".
'and' & 'or' are just a patch of meaningless squiggles with no more or less meaning than '&&' and '||' have. They have the meaning we impart to them. Personally, I associate '||' with the idea of disjunction just as much as I associate 'or'. Having the operators and the key-words/identifiers from different sets of characters, IMHO make things easer to read.
 "or" and "and" are about as long as those symbols in char count, quicker to
write because they are lowercase letters instead of symbols, and they are much
simpler told apart from bitwise&  |. This avoids some bugs where people use
"&&" where they want to use"&" or the other way around. Such bugs are so common
that D have had to introduce one or two rules to help avoid them.

 Python got this waaaaay much better than D. Using "&" for (uncommon, in
Python) binary ops, and "and" for the common logic boolean operation.
In a debate about readability, I don't give much weight to an argument that holds up Python as an ideal. Semanticly significant white-space? Are you kidding me?
Feb 16 2012
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
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
Feb 16 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 17, 2012 06:47:20 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
It's not beautiful code. - Jonathan M Davis
Feb 16 2012
parent reply "F i L" <witte2008 gmail.com> writes:
On Friday, 17 February 2012 at 05:53:08 UTC, Jonathan M Davis 
wrote:
 On Friday, February 17, 2012 06:47:20 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
It's not beautiful code. - Jonathan M Davis
I knew someone was going to say that >:{
Feb 16 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 17, 2012 06:57:48 F i L wrote:
 I knew someone was going to say that >:{
Well, you _were_ asking for it. :) But I do honestly think that it's ugly. Obviously, different people have different ideas of what a language's syntax should look like - frequently strongly influenced by what language or languages they used first. Personally, I _like_ the C style syntax and do not understand why people want to get rid of stuff like braces or semicolons (you didn't get rid of braces in your suggested syntax, but it's a common suggestion for people who don't like C style syntax). Overall, I think that D's syntax is very good. - Jonathan M Davis
Feb 16 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/16/12 11:47 PM, 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;
I figured I won't be able to unread the rest, so I stopped here :o). Andrei
Feb 16 2012
parent "F i L" <witte2008 gmail.com> writes:
Andrei Alexandrescu wrote:
 I figured I won't be able to unread the rest, so I stopped here 
 :o).
Well... my syntax must require a finer taste </posh> ;-p Jonathan M Davis wrote:
 On Friday, February 17, 2012 06:57:48 F i L wrote:
 I knew someone was going to say that >:{
Well, you _were_ asking for it. :) But I do honestly think that it's ugly. Obviously, different people have different ideas of what a language's syntax should look like - frequently strongly influenced by what language or languages they used first. Personally, I _like_ the C style syntax and do not understand why people want to get rid of stuff like braces or semicolons (you didn't get rid of braces in your suggested syntax, but it's a common suggestion for people who don't like C style syntax). Overall, I think that D's syntax is very good.
I started on C++ actually (ahh Codewarrior :)) and still find the after navigating the myriad of syntaxes and styles of web design, I'm not too picky. But my syntax does have purpose behind it's brilliance! For instance, all identifier names are placed at the beginning of Lines, which eliminates eyeballing each line to find it's definition and keeps accessor keywords (static, public, etc) from getting in the way of variable grouping. 'case' is used instead of 'if' to keep short, like-kind conditions aligned. 'else' can be used as 'else if' for the same reason. Contracts are kept from bumping up against the definitions (important when identifiers are first) and ending marks are largely unneeded in the first place. To eliminate Go's required "{" at the end of body definitions, I would make each "free scope" require a scope keyword. This might even be useful for something like functions derived of functions (not thoroughly thought out): foo( age:int ) { before: scope {} // foo code after: scope { // default after code } } bar( name:text, age:int ): foo( age ) { // inherited foo code scope( after ) { // override after code } } I know this is what polymorphism is for, but I think because object methods are conceptually "random access" and scopes are "in sequence" there might be a (any?) benefit to static function inheritance. Maybe in combination with structs or UFCS? Idk, maybe i'm just crazy :)
Feb 16 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 = These two are the most annoying syntax inherited from C, IMNSHO. I mean, mathematically speaking, = is equality, not assignment. Traditionally := has been used for assignment; so why mix them up? Besides, what on earth is == anyway? Equal-equal? It makes no sense. And even worse, languages like Javascript that copied C's lousy choice of equality operator made it worse by introducing ===, which is both nonsensical in appearance and semantically a symptom of language maldesign. Next on the list is, of course: && with and (or perhaps &) || with or (or perhaps even |) The symbol '&' is commonly used to mean 'and', such as "John & Wiley's". So why the && stutter? Bitwise operations aren't used very much anyway, so they shouldn't be hogging single-character operators. Let bitwise AND be &&, and I'd be OK with that. But C has gotten it the wrong way round. Similarly '|' *has* been used traditionally to separate alternatives, such as in BNF notation, so there's no reason for that silly || stutter. Bitwise OR isn't used very often anyway, so if anything, | should be logial OR, and I suppose it's OK for || to be bitwise OR. Again C has it the wrong way round. But more importantly: ^^ with ^ ^ with something else altogether I mean, c'mon. Everybody knows ^ means superscript, that is, exponentiation. So why waste such a convenient symbol on bitwise XOR, which is only rarely used anyway?! It should simply be called 'xor' at best. Nobody who hasn't learned C (or its derivatives) knows what '^' means (in C) anyway. And then: ! with not Everyone knows ! means exclamation mark, or factorial. Having it also mean logical NOT is just needlessly confusing. What's wrong with 'not'? Or, since we have Unicode, what about �? Much clearer. As for bitwise NOT, '~' is about the most counterintuitive symbol for such a thing. My presumptuous guess is that Kernighan ran out of symbols on the keyboard for operators, so he resorted to ~. The symbol '~' should've been reserved for an "approximately equal" operator, useful in comparing floating-point numbers (which as we know usually shouldn't be compared with equality due to roundoff errors), like this: if (a ~ b) { ... } rather than today's baroque dance of: if (fabs(b-a) < EPSILON) { ... } And what about: . with : or ; OK. The symbol '.' is supposed to be used for the end of a sentence. At least, so we were told in grade school. In the case of programming, it should denote the end of a statement. So why is it that ';' is used to end statements, and '.' to access struct/class members? It seems so bass-ackwards. A semicolon (or a colon) is much more suitable for what amounts to a name composed of parts (module:object:property), because they signify partial stop, implying there's more to come. The period (or full-stop for you brits) '.' should be used to *end* statements, not to *continue* a multi-part name. But who am I to speak out against more than four decades of historical accidents, right? I think I'll shut up now. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Feb 16 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.460.1329459948.20196.digitalmars-d puremagic.com...
 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 = These two are the most annoying syntax inherited from C, IMNSHO. I mean, mathematically speaking, = is equality, not assignment. Traditionally := has been used for assignment; so why mix them up? Besides, what on earth is == anyway? Equal-equal? It makes no sense. And even worse, languages like Javascript that copied C's lousy choice of equality operator made it worse by introducing ===, which is both nonsensical in appearance and semantically a symptom of language maldesign. Next on the list is, of course: && with and (or perhaps &) || with or (or perhaps even |) The symbol '&' is commonly used to mean 'and', such as "John & Wiley's". So why the && stutter? Bitwise operations aren't used very much anyway, so they shouldn't be hogging single-character operators. Let bitwise AND be &&, and I'd be OK with that. But C has gotten it the wrong way round. Similarly '|' *has* been used traditionally to separate alternatives, such as in BNF notation, so there's no reason for that silly || stutter. Bitwise OR isn't used very often anyway, so if anything, | should be logial OR, and I suppose it's OK for || to be bitwise OR. Again C has it the wrong way round. But more importantly: ^^ with ^ ^ with something else altogether I mean, c'mon. Everybody knows ^ means superscript, that is, exponentiation. So why waste such a convenient symbol on bitwise XOR, which is only rarely used anyway?! It should simply be called 'xor' at best. Nobody who hasn't learned C (or its derivatives) knows what '^' means (in C) anyway. And then: ! with not Everyone knows ! means exclamation mark, or factorial. Having it also mean logical NOT is just needlessly confusing. What's wrong with 'not'? Or, since we have Unicode, what about �? Much clearer. As for bitwise NOT, '~' is about the most counterintuitive symbol for such a thing. My presumptuous guess is that Kernighan ran out of symbols on the keyboard for operators, so he resorted to ~. The symbol '~' should've been reserved for an "approximately equal" operator, useful in comparing floating-point numbers (which as we know usually shouldn't be compared with equality due to roundoff errors), like this: if (a ~ b) { ... } rather than today's baroque dance of: if (fabs(b-a) < EPSILON) { ... } And what about: . with : or ; OK. The symbol '.' is supposed to be used for the end of a sentence. At least, so we were told in grade school. In the case of programming, it should denote the end of a statement. So why is it that ';' is used to end statements, and '.' to access struct/class members? It seems so bass-ackwards. A semicolon (or a colon) is much more suitable for what amounts to a name composed of parts (module:object:property), because they signify partial stop, implying there's more to come. The period (or full-stop for you brits) '.' should be used to *end* statements, not to *continue* a multi-part name. But who am I to speak out against more than four decades of historical accidents, right? I think I'll shut up now.
Meh. All of the syntaxes you're advocating are every bit as arbitrary as the ones you're against. So what if there's some other convention used in a completely different discipline? Code isn't english, and code isn't math: The needs, use-cases, etc. are all totally different so it makes sence that a different set of conventions would be much more appropriate. These arguments reminds me of a non-programmer I once talked to who was complaining that different languages don't all use the same syntax for comments. My reaction was: 1. Who the hell cares? 2. They're *different* languages, why can't they *be* different?
Feb 16 2012
parent reply "F i L" <witte2008 gmail.com> writes:
 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. 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. 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. 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.
Feb 16 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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).
Feb 17 2012
next sibling parent reply "F i L" <witte2008 gmail.com> writes:
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" { ... }
Feb 17 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Feb 17 2012
parent "F i L" <witte2008 gmail.com> writes:
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.
Feb 17 2012
prev sibling parent reply "Daren Scot Wilson" <darenw darenscotwilson.com> writes:
On Friday, 17 February 2012 at 16:43:54 UTC, F i L wrote:

 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.
There is a profound difference in that math is mostly about making a series of static statements, universal or temporary facts of relationships between things, while programming is all about describing operations to be performed, even if hidden by functional or object costume. Math may use operators and functions, and programming sometimes assertions of relations, which makes reality not so clean cut simple, but this is the essential difference. It does not serve any purpose to insist on closely similar notations.
Feb 21 2012
parent reply "F i L" <witte2008 gmail.com> writes:
 It does not serve any purpose to insist on closely similar 
 notations.
So let's make '+' be '$' and '-' be '+'? My point wasn't that mathematical equations are identical to sequential code statements, but that they should, as much as possible, attempt to stay inline. It's all about how difficult programming is to pick-up.
Feb 22 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 11:15:35PM +0100, F i L wrote:
It does not serve any purpose to insist on closely similar
notations.
So let's make '+' be '$' and '-' be '+'?
Sounds like an esolang (http://esolangs.org/wiki/Main_Page) :) Maybe I should invent one. I'll call it EsoD, for Esoteric D (or Evil Strain Of D). Syntax is exactly the same as D, except that instead of are spelt backwards. Addition is denoted ^, multiplication &, subtraction *, and division (. Assignment is denoted ), equality is -, and field access {. Lists are delimited by +, and statements end with =. Since } isn't used for anything, we'll use that instead of for properties. So for example, here's a function that computes the average of an array: a c)0= hcaerof~d=b! $c^)d=% nruter c(b{htgnel= % Here's an example of how to use it: tropmi dts{oidts= diov naim~! $ % If this looks hard, don't worry, once you are past the initial learning curve, it will all become crystal clear to you. ;-) T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Feb 22 2012
parent reply "F i L" <witte2008 gmail.com> writes:
H. S. Teoh wrote:
 So for example, here's a function that computes the average of 
 an array:


 		a c)0=
 		hcaerof~d=b! $c^)d=%
 		nruter c(b{htgnel=
 	%

 Here's an example of how to use it:

 	tropmi dts{oidts=
 	diov naim~! $

 	%

 If this looks hard, don't worry, once you are past the initial 
 learning
 curve, it will all become crystal clear to you. ;-)
Could be promising for dyslexics ;)
Feb 22 2012
parent James Miller <james aatch.net> writes:
On 23 February 2012 19:28, F i L <witte2008 gmail.com> wrote:
 H. S. Teoh wrote:
 So for example, here's a function that computes the average of an array:


 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a c)0=3D
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hcaerof~d=3Db! $c=
^)d=3D%
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nruter c(b{htgnel=
=3D
 =C2=A0 =C2=A0 =C2=A0 =C2=A0%

 Here's an example of how to use it:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0tropmi dts{oidts=3D
 =C2=A0 =C2=A0 =C2=A0 =C2=A0diov naim~! $
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nletirw~f|~laer!~=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0%

 If this looks hard, don't worry, once you are past the initial learning
 curve, it will all become crystal clear to you. ;-)
Could be promising for dyslexics ;)
The problem I had with it was having to stop myself from reading the entire lines from right-to-left.
Feb 23 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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...
Feb 17 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.492.1329503475.20196.digitalmars-d puremagic.com...
 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.
I do agree with all of this, FWIW.
Feb 17 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Feb 17 2012
parent "F i L" <witte2008 gmail.com> writes:
On Friday, 17 February 2012 at 17:49:53 UTC, H. S. Teoh wrote:
 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
Yes, that's why i said "text (only)" because some concepts are simply so abstract in nature, that "writing down" the precise logic is the most efficient way to convey them. But typing is only more direct when you: 1) know the name of what you're looking for, and 2) The problem isn't visual, or you don't think visually. If you ask a person to move an object from point A to point B, they will visualize the movement and use their hands to carry it out without ever really analyzing which muscles or numerical angles they need for approach. Moving visual data, or even abstract objects like memory, around might be best "illustrated" to the computer by recording a more hands-on example and having the compiler optimize that behavior in the best possible way. With fine-tuning step-by-step control a natural, but more expert approach. In advertising, the more positive senses (sight, sound, touch, etc) you can associate with a product or brand, the more you'll get a positive knee-jerk response to that item, because emotional memory is reinforced through association like any other memory. In good UI design, visual/audial distinction serves to associate controls with their function, while striving to advertise as much positive emotion as possible. A good example of this is GMail's new interface where important controls are conveyed in red and options are blue. So while "fancy graphics" for the sake of advertising alone would do nothing to boost efficiency, "fancy functional graphics" could help make developing software more direct, more conveyable, and more enjoyable overall.
Feb 17 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
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.
 These two are the most annoying syntax inherited from C, 
 IMNSHO. I mean,
 mathematically speaking, = is equality, not assignment. 
 Traditionally :=
 has been used for assignment; so why mix them up? Besides, what 
 on earth
 is == anyway? Equal-equal? It makes no sense. And even worse, 
 languages
 like Javascript that copied C's lousy choice of equality 
 operator made
 it worse by introducing ===, which is both nonsensical in 
 appearance and
 semantically a symptom of language maldesign.

 Next on the list is, of course:

 	&&	with	and	(or perhaps &)
 	||	with	or	(or perhaps even |)

 The symbol '&' is commonly used to mean 'and', such as "John & 
 Wiley's".
 So why the && stutter? Bitwise operations aren't used very much 
 anyway,
 so they shouldn't be hogging single-character operators. Let 
 bitwise AND
 be &&, and I'd be OK with that. But C has gotten it the wrong 
 way round.

 Similarly '|' *has* been used traditionally to separate 
 alternatives,
 such as in BNF notation, so there's no reason for that silly || 
 stutter.
 Bitwise OR isn't used very often anyway, so if anything, | 
 should be
 logial OR, and I suppose it's OK for || to be bitwise OR. Again 
 C has it
 the wrong way round.
Agreed. Though '|' is used to accumulate bit flags, but I guess "flag1 || flag2 || etc" isn't so bad. Especially since, as you said, these situations aren't uses nearly as much as conditional OR. Still, I think the best would be to simply use keyword and/or and leave &/| as bitwise operations.
 But more importantly:

 	^^	with	^
 	^	with something else altogether

 I mean, c'mon. Everybody knows ^ means superscript, that is,
 exponentiation. So why waste such a convenient symbol on 
 bitwise XOR,
 which is only rarely used anyway?! It should simply be called 
 'xor' at
 best.  Nobody who hasn't learned C (or its derivatives) knows 
 what '^'
 means (in C) anyway.

 And then:

 	!	with	not

 Everyone knows ! means exclamation mark, or factorial. Having 
 it also
 mean logical NOT is just needlessly confusing. What's wrong 
 with 'not'?
 Or, since we have Unicode, what about ¬? Much clearer.

 As for bitwise NOT, '~' is about the most counterintuitive 
 symbol for
 such a thing. My presumptuous guess is that Kernighan ran out 
 of symbols
 on the keyboard for operators, so he resorted to ~. The symbol 
 '~'
 should've been reserved for an "approximately equal" operator, 
 useful in
 comparing floating-point numbers (which as we know usually 
 shouldn't be
 compared with equality due to roundoff errors), like this:

 	if (a ~ b) { ... }
 	
 rather than today's baroque dance of:

 	if (fabs(b-a) < EPSILON) { ... }
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 Seeing as how your right, '~' means "about" in math.
 And what about:

 	.	with	: or ;
 
 OK. The symbol '.' is supposed to be used for the end of a 
 sentence. At
 least, so we were told in grade school. In the case of 
 programming, it
 should denote the end of a statement. So why is it that ';' is 
 used to
 end statements, and '.' to access struct/class members? It 
 seems so
 bass-ackwards. A semicolon (or a colon) is much more suitable 
 for what
 amounts to a name composed of parts (module:object:property), 
 because
 they signify partial stop, implying there's more to come. The 
 period (or
 full-stop for you brits) '.' should be used to *end* 
 statements, not to
 *continue* a multi-part name.
I don't think lines need ending marks at all. So, seeing as how ':' takes two key presses and '.' only takes one, I'd opt to keep that as the default member-access operator.
 But who am I to speak out against more than four decades of 
 historical
 accidents, right? I think I'll shut up now.
Nothing wrong with being creative ;-) Even if we know these changes will most likely never be used. I've been experimenting with LLVM to write a proof-of-concept for Tuple syntax, language State-objects, and a modularized compiler designed to be also be an IDE parser. Just a simple test obviously, but I'm using these syntax concepts. Thanks for the input.
Feb 16 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 17 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Feb 17 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 17.02.2012, 16:08 Uhr, schrieb Nick Sabalausky <a a.a>:

 I've always agreed with the usual reasoning behind ":=3D and =3D inste=
ad of =3D
 and =3D=3D", 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 y=
ou.
 And yes, equality is fairly common, too, but *UNLIKE MATH*, equality i=
sn't
 quite *as* common as assignment. Plus, "=3D=3D" is even a little easie=
r 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 - i= n parts - on the spoken language you use, because different keyboard lay= outs are used. To pick up your example, I don't mind :=3D because I have= to hold [shift] already for a normal =3D. I just compared the default U= S and DE layouts. Here are some characters that can be achieved with one= key stroke in either layout exclusively: US: =3D[];'\/` So while the US layout lacks XOR and even + (wow), I'm a bit jealous on = =3D, array operations [], end of statement ;, division /, character deli= miter ', 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=3D= Pascal A flood of users from countries with a Cyrillic keyboard layout joined t= he competition using Pascal. Back then I thought it was just a random pr= evalence of Pascal for reasons like, that being the language taught in s= chools. 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 m= ore appealing: http://en.wikipedia.org/wiki/Keyboard_layout#Cyrillic Tha= t's just a wild theory. I might look into tuning a keyboard layout towards D programming a bit. = :)
Feb 17 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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: =[];'\/`

 
 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.
Feb 17 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 17.02.2012, 19:00 Uhr, schrieb H. S. Teoh <hsteoh quickfur.ath.cx>:

 I thought the US/English keyboard layout is already very well suited to
 D.
Yes, but I am still using the German (DE) layout, which has all the keys (so there was never a _need_ to switch) but almost every symbol I type requires the shift key. EN might be an alternative, but '+' with shift and '-' without? i don't know...
Feb 17 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.v9uav5gm9y6py2 marco-leise.homedns.org...
 EN might be an alternative, but '+' with shift and '-' without? i don't 
 know...
That does seem weird now that you mention it. I guess I just managed to get used to it. *shrug*
Feb 17 2012
parent reply James Miller <james aatch.net> writes:
I would like to add a few more points.
I exclusively use (g)vim text editing, why? Because it means I can jump on
a console, SSH into a server, and it will probably have vim, or atleast vi.
I also switch between languages frequently, I use PHP and JavaScript at
work; and D, bash and python in my spare time. Im used to frequent syntax
switching, even if they might all be C-style.
Ultimately, the smaller the official syntax is, the better, just look at
lisp.

James Miller -- On The Go
Feb 17 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"James Miller" <james aatch.net> wrote in message 
news:mailman.523.1329551034.20196.digitalmars-d puremagic.com...
I would like to add a few more points.
 I exclusively use (g)vim text editing, why? Because it means I can jump on
 a console, SSH into a server, and it will probably have vim, or atleast 
 vi.
I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim). But I prefer to do it like this: SSH into a server, but then also connect via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I can use *any* editor I want: kate, gedit, whatever. If I'm using a server that doesn't already have ssh set up (for instance, if I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can, I'll install mcedit which is the closest I've seen to what I would consider a nice text-mode editor.
Feb 18 2012
next sibling parent reply bcs <bcs example.com> writes:
On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
 "James Miller"<james aatch.net>  wrote in message
 news:mailman.523.1329551034.20196.digitalmars-d puremagic.com...
 I would like to add a few more points.
 I exclusively use (g)vim text editing, why? Because it means I can jump on
 a console, SSH into a server, and it will probably have vim, or atleast
 vi.
I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim).
Vi's not that hard to use if you don't expect to be a power user.
 But I prefer to do it like this: SSH into a server, but then also connect
 via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I
 can use *any* editor I want: kate, gedit, whatever.
How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases (I need to edit one line of one config file on this server I touch less than once a quarter.
 If I'm using a server that doesn't already have ssh set up (for instance, if
 I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can,
 I'll install mcedit which is the closest I've seen to what I would consider
 a nice text-mode editor.
Feb 18 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"bcs" <bcs example.com> wrote in message 
news:jhonpv$neg$1 digitalmars.com...
 On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
 I've heard a lot of people say that about vi(m), but in my (admittedly
 somewhat limited) experience, I've never come across a (Li|U)n[ui]x 
 system
 that didn't have nano or pico (neither of which are great, but they're 
 good
 enough for editing Unix configuration files, and I'm actually capable of
 using them, unlike emacs or vim).
Vi's not that hard to use if you don't expect to be a power user.
I figure I could probably get by with it (if I had to) as long as I grabbed a command reference and kept it nearby. But so far, I haven't felt any need or desire to do so.
 But I prefer to do it like this: SSH into a server, but then also connect
 via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, 
 I
 can use *any* editor I want: kate, gedit, whatever.
How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases
Same speed as any normal SSH login. Only difference is instead of doing: $ssh user domain You do: $sshfs user domain: /desired/local/mount/point Or if you don't want it rooted on the remote user's home dir: system or $sshfs user domain:/remote/dir /desired/local/mount/point Then to logout, it's just: $fusermount -u /desired/local/mount/point It literally is SSH, so the actual login process is exactly the same as SSH, whether you use a key-pair or a full login/pass. So however fast that is, that's how fast SSHFS is. I've never noticed any difference.
Feb 18 2012
parent bcs <bcs example.com> writes:
On 02/18/2012 06:13 PM, Nick Sabalausky wrote:
 "bcs"<bcs example.com>  wrote in message
 news:jhonpv$neg$1 digitalmars.com...
 On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
 I've heard a lot of people say that about vi(m), but in my (admittedly
 somewhat limited) experience, I've never come across a (Li|U)n[ui]x
 system
 that didn't have nano or pico (neither of which are great, but they're
 good
 enough for editing Unix configuration files, and I'm actually capable of
 using them, unlike emacs or vim).
Vi's not that hard to use if you don't expect to be a power user.
I figure I could probably get by with it (if I had to) as long as I grabbed a command reference and kept it nearby. But so far, I haven't felt any need or desire to do so.
I'm in a similar position, vi is my tty console editor of choice but not my goto editor for anything of much significance.
 But I prefer to do it like this: SSH into a server, but then also connect
 via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server,
 I
 can use *any* editor I want: kate, gedit, whatever.
How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases
Same speed as any normal SSH login. Only difference is instead of doing: $ssh user domain You do: $sshfs user domain: /desired/local/mount/point Or if you don't want it rooted on the remote user's home dir: system or $sshfs user domain:/remote/dir /desired/local/mount/point Then to logout, it's just: $fusermount -u /desired/local/mount/point It literally is SSH, so the actual login process is exactly the same as SSH, whether you use a key-pair or a full login/pass. So however fast that is, that's how fast SSHFS is. I've never noticed any difference.
That's kind of borderline for some uses.
Feb 19 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:
[...]
 I've heard a lot of people say that about vi(m), but in my (admittedly
 somewhat limited) experience, I've never come across a (Li|U)n[ui]x
 system that didn't have nano or pico (neither of which are great, but
 they're good enough for editing Unix configuration files, and I'm
 actually capable of using them, unlike emacs or vim).
I used to swear by pico. Until my manager at my first job convinced me to try vi. Ever since then, I've acquired this occasional twitching to randomly hit the Escape key every few seconds. ;-) [...]
 If I'm using a server that doesn't already have ssh set up (for
 instance, if I'm actually setting up ssh) *then* I'll either use
 nano/pico or, if I can, I'll install mcedit which is the closest I've
 seen to what I would consider a nice text-mode editor.
[...] I used to hate vi and its variants because of modality, which I just couldn't understand how anyone could consider as *not* a handicap. But I have to say, after having actually used it for quite a number of years now, I simply can't bear to go back to pico. Being able to move in text by words or blocks or even matching parentheses/brackets/braces with just a keystroke or two, or apply complex commands (like regexes) to large blocks of text at a time (thus effecting a very large change *reliably*), going back to pico is like going back to a 50-year-old screwdriver with a loose handle after having used a power drill. It makes me feel so crippled. Part of what makes vi useful is that many of its commands can deal with logical units greater than a single character. So you can, e.g., navigate by words or paragraphs or matching braces (extremely useful for moving around in code) with just one or two keystrokes, replace a word without needing to count how long it is, cut-n-paste n paragraphs (or words, etc.) around without needing to actually traverse them. In pico you'd have to select, then hit down X number of times per paragraph, before you can actually cut. In vi, you just type "d5}" to delete 5 paragraphs, then use '/' (search) to find the reinsertion point, and then 'p' to paste everything in there. You can also say, "cut to end of file" with just two keystrokes: "dG". My favorite is "replace up to closing parenthesis": "c/)<ESC>replacement_text<ESC>". Very useful for editing code without needing to recount parentheses. Furthermore, being able to tell the editor to repeat a (set of) commands n times is very useful, instead of having to manually repeat it yourself. Having logical units is useful here, e.g., you can repeatedly replace words of different lengths with a replacement word without needing to worry about mismatching lengths. In many ways, using vi vs. pico to me is, in retrospect, like using C arrays vs. D arrays. :) Everything you can do with D arrays and slices, you can do in C, just in a much more tedious and error-prone way. Similarly, pico can in principle do everything that vi does too, just that vi gets you there with less pain. Just my $0.02. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Feb 18 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.527.1329589896.20196.digitalmars-d puremagic.com...
 On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:

 [...]
 If I'm using a server that doesn't already have ssh set up (for
 instance, if I'm actually setting up ssh) *then* I'll either use
 nano/pico or, if I can, I'll install mcedit which is the closest I've
 seen to what I would consider a nice text-mode editor.
[...] I used to hate vi and its variants because of modality, which I just couldn't understand how anyone could consider as *not* a handicap.
For most of these things you mention, I'd argue a modal editor like vi isn't really necessary. For instance I use Programmer's Notepad 2 (Windows-only, unfortunately) which is a "normal" word-processor-style GUI editor, and with it:
 But I have to say, after having actually used it for quite a number of
 years now, I simply can't bear to go back to pico. Being able to move in
 text by words
Ctrl-Left, Ctrl-Right
 or blocks or even matching parentheses/brackets/braces
 with just a keystroke or two,
I'm not sure if PN2 in particular does this, but I know that's fairly common in many typical non-VI/non-emacs editors.
 or apply complex commands (like regexes)
 to large blocks of text at a time (thus effecting a very large change
 *reliably*),
PN2 has regex find/replace. VS has it, too, and I'm sure many others. I agree, it *is* a fantastic thing to have.
 going back to pico is like going back to a 50-year-old
 screwdriver with a loose handle after having used a power drill. It
 makes me feel so crippled.

 Part of what makes vi useful is that many of its commands can deal with
 logical units greater than a single character. So you can, e.g.,
 navigate by words
Like I said, Ctrl-Left, Ctrl-Right
 or paragraphs
Not sure what that means in the context of code...? But I have the standard PgUp/PgDn/Home/End, FWIW.
 or matching braces (extremely useful for
 moving around in code) with just one or two keystrokes,
Again, fairly common even outside VI.
 replace a word
 without needing to count how long it is,
Replace following word: Shift-Ctrl-Right, Type new word Replace preceding word: Shift-Ctrl-Right, Type new word Replace random specific word: Double-click, Type new word
 cut-n-paste n paragraphs (or words, etc.)
 around without needing to actually traverse them. In pico
 you'd have to select, then hit down X number of times per paragraph,
Or mouse on most editors, which really isn't as bad as people make it out to be. (But maybe it's just because I'm on a trackball.)
 before you can actually cut. In vi, you just type "d5}" to delete 5
 paragraphs,
Yea, but that way, you have to actually count out what you need. Personally, I'd much rather traverse.
 then use '/' (search) to find the reinsertion point, and
 then 'p' to paste everything in there.
Ctrl-F: Quick find (not the default, but that's how I have it set up) Esc, Ctrl-V Yea, there's the Ctrl and Esc, but it's not so bad.
 You can also say, "cut to end of
 file" with just two keystrokes: "dG".
Shift-Ctrl-End, Ctrl-X This works, too: Shift-Ctrl-(End, then X)
 My favorite is "replace up to
 closing parenthesis": "c/)<ESC>replacement_text<ESC>". Very useful for
 editing code without needing to recount parentheses.
Assuming one of the many editors that supports "jump to paren" and such things: Shift-Ctrl-(whatever key it is), replacement_text
 Furthermore, being able to tell the editor to repeat a (set of) commands
 n times is very useful, instead of having to manually repeat it
 yourself.
Yea, admittedly that's not very common with "normal" editors, unless you count editor scripting (PN2 uses Python). But there's nothing stopping them from enhancing that with macro recording/playback.
 Having logical units is useful here, e.g., you can repeatedly
 replace words of different lengths with a replacement word without
 needing to worry about mismatching lengths.
Again, Shift-Ctrl-Left/Right, or Shift-(whatever other navigation keys/shortcuts you happen to have available).
 Similarly, pico can in principle do everything that vi does too,
Even *I* very much doubt that ;) Pico's benefit is that it's at least usable by people who are used to the typical word-processor-style editors. But feature-rich it certainly ain't (unless it's all hidden somewhere?).
 just that vi gets you there with less pain.

 Just my $0.02.
Yea. I'm not saying that VI isn't nice for those who have learned it and like it. But I don't think the typical eclipse/word-processor-style editors are much, if at all, behind on the tricks you describe. Certainly not impossible in theory (I can easily imagine an editor allowing "Ctrl-{number}-Right" for "Move {number} words to the right"). It sounds to me like the difference isn't so much "modal vs modeless" as it is whether you escape to the special modes by pressing a key or by holding a key. VI: Press a key. Others: Hold a key. The "Hold a key" is easier for new users since the mode always "snaps back" whenever you let go (or when you press Esc, if you're using something like Quick Find). But I understand that some people can get used to VI's...umm..."persistent" modality.
Feb 18 2012
next sibling parent Jose Armando Garcia <jsancio gmail.com> writes:
On Sun, Feb 19, 2012 at 1:31 AM, Nick Sabalausky <a a.a> wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.527.1329589896.20196.digitalmars-d puremagic.com...
 On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:

 [...]
 If I'm using a server that doesn't already have ssh set up (for
 instance, if I'm actually setting up ssh) *then* I'll either use
 nano/pico or, if I can, I'll install mcedit which is the closest I've
 seen to what I would consider a nice text-mode editor.
[...] I used to hate vi and its variants because of modality, which I just couldn't understand how anyone could consider as *not* a handicap.
For most of these things you mention, I'd argue a modal editor like vi isn't really necessary. For instance I use Programmer's Notepad 2 (Windows-only, unfortunately) which is a "normal" word-processor-style GUI editor, and with it:
 But I have to say, after having actually used it for quite a number of
 years now, I simply can't bear to go back to pico. Being able to move in
 text by words
Ctrl-Left, Ctrl-Right
 or blocks or even matching parentheses/brackets/braces
 with just a keystroke or two,
I'm not sure if PN2 in particular does this, but I know that's fairly common in many typical non-VI/non-emacs editors.
 or apply complex commands (like regexes)
 to large blocks of text at a time (thus effecting a very large change
 *reliably*),
PN2 has regex find/replace. VS has it, too, and I'm sure many others. I agree, it *is* a fantastic thing to have.
 going back to pico is like going back to a 50-year-old
 screwdriver with a loose handle after having used a power drill. It
 makes me feel so crippled.

 Part of what makes vi useful is that many of its commands can deal with
 logical units greater than a single character. So you can, e.g.,
 navigate by words
Like I said, Ctrl-Left, Ctrl-Right
 or paragraphs
Not sure what that means in the context of code...? But I have the standard PgUp/PgDn/Home/End, FWIW.
 or matching braces (extremely useful for
 moving around in code) with just one or two keystrokes,
Again, fairly common even outside VI.
 replace a word
 without needing to count how long it is,
Replace following word: Shift-Ctrl-Right, Type new word Replace preceding word: Shift-Ctrl-Right, Type new word Replace random specific word: Double-click, Type new word
 cut-n-paste n paragraphs (or words, etc.)
 around without needing to actually traverse them. In pico
 you'd have to select, then hit down X number of times per paragraph,
Or mouse on most editors, which really isn't as bad as people make it out to be. (But maybe it's just because I'm on a trackball.)
 before you can actually cut. In vi, you just type "d5}" to delete 5
 paragraphs,
Yea, but that way, you have to actually count out what you need. Personally, I'd much rather traverse.
 then use '/' (search) to find the reinsertion point, and
 then 'p' to paste everything in there.
Ctrl-F: Quick find (not the default, but that's how I have it set up) Esc, Ctrl-V Yea, there's the Ctrl and Esc, but it's not so bad.
 You can also say, "cut to end of
 file" with just two keystrokes: "dG".
Shift-Ctrl-End, Ctrl-X This works, too: Shift-Ctrl-(End, then X)
 My favorite is "replace up to
 closing parenthesis": "c/)<ESC>replacement_text<ESC>". Very useful for
 editing code without needing to recount parentheses.
Assuming one of the many editors that supports "jump to paren" and such things: Shift-Ctrl-(whatever key it is), replacement_text
 Furthermore, being able to tell the editor to repeat a (set of) commands
 n times is very useful, instead of having to manually repeat it
 yourself.
Yea, admittedly that's not very common with "normal" editors, unless you count editor scripting (PN2 uses Python). But there's nothing stopping them from enhancing that with macro recording/playback.
 Having logical units is useful here, e.g., you can repeatedly
 replace words of different lengths with a replacement word without
 needing to worry about mismatching lengths.
Again, Shift-Ctrl-Left/Right, or Shift-(whatever other navigation keys/shortcuts you happen to have available).
 Similarly, pico can in principle do everything that vi does too,
Even *I* very much doubt that ;) Pico's benefit is that it's at least usable by people who are used to the typical word-processor-style editors. But feature-rich it certainly ain't (unless it's all hidden somewhere?).
 just that vi gets you there with less pain.

 Just my $0.02.
Yea. I'm not saying that VI isn't nice for those who have learned it and like it. But I don't think the typical eclipse/word-processor-style editors are much, if at all, behind on the tricks you describe. Certainly not impossible in theory (I can easily imagine an editor allowing "Ctrl-{number}-Right" for "Move {number} words to the right"). It sounds to me like the difference isn't so much "modal vs modeless" as it is whether you escape to the special modes by pressing a key or by holding a key. VI: Press a key. Others: Hold a key. The "Hold a key" is easier for new users since the mode always "snaps back" whenever you let go (or when you press Esc, if you're using something like Quick Find). But I understand that some people can get used to VI's...umm..."persistent" modality.
What you just described is called Kung Fu Typing or Emacs Kung Fu. Vim has a little of it too. The common example is Ctrl-r which redoes or undoes the undo. In general Vim tries to avoid it and you can map redo to a different key(-stroke) if you like. Let the editor flame war continue... -Jose
Feb 19 2012
prev sibling parent James Miller <james aatch.net> writes:
I think the difference between chording and non-chording styles of
input depends on the person. I have dyspraxia, which affects my fine
motor control, so remembering and performing complex key sequences
(such as emacs' keyboard shortcuts) is difficult for me, hell I have
difficulty correctly typing ":qa:" properly to quit vim, I often type
":Qa" because I can't take my hand off the keyboard fast enough. I
mistype so often, especially when I have little mnemonic data to go
on.

Shift-Ctrl-End, Ctrl-X is two chords and 5 keystrokes, with <End>
being off my normal typing position, even if I used that combination
for years, I'll likely still get it wrong 1-2 times out of ten. I've
been vim-ing for about 2 years now, I still get the movement keys
wrong. I still type commands that I could bind to shortcut keys, or
already have bindings (":redo") for example. I create ways to remember
most keys, "i" for insert, "r" for replace, "s" for substitute, "d"
for delete, "p" for paste, "g" for go (sometimes), "a" for append, "c"
for cut. But I can't remember modifier keys normally, especially Ctrl
and Alt, I've set most of the keyboard shortcuts on my window manager,
I don't remember a lot of them, because they use <Mod4> (Windows
key/Meta key).

My point is, there's more to modal vs modeless than just how friendly
it is, once I got over the initial hurdle, and forcibly trained myself
to use h, j, k and l for motion (by disabling the arrow keys) I became
far more productive in Vim than I did in any other editor, simply
because I could use single key strokes for actions, I still press
<Esc> just before doing any non-insert on text, even if I'm already in
normal mode, and I still get things wrong, but I find it far easier to
type "dwdwdwdw" to delete 4 words that to type
<Ctrl>-<Shift>-<Right>,<Right>,<Right>,<Right>,<Del>, because its hard
for me to hit keys if I have to move far. Pressing "dd" to delete a
line is easier for me than doing <Home>,<Shift>-<End>,<Del>,<Del>
because its a single key, if I got it once, then I can get it again.

I don't care what editor you use, but I didn't pick mine simply
because I wanted more hacker cred, I picked mine because it allows me
to work around my disabilities.

For the record, while I didn't track it, I estimate that I made about
an average of 1 mistake per word typing this message, I mis-typed
"track" 4 times in this sentence.

--
James Miller
Feb 19 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 18.02.2012 18:10, schrieb Nick Sabalausky:
 "James Miller"<james aatch.net>  wrote in message
 news:mailman.523.1329551034.20196.digitalmars-d puremagic.com...
 I would like to add a few more points.
 I exclusively use (g)vim text editing, why? Because it means I can jump on
 a console, SSH into a server, and it will probably have vim, or atleast
 vi.
I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim). But I prefer to do it like this: SSH into a server, but then also connect via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I can use *any* editor I want: kate, gedit, whatever. If I'm using a server that doesn't already have ssh set up (for instance, if I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can, I'll install mcedit which is the closest I've seen to what I would consider a nice text-mode editor.
Well, it's been a while, but in a previous life many moons ago (2000-2003), most of customers at the company I worked for, had plain instalations of Solaris and HP-UX with only vi (not vim) and ed available. Oh, and the shells were the original sh or zsh without any of the GNU/BSD nice extensions. -- Paulo
Feb 18 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 17, 2012 at 08:44:48AM +0100, F i L wrote:
 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.
Are you referring to: int x = 10; vs. x = 10; ? In that case I would still prefer :=, since the first can be thought of as shorthand for "int x; x := 10". [...]
 Agreed. Though '|' is used to accumulate bit flags, but I guess "flag1
 || flag2 || etc" isn't so bad. Especially since, as you said, these
 situations aren't uses nearly as much as conditional OR.  Still, I
 think the best would be to simply use keyword and/or and leave &/| as
 bitwise operations.
I've always been of the opinion that common things should be shorter to type, and less common things is OK to be harder to type. So I still sorta lean towards & and | for logical and/or. [...]
As for bitwise NOT, '~' is about the most counterintuitive symbol for
such a thing. My presumptuous guess is that Kernighan ran out of
symbols on the keyboard for operators, so he resorted to ~. The
symbol '~' should've been reserved for an "approximately equal"
operator, useful in comparing floating-point numbers (which as we
know usually shouldn't be compared with equality due to roundoff
errors), like this:

	if (a ~ b) { ... }
	
rather than today's baroque dance of:

	if (fabs(b-a) < EPSILON) { ... }
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 Seeing as how your right, '~' means "about" in math.
Well, using + for array append leads to all sorts of problems, as you can see in Javascript: [] + [] = "" [] + {} = {} {} + [] = NaN OK, this craziness is also the responsibility of JS's implicit conversion rules, which D doesn't have (fortunately), but overloading + for both numerical addition and array append is not a good thing.
And what about:

	.	with	: or ;

OK. The symbol '.' is supposed to be used for the end of a sentence.
At least, so we were told in grade school. In the case of
programming, it should denote the end of a statement. So why is it
that ';' is used to end statements, and '.' to access struct/class
members? It seems so bass-ackwards. A semicolon (or a colon) is much
more suitable for what amounts to a name composed of parts
(module:object:property), because they signify partial stop, implying
there's more to come. The period (or full-stop for you brits) '.'
should be used to *end* statements, not to *continue* a multi-part
name.
I don't think lines need ending marks at all.
This leads to ambiguity problems if it's unclear whether two adjacent lines are a single statement or two. It also makes the grammar much harder to implement in a parser, because it can't easily tell between the end of a statement and a wrapped line. Having a statement separator is a good thing. [...]
But who am I to speak out against more than four decades of
historical accidents, right? I think I'll shut up now.
Nothing wrong with being creative ;-) Even if we know these changes will most likely never be used.
More like, they will obviously never be used. :-) We have 4 decades of historical accidents weighing against us. Still, it's nice to dream about the ideal language sometimes. :-) Having said that though, I have to admit that I'm *still* most comfortable with C-like syntax (and by extension, current D syntax). It's not perfect, but it's nice and concise and to-the-point, and also I've grown accustomed to its quirks, so what I wrote was more a nitpick and a what-my-ideals-are rather than real complaints about the current syntax.
 I've been experimenting with LLVM to write a proof-of-concept for
 Tuple syntax, language State-objects, and a modularized compiler
 designed to be also be an IDE parser.  Just a simple test obviously,
 but I'm using these syntax concepts.  Thanks for the input.
[...] Wait, you're trying to reimplement D syntax?? T -- Любишь кататься - люби и саночки возить.
Feb 17 2012
parent reply "F i L" <witte2008 gmail.com> writes:
H. S. Teoh wrote:
 Are you referring to:

 	int x = 10;

 vs.

 	x = 10;

 ?

 In that case I would still prefer :=, since the first can be 
 thought of
 as shorthand for "int x; x := 10".
I'm not sure what you're asking/saying here. What I mean is that there needs to be some distinction between variable declarations and variable assignment. Foo: class { x: int // lots of code bar: void() { x := 0 // set Foo.x or create a local 'x' variable? } }
 I don't think lines need ending marks at all.
This leads to ambiguity problems if it's unclear whether two adjacent lines are a single statement or two. It also makes the grammar much harder to implement in a parser, because it can't easily tell between the end of a statement and a wrapped line. Having a statement separator is a good thing.
I don't think this leads to ambiguity problems, I've thought about this before and can't come up with any that aren't easily addressed. Also, I don't think is much harder to parse at all, just when the statement is determined to stop needs to be slightly more intelligent. If we can understand the code without ending-marks, a compiler should be able to understand it as well. This is something I'm experimenting with at the moment with LLVM.
 Wait, you're trying to reimplement D syntax??
Nothing so robust. Mostly I'm playing around with compiler design while refreshing my C++ abilities (which it's been awhile). My main focus is to try and build a simplistic compiler around the concept of having an AST designed to stay in memory and be dynamically submitted changes and on-demand compilation (like NRefactory, or MS Roslyn). Kinda like and interrupter only designed with the goal of 1) Non-text forms of manipulation and logic construction, and 2) modularized AST libraries as development reflection tools (think objects overview, code-completion, etc). I'm thinking of textual syntax as more of "commands" to submit AST nodes, so there's no real "syntax" beyond what's saved in a file, which isn't really suppose to be humanly read/written though a traditional text editor. I think "standard tools" (+ modularized to used by other tools) are as important as standard libraries. Just a hobby :)
Feb 17 2012
parent "Paul D. Anderson" <paul.d.removethis.anderson comcast.andthis.net> writes:
On Friday, 17 February 2012 at 20:52:56 UTC, F i L wrote:
 H. S. Teoh wrote:
 Are you referring to:

 	int x = 10;

 vs.

 	x = 10;

 ?

 In that case I would still prefer :=, since the first can be 
 thought of
 as shorthand for "int x; x := 10".
I'm not sure what you're asking/saying here. What I mean is that there needs to be some distinction between variable declarations and variable assignment. Foo: class { x: int // lots of code bar: void() { x := 0 // set Foo.x or create a local 'x' variable? } }
 I don't think lines need ending marks at all.
This leads to ambiguity problems if it's unclear whether two adjacent lines are a single statement or two. It also makes the grammar much harder to implement in a parser, because it can't easily tell between the end of a statement and a wrapped line. Having a statement separator is a good thing.
I don't think this leads to ambiguity problems, I've thought about this before and can't come up with any that aren't easily addressed. Also, I don't think is much harder to parse at all, just when the statement is determined to stop needs to be slightly more intelligent. If we can understand the code without ending-marks, a compiler should be able to understand it as well. This is something I'm experimenting with at the moment with LLVM.
 Wait, you're trying to reimplement D syntax??
Nothing so robust. Mostly I'm playing around with compiler design while refreshing my C++ abilities (which it's been awhile). My main focus is to try and build a simplistic compiler around the concept of having an AST designed to stay in memory and be dynamically submitted changes and on-demand compilation (like NRefactory, or MS Roslyn). Kinda like and interrupter only designed with the goal of 1) Non-text forms of manipulation and logic construction, and 2) modularized AST libraries as development reflection tools (think objects overview, code-completion, etc). I'm thinking of textual syntax as more of "commands" to submit AST nodes, so there's no real "syntax" beyond what's saved in a file, which isn't really suppose to be humanly read/written though a traditional text editor. I think "standard tools" (+ modularized to used by other tools) are as important as standard libraries. Just a hobby :)
http://en.wikipedia.org/wiki/Forth_%28programming_language%29
Feb 17 2012
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
 But who am I to speak out against more than four decades of 
 historical
 accidents, right? I think I'll shut up now.
Can you forgive me a little investigation? I heard similar proposals and wonder where they come from. What do you think? It can't be python or golang, because they were already designed with there thoughts in mind.
Feb 22 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 07:57:31PM +0100, Kagamin wrote:
 On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
But who am I to speak out against more than four decades of
historical accidents, right? I think I'll shut up now.
Can you forgive me a little investigation? I heard similar proposals and wonder where they come from. What do you think? It can't be python or golang, because they were already designed with there thoughts in mind.
Wait, which proposal? To replace && and || with 'and' and 'or'? Or my slightly extreme rant about replacing '==' with '=' and '=' with ':=', amongst other things? T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Feb 22 2012
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 22 February 2012 at 19:04:55 UTC, H. S. Teoh wrote:
 Wait, which proposal? To replace && and || with 'and' and 'or'?

 Or my slightly extreme rant about replacing '==' with '=' and 
 '=' with
 ':=', amongst other things?
Well, it's hard to explain. Proposals like python's semantic whitespace or golang's "array of ints should be typed as []int in order to match the pronunciation sequence: array-of-ints" or equality should be '='. I don't know why, but they have something in common.
Feb 22 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 08:35:21PM +0100, Kagamin wrote:
 On Wednesday, 22 February 2012 at 19:04:55 UTC, H. S. Teoh wrote:
Wait, which proposal? To replace && and || with 'and' and 'or'?

Or my slightly extreme rant about replacing '==' with '=' and '='
with ':=', amongst other things?
Well, it's hard to explain. Proposals like python's semantic whitespace
These come from Python users. :P And maybe the fact that some people, for reasons unknown to me, just can't stand the sight of delimiting blocks with '{' and '}'. It's almost as if they get the creepy-crawlies when they see '{' and '}'. They'd much rather deal with words like 'begin' and 'end', or Python's semantic whitespace.
 or golang's "array of ints should be typed as []int in order to match
 the pronunciation sequence: array-of-ints"
That's just a native language bias. Well, it's not even that. If you interpret 'int' as an adjective, then int[] totally makes sense. But if you interpret 'int' as a genitive noun, then it'd be []int. To me, I find []int ineffably ugly. Even array(int) is better than []int. But that's just me. Whether you write int x[]; or int[] x; or []int x; or even x int[]; or any other permutation thereof, ultimately it's just a matter of conveying three pieces of information to the compiler: the name of the variable, the base type, and the fact that it's an array of the base type. If you could write code in 3D, you could equally well put these three elements in a triangle parallel to the flow of code, in which case order wouldn't even be an issue. So it all boils down to personal preference.
 or equality should be '='.
That's coming from math geeks like me. :P
 I don't know why, but they have something in common.
I'm not sure I know what you're referring to. What else do they have in common, besides wanting to tweak language syntax to suit one's own preferences? Preferences are shaped by what one is familiar with. I'm sure if you manage to herd enough APL programmers in here, they'd be clamoring for D to start using APL symbols instead of this verbose procedural trash like for-loops. :-) Or if you herd enough Lisp programmers in here... oh wait, we already have std.functional. :-P The only thing missing is to replace all ; with , (except after the last statement in a block), standardize on () for {}, [] and (), then rename some keywords, and it'd be Lisp heaven on earth! T -- It only takes one twig to burn down a forest. It only takes one twit to burn down a project.
Feb 22 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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. 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. 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. 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.
Feb 16 2012
parent reply "F i L" <witte2008 gmail.com> writes:
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.
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.
Feb 17 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
The better question is why is there no 'any' and 'all' template in Phobos!
Feb 17 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 17 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Feb 17 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 17 2012
parent "F i L" <witte2008 gmail.com> writes:
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 } }
Feb 17 2012