www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Python-like tabs instead of curley brackets?

reply Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> writes:
I've been following D for a few years now, and I'd like to suggest ditching
the (now completely redundant) curley brackets from the C-like syntax and
borrowing Python's use of tabs to replace them.   I see no reason to keep the
curley brackets now we have nice editors that know about (and can display) tab
characters.  The ideal programming language should have no redundancy, you
shouldn't have to say anything twice, and at present we are still repearting
ourselves with both curley brackets and indentation!  What do you think?
Oct 27 2006
next sibling parent Fredrik Olsson <peylow gmail.com> writes:
Charles Fox skrev:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

Absolutely not! Keep the brackets. Even making them mandatory for single statement if, is a better idea then removing them. // Fredrik Olsson
Oct 27 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

I think it would be a big mistake, and quite possibly enough to turn me away from D despite the years I have put into it as a user. Doing this, we would sacrifice expressiveness, source portability, useful niche features such as anonymous scopes, and enter the world of ambiguous nesting levels. Python and D are two different galaxies. Python is not a systems language (technically, its interprative, and doesn't provide any low-level functionality that I recall). Scope-by-indentation is a good choice in that case, where the speed and blindness of parsing are paramount. It would be a massacre for D. -- Chris Nicholson-Sauls
Oct 27 2006
parent reply Nils Hensel <nils.hensel web.de> writes:
Chris Nicholson-Sauls schrieb:
 Charles Fox wrote:
 Doing this, we would sacrifice expressiveness,

 source portability,

 useful niche  features such as anonymous scopes,

 and enter the world of ambiguous nesting levels.

 Python and D are two different galaxies.

 Python is not a systems language (technically, its interprative, and doesn't
provide
 any low-level functionality that I recall).

It is often refered to as a glue language because it will hold together very different pieces of software. Even those written in C or even D.
 Scope-by-indentation is a good choice in that case, where the speed and 
 blindness of parsing are paramount.  It would be a massacre for D.

openly visible code structure and shorter source code because of the lack of unnecessary delimiter syntax. I've written a preprocessor for C-style languages which allows me to write in a Python like manner and still have C(++) or D sources for compilation. I wrote the first version in january 2005 and have been using it eversince. It all works very well and allows me to write very readable sources that are usually about 25-30% shorter than the output files. The only shortcoming I've noticed was that with indentation based syntax you are unable to write bottom controlled loops, at least not in a way that it'll be recognized as such. Regards, Nils
Oct 29 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Nils Hensel wrote:
 Chris Nicholson-Sauls schrieb:
 
Charles Fox wrote:
Doing this, we would sacrifice expressiveness,

How's that?

You gave an example yourself at the bottom of your post, when you mentioned bottom-controlled loops. Although Ruby's until() loop is a good example of how to overcome such things, at least a little. Then again, Ruby isn't a good example for this discussion... I find that Ruby is almost mind-bogglingly expressive, which is nice, but makes it difficult to compare with. We would sacrifice it by giving whitespace meaning, thereby changing the priorities of operators and other symbols in parsing... or in short, changing this one piece of syntax changes the case-usability of the rest of the syntax. Or maybe I'm just being anal in this instance.
 
source portability,

Why?

I might like quad-spaces, you might like hard tabs, "Bob" might like 2-space, Walter likes 8-space, etc. Sure, editors can apply whatever tabbing rules one likes, but then only if one sticks to hard tabs. And heaven forbid if other whitespace starts getting meanings, then it can become "truly" non-portable if different OS's have different representations (an example is the newline, which is \n on some systems and \r\n on others).
 
useful niche  features such as anonymous scopes,

Not if you have a keyword for that.

One might argue, then they aren't really anonymous. ;) That's tongue-in-cheek, but the point is sound. Given these two examples: # void main () { # doStuff; # { auto Foo f = new Foo; # doOtherStuff; # } # doFinalStuff; # } # void main () # doStuff # auto Foo f = new Foo # doOtherStuff # doFinalStuff Yes I do admit that the second example is two lines shorter. However, a line with just a '}' on it is hardly worth counting, and also I find the braces immensely meaningful. They make it very clear that I'm introducing a new scope, whereas in the other case my "scope" might be mistaken as a body block to the 'doStuff' symbol. Not too likely to be problem with D as it stands, sure -- but it could be surprising to someone who actually /comes/ to D from a background of Python, ABC, et al. It also leaves me hanging as to whether or not main() is actually closed at this point. How do you suppose we should do D's design-by-contract functions? The only thing I can think of would be: // current # void foo (int x) # in { # blah # } # out { # blah # } # body { # blah # } # unittest { # blah # } // new # void foo (int x) # in: # blah # out: # blah # body: # blah # unittest: # blah Its cute, but one false move and I've got a dangling statement if I miss one little space character. I know, I'm being anal again. But its something I just don't feel I should have to worry about. In this kind of syntax, I find I actually end up spending more time worrying about alignment, etc, when I'm just trying to get a rought draft implemented, rather than doing it later during cleanup/tweaking.
 
and enter the world of ambiguous nesting levels.

In what way are they ambiguous?

See my previous example, and see the plethora of other discussions about it.
 
Python and D are two different galaxies.

I'd say: "different tools, same shed".

Fair enough, except that they still have niches they fulfill that the other doesn't. As I've said before, I have (and very occasionally still do) worked in Python, because at the time it seemed the most straight-forward way to solve a specific problem.
 
Python is not a systems language (technically, its interprative, and doesn't
provide
any low-level functionality that I recall).

Python is as interpretated as Java is (bytecode VM). It is often refered to as a glue language because it will hold together very different pieces of software. Even those written in C or even D.

Yes, indeed, and exactly.
 
Scope-by-indentation is a good choice in that case, where the speed and 
blindness of parsing are paramount.  It would be a massacre for D.

That is just not true. Scope indentation usually just results in an openly visible code structure and shorter source code because of the lack of unnecessary delimiter syntax.

What is more "openly visible" than open-close symbols, such as {}'s?
 I've written a preprocessor for C-style languages which allows me to
 write in a Python like manner and still have C(++) or D sources for
 compilation.
 
 I wrote the first version in january 2005 and have been using it
 eversince. It all works very well and allows me to write very readable
 sources that are usually about 25-30% shorter than the output files.
 

Then you have what you want. ;) I'm not concerned with how short the output files are, but rather with how well I can 1) express what I want with absolute clarity, and 2) format the code to suit my own aesthetics so that I can understand it later with ease. -- Chris Nicholson-Sauls
Oct 29 2006
parent reply Nils Hensel <nils.hensel web.de> writes:
Chris Nicholson-Sauls schrieb:
 You gave an example yourself at the bottom of your post, when you
 mentioned bottom-controlled loops.  Although Ruby's until() loop is a
 good example of how to overcome such things, at least a little.  Then
 again, Ruby isn't a good example for this discussion... I find that Ruby
 is almost mind-bogglingly expressive, which is nice, but makes it
 difficult to compare with.

