www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - why ; ?

reply Tomasz Sowinski <tomeksowi gmail.com> writes:
Just another feature thought. Never gonna happen, but still...

What's the reason of having lines end with a semicolon? Anything else than a
legacy issue with C/C++?

The only thing I can think of is having multiple statements in one line, but
that only makes code unreadable. Wouldn't getting rid of ; improve readability?


Tomek
May 05 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Tomasz Sowinski wrote:

 Just another feature thought. Never gonna happen, but still...
 
 What's the reason of having lines end with a semicolon? Anything else than a
legacy issue with C/C++?
 
 The only thing I can think of is having multiple statements in one line, but
that only makes code unreadable. Wouldn't getting rid of ; improve readability?
 
 
 Tomek


So the end of a statement would be marked by a newline character a la 
Python?

I usually like to keep my lines under 80 characters long for 
readability, and occasionally have long statements (especially if 
there's a ternary operator in there somewhere), so my vote is "nay". 
There are various other arguments against it, too (especially in that it 
makes parsing easier).
May 05 2008
next sibling parent reply Tomasz Sowinski <tomeksowi gmail.com> writes:
Robert Fraser Wrote:


 So the end of a statement would be marked by a newline character a la 
 Python?


yes


 I usually like to keep my lines under 80 characters long for 
 readability, and occasionally have long statements (especially if 
 there's a ternary operator in there somewhere), so my vote is "nay".


Maybe a breakline symbol like in Ruby or VB for long statements?
 

 There are various other arguments against it, too (especially in that it 
 makes parsing easier).


There is a meaningful newline character anyway to know where the // comment
ends, so would removing ; make a big difference in parsing?

I'm not arguing. As I said, I know it's never going to happen, I was just
curious about those "other various arguments".
May 05 2008
next sibling parent BCS <BCS pathlink.com> writes:
Tomasz Sowinski wrote:


 
 There is a meaningful newline character anyway to know where the // comment
ends


as a side issue, that is a lexical effect. The newline is part of the 
comment token so it likely never even shows up in the parser.
May 05 2008
prev sibling next sibling parent reply Tom <tom nospam.com> writes:
Tomasz Sowinski escribió:

 Robert Fraser Wrote:
 

 So the end of a statement would be marked by a newline character a la 
 Python?


 
 yes
 

 I usually like to keep my lines under 80 characters long for 
 readability, and occasionally have long statements (especially if 
 there's a ternary operator in there somewhere), so my vote is "nay".


 
 Maybe a breakline symbol like in Ruby or VB for long statements?
  


Please no!

Tom;
May 05 2008
parent reply Michael Neumann <mneumann ntecs.de> writes:
Tom wrote:

 Tomasz Sowinski escribió:

 Robert Fraser Wrote:


 So the end of a statement would be marked by a newline character a la
 Python?


 yes


 I usually like to keep my lines under 80 characters long for
 readability, and occasionally have long statements (especially if
 there's a ternary operator in there somewhere), so my vote is "nay".


 Maybe a breakline symbol like in Ruby or VB for long statements?


 Please no!


It is very successful in Ruby! But Ruby is a very different language.
Ruby allows you to separate statements with ";" in one line. And it
recognises statements that cross a line boundary like shown below:

   a +
   b
   ==> a + b

   a
   + b
   ==> a; +b (probably not what you want!)

One problem is clearly (as Walter said) that reporting syntax errors can
become hard, or very unprecise. The latter is the case in Ruby.

Regards,

   Michael
May 06 2008
parent reply Daniel Giddings <daniel.giddings gmail.com> writes:
; also works in Python as a line separator:

print "a" ; print "b"

and it gives quite good syntax error messages

Personally I'm more in favor of the Python style code as opposed to C 
style code, because while you might need a \ line break char for some 
code, it is very much the exception to the rule - saving quite an amount 
of hassle.

:-) Dan

Michael Neumann wrote:

 Tom wrote:
  > Tomasz Sowinski escribió:
  >> Robert Fraser Wrote:
  >>
  >>> So the end of a statement would be marked by a newline character a la
  >>> Python?
  >>
  >> yes
  >>
  >>> I usually like to keep my lines under 80 characters long for
  >>> readability, and occasionally have long statements (especially if
  >>> there's a ternary operator in there somewhere), so my vote is "nay".
  >>
  >> Maybe a breakline symbol like in Ruby or VB for long statements?
  >>
  >
  > Please no!
 
 It is very successful in Ruby! But Ruby is a very different language.
 Ruby allows you to separate statements with ";" in one line. And it
 recognises statements that cross a line boundary like shown below:
 
   a +
   b
   ==> a + b
 
   a
   + b
   ==> a; +b (probably not what you want!)
 
 One problem is clearly (as Walter said) that reporting syntax errors can
 become hard, or very unprecise. The latter is the case in Ruby.
 
 Regards,
 
   Michael
May 06 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 07/05/2008, Daniel Giddings <daniel.giddings gmail.com> wrote:

 while you might need a \ line break char for some code, it is
 very much the exception to the rule


Not if you are obliged (against your will) to write maximum-80-column
code, it isn't. In that circumstance, wrapping lines is very, very
common.

You are also forgetting that any statement block { ... } is
effectively a single statement, and that, if (...) { ... } else { ...
} is also a single statement. And within any statement, passing a
delegate literal to a function - e.g foo(delegate int(int x){ ... });
is still a single expression. In fact the whole concept of what is or
is not a "single statement" is really quite nebulous.

I suppose you could always make indentation significant too. But
here's an idea - how about, let's not.

Please let's keep our semicolons.
May 06 2008
next sibling parent sambeau <sambeau-nospam mac.com> writes:
Janice Caron Wrote:


 I suppose you could always make indentation significant too. But
 here's an idea - how about, let's not.


:-D
May 06 2008
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el  7 de mayo a las 05:22 me escribiste:

 On 07/05/2008, Daniel Giddings <daniel.giddings gmail.com> wrote:

 while you might need a \ line break char for some code, it is
 very much the exception to the rule


 
 Not if you are obliged (against your will) to write maximum-80-column
 code, it isn't. In that circumstance, wrapping lines is very, very
 common.


Only if you make a lot of steps in the same line or use incredibly long
variables or have a very deep nesting of blocks. Avoiding that usually
improves code readability and maintainability.


 You are also forgetting that any statement block { ... } is
 effectively a single statement, and that, if (...) { ... } else { ...
 } is also a single statement. And within any statement, passing a
 delegate literal to a function - e.g foo(delegate int(int x){ ... });
 is still a single expression. In fact the whole concept of what is or
 is not a "single statement" is really quite nebulous.


*This* is the real problem with making ';' and '{}' optional and why I
stop suggesting this change myself =)

I think Python syntax is way much more elegant and readable than C-like
syntax, but D has some constructions that are very dependant on '{}' and
';'.

Even so, making them *optional* it's maybe possible. You can mark blocks
with indentation *or* '{}', let's say:

void main()
	auto x = some_func((int i) { return i + 5 }) // {} are mandatory for delegates
	while (x)
		x = 0
		{ auto x = 1; writefln("this is a new block") }

A statement is parsed until ';' *or* EOL, a block is defined either by
deeper indentation *or* '{}'. Some constructs have mandatory block
delimitation using '{}'. This syntax should not be hard to parse,
you can give meaningfull errors, and you get backward compatibility.

Everybody should be happy, except from Walter, who has to touch the
parser =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Cada movimiento que no se hace, es un movimiento que se pierde.
Y cada movimiento que se pierde, se transforma en una mochila.
Y las mochilas nos alejan, de nuestros amigos y nuestras amigas.
Y nuestros amigos se transforman, en enemigos y en enemigas.
Cada movimiento que se hace, es una mochila que se deja.
May 07 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella Wrote [...]

I also suggest to take a look at the well designed Scala language, I think it
has optional ; 

Bye,
bearophile
May 07 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

An example of Scala code:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=meteor&lang=scala&id=4

More examples can be found near that one...

Bye,
bearophile
May 07 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 07/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

 Even so, making them *optional* it's maybe possible.
 <snip>
 Everybody should be happy, except from Walter, who has to touch the
 parser =)


Absolutely not. I deeply, deeply want semicolons to remain compulsory.

Lose that, and you lose redundancy.
Lose redundancy and you lose meaningful error messages.
May 07 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.547.1210179260.2351.digitalmars-d puremagic.com...

 On 07/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

 Even so, making them *optional* it's maybe possible.
 <snip>
 Everybody should be happy, except from Walter, who has to touch the
 parser =)


 Absolutely not. I deeply, deeply want semicolons to remain compulsory.

 Lose that, and you lose redundancy.
 Lose redundancy and you lose meaningful error messages.


It always seems funny that your opinions are exactly the same as Walter's. 
I mean, I think that's almost word-for-word what he said.

As I explained about my experience making semicolons optional in MiniD, I 
haven't run into any situations where skipping semicolons has been a 
problem.  The compiler still gives fine error messages.  They're 
unneccessary in virtually every case.  In the (one!) case where there's an 
ambiguity (though there might be a couple more in D), the compiler doesn't 
silently choose one, unintuitively; it gives a reasonable error.

I'd be interested to know your views on the issue if Walter was ambivalent 
on the issue or if he was for it.
May 07 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el  7 de mayo a las 17:54 me escribiste:

 On 07/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

 Even so, making them *optional* it's maybe possible.
 <snip>
 Everybody should be happy, except from Walter, who has to touch the
 parser =)


 
 Absolutely not. I deeply, deeply want semicolons to remain compulsory.
 
 Lose that, and you lose redundancy.
 Lose redundancy and you lose meaningful error messages.


No you don't, \n is your redundancy. So you still get meaningful messages.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
When I was a child
I caught a fleeting glimpse
Out of the corner of my eye.
I turned to look but it was gone
I cannot put my finger on it now
The child is grown,
The dream is gone.
I have become comfortably numb.
May 07 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 08/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

 No you don't, \n is your redundancy. So you still get meaningful messages.


That would be true IF AND ONLY IF we were forced to escape newlines
that didn't mean end-of-statement. e.g.

    auto a = b \
    (c)

I wasn't aware that requiring me to escaping newlines was part of the
suggestion. If it was, then I'm even more against it.

Besides which, how would that work with statements like

    if (a == b) { ++i; ++j } else { --i; --j }

If newlines were to take over the role of semicolons, then that would turn into

    if (a == b) { ++i
    ++j } else { --i
    --j }

Yuk.
May 07 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.550.1210220618.2351.digitalmars-d puremagic.com...

 Besides which, how would that work with statements like

    if (a == b) { ++i; ++j } else { --i; --j }

 If newlines were to take over the role of semicolons, then that would turn 
 into

    if (a == b) { ++i
    ++j } else { --i
    --j }


Not that I'm advocating any "non-compulsory semicolon" syntax, but couldn't 
the first one work fine by saying "Newline and semicolon are BOTH 
interpreted as end-of-statement"? (aside from the issue of "with or without 
a continue-on-next-line symbol"). Or am I just taking the discusion in a 
circle?
May 07 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
2008/5/8 Nick Sabalausky <a a.a>:

  Not that I'm advocating any "non-compulsory semicolon" syntax, but couldn't
  the first one work fine by saying "Newline and semicolon are BOTH
  interpreted as end-of-statement"? (aside from the issue of "with or without
  a continue-on-next-line symbol"). Or am I just taking the discusion in a
  circle?


Yeah, we're going round and round. If I break a line because it's too
long, I absolutely do not want the compiler assuming that means "end
of statement". As numerous examples have shown, it is perfectly
possible for the compiler to misinterpret the programmers intent, and
produce code that does completely the wrong thing.

There are only two ways to avoid this problem:
(1) require semicolons at end of statement
(2) require line breaks which are not end-of-statement to be escaped

Since I don't like (2), I must support (1).
May 08 2008
next sibling parent reply Gilles G. <schaouette free.fr> writes:
 Yeah, we're going round and round. If I break a line because it's too
 long, I absolutely do not want the compiler assuming that means "end
 of statement". As numerous examples have shown, it is perfectly
 possible for the compiler to misinterpret the programmers intent, and
 produce code that does completely the wrong thing.
 
 There are only two ways to avoid this problem:
 (1) require semicolons at end of statement
 (2) require line breaks which are not end-of-statement to be escaped
 
 Since I don't like (2), I must support (1).


In Python, nearly every time you need a long line, there are already
parentheses in the expression, so you don't need to escape the new line.
Using Python
aVeryLongFunctionName(
    argument1,
    argument2,
May 08 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
Z008/5/8 Gilles G. <schaouette free.fr>:

  > As numerous examples have shown, it is perfectly
  > possible for the compiler to misinterpret the programmers intent, and
  > produce code that does completely the wrong thing.
  >
  In Python, nearly every time you need a long line, there are already
parentheses in the expression, so you don't need to escape the new line.


So if I mistype, and accidently fail to match parenthesis, the
compiler can't detect it, and instead goes ploughing on, tying to
compile through the next few statements. When it finally reaches a
point where it can't parse any more, it will have no idea exactly
where it got lost in the first place.
May 08 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 08 May 2008 13:00:22 +0100, Janice Caron <caron800 googlemail.com>  
wrote:


 Z008/5/8 Gilles G. <schaouette free.fr>:

  > As numerous examples have shown, it is perfectly
  > possible for the compiler to misinterpret the programmers intent, and
  > produce code that does completely the wrong thing.
  >
  In Python, nearly every time you need a long line, there are already  
 parentheses in the expression, so you don't need to escape the new line.


 So if I mistype, and accidently fail to match parenthesis, the
 compiler can't detect it, and instead goes ploughing on, tying to
 compile through the next few statements. When it finally reaches a
 point where it can't parse any more, it will have no idea exactly
 where it got lost in the first place.


I got the T-shirt for that one when learning Python.
May 09 2008
prev sibling parent reply Michael Neumann <mneumann ntecs.de> writes:
Janice Caron wrote:

 2008/5/8 Nick Sabalausky <a a.a>:

  Not that I'm advocating any "non-compulsory semicolon" syntax, but 




couldn't

  the first one work fine by saying "Newline and semicolon are BOTH
  interpreted as end-of-statement"? (aside from the issue of "with or 




without

  a continue-on-next-line symbol"). Or am I just taking the discusion 




in a

  circle?


 Yeah, we're going round and round. If I break a line because it's too
 long, I absolutely do not want the compiler assuming that means "end
 of statement". As numerous examples have shown, it is perfectly
 possible for the compiler to misinterpret the programmers intent, and
 produce code that does completely the wrong thing.

 There are only two ways to avoid this problem:
 (1) require semicolons at end of statement
 (2) require line breaks which are not end-of-statement to be escaped


  (3) "Intelligent Parser"

     a +
     b

Here the parser knows that something has to follow.

     f(1, 2, 3,
       4, 5, 6)

Here again the parser knows that something has to follow.

Etc.

It works perfectly well in Ruby, and I've never found a bug according to
a wrongly placed newline during the last ~10 years writing some multiple
10k LoC in Ruby, while I often get nerved by the C/C++ compiler due to
missing semicolons.

Actually, IMHO any C-style syntax has much more sever problems leading
to hard to find bugs:

     if (a)
       s1;
     s2;

   vs.

     if (a)
     {
       s1;
       s2;
     }

   vs. in Ruby (Eiffel/Ada/Modula-style syntax)

     if a
       s1
       s2
     end


Another example which leads to hard to read code and potential
bugs is (ignoring compiler warnings):

     class A
     {
       int i;

       //
       // add some 25 lines of code here
       //

       void foo(int i)
       {
         // what is "i" here?
       }
     }

This is solved in Ruby by using a separate namespace for instance
variables (" i" for instance variable "i", and "i" for local variable
"i"). I regard this as one of the most important features found in Ruby
to prevent such issues and increase readability (and no, " " has nothing
to do with the " " used by Perl :).

I wouldn't suggest to remove semicolons from D, as the syntax it uses
makes it somewhat harder than the syntax used by Ruby (Python etc.).
But I'd suggest to introduce  variable as a synonym to this.variable.

Regards,

   Michael
May 08 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:48231B20.1080009 ntecs.de...

 Actually, IMHO any C-style syntax has much more sever problems leading
 to hard to find bugs:

     if (a)
       s1;
     s2;


I can't say I've ever found that to be a problem. But maybe that's just me.
May 08 2008
next sibling parent reply terranium <spam here.lot> writes:
Nick Sabalausky Wrote:


 to hard to find bugs:

     if (a)
       s1;
     s2;


 
 I can't say I've ever found that to be a problem. But maybe that's just me.


Programmer, who got used to one language finds it difficult to switch to
another language, because different languages require different styles of
thinking. Thus for C programmer it's difficult to understand block statement
without braces :) and for basic programmer it's difficult to delimit block
statement with braces.
May 08 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
 Programmer, who got used to one language finds it difficult to switch to
another language, because different languages require different styles of
thinking. Thus for C programmer it's difficult to understand block statement
without braces :) and for basic programmer it's difficult to delimit block
statement with braces.


Ah yes - that's probably true.

I wonder if it's possible to write a standalone tool that doesn't know
or care about language grammar (except maybe some general rules about
what constitutes a quote or a comment), that can freely convert
between

    Lorem ipsum (dolor sit amet)
    {
        consectetur!(adipisicing)(elit, sed);
        do
        {
            eiusmod tempor incididunt;
            ut labore;
            et dolore;
        }
        magna(aliqua);
    }

and

    Lorem ipsum (dolor sit amet):
        consectetur!(adipisicing)(elit, sed)
        do:
            eiusmod tempor incididunt
            ut labore
            et dolore
        magna aliqua

