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. oidhfoi123413j4h1ohsc! #$%^&*(vjkasdasdf 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