"until" is exactly what I use to overcome this but I don't know if that's anything like Ruby's for I don't know Ruby. You still have to know that it's bottom-controlled, though. :(
 
 We would sacrifice it by giving whitespace meaning, thereby changing the
 priorities of operators and other symbols in parsing... or in short,
 changing this one piece of syntax changes the case-usability of the rest
 of the syntax.

This problem doesn't arise when you only give meaning to leading whitespace and leave everything else as it is, except for the "one line = one statement" rule (which is true for most cases).
 source portability,

Why?

I might like quad-spaces, you might like hard tabs, "Bob" might like 2-space, Walter likes 8-space, etc. Sure, editors can apply whatever tabbing rules one likes, but then only if one sticks to hard tabs. And heaven forbid if other whitespace starts getting meanings, then it can become "truly" non-portable if different OS's have different representations (an example is the newline, which is \n on some systems and \r\n on others).

You're right: tabs are evil. ;-) But programmers shouldn't use them anyway IMO because they make code unreadable regardless of language.
 useful niche  features such as anonymous scopes,

Not if you have a keyword for that.

One might argue, then they aren't really anonymous. ;) That's tongue-in-cheek, but the point is sound. Given these two examples: # void main () { # doStuff; # { auto Foo f = new Foo; # doOtherStuff; # } # doFinalStuff; # } # void main () # doStuff # auto Foo f = new Foo # doOtherStuff # doFinalStuff Yes I do admit that the second example is two lines shorter. However, a line with just a '}' on it is hardly worth counting, and also I find the braces immensely meaningful. They make it very clear that I'm introducing a new scope, whereas in the other case my "scope" might be mistaken as a body block to the 'doStuff' symbol.

you could use a keyword like "scope". For example: # void main () # doStuff # scope # auto Foo f = new Foo # doOtherStuff # doFinalStuff That's the way indentation should work anyway, starting a block with a keyword, like you would usually do in D anyway. So # if (condition) # { # do_work(); # } becomes # if condition # do_work()
 It also leaves me hanging as to whether or not main() is actually
 closed at this point.

Experience tells me you may trust it to be closed. I've never had any difficulties with that. I believe you would soon feel the same, it's a proven technique.
 How do you suppose we should do D's
 design-by-contract functions?  The only thing I can think of would be:
 
 // current
 # void foo (int x)
 # in {
 #   blah
 # }
 # out {
 #   blah
 # }
 # body {
 #   blah
 # }
 # unittest {
 #   blah
 # }
 
 // new
 # void foo (int x)
 #   in:
 #     blah
 #   out:
 #     blah
 #   body:
 #     blah
 # unittest:
 #   blah

You may omit the ':'. It's not needed.
 Its cute, but one false move and I've got a dangling statement if I miss
 one little space character.

But the same is true if you accidentally erase a closing brace. You can easily screw up C-style syntax as well, trust me on that one ;-)
 I know, I'm being anal again.  But its
 something I just don't feel I should have to worry about.  In this kind
 of syntax, I find I actually end up spending more time worrying about
 alignment, etc, when I'm just trying to get a rought draft implemented,
 rather than doing it later during cleanup/tweaking.

I believe one crosses from worrying about alignment to just using alignment fairly quickly. Having to end up with readable code is a bonus IMO not a disadvantage.
 and enter the world of ambiguous nesting levels.

In what way are they ambiguous?

See my previous example, and see the plethora of other discussions about it.

I must confess I still don't see any ambiguity. To me it's pretty clear what opened the nesting level I'm currently in. I just have to look back to the last line with less indentation to see that.
 Python and D are two different galaxies.

I'd say: "different tools, same shed".

Fair enough, except that they still have niches they fulfill that the other doesn't. As I've said before, I have (and very occasionally still do) worked in Python, because at the time it seemed the most straight-forward way to solve a specific problem.

I agree that Python and D are best at different uses, but that is not due to different parsing. It's because D is very much less dynamic than Python at runtime at the increase of speed. Both approaches are valuable in different occasions, but both could be handled using the same syntax constructs.
 Scope-by-indentation is a good choice in that case, where the speed
 and blindness of parsing are paramount.  It would be a massacre for D.

That is just not true. Scope indentation usually just results in an openly visible code structure and shorter source code because of the lack of unnecessary delimiter syntax.

What is more "openly visible" than open-close symbols, such as {}'s?

A hint may be that there is no such thing as an "obfuscated Python"-contest as there is for C. You can write a whole C-program in one line if you are either an aesthetic pervert or just full of hate for your co-workers. ;-) Just think about the different conventions where to but the opening curly brace. There is no such choice in Python. You only agree on the depth of indentation you use. And years of working on OPC (other people's code ;-) have taught me the importance of writing easily understandable code. I would go as far as to say the best language would be one that forces you to comment your code as well as making it work.
 I've written a preprocessor for C-style languages

Then you have what you want. ;)

Yes, I do. Don't get me wrong. I'm not advocating switching from C-style to Python-style syntax for D. I also believe that to be a mistake at this time. It was just that there seemed to be a lot of unjustified Python-bashing going on (not from you though, I replied to your post because you were the only one actually giving arguments :) All I wanted to point out was that Python-style syntax does not prevent you from ending up with a powerful programming language such as D.
 I'm not concerned with how short the
 output files are, but rather with how well I can 1) express what I want
 with absolute clarity,

Same here, though I enjoy having shorter source files - less bugs and easier to grasp. I just want to do away with the unnecessary stuff like most parentheses, braces, semi-colons and the like. Actually some things are even longer to write in my preprocessor for the sake of expressiveness, e.g. logical operators ('and' instead of '&&').
 and 2) format the code to suit my own aesthetics
 so that I can understand it later with ease.

Which is great if you're the only one working on your code. Otherwise you have to hope for your co-workers to share the same aesthetics. :) Regards, Nils
Oct 30 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Nils Hensel wrote:
 Chris Nicholson-Sauls schrieb:
 
You gave an example yourself at the bottom of your post, when you
mentioned bottom-controlled loops.  Although Ruby's until() loop is a
good example of how to overcome such things, at least a little.  Then
again, Ruby isn't a good example for this discussion... I find that Ruby
is almost mind-bogglingly expressive, which is nice, but makes it
difficult to compare with.

"until" is exactly what I use to overcome this but I don't know if that's anything like Ruby's for I don't know Ruby. You still have to know that it's bottom-controlled, though. :(

In Ruby the statement "until (x == y)" is the same as "while (x != y)", which when coupled with some cut logic inversion, can pull off the trick. I don't think I ever used the Python equivelant, but I'm sure its likely the same.
We would sacrifice it by giving whitespace meaning, thereby changing the
priorities of operators and other symbols in parsing... or in short,
changing this one piece of syntax changes the case-usability of the rest
of the syntax.

This problem doesn't arise when you only give meaning to leading whitespace and leave everything else as it is, except for the "one line = one statement" rule (which is true for most cases).