If so, we can have not only D-in-Python-style (which I'd never use),
but also Python-in-D-style (which I actually might). It sounds like it
ought to be feasible.
May 08 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.556.1210267230.2351.digitalmars-d puremagic.com...

 I wonder if it's possible to write a standalone tool that doesn't know
 or care about language grammar (except maybe some general rules about
 what constitutes a quote or a comment), that can freely convert
 between

    Lorem ipsum (dolor sit amet)
    {
        consectetur!(adipisicing)(elit, sed);


(snipped)

        magna(aliqua);
    }

 and

    Lorem ipsum (dolor sit amet):
        consectetur!(adipisicing)(elit, sed)


(snipped)

        magna aliqua


I actually like that idea a lot. Although I'd do it like this:

The first line of the source file is something that specifies the style that 
the file "officially" uses (or, there's just one style that's always the 
"official" one for the given language). Then, in the development 
environment, you have a user setting for your style preference. Whenever the 
"official" style and "user" style don't match, a conversion is performed 
(via the compiler, or another universally standard command-line tool) on 
every save and load. Or, better yet, a normal save just saves the "user" 
version in a separate file, and the "official" version is only generated 
when you want to compile.

The only potential drawbacks I see is that the converter MUST be very, very 
reliable. Any bugs in the converter would destroy the whole point of using 
whichever style you felt aided productivity. It would also have to be fast, 
much faster than an actual compile.
May 08 2008
prev sibling next sibling parent Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Janice Caron wrote:

 Programmer, who got used to one language finds it difficult to switch to
another language, because different languages require different styles of
thinking. Thus for C programmer it's difficult to understand block statement
without braces :) and for basic programmer it's difficult to delimit block
statement with braces.


 
 Ah yes - that's probably true.
 
 I wonder if it's possible to write a standalone tool that doesn't know
 or care about language grammar (except maybe some general rules about
 what constitutes a quote or a comment), that can freely convert
 between
 
     Lorem ipsum (dolor sit amet)
     {
         consectetur!(adipisicing)(elit, sed);
         do
         {
             eiusmod tempor incididunt;
             ut labore;
             et dolore;
         }
         magna(aliqua);
     }
 
 and
 
     Lorem ipsum (dolor sit amet):
         consectetur!(adipisicing)(elit, sed)
         do:
             eiusmod tempor incididunt
             ut labore
             et dolore
         magna aliqua
 
 If so, we can have not only D-in-Python-style (which I'd never use),
 but also Python-in-D-style (which I actually might). It sounds like it
 ought to be feasible.


I have translated the passages above from Cicero's Latin and it says:

"It is a pleasure to read everybody's views about language coding
conventions but it is painful to realize that some people believe that
they know the one perfect way of using syntax and indentation."

That 'do' in there was causing a problem, since I could not find the
Latin equivalent, but I took it as Cicero's singing the beginning of "do
re mi..." in his Roman bath while he was composing his learned treatises
on computer language morality.
May 08 2008
prev sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 08 May 2008 18:20:15 +0100, Janice Caron <caron800 googlemail.com>  
wrote:


 Programmer, who got used to one language finds it difficult to switch  
 to another language, because different languages require different  
 styles of thinking. Thus for C programmer it's difficult to understand  
 block statement without braces :) and for basic programmer it's  
 difficult to delimit block statement with braces.


 Ah yes - that's probably true.

 I wonder if it's possible to write a standalone tool that doesn't know
 or care about language grammar (except maybe some general rules about
 what constitutes a quote or a comment), that can freely convert
 between

     Lorem ipsum (dolor sit amet)
     {
         consectetur!(adipisicing)(elit, sed);
         do
         {
             eiusmod tempor incididunt;
             ut labore;
             et dolore;
         }
         magna(aliqua);
     }

 and

     Lorem ipsum (dolor sit amet):
         consectetur!(adipisicing)(elit, sed)
         do:
             eiusmod tempor incididunt
             ut labore
             et dolore
         magna aliqua

 If so, we can have not only D-in-Python-style (which I'd never use),
 but also Python-in-D-style (which I actually might). It sounds like it
 ought to be feasible.


That's actually quite a clever way to enter a code obfuscation contest. My  
grasp of latin
is just sufficient to want to make me try to interpret what your saying  
(and fail because
I dropped Latin in favour of Chemistry) and ignore your code.
May 09 2008
parent user domain.invalid writes:
Bruce Adams wrote:

     Lorem ipsum (dolor sit amet):
         consectetur!(adipisicing)(elit, sed)
         do:
             eiusmod tempor incididunt
             ut labore
             et dolore
         magna aliqua


 My grasp of latin
 is just sufficient to want to make me try to interpret what your saying 


Check out http://www.lipsum.com/ for an explanation.

HTH
Dennis Cote
May 14 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 08/05/2008, Janice Caron <caron800 googlemail.com> wrote:

         magna aliqua

  It sounds like it ought to be feasible.


Except of course that the last line should have been

        magna(aliqua)

But hopefully I conveyed the idea.
May 08 2008
prev sibling parent reply Michael Neumann <mneumann ntecs.de> writes:
Nick Sabalausky wrote:

 "Michael Neumann" <mneumann ntecs.de> wrote in message
 news:48231B20.1080009 ntecs.de...

 Actually, IMHO any C-style syntax has much more sever problems leading
 to hard to find bugs:

     if (a)
       s1;
     s2;


 I can't say I've ever found that to be a problem. But maybe that's 


just me.

Me neither. But it's annoying to have at least 3 different style 
guidelines for C-style syntaxes.

   if (a) b;

   if (a)
     b;

   if (a) {
     b;
   }

   if (a)
   {
     b;
   }

   if (a)
     {
     b;
     }

   if (a)
     {
       b;
     }

And so on :).

Compare that with how many choices you have when using "if ... end"!

Regards,

   Michael
May 08 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:fvvd7r$882$1 digitalmars.com...

 Me neither. But it's annoying to have at least 3 different style 
 guidelines for C-style syntaxes.

   if (a) b;

   if (a)
     b;

   if (a) {
     b;
   }

   if (a)
   {
     b;
   }


(snipped)

 And so on :).

 Compare that with how many choices you have when using "if ... end"!


That's a very good point, I hadn't really thought about that (Personaly, I 
would want to keep the first two and just merge the rest of them into an 
"if...end"). Although that is more of a "{}" vs. "end" issue, and not 
directly related to "with or without semicolon".
May 08 2008
prev sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 08 May 2008 18:28:23 +0100, Michael Neumann <mneumann ntecs.de>  
wrote:


 Nick Sabalausky wrote:
  > "Michael Neumann" <mneumann ntecs.de> wrote in message
  > news:48231B20.1080009 ntecs.de...
  >> Actually, IMHO any C-style syntax has much more sever problems  
 leading
  >> to hard to find bugs:
  >>
  >>     if (a)
  >>       s1;
  >>     s2;
  >>
  >
  > I can't say I've ever found that to be a problem. But maybe that's  
 just me.

 Me neither. But it's annoying to have at least 3 different style  
 guidelines for C-style syntaxes.

    if (a) b;

    if (a)
      b;

    if (a) {
      b;
    }

    if (a)
    {
      b;
    }

    if (a)
      {
      b;
      }

    if (a)
      {
        b;
      }

 And so on :).

 Compare that with how many choices you have when using "if ... end"!

 Regards,

    Michael


I thought D had dropped single statement if's for this very reason. I must  
be mistaken. Many a (C) coding
style guide strongly encourages embracing even single statements in  
constructs like this.

You can go further with the idea. After all you can casuse ambiguity  
between e.g nested loops as well.

if (a) {
   while(b) {c}
}

versus

if (a)
    while(b)
       c
    wend
fi

or whatever.
You can mess around with this stuff forever without increasing programmer  
productivity signficantly.
The real gains are when you hit on improvements to semantic  
expressiveness. I'd much rather have the next
foreach than waste time worrying about } versus fi, endif etc.

Regards,

Bruce.
May 09 2008
parent reply Michael Neumann <mneumann ntecs.de> writes:
Bruce Adams wrote:

 I thought D had dropped single statement if's for this very reason. I
 must be mistaken. Many a (C) coding
 style guide strongly encourages embracing even single statements in
 constructs like this.

 You can go further with the idea. After all you can casuse ambiguity
 between e.g nested loops as well.

 if (a) {
   while(b) {c}
 }

 versus

 if (a)
    while(b)
       c
    wend
 fi

 or whatever.
 You can mess around with this stuff forever without increasing
 programmer productivity signficantly.


It's not about programm productivity, but about redundancy :)

But then there is still Ada for those that need that redundancy to
prevent bugs. Or just don't write too deeply nested code ;-)

Regards,

   Michael
May 10 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 10 May 2008 11:58:41 +0100, Michael Neumann <mneumann ntecs.de>  
wrote:


 Bruce Adams wrote:
  > I thought D had dropped single statement if's for this very reason. I
  > must be mistaken. Many a (C) coding
  > style guide strongly encourages embracing even single statements in
  > constructs like this.
  >
  > You can go further with the idea. After all you can casuse ambiguity
  > between e.g nested loops as well.
  >
  > if (a) {
  >   while(b) {c}
  > }
  >
  > versus
  >
  > if (a)
  >    while(b)
  >       c
  >    wend
  > fi
  >
  > or whatever.
  > You can mess around with this stuff forever without increasing
  > programmer productivity signficantly.

 It's not about programm productivity, but about redundancy :)

 But then there is still Ada for those that need that redundancy to
 prevent bugs. Or just don't write too deeply nested code ;-)

 Regards,

    Michael


Reducing bugs from syntax errors is one of several ways to improve
programmer productivity. Its much less important than good semantics  
though.
May 10 2008
prev sibling parent reply terranium <spam here.lot> writes:
Michael Neumann Wrote:


 Another example which leads to hard to read code and potential
 bugs is (ignoring compiler warnings):
 
      class A
      {
        int i;
 
        //
        // add some 25 lines of code here
        //
 
        void foo(int i)
        {
          // what is "i" here?
        }
      }
 
 This is solved in Ruby by using a separate namespace for instance
 variables (" i" for instance variable "i", and "i" for local variable
 "i").


In C family languages this is ruled out by naming convention.
May 08 2008
parent reply Michael Neumann <mneumann ntecs.de> writes:
terranium wrote:

 Michael Neumann Wrote:


 Another example which leads to hard to read code and potential
 bugs is (ignoring compiler warnings):

      class A
      {
        int i;

        //
        // add some 25 lines of code here
        //

        void foo(int i)
        {
          // what is "i" here?
        }
      }

 This is solved in Ruby by using a separate namespace for instance
 variables (" i" for instance variable "i", and "i" for local variable
 "i").


 In C family languages this is ruled out by naming convention.


Which in the case of using a m_ prefix leads to hard(er) to read code.
And then there is no standard naming convention, and who actually uses
such a naming convention? Without that, you can't easily distinguish a
local variable from an instance variable from a global variable.

Regards,

   Michael
May 08 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:fvvd1a$7p3$1 digitalmars.com...

 terranium wrote:

 Michael Neumann Wrote:


 Another example which leads to hard to read code and potential
 bugs is (ignoring compiler warnings):

      class A
      {
        int i;

        //
        // add some 25 lines of code here
        //

        void foo(int i)
        {
          // what is "i" here?
        }
      }

 This is solved in Ruby by using a separate namespace for instance
 variables (" i" for instance variable "i", and "i" for local variable
 "i").


 In C family languages this is ruled out by naming convention.


 Which in the case of using a m_ prefix leads to hard(er) to read code.
 And then there is no standard naming convention, and who actually uses
 such a naming convention? Without that, you can't easily distinguish a
 local variable from an instance variable from a global variable.


In "good" C family languages, the instance variable is referred to by 
prefixing it with something like "this.". I think there are some that do it 
differently (ECMAScript, IIRC), but I'd argue those ones are making a big 
mistake.

However, that does bring up an inconsistancy inherent to the C-style. 
Following your example, if I do this:

class A{
int i;
void foo(int i) {}
void foo() {}
void bar() {}
}

In that case, "i" means one thing if you're in "foo(int)", and another thing 
if you're in "foo()" or "bar()". Of course, you could decide to *always* use 
"this." when referring to an instance variable, but that's kinda long, and 
you still end up with a hidden bug if you decide to use a local var named 
"i" and forget to declare it.

There are things about Ruby I don't like, but the  instanceVar syntax is one 
of the things I think it got spot-on. I would be totally in favor of 
adopting that.
May 08 2008
next sibling parent reply Michael Neumann <mneumann ntecs.de> writes:
Nick Sabalausky wrote:

 "Michael Neumann" <mneumann ntecs.de> wrote in message
 news:fvvd1a$7p3$1 digitalmars.com...

 terranium wrote:

 Michael Neumann Wrote:


 Another example which leads to hard to read code and potential
 bugs is (ignoring compiler warnings):

      class A
      {
        int i;

        //
        // add some 25 lines of code here
        //

        void foo(int i)
        {
          // what is "i" here?
        }
      }

 This is solved in Ruby by using a separate namespace for instance
 variables (" i" for instance variable "i", and "i" for local variable
 "i").


 In C family languages this is ruled out by naming convention.


 Which in the case of using a m_ prefix leads to hard(er) to read code.
 And then there is no standard naming convention, and who actually uses
 such a naming convention? Without that, you can't easily distinguish a
 local variable from an instance variable from a global variable.


 In "good" C family languages, the instance variable is referred to by
 prefixing it with something like "this.". I think there are some that 


do it

 differently (ECMAScript, IIRC), but I'd argue those ones are making a 


big

 mistake.

 However, that does bring up an inconsistancy inherent to the C-style.
 Following your example, if I do this:

 class A{
 int i;
 void foo(int i) {}
 void foo() {}
 void bar() {}
 }

 In that case, "i" means one thing if you're in "foo(int)", and 


another thing

 if you're in "foo()" or "bar()". Of course, you could decide to 


*always* use

 "this." when referring to an instance variable, but that's kinda 


long, and

 you still end up with a hidden bug if you decide to use a local var 


named

 "i" and forget to declare it.


Yeah, you are right. It is inconsitent to define the instance variable
with "i" while accessing it with " i":

   class A {
     int i;

     void foo(int i) {  i = i; }
   };

But, then it's no less inconsistent than using "this.i".


 There are things about Ruby I don't like, but the  instanceVar syntax 


is one

 of the things I think it got spot-on. I would be totally in favor of
 adopting that.


Btw, I wrote a C++ preprocessor script that during compilation
transparently replaces every occurence of " " by "this->".
Would be nice to have this build into D directly.

Regards,

   Michael
May 08 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:48236605.9050806 ntecs.de...

 Yeah, you are right. It is inconsitent to define the instance variable
 with "i" while accessing it with " i":

   class A {
     int i;

     void foo(int i) {  i = i; }
   };


That's not really what I meant (See below for clarification of what I 
meant). Actually, I hadn't even thought of that, but it is a good point.


 Btw, I wrote a C++ preprocessor script that during compilation
 transparently replaces every occurence of " " by "this->".
 Would be nice to have this build into D directly.


I agree, that would be nice (provided, of course, it didn't interfere with 
deliberate uses of " ", such as within a string). Unfortunately, in C++ or D 
it still wouldn't solve the problem of accidentially clobbering the instance 
variable "i" by intending trying to use a local var "i", but forgetting to 
declare it:

// Note: untested
class A {
  int i=0;

  void foo() {
    // Accidentially clobbers "this.i" aka " i"
    for(i=0; i<77; i++)
      {/* Do stuff */}
  }

  invariant() {
    assert(this.i==0); // Fails after foo() is called
  }
}

I still like the   thing, though.
May 08 2008
parent reply Michael Neumann <mneumann ntecs.de> writes:
Nick Sabalausky wrote:

 // Note: untested
 class A {
   int i=0;

   void foo() {
     // Accidentially clobbers "this.i" aka " i"
     for(i=0; i<77; i++)
       {/* Do stuff */}
   }

   invariant() {
     assert(this.i==0); // Fails after foo() is called
   }
 }

 I still like the   thing, though.


Very good example!

A solution could be to force the programmer to use the "this." notation
or at least issuing a compiler warning if not done.  The latter could be
implemented in the compiler without any changes to the syntax/language.

The next step would be to have " " as a synonym for "this.", as typing
"this." all the time is either annoying and as such is ignored or leads
to less readable code (IMHO).

Regards,

   Michael
May 09 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:g01mtk$1nvj$1 digitalmars.com...

 Nick Sabalausky wrote:

 // Note: untested
 class A {
   int i=0;

   void foo() {
     // Accidentially clobbers "this.i" aka " i"
     for(i=0; i<77; i++)
       {/* Do stuff */}
   }

   invariant() {
     assert(this.i==0); // Fails after foo() is called
   }
 }

 I still like the   thing, though.


 Very good example!

 A solution could be to force the programmer to use the "this." notation
 or at least issuing a compiler warning if not done.  The latter could be
 implemented in the compiler without any changes to the syntax/language.


I had been thinking of this feature as a pipe dream (at least for D), just 
because it would mean changing the language to always require "this." or 
" ". Implimenting it as an optional warning hadn't occurred to me. That 
makes it sound much more possible. Good call on that (no pun intended).


 The next step would be to have " " as a synonym for "this.", as typing
 "this." all the time is either annoying and as such is ignored or leads
 to less readable code (IMHO).


Agreed. I would love to see this actually happen. Although, I do wonder if 
maybe we're chasing too rare of a problem to bother, or maybe it would 
segregate the D scene into " D" people and "raw D" people (I hope not, 
'cause I do like it).

Any comments from Walter? I'm curious what his take is on the original 
problem.
May 09 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Fri, 09 May 2008 21:20:30 +0100, Nick Sabalausky <a a.a> wrote:


 "Michael Neumann" <mneumann ntecs.de> wrote in message
 news:g01mtk$1nvj$1 digitalmars.com...

 Nick Sabalausky wrote:

 // Note: untested
 class A {
   int i=3D0;

   void foo() {
     // Accidentially clobbers "this.i" aka " i"
     for(i=3D0; i<77; i++)
       {/* Do stuff */}
   }

   invariant() {
     assert(this.i=3D=3D0); // Fails after foo() is called
   }
 }

 I still like the   thing, though.


 Very good example!

 A solution could be to force the programmer to use the "this." notati=




on

 or at least issuing a compiler warning if not done.  The latter could=




 be

 implemented in the compiler without any changes to the syntax/languag=




e.




I believe Walter disapproves of compiler warnings on principle. Its eith=
er  =

an error or it isn't.
I tend to disagree but on the otherhand I always code with -Werror and  =

frown at any warnings
emitted by anything so I guess deep down I really agree with him.



 May 09 2008



prev sibling  parent  "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Thu, 08 May 2008 21:43:49 +0100, Michael Neumann <mneumann ntecs.de> =
 =

wrote:


 Yeah, you are right. It is inconsitent to define the instance variable=



 with "i" while accessing it with " i":

    class A {
      int i;

      void foo(int i) {  i =3D i; }
    };

 But, then it's no less inconsistent than using "this.i".


Perhaps we should insist on using a dollar sign to indicate getting the =
 =

value from a variable?
;-> <cue evil laughter />



 May 09 2008



prev sibling  parent  "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Thu, 08 May 2008 19:19:23 +0100, Nick Sabalausky <a a.a> wrote:


 "Michael Neumann" <mneumann ntecs.de> wrote in message
 news:fvvd1a$7p3$1 digitalmars.com...

 terranium wrote:

 Michael Neumann Wrote:


 Another example which leads to hard to read code and potential
 bugs is (ignoring compiler warnings):

      class A
      {
        int i;

        //
        // add some 25 lines of code here
        //

        void foo(int i)
        {
          // what is "i" here?
        }
      }

 This is solved in Ruby by using a separate namespace for instance
 variables (" i" for instance variable "i", and "i" for local variable
 "i").


 In C family languages this is ruled out by naming convention.


 Which in the case of using a m_ prefix leads to hard(er) to read code.
 And then there is no standard naming convention, and who actually uses
 such a naming convention? Without that, you can't easily distinguish a
 local variable from an instance variable from a global variable.


 In "good" C family languages, the instance variable is referred to by
 prefixing it with something like "this.". I think there are some that do  
 it
 differently (ECMAScript, IIRC), but I'd argue those ones are making a big
 mistake.


A interesting take on this comes from the IDE crowd. You always know the  
type/context
of a variable because of tool-tips and syntax highlighting.
Its just us old-timers stuck in a world of ASCII editing.



 May 09 2008



prev sibling next sibling parent reply terranium <spam here.lot>  writes:


Michael Neumann Wrote:


 In C family languages this is ruled out by naming convention.


 
 Which in the case of using a m_ prefix leads to hard(er) to read code.


Yes, Hungarian prefixes are considered a bad practice in modern C family
languages. It was good in old times.


 And then there is no standard naming convention


As to java and .net standard naming convention is provided by standard library.


 and who actually uses such a naming convention?


Those, who care about good programming pactices.


 Without that, you can't easily distinguish a
 local variable from an instance variable from a global variable.


Who is keeping you from using a naming convention?



 May 08 2008



  parent reply terranium <spam here.lot>  writes:


terranium Wrote:


 As to java and .net standard naming convention is provided by standard library.
 


They say, ruby's code is very good... hmm... maybe, but I've seen its C sources
too... :) they're not just bad, they're chaotic evil :)))



 May 09 2008



  parent reply Michael Neumann <mneumann ntecs.de>  writes:


terranium wrote:

 terranium Wrote:


 As to java and .net standard naming convention is provided by 




