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