That is true, the comment on only giving meaning to the indentation, and not to internal spaces. And it would clarify most cases. However, unfortunately I have pleanty of "one line != one statement" code, due to using API's (such as Windows *shudder*) that expect arduous function arguments, and/or due to complex logic/bool expressions that are easier for me to read when spread across lines. I suppose a new indentation level in the middle of a statement would be enough to represent continuation, but then we introduce the new requirement of a statement terminator in the general case; re-introducing the "redundancies" that we had tossed. Its either that \ or prefixing lines with \ those bloody back-slashes \ like some platforms I \ won't mention by name. ;)
 
 
source portability,

Why?

I might like quad-spaces, you might like hard tabs, "Bob" might like 2-space, Walter likes 8-space, etc. Sure, editors can apply whatever tabbing rules one likes, but then only if one sticks to hard tabs. And heaven forbid if other whitespace starts getting meanings, then it can become "truly" non-portable if different OS's have different representations (an example is the newline, which is \n on some systems and \r\n on others).

You're right: tabs are evil. ;-) But programmers shouldn't use them anyway IMO because they make code unreadable regardless of language.

Well, we're agreed on that. Which is saying something, as I used to be a hard-tabs nut.
 
useful niche  features such as anonymous scopes,

Not if you have a keyword for that.

One might argue, then they aren't really anonymous. ;) That's tongue-in-cheek, but the point is sound. Given these two examples: # void main () { # doStuff; # { auto Foo f = new Foo; # doOtherStuff; # } # doFinalStuff; # } # void main () # doStuff # auto Foo f = new Foo # doOtherStuff # doFinalStuff Yes I do admit that the second example is two lines shorter. However, a line with just a '}' on it is hardly worth counting, and also I find the braces immensely meaningful. They make it very clear that I'm introducing a new scope, whereas in the other case my "scope" might be mistaken as a body block to the 'doStuff' symbol.

you could use a keyword like "scope". For example: # void main () # doStuff # scope # auto Foo f = new Foo # doOtherStuff # doFinalStuff

But scope already has a meaning... ;)
 That's the way indentation should work anyway, starting a block with a
 keyword, like you would usually do in D anyway. So
 
 # if (condition)
 # {
 #   do_work();
 # }
 
 becomes
 
 # if condition
 #   do_work()
 

My style would have that opening brace on the line with the if() statement, so dropping the {}'s really only shaved a single line off -- and never would remove any more than that. The one advantage this area does give to indentation-syntax is that it becomes easier to add debugging/etc code to pre-written one-line blocks that you hadn't considered for extra code. Personally, I just make a point of never leaving the {}'s out, and this never effects me.
 
It also leaves me hanging as to whether or not main() is actually
closed at this point.

Experience tells me you may trust it to be closed. I've never had any difficulties with that. I believe you would soon feel the same, it's a proven technique.

My eyes see nothing but more code after main(), therefore it takes me a while to register that main() is no longer going on, but that this code is something else. The fact that the whitespace is different simply doesn't register for me. I guess I just spend far too much time in things where I mostly (or even completely) ignore spaces.
 
How do you suppose we should do D's
design-by-contract functions?  The only thing I can think of would be:

// current
# void foo (int x)
# in {
#   blah
# }
# out {
#   blah
# }
# body {
#   blah
# }
# unittest {
#   blah
# }

// new
# void foo (int x)
#   in:
#     blah
#   out:
#     blah
#   body:
#     blah
# unittest:
#   blah

You may omit the ':'. It's not needed.

I know it isn't technically, but I liked the extra decoration. Oh well, just me thinking in terms of symbols again I suppose.
 
Its cute, but one false move and I've got a dangling statement if I miss
one little space character.

But the same is true if you accidentally erase a closing brace. You can easily screw up C-style syntax as well, trust me on that one ;-)

I can't imagine why I would erase braces unless I was erasing the entire statement associated with them (they're always the first thing I type as well, right after the statement name and its parenthesis). The difference is vital, however. If I am working on some code, and I accidentally put 7 spaces where there should be 8, I may or may not realize something is amiss. I sit and drum on Undo/Redo trying to spot something, and it just isn't there. On the other hand, if I somehow manage to erase or overwrite a brace character, as I tap on Undo/Redo I immediately notice a brace is appearing/disappearing, so I stick it back in where it belongs. Or, I can simply scan my cursor over the chunk of code I was editing, and the pair-highlighting feature makes it clear to me that this delimiter (parenthesis, bracket, or brace) has no partner; better give it one.
 
I know, I'm being anal again.  But its
something I just don't feel I should have to worry about.  In this kind
of syntax, I find I actually end up spending more time worrying about
alignment, etc, when I'm just trying to get a rought draft implemented,
rather than doing it later during cleanup/tweaking.

I believe one crosses from worrying about alignment to just using alignment fairly quickly. Having to end up with readable code is a bonus IMO not a disadvantage.

In the general case, you are right. But, what if I complete that draft of code, only to find that I've made a major mistake, and must scrap the entire thing and quickly re-write? If I was having to pretty-format the whole way, then I've wasted time.
 
and enter the world of ambiguous nesting levels.

In what way are they ambiguous?

See my previous example, and see the plethora of other discussions about it.

I must confess I still don't see any ambiguity. To me it's pretty clear what opened the nesting level I'm currently in. I just have to look back to the last line with less indentation to see that.
Python and D are two different galaxies.

I'd say: "different tools, same shed".

Fair enough, except that they still have niches they fulfill that the other doesn't. As I've said before, I have (and very occasionally still do) worked in Python, because at the time it seemed the most straight-forward way to solve a specific problem.

I agree that Python and D are best at different uses, but that is not due to different parsing. It's because D is very much less dynamic than Python at runtime at the increase of speed. Both approaches are valuable in different occasions, but both could be handled using the same syntax constructs.
Scope-by-indentation is a good choice in that case, where the speed
and blindness of parsing are paramount.  It would be a massacre for D.

That is just not true. Scope indentation usually just results in an openly visible code structure and shorter source code because of the lack of unnecessary delimiter syntax.

What is more "openly visible" than open-close symbols, such as {}'s?

A hint may be that there is no such thing as an "obfuscated Python"-contest as there is for C. You can write a whole C-program in one line if you are either an aesthetic pervert or just full of hate for your co-workers. ;-) Just think about the different conventions where to but the opening curly brace. There is no such choice in Python. You only agree on the depth of indentation you use. And years of working on OPC (other people's code ;-) have taught me the importance of writing easily understandable code. I would go as far as to say the best language would be one that forces you to comment your code as well as making it work.

The caveat is, 1) there are really only two choices on where to put the brace -- same line or next line -- and 2) one can quite easily run "obfuscated" C code through a dummy parser and casually read the properly-formatted output copy. Also, I seriously doubt anybody uses things such as may be found in "obfuscation" contests in legitimate real-world code. If they do, then they deserve to be one very, very lonely programmer. ;)
I've written a preprocessor for C-style languages

Then you have what you want. ;)