standard library.


 They say, ruby's code is very good... hmm... maybe, but I've seen its 


C sources too... :) they're not just bad, they're chaotic evil :)))

After working a while with the C sources of Ruby they'll become less
evil, even so they might be evil :). But hey, it's C!
Just wondering if the sources of the .NET of Java compiler/runtimes are
any better. For sure they are 10x as much code ;-)

And then, there is a lot of bad ruby code out there as well! But if you
have the choice between 500 lines of bad java code and 50 lines bad ruby
code, I'd just take the 50 lines bad ruby code and rewrite it myself ;-)

Regards,

   Michael



 May 09 2008



 next sibling parent reply terranium <spam here.lot>  writes:


Michael Neumann Wrote:


 But hey, it's C!


It's not an excuse for writing junk. The excuse is this was written by one man.



 May 09 2008



  parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Fri, 09 May 2008 15:45:47 +0100, terranium <spam here.lot> wrote:


 Michael Neumann Wrote:


 But hey, it's C!


 It's not an excuse for writing junk. The excuse is this was written by  
 one man.


That's no excuse either. Code for yourself as you would for others, if not  
better.



 May 09 2008



  parent  Michael Neumann <mneumann ntecs.de>  writes:


Bruce Adams wrote:

 On Fri, 09 May 2008 15:45:47 +0100, terranium <spam here.lot> wrote:


 Michael Neumann Wrote:


 But hey, it's C!


 It's not an excuse for writing junk. The excuse is this was written by
 one man.


 That's no excuse either. Code for yourself as you would for others, if
 not better.


Okay, it's not junk, definitvely not. It's just that some parts like
eval.c are not commented at all and for a newbie very hard to
understand. Another reason might be, because it origins from Japan, so
we wouldn't be able to read the comments anyway :).

To clarify: I'd actually call Ruby one of the best commented projects
I've ever seen, with the highest code/comment ratio. But only for the
parts that the programmer uses, not the very low-level implementation.

See this as just one example:

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/object.c?revision=15758&view=markup

Btw, I'd like to see this style of documentation in languages like Java.
Java has a lot of documentation, but actually very little (if any)
examples in the documentation, so you have to figure out yourself how to
use it, which costs a lot of time. "An example is worth a 1000 words."

Regards,

   Michael



 May 10 2008



prev sibling  parent  bearophile <bearophileHUGS lycos.com>  writes:


Michael Neumann:


 After working a while with the C sources of Ruby they'll become less
 evil, even so they might be evil :). But hey, it's C!
 Just wondering if the sources of the .NET of Java compiler/runtimes are
 any better. For sure they are 10x as much code ;-)


Perl source code looks messy to me, but C too can be written in a good and
readable way, you may take a look at Python C sources, for example the deque
module, written by a photographer (the good R. Hettinger):

http://svn.python.org/view/python/trunk/Modules/_collectionsmodule.c?rev=60749&view=markup

Bye,
bearophile



 May 09 2008



prev sibling  parent  "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Thu, 08 May 2008 18:24:54 +0100, Michael Neumann <mneumann ntecs.de>  
wrote:


 terranium wrote:
  > Michael Neumann Wrote:
  >
  >> Another example which leads to hard to read code and potential
  >> bugs is (ignoring compiler warnings):
  >>
  >>      class A
  >>      {
  >>        int i;
  >>
  >>        //
  >>        // add some 25 lines of code here
  >>        //
  >>
  >>        void foo(int i)
  >>        {
  >>          // what is "i" here?
  >>        }
  >>      }
  >>
  >> This is solved in Ruby by using a separate namespace for instance
  >> variables (" i" for instance variable "i", and "i" for local variable
  >> "i").
  >
  > In C family languages this is ruled out by naming convention.


Another take (which I prefer) comes from compiler warnings about variables
being shadowed. gcc is good like that.



 May 09 2008



prev sibling  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Janice Caron, el  8 de mayo a las 05:23 me escribiste:

 On 08/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

 No you don't, \n is your redundancy. So you still get meaningful messages.


 
 That would be true IF AND ONLY IF we were forced to escape newlines
 that didn't mean end-of-statement. e.g.
 
     auto a = b \
     (c)
 
 I wasn't aware that requiring me to escaping newlines was part of the
 suggestion. If it was, then I'm even more against it.


Yes, in my suggestion you need to escape false-newline-end-of-statement in
some few cases, like in Python.

What you written (which doesn't make any sense, I don't know what's the
point of putting shitty and unreal examples to prove a point) need a
escape at the end of the line, but this (more realistic) version doesn't:

auto a = b(
    c)

Because when you don't expect a statement to finish until the closing ) is
found (which is *exactly* the same behavior you get now, so please don't
bring the "meaningful errors" argument again =).

I have a Python project with 6482 LOC and I have just 39 lines with line
continuation. I think adding an extra character (\) to 0.6% of the lines is
pretty acceptable if you get rid of the extra character (;) at the end of
the line in the other 99.4% =)

Really. You are telling me that is ugly to have a '\' in 0.6% lines of code
but is pretty to have ';' in 100% of them??? It doesn't makes any sense to
me...


 Besides which, how would that work with statements like
 
     if (a == b) { ++i; ++j } else { --i; --j }
 
 If newlines were to take over the role of semicolons, then that would turn into
 
     if (a == b) { ++i
     ++j } else { --i
     --j }
 
 Yuk.


Is *that* hard to read the entire message? I said ';' is OPTIONAL (and
that's the key for backward compatibility). So you can perfectly write:

if (a == b) { ++i; ++j } else { --i; --j }

"Yuk."

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Dentro de 30 años Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
	-- Sidharta Wiki



 May 08 2008



 next sibling parent reply "Janice Caron" <caron800 googlemail.com>  writes:


2008/5/8 Leandro Lucarella <llucax gmail.com>:

 I don't know what's the
  point of putting shitty and unreal examples to prove a point


You won't win any arguments by calling examples "shitty". All that
will achieve is that people who don't want to be insulted will stop
debating with you, and D won't change.



 May 08 2008



 next sibling parent  Jesse Phillips <jessekphillips gmail.com>  writes:


On Thu, 08 May 2008 15:51:27 +0100, Janice Caron wrote:


 2008/5/8 Leandro Lucarella <llucax gmail.com>:

 I don't know what's the
  point of putting shitty and unreal examples to prove a point


 
 You won't win any arguments by calling examples "shitty". All that will
 achieve is that people who don't want to be insulted will stop debating
 with you, and D won't change.


I should point out that your argument was a little flawed, the suggestion 
is to use new lines to mark the end of statement not replace ;

In my thoughts I will just say I don't want the compiler to define rules 
based on white-space.



 May 08 2008



prev sibling  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Janice Caron, el  8 de mayo a las 15:51 me escribiste:

 2008/5/8 Leandro Lucarella <llucax gmail.com>:

 I don't know what's the
  point of putting shitty and unreal examples to prove a point


 
 You won't win any arguments by calling examples "shitty". All that
 will achieve is that people who don't want to be insulted will stop
 debating with you, and D won't change.


Great excuse to not answer a mail with a lot of good points...

Very convenient.

Ok, you are right about "shitty", my apologies for using an unappropriate
word. Please remove " shitty and" in my previous mail and tell me what
flaws you find in my proposal?

Thank you.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
EL PRIMER MONITO DEL MILENIO...
	-- Crónica TV



 May 08 2008



  parent reply "Janice Caron" <caron800 googlemail.com>  writes:


On 08/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

  Please remove " shitty and" in my previous mail and tell me what
  flaws you find in my proposal?


Sure, but I think it's kinda obvious. In answer to your question:
"What's the point of putting unreal examples to prove a point?", the
reason is /to prove a point/.

The onus is on you to prove that no examples are ambiguous. I only
have to provide a single counterexample. That, I have done, as have
many other people. Whether or not an example is "real" or "unreal" is
in the eye of the beholder, but certainly I simplified my examples so
as to demonstrate /only/ the point being made. Superflous information
just sidetracks the issue.

I'm not sure there's anything further to say, however. The reason is,
when you said "Yes, in my suggestion you need to escape
false-newline-end-of-statement", you effectively closed all
ambiguities. My arguments were predicated on the assumption that there
would be no newline-escaping. That means, your plan /is/ workable -
but the price (having to escape newlines) is higher than I want to
pay. It becomes a matter of taste. I prefer C-style; you prefer
Python-style. Maybe you (or someone else who wants this) can write
that conversion tool I mentioned somewhere.

But even with the "you need to escape escape
false-newline-end-of-statement" rule, there is still room for silent
bugs to creep in. For example:

    foo(int x)  // Danger!
    {
        /* stuff */
    }

Under your scheme that would have to be rewritten as either

    foo(int x)  {
        /* stuff */
    }

or

    foo(int x)  \
    {
        /* stuff */
    }

or else run the risk of being misparsed as

    foo(int x);
    {
        /* stuff */
    }

which often times will be valid D. (Not always, but sometimes - e.g.
as an inner function). So unless you go "all the way" and aim for full
Python style, you run the risk of introducing some very hard to find
bugs.



 May 08 2008



  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Janice Caron, el  9 de mayo a las 05:42 me escribiste:

 I'm not sure there's anything further to say, however. The reason is,
 when you said "Yes, in my suggestion you need to escape
 false-newline-end-of-statement", you effectively closed all
 ambiguities. My arguments were predicated on the assumption that there
 would be no newline-escaping. That means, your plan /is/ workable -
 but the price (having to escape newlines) is higher than I want to
 pay. It becomes a matter of taste. I prefer C-style; you prefer
 Python-style. Maybe you (or someone else who wants this) can write
 that conversion tool I mentioned somewhere.


I don't think it's entirely a matter of taste. It saves typing and thus
makes the code more readable and easier to maintain. Is like saying "auto"
it's just a matter of taste, and you say "auto" is bad because we should
always have the redundancy of the type declaration.


 But even with the "you need to escape escape
 false-newline-end-of-statement" rule, there is still room for silent
 bugs to creep in. For example:
 
     foo(int x)  // Danger!
     {
         /* stuff */
     }


Is this valid D?


 Under your scheme that would have to be rewritten as either
 
     foo(int x)  {
         /* stuff */
     }
 
 or
 
     foo(int x)  \
     {
         /* stuff */
     }
 
 or else run the risk of being misparsed as
 
     foo(int x);
     {
         /* stuff */
     }
 
 which often times will be valid D. (Not always, but sometimes - e.g.
 as an inner function). So unless you go "all the way" and aim for full
 Python style, you run the risk of introducing some very hard to find
 bugs.


I don't think that's valid D anyway, but I'll assume you meant:
void foo(int x)
{
    /* stuff */
}

If this is the case, the parser should expect a function definition after
a function declaration (since function declaration are not *that* usual in
D, I think is the better way to go).

So, for a function declaration and a new block of code you write:
void foo(int x); // ; is mandatory for function declaration
{
    // new block
}

For function definition, you just type:
void foo(int x)
{
    /* stuff */
}


BTW, I know this will never make it into D, I just don't think you have
the right reasons. I think the only valid reason to not do it (and a very
big one) is that D wants to be in the C-like syntax family, so it *wants*
to look like C. The ambiguities, redundancy and supposed hidden bugs are
all very weak reasons IMHO...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
EL PRIMER MONITO DEL MILENIO...
	-- Crónica TV



 May 12 2008



  parent  "Janice Caron" <caron800 googlemail.com>  writes:


On 12/05/2008, Leandro Lucarella <llucax gmail.com> wrote:

  >     foo(int x)  // Danger!
  >     {
  >         /* stuff */
  >     }

  Is this valid D?


I missed out the word "void". I meant

    void foo(int x) // Danger!
    {
        /* stuff */
    }

or else run the risk of being misparsed as

    void foo(int x);
    {
        /* stuff */
    }

And, yes, I'm sure you can invent some arbitrary ad hoc rule which
disambiguates in this case, but there are always going to be more
cases. I'm not the only one to have demonstrated an ambiguity which
would result from semicolons being optional. Doubtless there are many
more ambiguities lying in wait.

But I don't want to get into an endless cycle of "Here's another
ambiguity" followed by "Here's the next ad hoc rule to disambiguate".
Let's just not go there.



 May 12 2008



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


 Really. You are telling me that is ugly to have a '\' in 0.6% lines of 
 code
 but is pretty to have ';' in 100% of them??? It doesn't makes any sense to
 me...


I think we're starting to get more into an issue of preferences here, but:

Aside from the fact that ";" is only used on statements that don't end in a 
"{}" code block, I would have to say: yes, definitely. Personally, I find 
the rule "A statement is ended by either a semicolon or a curly-brace code 
block (where applicable)" to be cleaner and more consistent than "Statements 
end with a newline unless a "\" is used or the compiler is able to infer the 
statement shouldn't end", plus it allows me to rearrange portions of a long 
statement for readability without messing with adding/removing/moving "\" 
operators. Of course, in some cases, I can omit the "\", but that means I 
have to worry about "Do I need it here, or not?". Which first of all 
violates "don't make me think", and secondly leads to:

FormatString("This ({}) is a number, and this is a very," \
             "very, very long string. Yes it is, yes it is.",
             thisIsA + (rather() * longComputation) + orAtLeast \
             IAmTrying(toMakeItSo) - (yesIam * 2))

The use of multiple lines in that is very ugly. Of course, this can be 
solved by either trying to arrange parentheses in a way that side-steps the 
need for "\" (ie, very kludgey), or by saying "screw it, I'm using '\' on 
all the lines" (ie, effectively eliminating the "don't need it on parameter 
lists" feature), or by doing "FormatString(preComputedStr, 
preComputedValue)" (but why should I have to?)

Also, I've seen a lot of ECMAScript code that has semicolons on some lines 
and lacks it on others, just on the whim of the coder - that strikes me as 
very messy. Consistency is pretty.

Regarding remembering the semicolon, I haven't found that to be a problem. I 
find I do it naturally without even thinking about it, at least whenever I 
haven't been spending a lot of time in a language like VB which outright 
forbids semicolons. But even then, the compiler will tell me exactly where I 
went wrong until I can get the VB out of my head, so no big deal. 



 May 08 2008



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Tomasz Sowinski" <tomeksowi gmail.com> wrote in message 
news:fvmgn8$s5d$1 digitalmars.com...

 Robert Fraser Wrote:

 I usually like to keep my lines under 80 characters long for
 readability, and occasionally have long statements (especially if
 there's a ternary operator in there somewhere), so my vote is "nay".


 Maybe a breakline symbol like in Ruby or VB for long statements?


I can fully appreciate the reasoning behind "optional semicolon" syntax. Ie, 
there's a one-to-one relationship between "line" and "statement" for most 
lines and statements, therefore if an extra symbol is going to be used it 
should be for the border case (multi-line statement) rather than the typical 
case (single-line statement). But, in my experience, I find that there's 
another practicality-related issue that ends up trumping that one:

I'm constantly readjusting statements back and forth between "all on one 
line" and "spanned over multiple lines" (for instance, "if" statements with 
lots of clauses, and functions calls/definitions with lots of arguments). 
Every time something changes, I rearrange to make it more readable, which 
often involves moving parts of a multi-line statement from one line to 
another, or changing a statement back and forth between single-line and 
multi-line. End-of-line symbols don't prevent me from doing that, but they 
do get in the way and make it a regular pain-in-the-ass. End of statement 
symbols, however, are very easy to get accustomed to, quickly become second 
nature, and never really get in the way. 



 May 06 2008



prev sibling  parent  terranium <spam here.lot>  writes:


Tomasz Sowinski Wrote:


 I was just curious about those "other various arguments".


It's an important feature of C family languages which improves readability and
user experience (look and feel).



 May 07 2008



prev sibling  parent reply downs <default_357-line yahoo.de>  writes:


Robert Fraser wrote:

 Tomasz Sowinski wrote:

 Just another feature thought. Never gonna happen, but still...

 What's the reason of having lines end with a semicolon? Anything else
 than a legacy issue with C/C++?

 The only thing I can think of is having multiple statements in one
 line, but that only makes code unreadable. Wouldn't getting rid of ;
 improve readability?


 Tomek


 
 So the end of a statement would be marked by a newline character a la
 Python?


Why mark the end of statements at all?

Couldn't it be possible to have the compiler deduce the end of a statement
automatically, by parsing as much as it can and then stopping?

void main() { writefln("Hello World") int a float b = 4 writefln(a, " - ", b)
return 0 }

 
 I usually like to keep my lines under 80 characters long for
 readability, and occasionally have long statements (especially if
 there's a ternary operator in there somewhere), so my vote is "nay".
 There are various other arguments against it, too (especially in that it
 makes parsing easier).


I vote in favor, as long as I can do multiple statements per line. It's useful
sometimes. Maybe support "; "  as a fallback?

 --downs



 May 05 2008



 next sibling parent  naryl <cy ngs.ru>  writes:


On Mon, 05 May 2008 13:25:17 +0400, downs <default_357-line yahoo.de>  
wrote:


 I vote in favor, as long as I can do multiple statements per line. It's  
 useful sometimes. Maybe support "; "  as a fallback?

  --downs


<g> You are reinventing the Scala language here.



 May 05 2008



prev sibling  parent  BCS <BCS pathlink.com>  writes:


downs wrote:


 void main() { writefln("Hello World") int a float b = 4 writefln(a, " - ", b)
return 0 }
 


eyes.. bleeding..

Please don't do that.

Another (non style) reason to have the ; is that it provides a bit of 
redundancy in the code. This results in you needing 2 errors before it 
compile wrong rather than just one


int j = 6;
void main()
{
	bob();
	writef("%d", j); // 5 or 6?
}

void bob()
{
	int i j = 5	// this could be

	//int i, j = 5; // declare i and j as local var
	//int i; j = 5; // declare i and modify .j

}



 May 05 2008



prev sibling next sibling parent reply Sascha Katzner <sorry.no spam.invalid>  writes:


Tomasz Sowinski wrote:

 What's the reason of having lines end with a semicolon? Anything else
 than a legacy issue with C/C++?
 
 The only thing I can think of is having multiple statements in one
 line, but that only makes code unreadable. Wouldn't getting rid of ;
 improve readability?


No, you would never know if a statement is just a continuation from the 
previous line or actually a new one.

An example:

	int i
	for (i=0; i<10; i++)
	writefln(i)

Should this print all numbers from 1 to 9 or simply increment i ten 
times and print "10"?

The only exception to this are IMO inline assembly statements, the 
semicolons there are unnecessary and ugly. And since I'm accustomed to 
write assembly without semicolons at the end I continuously forget them. ;)

[X] Vote to kick semicolons in asm statements!

LLAP,
Sascha



 May 05 2008



  parent reply Tomasz Sowinski <tomeksowi gmail.com>  writes:


Sascha Katzner Wrote:


 An example:
 
 	int i
 	for (i=0; i<10; i++)
 	writefln(i)
 
 Should this print all numbers from 1 to 9 or simply increment i ten 
 times and print "10"?


The former. For the latter the it should be 
    for (i=0; i<10; i++) {}
    writefln(i)

btw, can you make a loop without any statement in D? I think no...
Anyway, I don't see the benefit of putting or not putting a semicolon there.



 May 05 2008



  parent reply BCS <BCS pathlink.com>  writes:


Tomasz Sowinski wrote:


 btw, can you make a loop without any statement in D? I think no...


correct, and the same for C.

In "for(;;);" the trailing ; is a null statement.



 May 05 2008



  parent reply Tomasz Sowinski <tomeksowi gmail.com>  writes:


BCS Wrote:


 In "for(;;);" the trailing ; is a null statement.


I just did that and the compiler said:
"use '{ }' for an empty statement, not a ';' "



 May 05 2008



 next sibling parent  Jesse Phillips <jessekphillips gmail.com>  writes:


On Mon, 05 May 2008 12:32:09 -0400, Tomasz Sowinski wrote:


 BCS Wrote:
 

 In "for(;;);" the trailing ; is a null statement.


 
 I just did that and the compiler said: "use '{ }' for an empty
 statement, not a ';' "


Since putting ; at the end of statements is common writing a for
(...;...;...); would be common, and so D makes this invalid, using a ; to 
make an empty loop, that is why it says to use {} if you want one. BCS's 
example is just the same as doing a while(true){} though would not 
compile because of the ; at the end.



 May 05 2008



prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Tomasz Sowinski wrote:

 BCS Wrote:
 

 In "for(;;);" the trailing ; is a null statement.


 
 I just did that and the compiler said:
 "use '{ }' for an empty statement, not a ';' "


I'm very glad of that protection there. Where I used to work, an 
accidental semicolon on an if statement ended up causing a production bug.



 May 05 2008



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Robert Fraser wrote:

 Where I used to work, an 
 accidental semicolon on an if statement ended up causing a production bug.


I've seen people waste several hours trying to figure out why their loop 
bodies would execute exactly once.



 May 06 2008



prev sibling  parent  BCS <BCS pathlink.com>  writes:


Tomasz Sowinski wrote:

 BCS Wrote:
 
 

In "for(;;);" the trailing ; is a null statement.


 
 
 I just did that and the compiler said:
 "use '{ }' for an empty statement, not a ';' "
 


it works in C.



 May 05 2008



prev sibling next sibling parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Mon, 05 May 2008 09:13:48 +0100, Tomasz Sowinski <tomeksowi gmail.com>  
wrote:


 Just another feature thought. Never gonna happen, but still...

 What's the reason of having lines end with a semicolon? Anything else  
 than a legacy issue with C/C++?

 The only thing I can think of is having multiple statements in one line,  
 but that only makes code unreadable. Wouldn't getting rid of ; improve  
 readability?


 Tomek


There is always going to be a trade off between having to mark the end of  
a statement using ";"
or having to escape newlines. Otherwise a language becomes horrendously  
difficult to parse.
The rules for when you really need to end a statement would look even  
stranger if you only needed
to do it for particular statements in particular contexts. Perhaps you  
could have the best of both
worlds with a statementiser that knew more about typography and layout.  
Then your heading back along
the python path. Either way the keep is simple rule applies. If its easier  
for a compiler to grok
it might well be easier for a human to grok too and visa versa.



 May 05 2008



  parent reply Tomasz Sowinski <tomeksowi gmail.com>  writes:


Bruce Adams Wrote:


 There is always going to be a trade off between having to mark the end of  
 a statement using ";"
 or having to escape newlines. Otherwise a language becomes horrendously  
 difficult to parse.


Can you give some examples of the difficulties?
I'm not into parsing issues really, so maybe I'll learn a thing or two.



 May 05 2008



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Tomasz Sowinski wrote:

 Can you give some examples of the difficulties?
 I'm not into parsing issues really, so maybe I'll learn a thing or two.


How should:

    f()
    *g()

parse?



 May 06 2008



prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"Tomasz Sowinski" <tomeksowi gmail.com> wrote in message 
news:fvmfjs$q4n$1 digitalmars.com...

 Just another feature thought. Never gonna happen, but still...

 What's the reason of having lines end with a semicolon? Anything else than 
 a legacy issue with C/C++?

 The only thing I can think of is having multiple statements in one line, 
 but that only makes code unreadable. Wouldn't getting rid of ; improve 
 readability?


I don't like semicolons.  To that end, I have changed statement terminators 
in my scripting language to accept semicolons or newlines.  Having a C-style 
syntax, it's been a sort of interesting experiment to see what ambiguities 
arise in the C syntax without them.

The language has not dropped semicolons entirely, it's just made it possible 
to skip them at the end of lines.  If you want multiple statements on one 
line, you still have to separate them with semicolons.

There are really only two places in the grammar where there are possible 
parsing ambiguities:

1) Return statements.  Does:

return
f()

parse as "return f();", or does it parse as a "return;" followed by a 
function call?  I have it parse as the latter, as that makes the most sense 
to me.

2) Function calls vs. parenthesized expressions.  Does:

x = f
(g + h).i()

parse as "x = f(g + h).i();" or as "x = f; (g + h).i();" ?  I have this give 
a parsing error since one way or the other doesn't really make sense.  In 
order to resolve the ambiguity, you either have to put a semicolon after the 
first statement to make it 2 statements, or move the open paren up to the 
first line to make it one.

Other than these two cases, I haven't run into any other tricky parsing 
spots.  Granted, the language is simpler than D and doesn't have nearly as 
many statements, but it doesn't seem like there would be any other 
difficulties in parsing.

The one major downside to this change in the grammar, however, is that it 
makes lexical analysis dependent upon syntactic analysis, since the 
significance of newlines depends upon the current construct being parsed.  D 
prides itself on having no such interdependencies, and you'd be hard-pressed 
to convince Walter to do otherwise. 



 May 05 2008



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Jarrett Billingsley wrote:

 The one major downside to this change in the grammar, however, is that it 
 makes lexical analysis dependent upon syntactic analysis, since the 
 significance of newlines depends upon the current construct being parsed.  D 
 prides itself on having no such interdependencies, and you'd be hard-pressed 
 to convince Walter to do otherwise. 


It's not pride based. There are sound technical reasons.



 May 05 2008



prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Tomasz Sowinski Wrote:

As you say such things of D probably aren't going to change, but with some
careful design most (I think all) of those problems can be solved.
And you can even go all the way :-)

This is a little old D example code of mine:

import std.stdio, std.stream, std.string, std.ctype, std.gc;

void traduct(char[] n, char[] digits, int start, char[][] words,
char[][][char[]] gdict) {
    if (start >= digits.length)
        writefln(n, ": ", words.join(" "));
    else {
        auto found_word = false;
        for(auto i = start; i < digits.length; i++)
            if (digits[start .. i+1] in gdict) {
                found_word = true;
                foreach(hit; gdict[digits[start .. i+1]])
                    traduct(n, digits, i+1, words ~ [hit], gdict);
            }
        if (!found_word && (!words || (words &&
!std.ctype.isdigit(words[words.length-1][0]))))
            traduct(n, digits, start+1, words ~ [digits[start..start+1]],
gdict);
    }
}

void main() {
    std.gc.disable();
    auto gtable = maketrans("ejnqrwxdsyftamcivbkulopghzEJNQRWXDSYFTAMCIVBKULOPGHZ",
                           
"0111222333445566677788899901112223334455666777888999");

    size_t line_start;
    char[][][char[]] gdict;
    auto input_dict = cast(char[])std.file.read("dictionary.txt");

    foreach (current_pos, c; input_dict)
        if (c == '\n') { // words with DOS newlines too
            auto word = input_dict[line_start .. current_pos].strip();
            // word isn't a string, it's just a reference (start-end index) to
            //   the input_dict string, despite being stripped.
            gdict[word.translate(gtable, "\"")] ~= word;
            line_start = current_pos+1;
        }
    auto word = input_dict[line_start .. input_dict.length].strip();
    if (word.length > 0)
        gdict[word.translate(gtable, "\"")] ~= word;

    foreach(char[] n; new BufferedFile("input.txt"))
        traduct(n, n.removechars("/-"), 0, [], gdict);
}


The alternative version without ; and braces may look unusual for C programmers:


import std.stdio, std.stream, std.string, std.ctype, std.gc

void traduct(char[] n, char[] digits, int start, char[][] words,
char[][][char[]] gdict):
    if (start >= digits.length):
        writefln(n, ": ", words.join(" "))
    else:
        auto found_word = false
        foreach(i; range(start, digits.length)):
            if (digits[start .. i+1] in gdict):
                found_word = true
                foreach(hit; gdict[digits[start .. i+1]]):
                    traduct(n, digits, i+1, words ~ [hit], gdict)
        if (!found_word && (!words || (words &&
!std.ctype.isdigit(words[words.length-1][0])))):
            traduct(n, digits, start+1, words ~ [digits[start..start+1]], gdict)

void main():
    std.gc.disable()
    auto gtable = maketrans("ejnqrwxdsyftamcivbkulopghzEJNQRWXDSYFTAMCIVBKULOPGHZ",
                           
"0111222333445566677788899901112223334455666777888999")

    char[][][char[]] gdict
    foreach(char[] w; new BufferedFile("dictionary.txt")):
        gdict[w.translate(gtable, "\"")] ~= w.dup

    foreach(char[] n; new BufferedFile("input.txt")):
        traduct(n, n.removechars("/-"), 0, [], gdict)


It seems some people have tried that:

http://www.imitationpickles.org/pyplus/
http://blog.micropledge.com/2007/09/nobraces/
http://micropledge.com/projects/nobraces

But they use very simple means, so they fail in certain situations.
To solve the problem better a pymeta (OMeta parser) may be useful:
http://washort.twistedmatrix.com/

Bye,
bearophile



 May 05 2008



  parent reply Tomasz Sowinski <tomeksowi gmail.com>  writes:


bearophile Wrote:


 Tomasz Sowinski Wrote:
 
 As you say such things of D probably aren't going to change, but with some
careful design most (I think all) of those problems can be solved.
 And you can even go all the way :-)
 
 This is a little old D example code of mine:
 
 import std.stdio, std.stream, std.string, std.ctype, std.gc;
 
 void traduct(char[] n, char[] digits, int start, char[][] words,
char[][][char[]] gdict) {
     if (start >= digits.length)
         writefln(n, ": ", words.join(" "));
     else {
         auto found_word = false;
         for(auto i = start; i < digits.length; i++)
             if (digits[start .. i+1] in gdict) {
                 found_word = true;
                 foreach(hit; gdict[digits[start .. i+1]])
                     traduct(n, digits, i+1, words ~ [hit], gdict);
             }
         if (!found_word && (!words || (words &&
!std.ctype.isdigit(words[words.length-1][0]))))
             traduct(n, digits, start+1, words ~ [digits[start..start+1]],
gdict);
     }
 }
 
 void main() {
     std.gc.disable();
     auto gtable = maketrans("ejnqrwxdsyftamcivbkulopghzEJNQRWXDSYFTAMCIVBKULOPGHZ",
                            
"0111222333445566677788899901112223334455666777888999");
 
     size_t line_start;
     char[][][char[]] gdict;
     auto input_dict = cast(char[])std.file.read("dictionary.txt");
 
     foreach (current_pos, c; input_dict)
         if (c == '\n') { // words with DOS newlines too
             auto word = input_dict[line_start .. current_pos].strip();
             // word isn't a string, it's just a reference (start-end index) to
             //   the input_dict string, despite being stripped.
             gdict[word.translate(gtable, "\"")] ~= word;
             line_start = current_pos+1;
         }
     auto word = input_dict[line_start .. input_dict.length].strip();
     if (word.length > 0)
         gdict[word.translate(gtable, "\"")] ~= word;
 
     foreach(char[] n; new BufferedFile("input.txt"))
         traduct(n, n.removechars("/-"), 0, [], gdict);
 }
 
 
 The alternative version without ; and braces may look unusual for C
programmers:
 
 
 import std.stdio, std.stream, std.string, std.ctype, std.gc
 
 void traduct(char[] n, char[] digits, int start, char[][] words,
char[][][char[]] gdict):
     if (start >= digits.length):
         writefln(n, ": ", words.join(" "))
     else:
         auto found_word = false
         foreach(i; range(start, digits.length)):
             if (digits[start .. i+1] in gdict):
                 found_word = true
                 foreach(hit; gdict[digits[start .. i+1]]):
                     traduct(n, digits, i+1, words ~ [hit], gdict)
         if (!found_word && (!words || (words &&
!std.ctype.isdigit(words[words.length-1][0])))):
             traduct(n, digits, start+1, words ~ [digits[start..start+1]],
gdict)
 
 void main():
     std.gc.disable()
     auto gtable = maketrans("ejnqrwxdsyftamcivbkulopghzEJNQRWXDSYFTAMCIVBKULOPGHZ",
                            
"0111222333445566677788899901112223334455666777888999")
 
     char[][][char[]] gdict
     foreach(char[] w; new BufferedFile("dictionary.txt")):
         gdict[w.translate(gtable, "\"")] ~= w.dup
 
     foreach(char[] n; new BufferedFile("input.txt")):
         traduct(n, n.removechars("/-"), 0, [], gdict)
 


I like the version without ; but how can you tell where a block ends without
braces? indents?



 May 05 2008



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Tomasz Sowinski:

 I like the version without ; but how can you tell where a block ends without
braces? indents?


Where there is a de-dent.
There's a known language that's designed like this ;-)

Bye,
bearophile



 May 05 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:fvnk34$m27$1 digitalmars.com...

 Tomasz Sowinski:

 I like the version without ; but how can you tell where a block ends 
 without braces? indents?


 Where there is a de-dent.
 There's a known language that's designed like this ;-)


Oh man, now you've got me started on one of my pet peeves...

Semantically-meaningful indentation: That is exactly the reason I truly, 
truly hate Python (Well, that and a complete lack of variable declarations. 
Hello, hidden bugs!).

Python's semantically-meaningful indentation was intended to fix the problem 
of poorly-indented code by enforcing proper indentation in the language and 
compiler. But the problem is, it *doesn't* actually enforce it. In fact, it 
*can't* enforce it because it doesn't have enough information to enforce it. 
All it really does (and all it's able to do) is run around *assuming* your 
code is properly indented while silently drawing semantic conclusions from 
those (obviously not always correct) assumptions.

In fact it's really the same root problem as "no variable declarations". In 
both cases, the compiler does nothing but assume that what you wrote is what 
you meant, thus silently introducing hidden bugs 1. Whenever you didn't 
*really* want the new variables "my_reponse" and "my_responce" in additon to 
"my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 
2. Whenever you didn't *really* want to break out of that loop/conditional. 



 May 06 2008



 next sibling parent  Bill Baxter <dnewsgroup billbaxter.com>  writes:


Nick Sabalausky wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:fvnk34$m27$1 digitalmars.com...

 Tomasz Sowinski:

 I like the version without ; but how can you tell where a block ends 
 without braces? indents?


 Where there is a de-dent.
 There's a known language that's designed like this ;-)


 
 Oh man, now you've got me started on one of my pet peeves...
 
 Semantically-meaningful indentation: That is exactly the reason I truly, 
 truly hate Python (Well, that and a complete lack of variable declarations. 
 Hello, hidden bugs!).
 
 Python's semantically-meaningful indentation was intended to fix the problem 
 of poorly-indented code by enforcing proper indentation in the language and 
 compiler. But the problem is, it *doesn't* actually enforce it. In fact, it 
 *can't* enforce it because it doesn't have enough information to enforce it. 
 All it really does (and all it's able to do) is run around *assuming* your 
 code is properly indented while silently drawing semantic conclusions from 
 those (obviously not always correct) assumptions.
 
 In fact it's really the same root problem as "no variable declarations". In 
 both cases, the compiler does nothing but assume that what you wrote is what 
 you meant, thus silently introducing hidden bugs 1. Whenever you didn't 
 *really* want the new variables "my_reponse" and "my_responce" in additon to 
 "my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 
 2. Whenever you didn't *really* want to break out of that loop/conditional. 


I like Python, but I agree the whitespace structure thing is at best a 
wash.  Not having to type braces does make the code look cleaner, but 
causes other problems.  If there were such a thing as curly-brace 
Python, I'd probably use that.

--bb



 May 06 2008



prev sibling  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Nick Sabalausky wrote:

 Python's semantically-meaningful indentation was intended to fix the problem 
 of poorly-indented code by enforcing proper indentation in the language and 
 compiler. But the problem is, it *doesn't* actually enforce it. In fact, it 
 *can't* enforce it because it doesn't have enough information to enforce it. 
 All it really does (and all it's able to do) is run around *assuming* your 
 code is properly indented while silently drawing semantic conclusions from 
 those (obviously not always correct) assumptions.
 
 In fact it's really the same root problem as "no variable declarations". In 
 both cases, the compiler does nothing but assume that what you wrote is what 
 you meant, thus silently introducing hidden bugs 1. Whenever you didn't 
 *really* want the new variables "my_reponse" and "my_responce" in additon to 
 "my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 
 2. Whenever you didn't *really* want to break out of that loop/conditional. 


That goes back to the point that a language needs redundancy in order to 
detect errors. Having semantically-meaningful indentation, removing 
redundant semicolons, and implicitly declaring variables all remove 
redundancy at the (high) cost of inability to detect common bugs.

Those things are fine for scripting language programs that are fairly 
short (like under a screenful). It gets increasingly bad as the size of 
the program increases.



 May 06 2008



  parent reply Don <nospam nospam.com.au>  writes:


Walter Bright wrote:

 Nick Sabalausky wrote:

 Python's semantically-meaningful indentation was intended to fix the 
 problem of poorly-indented code by enforcing proper indentation in the 
 language and compiler. But the problem is, it *doesn't* actually 
 enforce it. In fact, it *can't* enforce it because it doesn't have 
 enough information to enforce it. All it really does (and all it's 
 able to do) is run around *assuming* your code is properly indented 
 while silently drawing semantic conclusions from those (obviously not 
 always correct) assumptions.

 In fact it's really the same root problem as "no variable 
 declarations". In both cases, the compiler does nothing but assume 
 that what you wrote is what you meant, thus silently introducing 
 hidden bugs 1. Whenever you didn't *really* want the new variables 
 "my_reponse" and "my_responce" in additon to "my_response" 
 (VB/VBScript coders use "option explicit" *for a reason*), and 2. 
 Whenever you didn't *really* want to break out of that loop/conditional. 


 
 That goes back to the point that a language needs redundancy in order to 
 detect errors. Having semantically-meaningful indentation, removing 
 redundant semicolons, and implicitly declaring variables all remove 
 redundancy at the (high) cost of inability to detect common bugs.
 
 Those things are fine for scripting language programs that are fairly 
 short (like under a screenful). It gets increasingly bad as the size of 
 the program increases.


Implicitly declared variables are probably the greatest of all false 
economies in the programming world.

bugs(no variable declarations) > 100 * bugs(dangling pointers).



 May 08 2008



  parent reply Michael Neumann <mneumann ntecs.de>  writes:


Don wrote:

 Walter Bright wrote:

 Nick Sabalausky wrote:

 Python's semantically-meaningful indentation was intended to fix the
 problem of poorly-indented code by enforcing proper indentation in
 the language and compiler. But the problem is, it *doesn't* actually
 enforce it. In fact, it *can't* enforce it because it doesn't have
 enough information to enforce it. All it really does (and all it's
 able to do) is run around *assuming* your code is properly indented
 while silently drawing semantic conclusions from those (obviously not
 always correct) assumptions.

 In fact it's really the same root problem as "no variable
 declarations". In both cases, the compiler does nothing but assume
 that what you wrote is what you meant, thus silently introducing
 hidden bugs 1. Whenever you didn't *really* want the new variables
 "my_reponse" and "my_responce" in additon to "my_response"
 (VB/VBScript coders use "option explicit" *for a reason*), and 2.
 Whenever you didn't *really* want to break out of that 






loop/conditional.

 That goes back to the point that a language needs redundancy in order
 to detect errors. Having semantically-meaningful indentation, removing
 redundant semicolons, and implicitly declaring variables all remove
 redundancy at the (high) cost of inability to detect common bugs.

 Those things are fine for scripting language programs that are fairly
 short (like under a screenful). It gets increasingly bad as the size
 of the program increases.


 Implicitly declared variables are probably the greatest of all false
 economies in the programming world.

 bugs(no variable declarations) > 100 * bugs(dangling pointers).


Is that your own experience? Only practice tells the truth!

Would you say that Smalltalk is a scripting language? See where it is
used, and notice the size of the applications written in it.

I am sure every C program includes more errors than the worst
Ruby/Python program you can ever write. Not so sure about other
scripting language... :)

Regards,

   Michael



 May 08 2008



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Michael Neumann" <mneumann ntecs.de> wrote in message 
news:fvv6a4$2sb3$1 digitalmars.com...

 I am sure every C program includes more errors than the worst
 Ruby/Python program you can ever write. Not so sure about other
 scripting language... :)


