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,


How's that?


 source portability,


Why?


 useful niche  features such as anonymous scopes,


Not if you have a keyword for that.


 and enter the world of ambiguous nesting levels.


In what way are they ambiguous?


 Python and D are two different galaxies.


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


 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.


 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.

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:















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














// new










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:
 







 





 
 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:








That's the way indentation should work anyway, starting a block with a
keyword, like you would usually do in D anyway. So






becomes






 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













 
 // new











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:















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:
 








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
 




 
 becomes
 


 


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














// new











 
 
 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 =


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 thin=


k?



-- =

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=




ge  =


 (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.
 


I find my self punctuating English with them; It's really funny when 
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 parent reply Witold Baryluk <baryluk mpi.int.pl> writes:
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?


 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


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
parent reply 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 >>
  > });


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
})



 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. :)


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.


--=20
Witold Baryluk
MAIL: baryluk smp.if.uj.edu.pl, baryluk mpi.int.pl
JID: movax jabber.autocom.pl
Dec 01 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