Yes, I do. Don't get me wrong. I'm not advocating switching from C-style to Python-style syntax for D. I also believe that to be a mistake at this time. It was just that there seemed to be a lot of unjustified Python-bashing going on (not from you though, I replied to your post because you were the only one actually giving arguments :) All I wanted to point out was that Python-style syntax does not prevent you from ending up with a powerful programming language such as D.
I'm not concerned with how short the
output files are, but rather with how well I can 1) express what I want
with absolute clarity,

Same here, though I enjoy having shorter source files - less bugs and easier to grasp. I just want to do away with the unnecessary stuff like most parentheses, braces, semi-colons and the like.

In the BovisMOO language, which I have full control over, there are certain cases where one can do away with some things (for example the expression ' :name ' is the same as ' $This:name() '). But I actually find that trying to become completely independant of symbols/operators in a language design is quite simply beyond me. Maybe just not enough of the right kind of experience.
 Actually some things are even longer to write in my preprocessor for the
 sake of expressiveness, e.g. logical operators ('and' instead of '&&').
 
 
 
and 2) format the code to suit my own aesthetics
so that I can understand it later with ease.

Which is great if you're the only one working on your code. Otherwise you have to hope for your co-workers to share the same aesthetics. :)

They'd better. ;) Generally though, at least being consistant in one's formatting is enough. For example, I am completely baffled by Kris' coding style used in Mango, and yet I can read Mango code with no difficulty, because his style is consistant enough my eyes just "learn" it as they go. -- Chris Nicholson-Sauls
Oct 30 2006
prev sibling next sibling parent reply mike <vertex gmx.at> writes:
To be honest that's a really scary thought. I think the idea of whitespa=
ce  =