C/C++ are probably not good examples. There are plently of other things 
wrong with C and C++. But, as I like to say, "There's a reason most VB code 
uses option explicit" (Not that I'm advocating VB). 



 May 08 2008



prev sibling  parent reply Don <nospam nospam.com.au>  writes:


Michael Neumann wrote:

 Don wrote:
  > Walter Bright wrote:
  >> Nick Sabalausky wrote:
  >>> Python's semantically-meaningful indentation was intended to fix the
  >>> problem of poorly-indented code by enforcing proper indentation in
  >>> the language and compiler. But the problem is, it *doesn't* actually
  >>> enforce it. In fact, it *can't* enforce it because it doesn't have
  >>> enough information to enforce it. All it really does (and all it's
  >>> able to do) is run around *assuming* your code is properly indented
  >>> while silently drawing semantic conclusions from those (obviously not
  >>> always correct) assumptions.
  >>>
  >>> In fact it's really the same root problem as "no variable
  >>> declarations". In both cases, the compiler does nothing but assume
  >>> that what you wrote is what you meant, thus silently introducing
  >>> hidden bugs 1. Whenever you didn't *really* want the new variables
  >>> "my_reponse" and "my_responce" in additon to "my_response"
  >>> (VB/VBScript coders use "option explicit" *for a reason*), and 2.
  >>> Whenever you didn't *really* want to break out of that 
 loop/conditional.
  >>
  >> That goes back to the point that a language needs redundancy in order
  >> to detect errors. Having semantically-meaningful indentation, removing
  >> redundant semicolons, and implicitly declaring variables all remove
  >> redundancy at the (high) cost of inability to detect common bugs.
  >>
  >> Those things are fine for scripting language programs that are fairly
  >> short (like under a screenful). It gets increasingly bad as the size
  >> of the program increases.
  >
  > Implicitly declared variables are probably the greatest of all false
  > economies in the programming world.
  >
  > bugs(no variable declarations) > 100 * bugs(dangling pointers).
 
 Is that your own experience? Only practice tells the truth!


Yes. And such bugs can be horrible to track down. When I use such 
languages I seem to spend most of my time hunting for typos which the 
compiler should have caught.


 
 Would you say that Smalltalk is a scripting language? See where it is
 used, and notice the size of the applications written in it.
 
 I am sure every C program includes more errors than the worst
 Ruby/Python program you can ever write. Not so sure about other
 scripting language... :)


Ignoring the obvious exaggeration (look at the bug lists for Knuth's 
code, for an example of bug-free C code) -- there are many causes of 
bugs in C, other than dangling pointers!
And I think that many bugs attributed to dangling pointers are actually 
_uninitialized variable_ bugs. An uninitialised pointer containing 
random garbage is horrible thing. In my experience, the problem is 
almost always in the initialisation, not in the use of pointers.



 May 09 2008



  parent reply Michael Neumann <mneumann ntecs.de>  writes:


Don wrote:

 Michael Neumann wrote:

 Don wrote:
  > Walter Bright wrote:
  >> Nick Sabalausky wrote:
  >>> Python's semantically-meaningful indentation was intended to 




fix the

  >>> problem of poorly-indented code by enforcing proper indentation in
  >>> the language and compiler. But the problem is, it *doesn't* 




actually

  >>> enforce it. In fact, it *can't* enforce it because it doesn't have
  >>> enough information to enforce it. All it really does (and all it's
  >>> able to do) is run around *assuming* your code is properly indented
  >>> while silently drawing semantic conclusions from those (obviously
 not
  >>> always correct) assumptions.
  >>>
  >>> In fact it's really the same root problem as "no variable
  >>> declarations". In both cases, the compiler does nothing but assume
  >>> that what you wrote is what you meant, thus silently introducing
  >>> hidden bugs 1. Whenever you didn't *really* want the new variables
  >>> "my_reponse" and "my_responce" in additon to "my_response"
  >>> (VB/VBScript coders use "option explicit" *for a reason*), and 2.
  >>> Whenever you didn't *really* want to break out of that
 loop/conditional.
  >>
  >> That goes back to the point that a language needs redundancy in 




order

  >> to detect errors. Having semantically-meaningful indentation,
 removing
  >> redundant semicolons, and implicitly declaring variables all remove
  >> redundancy at the (high) cost of inability to detect common bugs.
  >>
  >> Those things are fine for scripting language programs that are 




fairly

  >> short (like under a screenful). It gets increasingly bad as the size
  >> of the program increases.
  >
  > Implicitly declared variables are probably the greatest of all false
  > economies in the programming world.
  >
  > bugs(no variable declarations) > 100 * bugs(dangling pointers).

 Is that your own experience? Only practice tells the truth!


 Yes. And such bugs can be horrible to track down. When I use such
 languages I seem to spend most of my time hunting for typos which the
 compiler should have caught.


How can the compiler prevent you from doing any typos? Imagine mixing
two variables "i" and "j". This can happen to you in any language!

And how is the following any better (taken from another post):

   class A {
     int i=0;

     void foo() {
       // Accidentially clobbers "this.i" aka " i"
       for(i=0; i<77; i++)
         {/* Do stuff */}
     }

     invariant() {
       assert(this.i==0); // Fails after foo() is called
     }
   }

Sure, the compiler will issue a warning.


 Would you say that Smalltalk is a scripting language? See where it is
 used, and notice the size of the applications written in it.

 I am sure every C program includes more errors than the worst
 Ruby/Python program you can ever write. Not so sure about other
 scripting language... :)


 Ignoring the obvious exaggeration (look at the bug lists for Knuth's
 code, for an example of bug-free C code) -- there are many causes of
 bugs in C, other than dangling pointers!


Agreed.


 And I think that many bugs attributed to dangling pointers are actually
 _uninitialized variable_ bugs.


But in Ruby, to mention a scripting language, instance variables are
*always* initialized! In C, an uninitialized variable will silently
produce wrong results, which are hardest to find bugs (IMHO). On the
other side, in Ruby, it's very likely that you get a method-missing
runtime exception and as such the problem is easy to spot!


 An uninitialised pointer containing
 random garbage is horrible thing. In my experience, the problem is
 almost always in the initialisation, not in the use of pointers.


Lets replace "declarations" with "initialization" in your
original statement, and I agree 100%:

bugs(no variable initialization) > 100 * bugs(dangling pointers).

Regards,

   Michael



 May 09 2008



  parent reply Don <nospam nospam.com.au>  writes:


Michael Neumann wrote:

 Don wrote:
  > Michael Neumann wrote:
  >> Don wrote:
  >>  > Walter Bright wrote:
  >>  >> Nick Sabalausky wrote:
  >>  >>> Python's semantically-meaningful indentation was intended to 
 fix the
  >>  >>> problem of poorly-indented code by enforcing proper indentation in
  >>  >>> the language and compiler. But the problem is, it *doesn't* 
 actually
  >>  >>> enforce it. In fact, it *can't* enforce it because it doesn't have
  >>  >>> enough information to enforce it. All it really does (and all it's
  >>  >>> able to do) is run around *assuming* your code is properly 
 indented
  >>  >>> while silently drawing semantic conclusions from those (obviously
  >> not
  >>  >>> always correct) assumptions.
  >>  >>>
  >>  >>> In fact it's really the same root problem as "no variable
  >>  >>> declarations". In both cases, the compiler does nothing but assume
  >>  >>> that what you wrote is what you meant, thus silently introducing
  >>  >>> hidden bugs 1. Whenever you didn't *really* want the new variables
  >>  >>> "my_reponse" and "my_responce" in additon to "my_response"
  >>  >>> (VB/VBScript coders use "option explicit" *for a reason*), and 2.
  >>  >>> Whenever you didn't *really* want to break out of that
  >> loop/conditional.
  >>  >>
  >>  >> That goes back to the point that a language needs redundancy in 
 order
  >>  >> to detect errors. Having semantically-meaningful indentation,
  >> removing
  >>  >> redundant semicolons, and implicitly declaring variables all remove
  >>  >> redundancy at the (high) cost of inability to detect common bugs.
  >>  >>
  >>  >> Those things are fine for scripting language programs that are 
 fairly
  >>  >> short (like under a screenful). It gets increasingly bad as the 
 size
  >>  >> of the program increases.
  >>  >
  >>  > Implicitly declared variables are probably the greatest of all false
  >>  > economies in the programming world.
  >>  >
  >>  > bugs(no variable declarations) > 100 * bugs(dangling pointers).
  >>
  >> Is that your own experience? Only practice tells the truth!
  >
  > Yes. And such bugs can be horrible to track down. When I use such
  > languages I seem to spend most of my time hunting for typos which the
  > compiler should have caught.
 
 How can the compiler prevent you from doing any typos? Imagine mixing
 two variables "i" and "j". This can happen to you in any language!


Yes, but when you have declarations, you can reduce that probability 
dramatically by using meaningful identifier names. That doesn't work in 
a language without them.

HaveWeInitializedEverythingYet when elsewhere it is 
HaveWeInitialisedEverythingYet

(I've had examples like that in PHP).

That just doesn't happen when you have variable declarations. Short, 
typo-prone names generally have small enough scope that you can see them 
in a screen or two.


  > And I think that many bugs attributed to dangling pointers are actually
  > _uninitialized variable_ bugs.
 
 But in Ruby, to mention a scripting language, instance variables are
 *always* initialized! In C, an uninitialized variable will silently
 produce wrong results, which are hardest to find bugs (IMHO). 


Yup. Especially with floating point, where 1% of the time it will be 
initialized to NaN...

On the

 other side, in Ruby, it's very likely that you get a method-missing
 runtime exception and as such the problem is easy to spot!
 
  > An uninitialised pointer containing
  > random garbage is horrible thing. In my experience, the problem is
  > almost always in the initialisation, not in the use of pointers.
 
 Lets replace "declarations" with "initialization" in your
 original statement, and I agree 100%:
 
 bugs(no variable initialization) > 100 * bugs(dangling pointers).


Yes, I probably overstated the case for declarations. But my experience 
with PHP is that absence of declarations is the number 1 source of bugs 
in that language. And it manifests itself as an initialization problem 
-- I DID initialise that variable, but because of a typo, I find that 
it's unexpectedly zero!



 May 09 2008



 next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Don:

 But my experience 
 with PHP is that absence of declarations is the number 1 source of bugs 
 in that language. And it manifests itself as an initialization problem 
 -- I DID initialise that variable, but because of a typo, I find that 
 it's unexpectedly zero!


I think here there's a difference between Python and PHP, Python creates
variables only when you write them, not when you read them.

Bye,
bearophile



 May 09 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:g01trc$27bs$1 digitalmars.com...

 Don:

 But my experience
 with PHP is that absence of declarations is the number 1 source of bugs
 in that language. And it manifests itself as an initialization problem
 -- I DID initialise that variable, but because of a typo, I find that
 it's unexpectedly zero!


 I think here there's a difference between Python and PHP, Python creates 
 variables only when you write them, not when you read them.


That's certainly an improvement, and does reduce the number of problems, but 
the problem is still there:

Quoted from 
http://mail.python.org/pipermail/python-list/2005-January/304959.html


 epsilon=0
 S=0
 while epsilon<10:
   S=S+epsilon
   epselon=epsilon+1
 print S

 It will print zero, and it is not easy to find such a bug!





 May 09 2008



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


This answer is mostly off topic in this newsgroup...

Nick Sabalausky:

 epsilon=0
 S=0
 while epsilon<10:
   S=S+epsilon
   epselon=epsilon+1
 print S

 It will print zero, and it is not easy to find such a bug!




No language is perfect, it's always a compromise. For my personal style of
programming Python is closer to being the best (I use D a lot because I need to
be "closer to the metal", and I like it a lot). I think I have done a similar
mistake only twice in more than 60 thousand of lines of Python I have written,
and I have found the bug once 30 seconds later, and the other time ten minutes
later, using doctests:
http://docs.python.org/lib/module-doctest.html
they are a very good tool to test your code and spot bugs. Dynamic languages
allows you to spot and fix those bugs faster, so it's a matter of balance.
Usually the worse bugs aren't misspelled variable names.

Bye,
bearophile



 May 09 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:g02cej$7hb$1 digitalmars.com...

 Dynamic languages allows you to spot and fix those bugs faster


I've seen fans of dynamic languages say this a lot. I'm not challenging it, 
so please don't take this as an attack, but I'm curious: How are dynamic 
languages are considered to be easier/faster to spot/fix bugs? 



 May 09 2008



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Nick Sabalausky:

 How are dynamic languages are considered to be easier/faster to spot/fix bugs?


Well:
- here I talk about Python, because I usually talk about the things I know.
- They often have a faster write code-test code loop because there's no
compilation phase.
- Python has an interactive shell, you usually use that to build and try and
test little complex pieces of code, for example to be sure complex slices are
correct, etc. You can use that to test the code (a little piece, one line of
code, a function, a class, a module, the whole program) interactively (with the
debugger too, if you want).
- When you have done some tests of the method/function/class/module in the
shell, you can just copy the text of that interactive session and paste it into
a docstring of that function/class (and you may want to clean it a bit), that's
a doctest already (adding two lines in the "main" too). Then you can add more
tests like that very quickly. It's not easy to find a faster and simpler way to
test code. With that you can avoid most little bugs from your code. I miss
doctests in D.
- There are lints for Python too, you may want to use them too if you are
developing a large code, etc. I generally don't use them for small programs.
- Python code is very readable and it has very little noise/clutter. And its
formatting is very uniform across different developers. That helps you
spot/avoid bugs. It helps you focus on the algorithm instead on the
syntax/noise.
- Python has good builtins, and their API is very well designed, with easy
short names, and it's easy to remember even if you don't use an IDE. And they
are designed to often warn you if you use them in the wrong way (try using
sum() to sum strings). So using them you can write code faster, and put less
bugs in. D phobos std.string API shows some examples where its API can be
improved, like the string cropping that's confusing between two very similarly
named functions. Those things may increase your bug count.
- Like D python has many fail-safe, for example there is no ++ or while b=a+12:
etch, those details (and other parts of the Python syntax) are designed
specifically to avoid you the most common bugs, even if that may cost you few
extra chars of code.
- Unlike C, lot things are safe(r), there are no pointers, etc.
- Python has some higher-order functions and tools (like itertools, map, list
comprehensions, apply, keyword arguments, zip, generator, iterators,
decorators, etc) that help you write less code, write it in a higher level,
avoiding bugs, making code more readable, etc. I have tried to put some of
those things into my D libs I show here now and then, and I think I have
partially succeed.
- It has a very uniform syntax and semantics, everything is managed by
reference, classes and functions are objects of some metaclass, so you have
much less things to think about, and you program faster putting less bugs in.
Corner cases (C++ is *full* of them) slow you down and make you put *tons* of
bugs into your code. Python is slower at running time than compiled languages,
but it's simpler. This allows faster coding and give you less things to think
of while you code or while you debug, so you have more free brainpower to think
about writing the good/correct algorithm or avoiding more logical/higher-order
bugs.
- having shorter names and methods everywhere allows you to write Python code
with a bigger font, so your eyes can read code better, and you can spot
syntax/typo bugs better. I use a smaller font when I use languages that burn a
lot of horizontal space.
- Python is very well debugged (I have found only two bugs in Python so far,
while I have found about 15 in DMD, and I have used D for much less time) and
it has a large std lib, full of many useful things you can use quickly in
simple ways to do most common things, that are almost bug-free, usually with a
simple and logical API. All this speeds up your coding, because you use those
things instead of re-writing them yourself, avoids you bugs, allows you to use
algorithms by Knuth, etc. When you spot a bug it's nearly always yours.
- Python module system avoids you TONS of compilation/linking problems you may
find in C++. D module system looks like a partially copy of the Python module
system, but it has some bugs/missing parts/bad designed things that I have
discussed in a nearly ignored post of mine in this newsgroup. Such module
system keeps things tidy, and avoids you many bugs. (Import is dynamic, that
helps for other things).
- Probably there are other things I have missed. Each of those things can be
found in other languages (and D copies some of them), but when you sum them all
you may find your coding speed rather high and your bug count low enough to
allow you to write systems like Zope (I think it's about 1e5 - 2e5 lines long).

Now back to D!

Bye,
bearophile



 May 09 2008



prev sibling  parent  Michael Neumann <mneumann ntecs.de>  writes:


Don wrote:

 Yes, but when you have declarations, you can reduce that probability
 dramatically by using meaningful identifier names. That doesn't work in
 a language without them.

 HaveWeInitializedEverythingYet when elsewhere it is
 HaveWeInitialisedEverythingYet

 (I've had examples like that in PHP).


Not neccessarily! The last 45 minutes I hacked up TypoCheck, which
inspects the source code of any Ruby application and will warn about any
potential mispelled local variable. I use the Levensthein distance for
that.

http://www.ntecs.de/projects/TypoCheck/

This will catch most cases, except very short variable names, as here
it's hard to distinguish a typo.

Of course it can never be as good as when manually declaring variables
(due to missing redundance).


 bugs(no variable initialization) > 100 * bugs(dangling pointers).


 Yes, I probably overstated the case for declarations. But my experience
 with PHP is that absence of declarations is the number 1 source of bugs
 in that language. And it manifests itself as an initialization problem
 -- I DID initialise that variable, but because of a typo, I find that
 it's unexpectedly zero!


So I guess PHP will just return a value if you read an uninitialized
local variable, while Ruby will very likely raise an exception.

Uhm, but I think it's getting very off-topic :)

Regards,

   Michael



 May 09 2008



prev sibling next sibling parent  J Duncan <jtd514_ ameritech.net>  writes:


This isn't BASIC.



 May 05 2008



prev sibling next sibling parent  "Koroskin Denis" <2korden gmail.com>  writes:


On Mon, 05 May 2008 12:13:48 +0400, Tomasz Sowinski <tomeksowi gmail.com>  
wrote:


 Just another feature thought. Never gonna happen, but still...

 What's the reason of having lines end with a semicolon? Anything else  
 than a legacy issue with C/C++?

 The only thing I can think of is having multiple statements in one line,  
 but that only makes code unreadable. Wouldn't getting rid of ; improve  
 readability?


 Tomek


Although Javascript has a C-style syntax, it doesn't force you to use  
semicolon.
 From my experience, the code doesn't get any readability improvements that  
way.



 May 05 2008



prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Tomasz Sowinski wrote:

 What's the reason of having lines end with a semicolon?


A well designed language has some redundancy built in. The reason for 
the redundancy is so the compiler can detect and diagnose errors. If 
there was no redundancy, any random stream of characters, i.e. 

would be a valid program.

Having the ; end statements provides a nice "anchor" point for the 
parser. It means that what comes before it must form a grammatically 
correct statement. Otherwise, the compiler must hopefully keep scanning 
forward, and then try all kinds of parse trees out on the jumble of 
tokens looking for a set of statements that will fit it.

Furthermore, when the compiler does diagnose an error, error recovery 
can be as simple as "skip forward to the ;, then restart the statement 
parser." Without such an anchor, you'll get one error message followed 
by a cascade of useless drivel.

BTW, double entry bookkeeping, invented in the middle ages, was a huge 
advance in accounting. It essentially made everything redundant, which 
helped find and correct arithmetic errors. It spawned the term 
"balancing the books" which is nothing more than tracking down and 
reconciling all the errors. Without the redundancy, there'd be no way to 
balance the books because there'd be no way to detect errors.



 May 05 2008



 next sibling parent  Tower  Ty <towerty msn.com.au>  writes:


Walter Bright Wrote:

 
 BTW, double entry bookkeeping, invented in the middle ages, was a huge 
 advance in accounting. It essentially made everything redundant, which 
 helped find and correct arithmetic errors. It spawned the term 
 "balancing the books" which is nothing more than tracking down and 
 reconciling all the errors. Without the redundancy, there'd be no way to 
 balance the books because there'd be no way to detect errors.


Keep in mind that alongside double entry  runs a system called single entry
accounting  which can be used instead. Usually it is used for smaller
enterprises and avoids the duplication of double entry. Single entry accounting
is what you would use to balance your petty cash or your cheque book 



 May 05 2008



prev sibling  parent  Tower  Ty <towerty msn.com.au>  writes:


Walter Bright Wrote:

 
 BTW, double entry bookkeeping, invented in the middle ages, was a huge 
 advance in accounting. It essentially made everything redundant, which 
 helped find and correct arithmetic errors. It spawned the term 
 "balancing the books" which is nothing more than tracking down and 
 reconciling all the errors. Without the redundancy, there'd be no way to 
 balance the books because there'd be no way to detect errors.


Keep in mind that alongside double entry  runs a system called single entry
accounting  which can be used instead. Usually it is used for smaller
enterprises and avoids the duplication of double entry. Single entry accounting
is what you would use to balance your petty cash or your cheque book 



 May 05 2008



prev sibling next sibling parent  janderson <askme me.com>  writes:


Tomasz Sowinski wrote:

 Just another feature thought. Never gonna happen, but still...
 
 What's the reason of having lines end with a semicolon? Anything else than a
legacy issue with C/C++?
 
 The only thing I can think of is having multiple statements in one line, but
that only makes code unreadable. Wouldn't getting rid of ; improve readability?
 
 
 Tomek


This has been discussed before. Apparently Walter even tried it for a 
scripting language with not so good results.

-Joel



 May 05 2008



prev sibling next sibling parent reply Pragma <eric.t.anderton gmail.com>  writes:


Tomasz Sowinski Wrote:


 
 Just another feature thought. Never gonna happen, but still...
 
 What's the reason of having lines end with a semicolon? Anything else than a
legacy issue with C/C++?
 
 The only thing I can think of is having multiple statements in one line, but
that only makes code unreadable. Wouldn't getting rid of ; improve readability?
 


ECMAScript (JavaScript) allows this by making the terminating ';' optional, 
but you wind up with occasionally hard-to-find ambiguities as a result.  You
wind up falling back on using ';' everywhere as a habit just to avoid that
problem.  Requiring it, on the other hand, means that this problem never comes
up.

As as part of D's philosophy is to reduce to program errors by language design,
removing ';' would be somewhat against that goal.  Even making it optional
would be a bad move IMO.  So I think it's here to stay.



 May 06 2008



  parent  Tom <tom nospam.com>  writes:


Pragma escribió:

 Tomasz Sowinski Wrote:
 

 Just another feature thought. Never gonna happen, but still...

 What's the reason of having lines end with a semicolon? Anything else than a
legacy issue with C/C++?

 The only thing I can think of is having multiple statements in one line, but
that only makes code unreadable. Wouldn't getting rid of ; improve readability?


 
 ECMAScript (JavaScript) allows this by making the terminating ';' optional, 
but you wind up with occasionally hard-to-find ambiguities as a result.  You
wind up falling back on using ';' everywhere as a habit just to avoid that
problem.  Requiring it, on the other hand, means that this problem never comes
up.
 
 As as part of D's philosophy is to reduce to program errors by language
design, removing ';' would be somewhat against that goal.  Even making it
optional would be a bad move IMO.  So I think it's here to stay.


I fully agree.


--
Tom;



 May 06 2008



prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Pragma:

 ECMAScript (JavaScript) allows this by making the terminating ';' optional, 
but you wind up with occasionally hard-to-find ambiguities as a result.  You
wind up falling back on using ';' everywhere as a habit just to avoid that
problem.


Can someone show me few examples of such ambiguities?
(In about ten thousands lines of D code I have written I think there are very
few (or maybe none) of them...).

Bye,
bearophile



 May 07 2008



  parent reply Pragma <eric.t.anderton gmail.com>  writes:


bearophile Wrote:


 Pragma:

 ECMAScript (JavaScript) allows this by making the terminating ';' optional, 
but you wind up with occasionally hard-to-find ambiguities as a result.  You
wind up falling back on using ';' everywhere as a habit just to avoid that
problem.


 
 Can someone show me few examples of such ambiguities?
 (In about ten thousands lines of D code I have written I think there are very
few (or maybe none) of them...).


Sure.  

// given:
void foo(){}
void bar(){}

// call both functions without a terminating ';' 
foo bar

The parser would likely interpret this as a variable declaration for "bar of
type foo".  However it's also just as valid as the intent: two consecutive
calls to functions w/o the "()" hint.

Not only is this difficult for the compiler to parse correctly (it lexes just
fine), but it's just as hard for the developer to validate.  Having little
things like semicolons help alleviate those issues without complicating the
compiler, or making the developer's job more cumbersome.

In practice, I'd imagine that these kinds of things would happen infrequently,
but then again that's also the reigning theory about deliberately writing buggy
code. ;)

- Pragma



 May 07 2008



  parent  terranium <spam here.lot>  writes:


Pragma Wrote:


 // call both functions without a terminating ';' 
 foo bar
 
 The parser would likely interpret this as a variable declaration for "bar of
type foo".


:) you can't declare a variable of certain type in ecmascript.



 May 08 2008



prev sibling next sibling parent reply terranium <spam here.lot>  writes:


Nick Sabalausky Wrote:


 Python's semantically-meaningful indentation was intended to fix the problem 
 of poorly-indented code by enforcing proper indentation in the language and 
 compiler. But the problem is, it *doesn't* actually enforce it.


:-/ It's a hard task to keep code poorly formatted in MS Visual Studio, since a
code formatter is built into editor.



 May 07 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"terranium" <spam here.lot> wrote in message 
news:fvsdet$231s$1 digitalmars.com...

 Nick Sabalausky Wrote:


 Python's semantically-meaningful indentation was intended to fix the 
 problem
 of poorly-indented code by enforcing proper indentation in the language 
 and
 compiler. But the problem is, it *doesn't* actually enforce it.


 :-/ It's a hard task to keep code poorly formatted in MS Visual Studio, 
 since a code formatter is built into editor.


Exactly. That's the second reason I disagree with Python's rationale for 
their indentation mechanism: Automatic code formatters already solve the 
issue without introducing hidden bugs. And, they're relatively easy to 
implement anyway, or at least compared to a full-blown compiler (especially 
if you write it in D ;-) ). 



 May 07 2008



  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Nick Sabalausky wrote:

 "terranium" <spam here.lot> wrote in message 
 news:fvsdet$231s$1 digitalmars.com...

 Nick Sabalausky Wrote:


 Python's semantically-meaningful indentation was intended to fix the 
 problem
 of poorly-indented code by enforcing proper indentation in the language 
 and
 compiler. But the problem is, it *doesn't* actually enforce it.


 :-/ It's a hard task to keep code poorly formatted in MS Visual Studio, 
 since a code formatter is built into editor.


 
 Exactly. That's the second reason I disagree with Python's rationale for 
 their indentation mechanism: Automatic code formatters already solve the 
 issue without introducing hidden bugs. And, they're relatively easy to 
 implement anyway, or at least compared to a full-blown compiler (especially 
 if you write it in D ;-) ). 