having any syntactic meaning is bad. In any kind of language (in "real" =
 =

languages like english whitespaces don't have any meaning either). I'd  =

rather type those redundant braces over and over again - and keep the  =

option of formatting the code how I think it's best for that particular =
 =

piece of code.

Sorry, but if Walter does that I'll delete my dmd folder immediatly,  =

defragment my hard drive, redirect digitalmars.com to 127.0.0.1, make so=
me  =

self-hypnosis tapes with the text "There is no such thing as the D  =

programming language" and listen to those tapes all night long :)

Seriously, I would immediatly stop using D.

Am 27.10.2006, 14:15 Uhr, schrieb Charles Fox  =

<charles SPAMMENOT.robots.ox.ac.uk>:

 I've been following D for a few years now, and I'd like to suggest  =

 ditching
 the (now completely redundant) curley brackets from the C-like syntax =

 borrowing Python's use of tabs to replace them.   I see no reason to  =

 keep the
 curley brackets now we have nice editors that know about (and can  =

 display) tab
 characters.  The ideal programming language should have no redundancy,=

 you
 shouldn't have to say anything twice, and at present we are still  =

 repearting
 ourselves with both curley brackets and indentation!  What do you thin=

-- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Oct 27 2006
parent reply "mc" <mco333 sympatico.ca> writes:
 To be honest that's a really scary thought. I think the idea of whitespace 
 having any syntactic meaning is bad. In any kind of language (in "real"

Do you know the Whitespace Programming Language ? http://compsoc.dur.ac.uk/whitespace/index.php :-)
Oct 27 2006
parent mike <vertex gmx.at> writes:
Yes :)
I found it once via  =

http://99-bottles-of-beer.net/language-whitespace-154.html

Am 27.10.2006, 16:04 Uhr, schrieb mc <mco333 sympatico.ca>:

 To be honest that's a really scary thought. I think the idea of  =


 whitespace having any syntactic meaning is bad. In any kind of langua=


 (in "real"

Do you know the Whitespace Programming Language ? http://compsoc.dur.ac.uk/whitespace/index.php :-)

-- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Oct 27 2006
prev sibling next sibling parent David Medlock <noone nowhere.com> writes:
Charles Fox wrote:

 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

This would destroy anonymous delegates, one of the best new features of D. If this concerns you a lot, write a converter to read your source and add the brackets! -DavidM
Oct 27 2006
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

Yuck. That's one of the things that turns me off about Python. I would hate to see that in D.
Oct 27 2006
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

Honestly, I don't think this is a good idea. Linguistic ideals like this make wonderful goals for language development, but should be viewed as just that. Ultimately, *good* language comes from a blend of ideal and non-ideal parts that yield the overall character of the language. A good example of how redundancy can be healthy, is how spoken languages work. English, happens to be a wonderfully expressive language since it is jam-packed with redundancy. You don't get this effect with languages that are less hap-hazard in their design, even if they are easier to learn. But note that there aren't any perfectly redundant words, expressions or idioms in any langauge. Each one comes with a different history, usage and (obviously) alliteration or cadence. I think it's these subtle differences that are important, as they give additional weight and meaning to what would otherwise be just a redundant collection words. So how does this apply to programming languages? We spend the overwhelming majority of our time 'developing' software, through trying to understand it. A good chunk of that is reading our own, and other's works. You need all the clues you can get: comments, good function names and a style that takes advantage of the variability of the programming language itself. A less idiosyncratic grammar might help cut down the time spent understanding code. But, I can tell you from my own experience in hacking Trac code (python): it doesn't. Instead, with something like Python, one has to somehow derive additional meaning from the code called and invoked, rather than from the additional clues that a richer grammar can give. Code like this is sane, but lacks intangible factors like cadence, depth and soul. A personal example of mine: I can tell who has maintained a piece of code based on who wrote it - no comments needed. Ultimately, this comes down to these redundant and secondary language features that have marginal impact on the code's meaning like indentation and brace style. But that kind of 'fingerprinting' is loudest and most notable in C-style langauges, especially in Javascript (it practically has TIMTOWDI as a language foundation). You don't get this effect in less expressive, and less redundant grammars like Basic or Assembler. So there's a poetic component, if you will, that is lost when you root out such 'unneccesary' components. Again, this folds into any effort to the research and understanding phase of development. To invoke the old idiom "if it ain't broken, don't fix it." C-style syntax and character has been borrowed and used in countless other languages. Other language have lived, and died, after C was created and long before the present. Surely there's something to be said for how well it's syntax works? -- - EricAnderton at yahoo
Oct 27 2006
parent Walter Bright <newshound digitalmars.com> writes:
Pragma wrote:
 To invoke the old idiom "if it ain't broken, don't fix it."  C-style 
 syntax and character has been borrowed and used in countless other 
 languages.  Other language have lived, and died, after C was created and 
 long before the present.  Surely there's something to be said for how 
 well it's syntax works?

That's so true. We all know and harp on C's faults, but overlook the overwhelming stuff that C got *right*. C was the first really usable high level language. I've heard from some people who should know that one thing that has consistently held Python back from adoption is the whitespace thing. As long as I have any influence on the matter, D is not going to adopt that feature of Python.
Oct 30 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

/delurk /2cents Curly-bracket languages are a pain because you end up with all those redundant braces and parenthesis all over the place, when we all know they're not *really* needed! Offside-rule languages are a pain because any nested structure can't be expressed inline, and you can end up with painful, subtle bugs, not to mention lots of things play silly-buggers with whitespace since it's "not important"! Six of one, half a dozen of the other. Offside rule works for Python because that's what it was designed with. C-style works for D because that's what it was designed with. Another interesting thing is Lua code: it doesn't require you to use an explicit statement separator; it's smart enough to "know" where statements start and end. And yet the majority of Lua code I've seen uses those redundant semicolons and parenthesis. Why? Not really sure; could be they're either so C-style brain-damaged they can't code without compulsively hitting those keys (must... insert... delimiters...), or they just like the additional explicitness. I suppose in the end, it's all a matter of taste. D programmers seem to like curly braces. It's as good a reason as any other :) If you want to see what a language with little to no redundancy looks like, go take a peek at APL. You may want to take a box of headache tablets with you... -- Daniel P.S. Also, I would suggest you go check out Nemerle: <http://nemerle.org/Main_Page> - it's got both a C-style parser and a Python-style parser. It's a very cool language, irrespective :P P.P.S. You use TABs for Python code? What blasphemy! Everyone knows that *FOUR SPACES* is superior to those pathetic tab characters! :3 -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Oct 27 2006
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Daniel Keep wrote:
 Another interesting thing is Lua code: it doesn't require you to use an
 explicit statement separator; it's smart enough to "know" where
 statements start and end.  And yet the majority of Lua code I've seen
 uses those redundant semicolons and parenthesis.  Why?  Not really sure;
 could be they're either so C-style brain-damaged they can't code without
 compulsively hitting those keys (must... insert... delimiters...), or
 they just like the additional explicitness.

Well, FWIW, when I first switched from a significant period of time of C-like languages to another language (VB, for a school assignment. Don't ask) I was automatically hitting ';' at the end of every statement. Sort of the same thing happened when I coded in Pascal (well, Delphi mostly) for a while, I hit ';' at the end of every statement (it's only required as a statement _separator_ in Pascal, so it's unnecessary after the last statement). Since it compiled I never stopped. Of course, there you can justify it by the fact that it makes it easier to add statements to a block :) I guess it's just one of those things that, once learned, you keep doing until you notice that the compiler you're using keeps complaining about them :).
Oct 27 2006
parent reply BCS <BCS pathlink.com> writes:
Frits van Bommel wrote:

 Well, FWIW, when I first switched from a significant period of time of 
 C-like languages to another language (VB, for a school assignment. Don't 
 ask) I was automatically hitting ';' at the end of every statement.
 

things like that creep into "real" life; I have also been known to use a single line comment to annotate notes in class; // in other non-CS classes to <g>
Oct 27 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
BCS wrote:
 I have also been known to use a single line comment to annotate notes in 
 class;
 
 // in other non-CS classes to <g>

heheh .. I do that too!!
Oct 27 2006
prev sibling next sibling parent =?UTF-8?B?IlRvbcOhcyBBLiBSb3NzaSI=?= <tom nospam.com> writes:
Daniel Keep wrote:
 Charles Fox wrote:
 [...]
 Why?  Not really sure; could be they're either so C-style
 brain-damaged they can't code without compulsively hitting those keys
 (must... insert... delimiters...),
 [...]

LOL! :D -- Tom;
Oct 28 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Daniel Keep wrote:
 Another interesting thing is Lua code: it doesn't require you to use an
 explicit statement separator; it's smart enough to "know" where
 statements start and end.  And yet the majority of Lua code I've seen
 uses those redundant semicolons and parenthesis.  Why?  Not really sure;
 could be they're either so C-style brain-damaged they can't code without
 compulsively hitting those keys (must... insert... delimiters...), or
 they just like the additional explicitness.

Adding the ';' makes it a lot easier for the compiler to give reasonable targetted error messages when the syntax is wrong. Not only does it give the parser an obvious "resynchronize" marker, it helps the user "resynchronize" when faced with complex text.
Oct 29 2006
prev sibling next sibling parent J Duncan <jtd514 nospam.ameritech.net> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

EWWWWWWWWW! redundant? Hardly. There is a place for insanity such as this, its called Python.
Oct 27 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

http://media.urbandictionary.com/image/large/SRSLY-40514.jpg -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 27 2006
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
Charles Fox wrote:
 I've been following D for a few years now, and I'd like to suggest ditching
 the (now completely redundant) curley brackets from the C-like syntax and
 borrowing Python's use of tabs to replace them.   I see no reason to keep the
 curley brackets now we have nice editors that know about (and can display) tab
 characters.  The ideal programming language should have no redundancy, you
 shouldn't have to say anything twice, and at present we are still repearting
 ourselves with both curley brackets and indentation!  What do you think?

I like Python, but I find the use of tabs for scope to have both plusses and minuses. Even with a good tab-aware editor it's difficult to do major reworks of chunks of code. Like cutting a big nested chunk of stuff from one place and dropping it into a another function somehwere else. You have to be very careful when doing that kind of thing with Python code. With a curly brace language the braces make sure you don't mess anything up. Just paste it in however you want and hit your editor's 'reformat selection' button. Also I was just looking through the Python mailing list archives the other day and saw lots of code snippets from which the leading whitespace had been stripped by news software or something along the way. Including the braces is just more robust in the long term. That said, it is nice to be able to omit all the ';' and '{' characters. But like another person said it's 6 of one 1/2 dozen the other. They both have pros and cons, and since D aims to be an easy transition language for C/C++ users, it makes sense to stick with the braces. --bb
Oct 27 2006
prev sibling next sibling parent reply Witold Baryluk <baryluk mpi.int.pl> writes:
Content-Type: text/plain; charset=ISO-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> napisa=B3/a:

 I've been following D for a few years now, and I'd like to suggest
 ditching the (now completely redundant) curley brackets from the
 C-like syntax and borrowing Python's use of tabs to replace them.   I
 see no reason to keep the curley brackets now we have nice editors
 that know about (and can display) tab characters.  The ideal
 programming language should have no redundancy, you shouldn't have to
 say anything twice, and at present we are still repearting ourselves
 with both curley brackets and indentation!  What do you think?

Hi all. Try this: http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future). -- Witold Baryluk MAIL: baryluk smp.if.uj.edu.pl, baryluk mpi.int.pl JID: movax jabber.autocom.pl
Nov 29 2006
next sibling parent Leandro Lucarella <llucarella integratech.com.ar> writes:
Witold Baryluk escribi├│:
 Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
 Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> napisał/a:
 
 I've been following D for a few years now, and I'd like to suggest
 ditching the (now completely redundant) curley brackets from the
 C-like syntax and borrowing Python's use of tabs to replace them.   I
 see no reason to keep the curley brackets now we have nice editors
 that know about (and can display) tab characters.  The ideal
 programming language should have no redundancy, you shouldn't have to
 say anything twice, and at present we are still repearting ourselves
 with both curley brackets and indentation!  What do you think?

Hi all. Try this: http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz

This is soooo nice, I know is too late to ask for pyton-like syntax, but this keeps the hope high ;) -- Leandro Lucarella Integratech S.A. 4571-5252
Nov 30 2006
prev sibling next sibling parent reply Mark Wrenn <mark binarytheory.com> writes:
On Thu, 30 Nov 2006 03:56:39 +0100, Witold Baryluk wrote:

 Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
 Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> napisa│/a:
 
 I've been following D for a few years now, and I'd like to suggest
 ditching the (now completely redundant) curley brackets from the
 C-like syntax and borrowing Python's use of tabs to replace them.   I
 see no reason to keep the curley brackets now we have nice editors
 that know about (and can display) tab characters.  The ideal
 programming language should have no redundancy, you shouldn't have to
 say anything twice, and at present we are still repearting ourselves
 with both curley brackets and indentation!  What do you think?

Hi all. Try this: http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future).