There is a D code formatter... it's written in Java, though. It has ~300 
options last time I touched it, but I think it'll get a couple more when 
I get around to updating it for D2.



 May 07 2008



  parent  Ary Borenszweig <ary esperanto.org.ar>  writes:


Robert Fraser escribió:

 Nick Sabalausky wrote:

 "terranium" <spam here.lot> wrote in message 
 news:fvsdet$231s$1 digitalmars.com...

 Nick Sabalausky Wrote:


 Python's semantically-meaningful indentation was intended to fix the 
 problem
 of poorly-indented code by enforcing proper indentation in the 
 language and
 compiler. But the problem is, it *doesn't* actually enforce it.


 :-/ It's a hard task to keep code poorly formatted in MS Visual 
 Studio, since a code formatter is built into editor.


 Exactly. That's the second reason I disagree with Python's rationale 
 for their indentation mechanism: Automatic code formatters already 
 solve the issue without introducing hidden bugs. And, they're 
 relatively easy to implement anyway, or at least compared to a 
 full-blown compiler (especially if you write it in D ;-) ). 


 
 There is a D code formatter... it's written in Java, though. It has ~300 
 options last time I touched it, but I think it'll get a couple more when 
 I get around to updating it for D2.


My intentions are to update to 1.029, then support latest 2.x, then 
optimize while retaining correct semantic funcionality. :-)



 May 07 2008



prev sibling next sibling parent  terranium <spam here.lot>  writes:


Walter Bright Wrote:


 Having the ; end statements provides a nice "anchor" point for the 
 parser.


It should be noted that programmer also has a parser.



 May 07 2008



prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Walter Bright:

 Those things are fine for scripting language programs that are fairly 
 short (like under a screenful). It gets increasingly bad as the size of 
 the program increases.


You may look at Zope (written in Python), that codebase is a bit more than a
screenful long; so evidence shows you may be wrong.

You may also take a look at Scala code, that is a java-like language (plus
functional ideas) with optional semicolons. It seems a good enough language to
use.
Note that the "auto" of D too removes redundancy, and once it has caused me a
little bug, quickly fixed, I think "auto" is very useful still.


 How should:
    f()
     *g()
 parse?


Like this:
f();
*g();

That's a call to f() followed by what it seems an error.

Bye,
bearophile



 May 07 2008



 next sibling parent  Robert Fraser <fraserofthenight gmail.com>  writes:


bearophile wrote:

 Like this:
 f();
 *g();
 
 That's a call to f() followed by what it seems an error.
 
 Bye,
 bearophile


An expression statement is not an error. If g() returns a struct with an 
opStar() that has side effects, that's a perfectly valid construction, 
and an excellent idea for the next D obfuscated code contest you're in.



 May 07 2008



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:fvt3r2$2qfj$1 digitalmars.com...

 Walter Bright:

 Those things are fine for scripting language programs that are fairly
 short (like under a screenful). It gets increasingly bad as the size of
 the program increases.


 You may look at Zope (written in Python), that codebase is a bit more than 
 a screenful long; so evidence shows you may be wrong.


Just because a large program *has* been written in such a language doesn't 
mean it's a good idea in general. I could write a large mission-critical 
program in Perl or a graphics library in brainfuck if I really wanted to, 
just like a builder could put up a house by using a big rock instead of a 
hammer. Still doesn't mean it's the right tool for the job.


 Note that the "auto" of D too removes redundancy, and once it has caused 
 me a little bug, quickly fixed, I think "auto" is very useful still.


I'd argue that the metric of "with/without redundancy" is a little bit 
misleading, simply because we can all come up with obscure counter-examples 
(ex: A language that requires you write an exact duplicate of every source 
file, just like when creating a password. Wheee!). The way I see it, the 
real issue is whether the alleged productivity enhancement helps the 
programmer make mistakes, or helps the programmer catch/avoid mistakes. 
Typically that takes the form of some sort of redundancy, but the key is 
"Mistakes: Nurtured Or Inhibited?". That's just the way I see it, anyway.


 How should:
    f()
     *g()
 parse?


 Like this:
 f();
 *g();

 That's a call to f() followed by what it seems an error.


Depends on the specific manner in which semicolons are made optional. If 
they're just flatout made optional by having "end-of-statement" somehow be 
inferred by statement semantics, then the code is totally ambiguous (But I'm 
not sure anyone was really advocating this method anyway, were they?) If, 
however, newline either becomes the new "end-of-statement" or shares the 
"end-of-statement" role with semicolon, then yea, it gets interpreted as two 
unrelated function calls, the second of which is attached to a unary prefix 
"*" operator. In the case of newline being a/the "end-of-statement", then 
multi-line statements would be either impossible, or require a "C 
Macros"/"Visual Basic"-style symbol for "continue statement on next line" 
(which is perfectly doable, but not something I'm personally a big fan of 
for reasons I mentioned in an earlier post in this thread.)

Maybe I just stated the obvious there, I dunno. But I thought it should said 
that there are those different possible meanings for "optional semicolons", 
each with their own implications. 



 May 07 2008



  parent reply Robert Fraser <fraserofthenight gmail.com>  writes:


Nick Sabalausky wrote:

 Just because a large program *has* been written in such a language doesn't 
 mean it's a good idea in general. I could write a large mission-critical 
 program in Perl 


I know of at least one large (non-web) system written in Perl that was 
servicing over 2 million users before being switched. Perl with "use 
strict" and some good coding standards can be just as clean as any other 
language. It's gotten a bad reputation because of its shell scripting 
roots and use by web designers with limited programming experience.

IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I 
was writing PHP for a resarch project, I found myself literally spending 
hours tracing down bugs caused by typos in variable names, but a simple 
"use strict;" in Perl fixes that completely.



 May 07 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fvu5k1$2gct$1 digitalmars.com...

 Nick Sabalausky wrote:

 Just because a large program *has* been written in such a language 
 doesn't mean it's a good idea in general. I could write a large 
 mission-critical program in Perl


 I know of at least one large (non-web) system written in Perl that was 
 servicing over 2 million users before being switched. Perl with "use 
 strict" and some good coding standards can be just as clean as any other 
 language. It's gotten a bad reputation because of its shell scripting 
 roots and use by web designers with limited programming experience.

 IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I 
 was writing PHP for a resarch project, I found myself literally spending 
 hours tracing down bugs caused by typos in variable names, but a simple 
 "use strict;" in Perl fixes that completely.


Well, it was just an example. Perhaps a poorly chosen one. I'm really not as 
familiar with Perl as I am with others like PHP, VB*, Python, etc. Feel free 
to take "Perl" and insert "{name of some shitty language here}".

(Since you bring it up: as much as VBScript annoys the crap out of me, I 
find that I still prefer it to PHP for the sole reason that VBScript has 
"option explicit", fixing all those stupid hard-to-track-down typos. Not 
that PHP doesn't have it's advantages over VBScript in other areas, though. 
If they'd add a "use strict", I'd be flying a giant "PHP > VBScript" banner. 
At least for pre-.NET ASP anyway. Not sure how relevant that is now though. 
As for ASP.NET, well, I've been successfully avoiding web dev for awhile so, 
don't know, don't care ;) ) 



 May 08 2008



  parent  Robert Fraser <fraserofthenight gmail.com>  writes:


Nick Sabalausky wrote:

 IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I 
 was writing PHP for a resarch project, I found myself literally spending 
 hours tracing down bugs caused by typos in variable names, but a simple 
 "use strict;" in Perl fixes that completely.


 
 Well, it was just an example. Perhaps a poorly chosen one. I'm really not as 
 familiar with Perl as I am with others like PHP, VB*, Python, etc. Feel free 
 to take "Perl" and insert "{name of some shitty language here}".


Sorry; I know that wasn't the point of your post. Perl is just unjustly 
maligned because it _can_ be confusing and is often used badly. But the 
language is actually quite well-designed.



 May 09 2008



prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Janice Caron Wrote:

 Besides which, how would that work with statements like
     if (a == b) { ++i; ++j } else { --i; --j }
 If newlines were to take over the role of semicolons, then that would turn into
     if (a == b) { ++i
     ++j } else { --i
     --j }


You may want to take a look at Scala.
Your statement can be written like this, that is readable but needs many lines:

if (a == b) {
    ++i
    ++j
} else {
    --i
    --j
}

Or like this:

if (a == b) { ++i; ++j; } else { --i; --j; }

(Plus various other ways you can use today).
Both versions are okay, because ; becomes optional when it's at the end of the
line. And the symbols for line continuations are part of this proposal, I
presume.

If you want to remove the brackets too, you may end with:

if a == b:
    ++i
    ++j
else:
    --i
    --j

Bye,
bearophile



 May 08 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


IMO, this whole thread is ridiculous since you're arguing about
something that amounts to just personal style. D was created by Walter
to be part of the C family of languages therefore D should continue to
use the style Walter chose.
Personally I prefer to use ; in my code but I won't join the argument
since it's just a matter of style and personal taste.

for all the python fans here - my suggestion would be to add a switch to
the compiler to parse D files written with a Python style. D would
officially use the current style but if someone wants he could use a
python style in his own code via the proposed switch. Official code
(standard library, code on digital mars, etc) will remain in the current
style.
This extension is very low priority IMHO.

--Yigal



 May 08 2008



 next sibling parent reply "Janice Caron" <caron800 googlemail.com>  writes:


On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument


You just did. :-) The only way not to join the argument is not to post
your opinion, but alas you gave in to the temptation. :-)

You did hold out for a long time though.



 May 08 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


Janice Caron wrote:

 On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument


 
 You just did. :-) The only way not to join the argument is not to post
 your opinion, but alas you gave in to the temptation. :-)
 
 You did hold out for a long time though.


All I stated is my preferred style without getting into the whole
argument which style is technically better. So you see, technically I
_didn't_ post my opinion so I didn't join the argument after all.

My firm belief on the subject is that you should always choose the best
tool for the job and that there are no absolutes. People who go for such
absolutes confirm the phrase: "When all you got is a hammer, everything
becomes a nail", which is to say that I don't think any one style is
absolutely always better than all the other alternatives.
Another factor to this debate is this -
http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis

--Yigal



 May 08 2008



  parent  "Bruce Adams" <tortoise_74 yeah.who.co.uk>  writes:


On Thu, 08 May 2008 21:06:30 +0100, Yigal Chripun <yigal100 gmail.com>  
wrote:


 Janice Caron wrote:

 On 08/05/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  but I won't join the argument


 You just did. :-) The only way not to join the argument is not to post
 your opinion, but alas you gave in to the temptation. :-)

 You did hold out for a long time though.


 All I stated is my preferred style without getting into the whole
 argument which style is technically better. So you see, technically I
 _didn't_ post my opinion so I didn't join the argument after all.

 My firm belief on the subject is that you should always choose the best
 tool for the job and that there are no absolutes. People who go for such
 absolutes confirm the phrase: "When all you got is a hammer, everything
 becomes a nail", which is to say that I don't think any one style is
 absolutely always better than all the other alternatives.
 Another factor to this debate is this -
 http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis

 --Yigal


Maybe you just joined a different argument?
Anyway, times up! That will be five pounds please.



 May 09 2008



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:fvvk5j$k56$1 digitalmars.com...

 IMO, this whole thread is ridiculous since you're arguing about
 something that amounts to just personal style.


I think it's been a very interesting discussion.

Yes, there is a lot that comes down to preference in the end, and yes, we 
have come up with some such things in this thread. But we can't just go 
around assuming that all opposing viewpoints are always equally valid, 
because a lot of times they just simply aren't.  Sometimes a clear "best 
practice" does emerge. Not by unanimous vote though, but by merit of the 
argument itself. For instance, everyone could agree 2+2=5, but that doesn't 
make it so, and by the same token, one rouge diehard "2+2=5" person doesn't 
turn "2+2=4" from a fact into an opinion or a preference.

And on the things that do turn out to be matters of preference, it's still 
interesting (my opinion) and potentially helpful/productive (which I submit 
as fact, but open for debate, of course) to see the pros and cons of each 
actually laid out for all to see. 



 May 08 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


Nick Sabalausky wrote:

 I think it's been a very interesting discussion.
 
 Yes, there is a lot that comes down to preference in the end, and yes, we 
 have come up with some such things in this thread. But we can't just go 
 around assuming that all opposing viewpoints are always equally valid, 
 because a lot of times they just simply aren't.  Sometimes a clear "best 
 practice" does emerge. Not by unanimous vote though, but by merit of the 
 argument itself. For instance, everyone could agree 2+2=5, but that doesn't 
 make it so, and by the same token, one rouge diehard "2+2=5" person doesn't 
 turn "2+2=4" from a fact into an opinion or a preference.
 
 And on the things that do turn out to be matters of preference, it's still 
 interesting (my opinion) and potentially helpful/productive (which I submit 
 as fact, but open for debate, of course) to see the pros and cons of each 
 actually laid out for all to see. 
 


Where in my post did you read that I said "[we should] go around
assuming that all opposing viewpoints are always equally valid"? I know
what I wrote and that ain't it.

I said that this specific argument which I'm replying to is about
personal preferences/style only and is not a technical discussion
related to D and have stated my opinion that arguing about
_this_specific_subject_ is ridiculous. In the same way you could argue
that you prefer you code to be shown with red color and someone else
would argue that green is better. Colors do have pros and cons regarding
eye-sight but they don't make your red if statement any better than
Janice's green one from a code POV. Both will compile to the same
assembly code. therefore, unless you discuss the pros and cons of colors
to a programmer's sight, arguing whether red code is better than green
code is indeed ridiculous.

If you decide to discuss next which editor is better: vi[m] or emacs
(since as you say, this is "potentially helpful/productive" in your
opinion) than count me out since yet again this comes down to personal
preference.

--Yigal

PS: it's amazing how such smart people can waste so much time and energy
debating such unimportant issues as the semicolon at the end of
statements with such a passion.



 May 08 2008



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.


Where in my post did you read that I said "You said that we should go around 
assuming that all opposing viewpoints are always equally valid"? ;)

But you did say "this whole thread is ridiculous", even though we discussed 
other issues besides "semicolon-oriented language" vs. "newline-oriented 
language". If you really meant just the particular branch of the thread you 
replied to and not actually the whole thread, then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.


Sure. After all, nobody would say that you were obligated to participate. 
Feel free to pick and choose which discussions you wish to participate in. I 
do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.


One could make the same claim about meta-debates, such as this. (I'm not 
actually making that claim though. I don't personally mind the occasional 
meta-debate.)

Besides, I think it's good to periodically challenge, and be challenged by, 
each others viewpoints. This way we don't stagnate, isolated in the world of 
our own preferences, possibly even blind to the occasional mistaken 
assumption. For all I know, someone might say something that makes me think 
of Python in a new way and I decide "Wow, this is my new preference. I like 
Python better than D. If I had just agreed to disagree then my eyes never 
would have been opened to this."

As real-world examples, when I first started reading about Python, I had a 
knee-jerk reaction and decided "this is garbage, I'm not going near it", and 
that was that. But a couple weeks ago I was talking to a friend who liked 
Python, we disagreed, but still discussed, and I realized that Python did 
have some good functional-ish features - things that even my favorite 
language, D, could use to borrow. And I also came to the conclusion that it 
really wouldn't kill me, at the very least, to write a quck little 
prototype, script, etc., in Python every now and then. All this even though 
I still consider, for example, the rationale behind Python's indentation to 
be logically flawed and inappropriate for large projects. In much the same 
way, my friend ended up getting interested in D (To paraphrase: "Wow, a 
static typed, non-VM language without the muss and fuss of C/C++, who 
knew?").

If we had just decided "these are matters of preference, discussing it is 
ridiculous", and avoided what seemed like a pointless discussion, then where 
would we both be right now? Sitting in our own happy ignorance.



 May 08 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.


 Where in my post did you read that I said "You said that we should go 
 around assuming that all opposing viewpoints are always equally valid"? ;)

 But you did say "this whole thread is ridiculous", even though we 
 discussed other issues besides "semicolon-oriented language" vs. 
 "newline-oriented language". If you really meant just the particular 
 branch of the thread you replied to and not actually the whole thread, 
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.


 Sure. After all, nobody would say that you were obligated to participate. 
 Feel free to pick and choose which discussions you wish to participate in. 
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.


 One could make the same claim about meta-debates, such as this. (I'm not 
 actually making that claim though. I don't personally mind the occasional 
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged 
 by, each others viewpoints. This way we don't stagnate, isolated in the 
 world of our own preferences, possibly even blind to the occasional 
 mistaken assumption. For all I know, someone might say something that 
 makes me think of Python in a new way and I decide "Wow, this is my new 
 preference. I like Python better than D. If I had just agreed to disagree 
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had a 
 knee-jerk reaction and decided "this is garbage, I'm not going near it", 
 and that was that. But a couple weeks ago I was talking to a friend who 
 liked Python, we disagreed, but still discussed, and I realized that 
 Python did have some good functional-ish features - things that even my 
 favorite language, D, could use to borrow. And I also came to the 
 conclusion that it really wouldn't kill me, at the very least, to write a 
 quck little prototype, script, etc., in Python every now and then. All 
 this even though I still consider, for example, the rationale behind 
 Python's indentation to be logically flawed and inappropriate for large 
 projects. In much the same way, my friend ended up getting interested in D 
 (To paraphrase: "Wow, a static typed, non-VM language without the muss and 
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it is 
 ridiculous", and avoided what seemed like a pointless discussion, then 
 where would we both be right now? Sitting in our own happy ignorance.


I just re-read what I wrote here and realized it came across a little bit 
hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s as 
you read it. ;) 



 May 08 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message 
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.


 Where in my post did you read that I said "You said that we should go 
 around assuming that all opposing viewpoints are always equally valid"? ;)

 But you did say "this whole thread is ridiculous", even though we 
 discussed other issues besides "semicolon-oriented language" vs. 
 "newline-oriented language". If you really meant just the particular 
 branch of the thread you replied to and not actually the whole thread, 
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.


 Sure. After all, nobody would say that you were obligated to participate. 
 Feel free to pick and choose which discussions you wish to participate in. 
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.


 One could make the same claim about meta-debates, such as this. (I'm not 
 actually making that claim though. I don't personally mind the occasional 
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged 
 by, each others viewpoints. This way we don't stagnate, isolated in the 
 world of our own preferences, possibly even blind to the occasional 
 mistaken assumption. For all I know, someone might say something that 
 makes me think of Python in a new way and I decide "Wow, this is my new 
 preference. I like Python better than D. If I had just agreed to disagree 
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had a 
 knee-jerk reaction and decided "this is garbage, I'm not going near it", 
 and that was that. But a couple weeks ago I was talking to a friend who 
 liked Python, we disagreed, but still discussed, and I realized that 
 Python did have some good functional-ish features - things that even my 
 favorite language, D, could use to borrow. And I also came to the 
 conclusion that it really wouldn't kill me, at the very least, to write a 
 quck little prototype, script, etc., in Python every now and then. All 
 this even though I still consider, for example, the rationale behind 
 Python's indentation to be logically flawed and inappropriate for large 
 projects. In much the same way, my friend ended up getting interested in D 
 (To paraphrase: "Wow, a static typed, non-VM language without the muss and 
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it is 
 ridiculous", and avoided what seemed like a pointless discussion, then 
 where would we both be right now? Sitting in our own happy ignorance.


 
 I just re-read what I wrote here and realized it came across a little bit 
 hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s as 
 you read it. ;) 
 
 


I'm glad that you realize that I was talking about "semicolon-oriented
language" vs. "newline-oriented language". I never said we shouldn't
discuss python vs. D which (again) was not discussed in this thread.
this very long discussion was about the semicolon and you already know
what I think of such discussions.

Your post actually proves my original post. If you read it again you
would realize that I said that I prefer to use the right tool for the
job, be it D, python or even VB (ok, I would probably would never use VB
if I can help it ;) ). Also, there's was link to a wiki page about the
Sapir hypothesis in there. Sapir is a linguist and he noticed that the
language used by a people affects their way of thinking. Applying this
to our discussion means that a C/C++ programmer "thinks" in a C/C++ way
and it would be harder for him to understand python vs D. Hence your
knee jerk reaction to Python as you stated above. so you see, you've
just proved my point.

--Yigal



 May 09 2008



  parent  "Nick Sabalausky" <a a.a>  writes:


"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:g0156n$lj6$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:g003u3$1g02$1 digitalmars.com...

 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:fvvtu6$16tq$1 digitalmars.com...

 Where in my post did you read that I said "[we should] go around
 assuming that all opposing viewpoints are always equally valid"? I know
 what I wrote and that ain't it.


 Where in my post did you read that I said "You said that we should go
 around assuming that all opposing viewpoints are always equally valid"? 
 ;)

 But you did say "this whole thread is ridiculous", even though we
 discussed other issues besides "semicolon-oriented language" vs.
 "newline-oriented language". If you really meant just the particular
 branch of the thread you replied to and not actually the whole thread,
 then ok, fair enough.


 If you decide to discuss next which editor is better: vi[m] or emacs
 (since as you say, this is "potentially helpful/productive" in your
 opinion) than count me out since yet again this comes down to personal
 preference.


 Sure. After all, nobody would say that you were obligated to 
 participate.
 Feel free to pick and choose which discussions you wish to participate 
 in.
 I do that, just as I image most of the others here do.


 PS: it's amazing how such smart people can waste so much time and 
 energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.


 One could make the same claim about meta-debates, such as this. (I'm not
 actually making that claim though. I don't personally mind the 
 occasional
 meta-debate.)

 Besides, I think it's good to periodically challenge, and be challenged
 by, each others viewpoints. This way we don't stagnate, isolated in the
 world of our own preferences, possibly even blind to the occasional
 mistaken assumption. For all I know, someone might say something that
 makes me think of Python in a new way and I decide "Wow, this is my new
 preference. I like Python better than D. If I had just agreed to 
 disagree
 then my eyes never would have been opened to this."

 As real-world examples, when I first started reading about Python, I had 
 a
 knee-jerk reaction and decided "this is garbage, I'm not going near it",
 and that was that. But a couple weeks ago I was talking to a friend who
 liked Python, we disagreed, but still discussed, and I realized that
 Python did have some good functional-ish features - things that even my
 favorite language, D, could use to borrow. And I also came to the
 conclusion that it really wouldn't kill me, at the very least, to write 
 a
 quck little prototype, script, etc., in Python every now and then. All
 this even though I still consider, for example, the rationale behind
 Python's indentation to be logically flawed and inappropriate for large
 projects. In much the same way, my friend ended up getting interested in 
 D
 (To paraphrase: "Wow, a static typed, non-VM language without the muss 
 and
 fuss of C/C++, who knew?").

 If we had just decided "these are matters of preference, discussing it 
 is
 ridiculous", and avoided what seemed like a pointless discussion, then
 where would we both be right now? Sitting in our own happy ignorance.


 I just re-read what I wrote here and realized it came across a little bit
 hippy-ish. Anybody: feel free to sprinkle in a few "fuck"s or "damnit"s 
 as
 you read it. ;)


 I'm glad that you realize that I was talking about "semicolon-oriented
 language" vs. "newline-oriented language". I never said we shouldn't
 discuss python vs. D which (again) was not discussed in this thread.
 this very long discussion was about the semicolon and you already know
 what I think of such discussions.

 Your post actually proves my original post. If you read it again you
 would realize that I said that I prefer to use the right tool for the
 job, be it D, python or even VB (ok, I would probably would never use VB
 if I can help it ;) ).


Agreed on VB ;)

Not everyone always agrees what the right tool for a given job is. But the 
problem is: even when preference plays a large part, it isn't always due 
100% to preference. For instance, sometimes a mistaken assumption may have 
slipped in, or an oversight. We don't know if it really is purely 
preference, or if faulty reasoning has managed to slip in until 
it's...discussed.


 Also, there's was link to a wiki page about the
 Sapir hypothesis in there. Sapir is a linguist and he noticed that the
 language used by a people affects their way of thinking. Applying this
 to our discussion means that a C/C++ programmer "thinks" in a C/C++ way
 and it would be harder for him to understand python vs D. Hence your
 knee jerk reaction to Python as you stated above.


A knee-jerk reaction which I then (at least partially) overcame 
through...discussion. The Sapir hypothesis doesn't mean that we should just 
stick to our native language and avoid comparing/contrasting languages. But 
what it does mean that we're naturally blind to the pros/cons of that which 
we are unfamiliar with. Avoiding discussion allows this natural ignorance to 
persist, while participating in discussion helps to dispell it.



 May 09 2008



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


Yigal Chripun wrote:

 PS: it's amazing how such smart people can waste so much time and energy
 debating such unimportant issues as the semicolon at the end of
 statements with such a passion.


Also known as the bikeshed problem 
(http://en.wikipedia.org/wiki/Color_of_the_bikeshed)
:)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



 May 13 2008



  parent reply BCS <ao pathlink.com>  writes:


Reply to Bruno,


 Yigal Chripun wrote:
 

 PS: it's amazing how such smart people can waste so much time and
 energy debating such unimportant issues as the semicolon at the end
 of statements with such a passion.
 


 Also known as the bikeshed problem
 (http://en.wikipedia.org/wiki/Color_of_the_bikeshed) :)
 


The only usable solution is the define the language is such a way that there 
is exactly one correct way to format code. That way must be so bad that
absolutely 
no one will even try to edit it without a pretty printer (and an ugly printer 
to go back the other way) That way everyone is unhappy with the actual files 
but no one cares because then never see it.



 May 13 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


BCS wrote:

 Reply to Bruno,
 

 Yigal Chripun wrote:


 PS: it's amazing how such smart people can waste so much time and
 energy debating such unimportant issues as the semicolon at the end
 of statements with such a passion.


 Also known as the bikeshed problem
 (http://en.wikipedia.org/wiki/Color_of_the_bikeshed) :)


 
 The only usable solution is the define the language is such a way that
 there is exactly one correct way to format code. That way must be so bad
 that absolutely no one will even try to edit it without a pretty printer
 (and an ugly printer to go back the other way) That way everyone is
 unhappy with the actual files but no one cares because then never see it.
 


personally I don't understand why we still use text files to represent
code. that's just so silly. data in a computer is stored in binary form
not text, so you don't get to see your "real" code anyway, but rather a
specific interpretation of it. and this encoding is very old and very
simplistic. this is identical to word for example only difference is the
format used by word is a different binary encoding.

there is a programming language where you use pixels and colors to
program and you can actually create pretty code. imagine your source
code looks like a butterfly, for example. there are some mostly academic
languages that use math extensivly and thus rely on latex for syntax.
I'm sure that there are endless possibilities of richer representations
of code than just text.

in star-trek when they need to "program" the holo-deck or the machine
that creates food (darn, I forgot the name of it) they simply explain to
the computer what they actually want. no need for a formal language at
all. there's an episode in star-trek TNG where they unfreeze someone in
a space shuttle which was frozen since the 20th century. since in the
Utopian earth in the future they don't have alcohol nor anything
unhealthy like coca-cola, he tries to program that machine to create
coke, and it takes a while since he didn't know how to explain what a
coke is. (he had much better luck with whiskey, though ;) )

and with all those endless possibilities, we still spend time arguing
the semi-colon?! doesn't it look silly, in comparison?

D is already years ahead of many other languages, simple by using
Unicode instead of ASCII. wouldn't it be cool to have a voice
recognition compiler for D too? ;)



 May 13 2008



 next sibling parent reply BCS <ao pathlink.com>  writes:


Reply to Yigal,


 personally I don't understand why we still use text files to represent
 code.
 


I's to long a story to post here, but my day job is working on a new
programming 
language. For several years it was a non text based language. Suffice to 
say, it just couldn't be made to work.



 May 13 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


BCS wrote:

 Reply to Yigal,
 

 personally I don't understand why we still use text files to represent
 code.


 
 I's to long a story to post here, but my day job is working on a new
 programming language. For several years it was a non text based
 language. Suffice to say, it just couldn't be made to work.
 
 


I'll be glad to here that sometime when there's time, if you care to
tell it.
anyway, that doesn't mean anything. this just shows that your particular
 language couldn't be made to work by your company. that's not a proof
in any way.
the little theorem of Fermat was calculated by super computers for a
huge set of numbers, but until it was formally proved it wasn't formally
true. the story of the light bulb shows also how despite hundreds of
failures Edison continued his work until he did manage to create a
light-bulb.
on the other hand, as I said in the original post, there are already
available programming languages that are not text based. even those math
(latex) languages are included in this. You can even include UML in this
if you use a weaker definition, since there are (many) tools that
generate code from UML diagrams.
GUI is a prime candidate for a visual language. most people already use
tools like eclipse's visual editor to draw the GUI and have the IDE
generate the code for them. I don't think there are any Java programmers
left (outside the educational system) that actually hand code their GUI
code. Eclipse does a better job of it and the development is faster.
this is just evolution taking it's course.
once upon a time humans used assembly. I think the last assembly
language designed to be used by humans was that of the PDF-11. today the
compiler generates it for you. you still can use assembly directly of
course, but the current design is driven by the needs of compiler
writers and the assembly language is no longer built to accommodate mere
humans.

http://en.wikipedia.org/wiki/Visual_programming_language



 May 13 2008



  parent  BCS <ao pathlink.com>  writes:


Reply to Yigal,


 I'll be glad to here that sometime when there's time, if you care to
 tell it.


I'll show up here sooner or later (don't expect sooner)


 anyway, that doesn't mean anything. this just shows that your
 particular
 language couldn't be made to work by your company. that's not a proof
 in any way.


The issue didn't forbid general purpose non-text languages, but they don't 
make me thinking it's going to happen any time soon. To put it concisely, 
visual systems are fine for a well defined, static domains, but are to rigid 
for anything else.



 May 13 2008



prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com>  writes:


Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.


I've used Lingo, a proprietary programming language that uses a binary 
format for code. Of course, the code is largely textual, so it's the 
worst of both worlds.

The largest issue is finding an efficient means of recording intent that 
is Turing-complete (and can easily be translated to machine code). Text 
fulfills that wonderfully. Human languages do not, for a variety of 
reasons. You could come up with a pixelmap solution that is reasonable, 
but it would be compilable to text without significant difficulty, and 
text is probably easier to read and write.

The second largest issue is editors. Once you have your visual 
programming language, everyone needs an editor that can display it in 
order to program for it, which is a considerable barrier to entry. I 
tried learning Lingo recently, and though most of the code involved is 
text, it's in a binary format along with images and other data, so you 
can't hope to learn it without shelling out $800 for Adobe Director. 
Even if the editor were free, even if it were available for all 
platforms, it would still require everyone to use that editor, no matter 
its quality. And there are wars over editors, so this is no trivial matter.



 May 13 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