I must be old :) I have to say that I like the C style brackets. I'll catch you guys later at the old programmers home :) Mark
Nov 30 2006
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Mark Wrenn wrote:
 
 I must be old :)  I have to say that I like the C style brackets.  I'll
 catch you guys later at the old programmers home :)
 
 Mark

I'm not old and I like the brackets too
Nov 30 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Tomas Lindquist Olsen wrote:
 Mark Wrenn wrote:
 I must be old :)  I have to say that I like the C style brackets.  I'll
 catch you guys later at the old programmers home :)

 Mark

I'm not old and I like the brackets too

Likewise
Nov 30 2006
parent Jeff <jeffrparsons optusnet.com.au> writes:
Kyle Furlong wrote:
 Tomas Lindquist Olsen wrote:
 Mark Wrenn wrote:
 I must be old :)  I have to say that I like the C style brackets.  I'll
 catch you guys later at the old programmers home :)

 Mark

I'm not old and I like the brackets too

Likewise

Ditto. I'm by no means old yet I'm a fan of braces. I'll admit that BSD/Allman style annoys me (it wastes a bit -too- much space for my liking) but following K&R in general results in fairly neat, legible code without too much waste. Sure, there's even less space "wasted" if you remove braces altogether, but it's not true to say that there is no longer any justification for them: tabs vs. spaces problems still plague some such languages (though this is generally a minor concern) and removing braces kills flexibility! I couldn't count the times I've needed to break convention to lay some special code out in a more sensible way.
Dec 01 2006
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Mark Wrenn wrote:
 On Thu, 30 Nov 2006 03:56:39 +0100, Witold Baryluk wrote:
 
 Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
 Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> napisa│/a:

 I've been following D for a few years now, and I'd like to suggest
 ditching the (now completely redundant) curley brackets from the
 C-like syntax and borrowing Python's use of tabs to replace them.   I
 see no reason to keep the curley brackets now we have nice editors
 that know about (and can display) tab characters.  The ideal
 programming language should have no redundancy, you shouldn't have to
 say anything twice, and at present we are still repearting ourselves
 with both curley brackets and indentation!  What do you think?

Try this: http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future).

I must be old :) I have to say that I like the C style brackets. I'll catch you guys later at the old programmers home :) Mark

Put me in the "old" camp too I guess. I've posted before about this, but I still think it bears repeating why this isn't a good idea for D. I've been doing some Trac hacking lately so I've come to despise Python's whitespace scheme. Oh sure, it makes for some nice looking code, but in the end, my code fails compilation after compilation just because I mashed the [tab] key (instead of four spaces) by mistake. Recently, I showed an example to my wife (who's not a programmer BTW) of two lines of python code: print('hello world') print('hello world') I then told her that "one of those lines is 100% valid code, and the other isn't." I added that "the bad line will stop my program dead in it's tracks, even though I double checked my work, just as we did. The difference is one has four spaces and the other a [tab] character." Her response? "Wow, that's pretty lame." If the design failure here is easily grasped by someone, who's entire "coding" experience can be summed up in using LiveJournal and MySpace daily, then something is very, very wrong. -- - EricAnderton at yahoo
Nov 30 2006
parent reply Daniel Giddings <dgiddings bigworldtech.com> writes:
Get an editor that understands Python ;-) Most will either use whatever 
that code block uses, or highlight the problem indentation in bright red.

Personally I much prefer the Python way of doing indentation, after all 
you indent your code anyway making the curly braces somewhat redundant 
(and I program about equally in C/C++ and Python).

:-) Dan

Pragma wrote:
 
 Put me in the "old" camp too I guess.
 
 I've posted before about this, but I still think it bears repeating why 
 this isn't a good idea for D.
 
 I've been doing some Trac hacking lately so I've come to despise 
 Python's whitespace scheme.  Oh sure, it makes for some nice looking 
 code, but in the end, my code fails compilation after compilation just 
 because I mashed the [tab] key (instead of four spaces) by mistake.
 
 Recently, I showed an example to my wife (who's not a programmer BTW) of 
 two lines of python code:
 
     print('hello world')
     print('hello world')
 
 I then told her that "one of those lines is 100% valid code, and the 
 other isn't."  I added that "the bad line will stop my program dead in 
 it's tracks, even though I double checked my work, just as we did.  The 
 difference is one has four spaces and the other a [tab] character."  Her 
 response?
 
 "Wow, that's pretty lame."
 
 If the design failure here is easily grasped by someone, who's entire 
 "coding" experience can be summed up in using LiveJournal and MySpace 
 daily, then something is very, very wrong.
 

Nov 30 2006
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Daniel Giddings wrote:
 Get an editor that understands Python ;-) Most will either use whatever 
 that code block uses, or highlight the problem indentation in bright red.
 
 Personally I much prefer the Python way of doing indentation, after all 
 you indent your code anyway making the curly braces somewhat redundant 
 (and I program about equally in C/C++ and Python).

I use Python occasionally, and the indentation requirements have never bothered me. But, from what I've heard, web programming is a huge pain in the ass using Python. Embedding Python source in an HTML document (php/jsp style) causes major pain, since whitespace matters within python blocks. --benji
Nov 30 2006
next sibling parent Daniel Giddings <dgiddings bigworldtech.com> writes:
I've not done any web programming presentation wise, except using Zope 
(a Python application server for building web apps). I can see where JSP 
style programming would be a problem with Python.

Zope takes the approach of using a templating language for seperating 
presentation with back end logic. It's a far better approach than 
embedding code into a web page. Your graphics designers can take the 
pages directly into dreamweaver / whatever and see sample values in the 
dynamic fields, and modify it without having to worry about broken html 
due to <% %>.

Zope Page Templates:
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx

:-) Dan

Benji Smith wrote:
 Daniel Giddings wrote:
 Get an editor that understands Python ;-) Most will either use 
 whatever that code block uses, or highlight the problem indentation in 
 bright red.

 Personally I much prefer the Python way of doing indentation, after 
 all you indent your code anyway making the curly braces somewhat 
 redundant (and I program about equally in C/C++ and Python).

I use Python occasionally, and the indentation requirements have never bothered me. But, from what I've heard, web programming is a huge pain in the ass using Python. Embedding Python source in an HTML document (php/jsp style) causes major pain, since whitespace matters within python blocks. --benji

Nov 30 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Benji Smith wrote:
 But, from what I've heard, web programming is a huge pain in the ass 
 using Python. Embedding Python source in an HTML document (php/jsp 
 style) causes major pain, since whitespace matters within python blocks.

Every programming language has some stupid mistake in it that sounded like a good idea at the time: C: pointer-array equivalence C++: using < > for templates Python: spaces mean something Java: exception specifications Lisp: ( ) FORTRAN: DO 10 I Pascal: I/O is a special case D: I'm sure you all have your own ideas for this!
Nov 30 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Benji Smith wrote:
 
 But, from what I've heard, web programming is a huge pain in the ass 
 using Python. Embedding Python source in an HTML document (php/jsp 
 style) causes major pain, since whitespace matters within python blocks.

Every programming language has some stupid mistake in it that sounded like a good idea at the time: C: pointer-array equivalence C++: using < > for templates Python: spaces mean something Java: exception specifications Lisp: ( ) FORTRAN: DO 10 I Pascal: I/O is a special case D: I'm sure you all have your own ideas for this!

:-) For me, I think it's too soon to tell. After all, we're still living the "at the time" part with D. Right now I'm actually more satisfied with D than ever!
Nov 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 Benji Smith wrote:

 But, from what I've heard, web programming is a huge pain in the ass 
 using Python. Embedding Python source in an HTML document (php/jsp 
 style) causes major pain, since whitespace matters within python blocks.

Every programming language has some stupid mistake in it that sounded like a good idea at the time: C: pointer-array equivalence C++: using < > for templates Python: spaces mean something Java: exception specifications Lisp: ( ) FORTRAN: DO 10 I Pascal: I/O is a special case D: I'm sure you all have your own ideas for this!

:-) For me, I think it's too soon to tell. After all, we're still living the "at the time" part with D.

That's what I think, too. In 10 years we'll all know what is screwed up in D. At least we got rid of the bit type before it got too entrenched!
 Right now I'm actually more satisfied with D than ever!

Perspective is a funny thing. Many years ago, the appliances in my kitchen were old and cruddy, and I thought it might be time to do a kitchen remodel. So I hired this high end kitchen design outfit. They came in, and designed an absolutely stunning kitchen. So I showed the design to my dad. He told me I'd be sorry if I went ahead with the project, because the kitchen would look so good the rest of the house would look like garbage. Whereas I was satisfied with the rest of the house, I wouldn't be after the remodel. I think he was right, and I canceled the project. So how does this relate to D? The best compliment on D I received a while a go started by cussing me out. The person had used D for a while, and then went back to C++. He found that whereas he was perfectly happy with C++ before, he couldn't write C++ any more. D had ruined his taste for it <g>.
Nov 30 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Perspective is a funny thing. Many years ago, the appliances in my 
 kitchen were old and cruddy, and I thought it might be time to do a 
 kitchen remodel. So I hired this high end kitchen design outfit. They 
 came in, and designed an absolutely stunning kitchen. So I showed the 
 design to my dad. He told me I'd be sorry if I went ahead with the 
 project, because the kitchen would look so good the rest of the house 
 would look like garbage. Whereas I was satisfied with the rest of the 
 house, I wouldn't be after the remodel. I think he was right, and I 
 canceled the project.
 
 So how does this relate to D? The best compliment on D I received a 
 while a go started by cussing me out. The person had used D for a while, 
 and then went back to C++. He found that whereas he was perfectly happy 
 with C++ before, he couldn't write C++ any more. D had ruined his taste 
 for it <g>.
 

I can relate to the poor guy. I started out, many a moon ago, bashing out BASIC/1a on a Trash-80. (Model 4P, for those who know.) Took a course on C/C++ in high school, went along with that for a few years. Then took up Java because, at the time, I was doing mostly very small GUI convenience apps. Then (gosh, has it been that long?) I came across D (0.49). (Don't even remember how I found it!) I played around with it, doing random silly things for a week or two, and put it aside. About that time, I took a little vacation, so to say... I did peek back every now and then at the change log, just to see if that "interesting little language idea was going anywhere." Come 0.63, I 'converted' and haven't looked back since. I wanted so badly to get away from Java's VM-hell (yes I know, its all improved vastly over time, but still) but just couldn't swallow C++ at all anymore, I'd actually started pondering on my /own/ new language idea... just to realize I was practically making a substandard D anyhow. -- Chris Nicholson-Sauls
Nov 30 2006
prev sibling parent reply Leandro Lucarella <llucarella integratech.com.ar> writes:
Daniel Giddings escribiˇ:
 Get an editor that understands Python ;-) Most will either use whatever 
 that code block uses, or highlight the problem indentation in bright red.
 
 Personally I much prefer the Python way of doing indentation, after all 
 you indent your code anyway making the curly braces somewhat redundant 
 (and I program about equally in C/C++ and Python).

And I found all the people who don't like indent blocks is people that doesn't use them for too long. Sure at first is horrible, shocking, but when you get used to, there's no way back. Bracket (and sentence terminators) are syntactic noise[1]. [1] http://xlr.sourceforge.net/concept/synnoise.html -- Leandro Lucarella Integratech S.A. 4571-5252
Dec 01 2006
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Leandro Lucarella wrote:
 Daniel Giddings escribiˇ:
 Get an editor that understands Python ;-) Most will either use 
 whatever that code block uses, or highlight the problem indentation in 
 bright red.

 Personally I much prefer the Python way of doing indentation, after 
 all you indent your code anyway making the curly braces somewhat 
 redundant (and I program about equally in C/C++ and Python).

And I found all the people who don't like indent blocks is people that doesn't use them for too long. Sure at first is horrible, shocking, but when you get used to, there's no way back. Bracket (and sentence terminators) are syntactic noise[1]. [1] http://xlr.sourceforge.net/concept/synnoise.html

A friend of mine spent four years or so of his life up to his waist in Python, as the maintainer and new feature developer of a popular bittorrent client. (Trying to avoid names here... :)) When the original developer became interested in taking back his project, my friend was only too happy to give it to him and go back to C. Personally, I only touched Python for about a year and a half and found it too difficult for myself to work with. I guess I'm just too darn dependant on visual cues and layout aesthetics to make it easier to read my code. I'll take my flexibility-offering noise any day. Even Pascal-like begin/end keywords don't bother me. (Not even LambdaMOO's IF...ENDIF, FOR...ENDFOR, etc. At least they're darn clear. ;)) -- Chris Nicholson-Sauls
Dec 01 2006
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 01 Dec 2006 10:03:21 -0300, Leandro Lucarella wrote:

 Daniel Giddings escribi├│:

 Bracket (and sentence terminators) are syntactic noise[1].

Much like question marks, commas, periods, parenthesis, whitespace and upper/lower case in English text, no? Some other languages don't use them so why does English persist!? -- Derek Parnell
Dec 01 2006
prev sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Witold Baryluk wrote:
 Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
 Charles Fox <charles SPAMMENOT.robots.ox.ac.uk> napisał/a:
 
 