Christopher Wright wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.


 
 I've used Lingo, a proprietary programming language that uses a binary
 format for code. Of course, the code is largely textual, so it's the
 worst of both worlds.
 
 The largest issue is finding an efficient means of recording intent that
 is Turing-complete (and can easily be translated to machine code). Text
 fulfills that wonderfully. Human languages do not, for a variety of
 reasons. You could come up with a pixelmap solution that is reasonable,
 but it would be compilable to text without significant difficulty, and
 text is probably easier to read and write.
 
 The second largest issue is editors. Once you have your visual
 programming language, everyone needs an editor that can display it in
 order to program for it, which is a considerable barrier to entry. I
 tried learning Lingo recently, and though most of the code involved is
 text, it's in a binary format along with images and other data, so you
 can't hope to learn it without shelling out $800 for Adobe Director.
 Even if the editor were free, even if it were available for all
 platforms, it would still require everyone to use that editor, no matter
 its quality. And there are wars over editors, so this is no trivial matter.


while that's true, it doesn't really prevent us from having a language
that has a more rich representation. also note, I didn't say we should
ban the use of text, merely that we shouldn't be limited by text.
text is a binary format too as I said earlier, the only difference is
that you already have many free editors for it. that's a bit of an egg
and a chicken problem. but that shouldn't force us to limit ourselves to
only text. look at Java for instance, it already is used almost
exclusively with IDEs, you can use a text editor with Java of course,
but in practice, nobody does that. the next step would be to write a
language with a rich representation and provide an eclipse plugin for it.

the point of this is not to find something easier for the computer to
understand, but to find something more easy for humans to use. finding a
way to generate code from human languages is probably hard, I agree. the
benefit would be that you will not need to be a programmer to create a
program. you could just describe your problem to the PC and it'll
understand it and generate a solution. (maybe this needs AI for that.)

another line of thinking is this: why do we need a general purpose
Turing-complete language anyway? programmers deal with abstractions,
right? we are constantly trying to raise the level of those abstractions
to make them closer to the domain of the problem. otherwise we would
still be using assembly since all the Turing complete languages have
equal power. so everything you can do with D (for instance) is possible
to do in assembly as well (it'll be harder to program, though).

what's the next level of abstraction, than? let's define a DSL (domain
specific language) that describes our problem domain and use that
language to solve the problem. SQL for example is very good at DBs and
it isn't even Turing complete. so instead of using one general purpose
language (which internally has to have design trade-offs) you can choose
the language for the job or create a new one. (there's an interesting
article about this idea by the jetbrains developers with their MPL
system, you can google it up - highly recommended to read)

by doing this we have just added another level of abstraction. now your
code is written in a a set of specific DSLs suitable for your problem.
those are translated to a general purpose language like D or Java, which
then is compiled and linked to a binary.
this way you can use graphics to design the GUI, SQL for DB access, and
other languages for other stuff.



 May 13 2008



  parent reply Christopher Wright <dhasenan gmail.com>  writes:


Yigal Chripun wrote:

 Christopher Wright wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.


 I've used Lingo, a proprietary programming language that uses a binary
 format for code. Of course, the code is largely textual, so it's the
 worst of both worlds.

 The largest issue is finding an efficient means of recording intent that
 is Turing-complete (and can easily be translated to machine code). Text
 fulfills that wonderfully. Human languages do not, for a variety of
 reasons. You could come up with a pixelmap solution that is reasonable,
 but it would be compilable to text without significant difficulty, and
 text is probably easier to read and write.

 The second largest issue is editors. Once you have your visual
 programming language, everyone needs an editor that can display it in
 order to program for it, which is a considerable barrier to entry. I
 tried learning Lingo recently, and though most of the code involved is
 text, it's in a binary format along with images and other data, so you
 can't hope to learn it without shelling out $800 for Adobe Director.
 Even if the editor were free, even if it were available for all
 platforms, it would still require everyone to use that editor, no matter
 its quality. And there are wars over editors, so this is no trivial matter.


 
 while that's true, it doesn't really prevent us from having a language
 that has a more rich representation. also note, I didn't say we should
 ban the use of text, merely that we shouldn't be limited by text.
 text is a binary format too as I said earlier, the only difference is
 that you already have many free editors for it. that's a bit of an egg
 and a chicken problem. but that shouldn't force us to limit ourselves to
 only text. look at Java for instance, it already is used almost
 exclusively with IDEs, you can use a text editor with Java of course,
 but in practice, nobody does that. the next step would be to write a
 language with a rich representation and provide an eclipse plugin for it.


I have regularly written Java with vim. It's only annoying because the 
Java stdlib is hueg, and every class has so many methods, and a lot of 
the identifier names are quite long. If you're primarily working with 
your own code and keep the identifiers and classes managably sized, and 
are working on a small project, it's quite reasonable.

But I'm just uncertain that there is a visual representation of computer 
programs that is useful aside from code. I mean, GUI designers work 
because they're concerned about layout and not function. But actual code?

Perhaps editing assembly would be easier if you could view your program 
as a set of still images or a video that's showing what is happening 
with which registers. But I'm sure that it would be slower than just 
using your text editor of choice.


 another line of thinking is this: why do we need a general purpose
 Turing-complete language anyway? programmers deal with abstractions,
 right? we are constantly trying to raise the level of those abstractions
 to make them closer to the domain of the problem. otherwise we would
 still be using assembly since all the Turing complete languages have
 equal power. so everything you can do with D (for instance) is possible
 to do in assembly as well (it'll be harder to program, though).
 
 what's the next level of abstraction, than? let's define a DSL (domain
 specific language) that describes our problem domain and use that
 language to solve the problem. SQL for example is very good at DBs and
 it isn't even Turing complete. so instead of using one general purpose
 language (which internally has to have design trade-offs) you can choose
 the language for the job or create a new one. (there's an interesting
 article about this idea by the jetbrains developers with their MPL
 system, you can google it up - highly recommended to read)


If I design a DSL, it's easier to start with an existing language. For 
instance, at work I use Castle Windsor for dependency injection, 
configured with Bindsor, a DSL based on Boo. Bindsor is pretty small, 
since it doesn't have to contain a lexer or a parser or do any code 
generation.

It would have been harder to make Bindsor without Boo, and it may well 
have been impossible to get any gains over the original XML 
configuration without making the language Turing-complete. (In fact, 
since looping and conditional execution are pretty much sufficient to 
make a language Turing-complete, Bindsor would be useless if it were not 
Turing-complete. And it's primarily a declarative language!)

At the very least, arbitrary DSLs branched off an existing language 
would be extremely difficult to create if the existing language were not 
Turing complete. At that point, why not make the DSLs into libraries and 
just use the original language for your application? Or why not add each 
of the compiler interceptors for these DSLs to the compiler so you can 
use each of the DSLs at once?



 May 14 2008



  parent  Yigal Chripun <yigal100 gmail.com>  writes:


Christopher Wright wrote:

 I have regularly written Java with vim. It's only annoying because the
 Java stdlib is huge, and every class has so many methods, and a lot of
 the identifier names are quite long. If you're primarily working with
 your own code and keep the identifiers and classes managably sized, and
 are working on a small project, it's quite reasonable.


of course you can use vim to program in Java, you also can use assembly
if you want, you can even use a hex editor and write the binary OP codes
directly. The question is, should you do this?
Java is indeed annoying when used in a text editor. In a way you can say
that Java is designed to be used with an IDE.  Java uses long
descriptive names for everything. this is a non issue since the IDE
auto-completes Identifiers. in fact the IDE *knows* Java and it can
write code and transform code for you. there are literally hundreds of
refactoring operations it can perform. in view of that, you can say that
Java is designed such that an IDE is considered integral part of the
language. Writing Java without an IDE is almost like programming D
without a compiler.
a similar example is smalltalk. when smalltalk was designed, its IDE was
designed with it. it's not an optional part but rather an important
integral part of the language implementation.

 
 But I'm just uncertain that there is a visual representation of computer
 programs that is useful aside from code. I mean, GUI designers work
 because they're concerned about layout and not function. But actual code?


I'm uncertain that only textual free context grammars can be used for
programming. we both do not the answer to this question yet, but it's
still fun exploring the possibilities.

 
 Perhaps editing assembly would be easier if you could view your program
 as a set of still images or a video that's showing what is happening
 with which registers. But I'm sure that it would be slower than just
 using your text editor of choice.
 
 
 If I design a DSL, it's easier to start with an existing language. For
 instance, at work I use Castle Windsor for dependency injection,
 configured with Bindsor, a DSL based on Boo. Bindsor is pretty small,
 since it doesn't have to contain a lexer or a parser or do any code
 generation.
 
 It would have been harder to make Bindsor without Boo, and it may well
 have been impossible to get any gains over the original XML
 configuration without making the language Turing-complete. (In fact,
 since looping and conditional execution are pretty much sufficient to
 make a language Turing-complete, Bindsor would be useless if it were not
 Turing-complete. And it's primarily a declarative language!)
 
 At the very least, arbitrary DSLs branched off an existing language
 would be extremely difficult to create if the existing language were not
 Turing complete. At that point, why not make the DSLs into libraries and
 just use the original language for your application? Or why not add each
 of the compiler interceptors for these DSLs to the compiler so you can
 use each of the DSLs at once?


there are two issues here.
a) Turing-completeness: if we are discussing DSLs than the best thing is
to look at the problem domain and try to create the most suitable
abstraction. sometimes that requires Turing completeness, and sometimes
it doesn't. SQL is an example where this is not required. I don't know
the statistics for this but I think that if you want to abstract as
close as possible to the problem domain the more specialized the DSL
will become and it'll be less likely you'll need Turing-completeness.
b) the point of the MPL and similar tools is to provide a way to easily
define a language, it's tools (IDE, compiler, etc..) and define a
translation to some general purpose language. the idea is to add to the
stack of abstractions another level. with this scheme you'll get:
My Specific Language -> general purpose language -> assembly -> binary.
it's the reverse of inner DSLs common to lisp. to answer your question
of: "why not make the DSLs into libraries and just use the original
language?"
let's compare the two by looking at Java's swing library:
swing is very complex and has a lot of code in it in order to provide
maximum flexibility. but it's just a library with API. a DSL based on
that API will add specific language support and an IDE that understands
swing. for example it can provide compile time checks and rules that a
regular Java cannot check/enforce.  for example swing might define rules
 about layout for accessibility [certain combinations of colors and
fonts are forbidden].
a DSL is like a library API with it's own compiler/IDE that know how to
highlight the syntax/check correctness/etc..
all of this can be implemented manually too of course, but the end user
which just wants to create a window and a bunch of buttons can be just a
graphic designer instead of a C++ expert when using a DSL.
also nothing should prevent you to from using any combination of DSLs to
create your product. most developers today already use some sort of a
DSL, this is just the next step in evolution. not only can you use a
visual designer for you GUI (just an example, of course) but you'll also
get an automatic check to make sure your widgets do not overlap,
colors/fonts are accessible, etc, etc.
the editor will also point to errors in the design, and suggest some
solutions to common issues.

I highly recommend to google for MPL and Language Oriented Programming
for better explanations.



 May 14 2008



prev sibling  parent reply "Joel C. Salomon" <joelcsalomon gmail.com>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.


 Bjarne Stroustrup had some hopes that the particular textual form of
C++ he’d developed could be replaced with other forms that were
conceptually identical but different syntactically. Turns out that isn’t
quite so doable. (Though when D exposes the syntax-tree form it’s a step
in that direction.)

—Joel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIKwaWzLx4GzBL9dYRAtz0AKCjA7WFMZRXjRRZ/Dt0QLLSu0Z/YQCfduXQ
mp5Tu7CtjLOOgRq+7H6DZNg=
=zqUy
-----END PGP SIGNATURE-----



 May 14 2008



  parent reply Yigal Chripun <yigal100 gmail.com>  writes:


Joel C. Salomon wrote:

 Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is the
 format used by word is a different binary encoding.


 
  Bjarne Stroustrup had some hopes that the particular textual form of
 C++ he’d developed could be replaced with other forms that were
 conceptually identical but different syntactically. Turns out that isn’t
 quite so doable. (Though when D exposes the syntax-tree form it’s a step
 in that direction.)
 
 —Joel


on the contrary, I've seen an article online of two people that did
exactly that. they defined an alternative syntax for C++ which is both
consistent and preserves the semantics of c++. it was their Thesis or
something like that. just stumbled on it via google.



 May 14 2008



  parent reply "Simen Kjaeraas" <simen.kjaras gmail.com>  writes:


On Thu, 15 May 2008 00:56:49 +0200, Yigal Chripun <yigal100 gmail.com>  
wrote:


 Joel C. Salomon wrote:
  > Yigal Chripun wrote:

 personally I don't understand why we still use text files to represent
 code. that's just so silly. data in a computer is stored in binary form
 not text, so you don't get to see your "real" code anyway, but rather a
 specific interpretation of it. and this encoding is very old and very
 simplistic. this is identical to word for example only difference is  
 the
 format used by word is a different binary encoding.


  Bjarne Stroustrup had some hopes that the particular textual form of
 C++ he’d developed could be replaced with other forms that were
 conceptually identical but different syntactically. Turns out that isn’t
 quite so doable. (Though when D exposes the syntax-tree form it’s a step
 in that direction.)

 —Joel


 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.


Link?



 May 15 2008



  parent reply "Joel C. Salomon" <joelcsalomon gmail.com>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simen Kjaeraas wrote:

 Yigal Chripun wrote:

 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.


 
 Link?


<http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C++_Syntax>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILD6UzLx4GzBL9dYRAjMrAJ9WiMCBA5qUswzHBhtypOwSjfdxrgCgzIbN
vln72iicI3pFCgpDIyD4th8=
=BGPP
-----END PGP SIGNATURE-----



 May 15 2008



  parent  Yigal Chripun <yigal100 gmail.com>  writes:


Joel C. Salomon wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Simen Kjaeraas wrote:

 Yigal Chripun wrote:

 on the contrary, I've seen an article online of two people that did
 exactly that. they defined an alternative syntax for C++ which is both
 consistent and preserves the semantics of c++. it was their Thesis or
 something like that. just stumbled on it via google.


 Link?


 
 <http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C++_Syntax>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.6 (GNU/Linux)
 
 iD8DBQFILD6UzLx4GzBL9dYRAjMrAJ9WiMCBA5qUswzHBhtypOwSjfdxrgCgzIbN
 vln72iicI3pFCgpDIyD4th8=
 =BGPP
 -----END PGP SIGNATURE-----


Yeah, this is exactly what I was talking about :)
thanks Joel. you saved me the need to go look it up myself.



 May 15 2008



prev sibling  parent reply terranium <spam here.lot>  writes:


Michael Neumann Wrote:


    if (a) {
      b;
    }
 
    if (a)
    {
      b;
    }


and this is called a coding style :)



 May 09 2008



  parent reply "Nick Sabalausky" <a a.a>  writes:


"terranium" <spam here.lot> wrote in message 
news:g01okr$1r0c$1 digitalmars.com...

 Michael Neumann Wrote:


    if (a) {
      b;
    }

    if (a)
    {
      b;
    }


 and this is called a coding style :)


My preferred coding style has been:


    if (a)
    {
      b;
    }




...just because the curley braces line up. But, lately, I've been tempted by 
the compactness of:


    if (a) {
      b;
    }




However, (after Michael Neumann convinced me in another post) I would much 
prefer to not have to even deal with that particular coding style issue in 
the first place (Ie, Don't make me make insignificant choices. It doesn't 
matter if you put the receipt in the bag, or hand it to me: don't make me 
choose.) This eliminates the entire reason to make a decision (and keeps 
everyone using one consistent style *without* forcing anyone to "do curley 
braces THIS way"):

if (a)
  b;
  c;
end

Plus, that then opens up the ability to do something like this:

while (a)
  if (b)
    c;
    d;
  fi // Or _if, or something else
wend // or _while, or something else (but please, not "end while"...way too 
long)

I used to dislike that, but the benefit is I no longer have giant unreadable 
chunks of:

      }
    }
  }
}
// Etc..

LISCB (lost in stupid curley braces), anyone? ;)

I once saw someone that had a style of commenting the ending braces with 
what the block was. I tried to adopt that, but found that I rarely ended up 
doing it unless the language forced me to.



 May 09 2008



  parent reply "Janice Caron" <caron800 googlemail.com>  writes:


On 09/05/2008, Nick Sabalausky <a a.a> wrote:

  Plus, that then opens up the ability to do something like this:

  while (a)
   if (b)
     c;
     d;
   fi // Or _if, or something else
  wend // or _while, or something else


But my text editor can do bracket matching. With one keystroke, I can
jump from an opening brace to the matching closing brace, or vice
versa, and /know/ that all is correctly matched (or easily fix the
problem if not).

My text editor, however, cannot do if-to-fi matching. Under your
scheme, I'd be giving up a valuable piece of functionality.



 May 09 2008



 next sibling parent  Matti Niemenmaa <see_signature for.real.address>  writes:


Janice Caron wrote:

 On 09/05/2008, Nick Sabalausky <a a.a> wrote:

  Plus, that then opens up the ability to do something like this:

  while (a)
   if (b)
     c;
     d;
   fi // Or _if, or something else
  wend // or _while, or something else


 
 But my text editor can do bracket matching. With one keystroke, I can
 jump from an opening brace to the matching closing brace, or vice
 versa, and /know/ that all is correctly matched (or easily fix the
 problem if not).
 
 My text editor, however, cannot do if-to-fi matching. Under your
 scheme, I'd be giving up a valuable piece of functionality.


That's a flaw in the text editor, not his scheme.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi



 May 09 2008



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.569.1210359943.2351.digitalmars-d puremagic.com...

 On 09/05/2008, Nick Sabalausky <a a.a> wrote:

  Plus, that then opens up the ability to do something like this:

  while (a)
   if (b)
     c;
     d;
   fi // Or _if, or something else
  wend // or _while, or something else


 But my text editor can do bracket matching. With one keystroke, I can
 jump from an opening brace to the matching closing brace, or vice
 versa, and /know/ that all is correctly matched (or easily fix the
 problem if not).


True, but under my proposal, you usually wouldn't need to do even that . You 
would just see them there (albiet, with less detail). Also, that only works 
for one block at a time.

Example scenario: Suppose I have a function that iterates over a collection, 
and does it over and over until some condition is met. Then, I want to add 
one last bit of processing to be done as the final action on each element of 
the collection. If the last few lines of my function look like this:

            _func // (ie, an anonymous closure)
          _if
        _foreach
      _if
    _while
  _if
_func

I know at a glance to put my code right before "_foreach". But if it looks 
like this:

            }
          }
        }
      }
    }
  }
}

Then I have to jump to find the right place. And depending on the function, 
I might have to try a few braces before I get the right one. Or, I could 
scroll to the start of the desired loop, and jump down from there. But 
still, why do that, when I could just know at a mere glance where to put the 
code?

You could argue that a scenario like that is the result of an overly-large 
function that should be broken into smaller parts, and you'd probably be 
right. But, at least in my experience, it's typical for a function to start 
small, then later on, grow large and *then* get broken up as necessary. Plus 
it might not even be your function anyway.

I'm not saying that this could effectively replace bracket matching in a 
text editor. But I do think "fi"/"wend" *plus* bracket matching would be 
better than "a bunch of }'s" plus bracket matching. I think they'd 
compliment each other nicely (And the "fi"/"wend" would also be better when 
someone's not using bracket-matching).


 My text editor, however, cannot do if-to-fi matching. Under your
 scheme, I'd be giving up a valuable piece of functionality.


I'd classify that as a limitation in the editor. Most editors let you 
manually define a list of language keywords. I can't imagine it would be 
significantly more difficult for an editor that already handles both 
user-defined keywords and non-configurable bracket matching (or collapsable 
regions), to expose the tokens it uses for bracket matching as configurable. 
Ie, "(",")" as well as "{", "}", and "[","]" would already be set by 
default, and you could either remove those and/or add pairs like "if","fi", 
or "spoogystart","spoogyend".



 May 09 2008