I've been following D for a few years now, and I'd like to suggest
ditching the (now completely redundant) curley brackets from the
C-like syntax and borrowing Python's use of tabs to replace them.   I
see no reason to keep the curley brackets now we have nice editors
that know about (and can display) tab characters.  The ideal
programming language should have no redundancy, you shouldn't have to
say anything twice, and at present we are still repearting ourselves
with both curley brackets and indentation!  What do you think?

Hi all. Try this: http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future). -- Witold Baryluk MAIL: baryluk smp.if.uj.edu.pl, baryluk mpi.int.pl JID: movax jabber.autocom.pl

Question: how do you propose to do these with only indentation:
 extern(C):
 << Butt-loads of non-indented code because indenting a whole file four
    spaces is stupid >>

Or this:
 FunkyThing(some_expression,
 {
 	<< More Code >>
 });

(Walter, can we *pretty please* have trailing delegate literals? *puppy-dog eyes*) Or even THIS (which Python to this day cannot do):
 do
 {
 	<< code >>
 }
 while( expression );

There's no way to indent the above that makes sense. You say that we are repeating ourselves with indentation and curly braces... but that's not always true. Take the following:
 class Foo
 {
 public:
 	<< Public members >>

 private:
 	<< Private members >>
 }

Here I'm *not* repeating myself. I'm deliberately altering the indentation because losing eight characters on the side of every line of code just to make room for access modifiers is stupid. Here's another real-life example:
 for( int i=0; i<WIDTH; i++ )
 for( int j=0; j<HEIGHT; j++ )
 {
 	<< Code >>
 }

I've broken convention there to emphasise that this is a 2D traversal across a rectangular array. The curly brace syntax is NOT redundant. It's just different. Please stop being syntaxist -- all syntaxes are created equal! ... except for APL. That's like vomiting random unicode code points onto a piece of paper and calling it code. Oh, and LISP. But then, that's not really a syntax so much as a file format for S-expressions that happens to be executable :3 -- Daniel "has far too many 2c coins lying around" P.S. Just so you know, I love Python's syntax. I just don't think it's suitable for D. :)
Nov 30 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Witold Baryluk wrote:

 I also like Python's syntax, but i think small portion of D can be
 adapted to this syntax (if anyone like tabs, and if it will be used
 by anyone). I also think that people frustrated by Python syntax,
 simply have bad editor/configuration. Lots of editors now is not tabaware.

Nope, my editor handles it perfectly. I just find the indenting in Python to suck. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Dec 01 2006
prev sibling parent Daniel Keep <daniel.keep+lists gmail.com> writes:
Or this:

 FunkyThing(some_expression,
 {
 	<< More Code >>
 });


You can, or we can adapt backslash (like in bash) to do this: FunkyThing(some_expression, \ { \ << More Code >> \ }); \ I know, it is awful. Another proposition can be: Implicit { introduce additional indentation level inside. So it will be like: FunkyThinkg(some, \ { xx if y: z })

So if curly braces are unneccesary and nothing but syntactic noise... then why are you using them, and then having to invent hacks to get around the fact that you're relying on indentation? The fact that you're having to compensate for their absense obviously means they aren't redundant :3
 
P.S.  Just so you know, I love Python's syntax.  I just don't think
it's suitable for D. :)

I also like Python's syntax, but i think small portion of D can be adapted to this syntax (if anyone like tabs, and if it will be used by anyone). I also think that people frustrated by Python syntax, simply have bad editor/configuration. Lots of editors now is not tabaware. PS. I use in all languages (Python, C, D, etc.) hard-tabs (for indentations), which are displayed as 4-character in my editor. There are simple rules to be consistent with such style, and not introduce problems in any situation.

And there's another problem with Python's syntax: I hate *hard* tabs. Absolutely loathe them; they continuously get displayed as 8 spaces when I damn well want them to be 4 spaces. And some hideously misguided fools display them as *2* spaces! Those sick, sad people... (joking) I worked on a project in my third year of uni with four other people. Things were going swell until files started breaking. Stuff would just stop compiling from svn suddenly. It turned out that one of the guys was using a MODERN editor that simply couldn't cope with the rigors of Python: specifically, he liked hard tabs but everyone else was using soft tabs. The editor started changing bits and pieces of our code from soft to hard, and broke tons of stuff. It was really bad when it would combine soft and hard tabs in places into something that looked valid on HIS machine, but totally borked on ours. And since Python has nothing bar indentation to signify nesting, it was a painful job to fix it all up manually. He complained bitterly that it was a pain to have to continually reconfigured his editor to support our coding style. And he was damn right, too--some say "get a better editor", but he shouldn't *have* to. He chose his editor for good reasons, and it's not fair to force people to change because you think their editor sucks. (Incidentally, I use IDLE for Python coding and GVim for everything else. I guess I just didn't mind so much.) In the end, we just kept having to "sanitise" his files every once in a while, especially when someone else had to work on them. I am, once again, rambling. :) In any case, you mention converting a "small portion of D"... I think that if you boiled down D to a simple, indentation-based language... you'd end up with Python anyway :P If you're really set on compiling it to native, I recommend checking out Pyrex. -- Daniel
Dec 03 2006
prev sibling parent Witold Baryluk <baryluk mpi.int.pl> writes:
Dnia Fri, 01 Dec 2006 13:33:05 +0800
Daniel Keep <daniel.keep+lists gmail.com> napisa=B3/a:

 Question: how do you propose to do these with only indentation:
=20
  > extern(C):
  > << Butt-loads of non-indented code because indenting a whole file
  > four spaces is stupid >>
=20

You can't do this in simple/automatic way. "Indented D" (if i can name it so) is for other purpose - for quick & dirty scripting, accessing library function, not creating them. Of course, we can create rules, so all of D constructs will be possible/allowed, but probably there will be lots of such rules. In hard cases I like strong syntax discipline, and if there is any notstrict construct it is an error.
 Or this:
=20
  > FunkyThing(some_expression,
  > {
  > 	<< More Code >>
  > });

FunkyThing(some_expression, \ { \ << More Code >> \ }); \ I know, it is awful. Another proposition can be: Implicit { introduce additional indentation level inside. So it will be like: FunkyThinkg(some, \ { xx if y: z })
 Please stop being syntaxist -- all syntaxes are created equal!

BTW. Whitespace also?
 P.S.  Just so you know, I love Python's syntax.  I just don't think
 it's suitable for D. :)

adapted to this syntax (if anyone like tabs, and if it will be used by anyone). I also think that people frustrated by Python syntax, simply have bad editor/configuration. Lots of editors now is not tabaware. PS. I use in all languages (Python, C, D, etc.) hard-tabs (for indentations), which are displayed as 4-character in my editor. There are simple rules to be consistent with such style, and not introduce problems in any situation. --=20 Witold Baryluk MAIL: baryluk smp.if.uj.edu.pl, baryluk mpi.int.pl JID: movax jabber.autocom.pl
Dec 01 2006