www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Python-indentation (Was: Re: Is the world coming to an end?)

reply ulrik.mikaelsson gmail.com writes:
 PS I don't want to say every of Python's decisions is wrong. Many of them  
 are great (but defenitely not significant intendation).


On a side-note, I thought the same, until I realised I hate redundancies  
even more than I hated forced code-styles. And code-indentation AND  
brackets are clearly redundant, since they pretty much convey the same  
information "block", only one is structural and the other visual.

Nowadays, my complaint on Python-indentation are that they aren't fully  
enforcing a STRICT policy on indentation. Mixed-code indentation in 3d-part  
can cause a lot of unexpected bugs.


Personally, I'd like to see a world where "plain old text" (whatever that  
means, considering all the related encoding and line-ending-problems  
constantly biting us multi-platform non-ASCII-people in the behind) were  
replaced with something just slightly higher-level, such as semantic trees.  
For programming, the notion would be to, instead of storing "text", storing  
the AST of the parsed code, letting the editor render the tree to the  
user's preferences, to create true separation between information (the  
structural code) and visualization (the readable code).

If a standardized format for the serialized tree was used, VCS:es could use  
it to record changes not as "lines changed", but changes in the AST.  
Name-changes would not change entire lines, but just the references to that  
symbol. Wrapping a block of code into an "if-statement" could clearly be  
visualized, instead of appearing like a big chunk of code were COMPLETELY  
rewritten (when in reality it was just indented.)

For other tree structured formats, if nothing else, efficient standardized  
tree-representation could significantly boost performance of some  
protocols. (XML, I'm looking at you)

I know, it's not going to happen, but one can dream?
Apr 02 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
 PS I don't want to say every of Python's decisions is wrong. Many of them  
 are great (but defenitely not significant intendation).




There's a large difference between Python and D design process: Python devs
discuss ideas about possible designs, even for days, and then the most
preferred one is chosen. Only in uncommon cases, when there is no consensus,
Guido chooses (like in the "X if P else Y" syntax). This, and the care they
give to that process (they believe that good syntax matters), produce a
language that's very well designed (despite some flaws).

Bye,
bearophile
Apr 02 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 03.04.2011 03:01, schrieb bearophile:

 PS I don't want to say every of Python's decisions is wrong. Many of them  
 are great (but defenitely not significant intendation).




 
 There's a large difference between Python and D design process: Python devs
discuss ideas about possible designs, even for days, and then the most
preferred one is chosen. Only in uncommon cases, when there is no consensus,
Guido chooses (like in the "X if P else Y" syntax). This, and the care they
give to that process (they believe that good syntax matters), produce a
language that's very well designed (despite some flaws).
 
 Bye,
 bearophile


IMHO D is a language that is very well designed (despite some flaws) as well, so
it seems like D's design process isn't any worse ;)
Apr 02 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/2/11 8:01 PM, bearophile wrote:

 PS I don't want to say every of Python's decisions is wrong. Many of them
 are great (but defenitely not significant intendation).




 There's a large difference between Python and D design process: Python devs
discuss ideas about possible designs, even for days, and then the most
preferred one is chosen. Only in uncommon cases, when there is no consensus,
Guido chooses (like in the "X if P else Y" syntax). This, and the care they
give to that process (they believe that good syntax matters), produce a
language that's very well designed (despite some flaws).

 Bye,
 bearophile


That's how it works for D too.

Andrei
Apr 02 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
<ulrik.mikaelsson gmail.com> wrote in message 
news:mailman.3049.1301786442.4748.digitalmars-d puremagic.com...

 PS I don't want to say every of Python's decisions is wrong. Many of them
 are great (but defenitely not significant intendation).


 On a side-note, I thought the same, until I realised I hate redundancies
 even more than I hated forced code-styles. And code-indentation AND
 brackets are clearly redundant, since they pretty much convey the same
 information "block", only one is structural and the other visual.

 Nowadays, my complaint on Python-indentation are that they aren't fully
 enforcing a STRICT policy on indentation. Mixed-code indentation in 
 3d-part
 can cause a lot of unexpected bugs.


My main objection to Python's indentation was always: It *doesn't* enforce 
*anything*. It makes *assumptions*. (Plus, I like to leave temporary 
debugging code unindented so it's easy to spot. And easy to remove before 
comitting.)

...But now I've simplified my stance on Python's indentation to: I'm very 
allergic to it. (Easier to say, and I don't end up needed to defend it ;) )


 Personally, I'd like to see a world where "plain old text" (whatever that
 means, considering all the related encoding and line-ending-problems
 constantly biting us multi-platform non-ASCII-people in the behind) were
 replaced with something just slightly higher-level, such as semantic 
 trees.
 For programming, the notion would be to, instead of storing "text", 
 storing
 the AST of the parsed code, letting the editor render the tree to the
 user's preferences, to create true separation between information (the
 structural code) and visualization (the readable code).

 If a standardized format for the serialized tree was used, VCS:es could 
 use
 it to record changes not as "lines changed", but changes in the AST.
 Name-changes would not change entire lines, but just the references to 
 that
 symbol. Wrapping a block of code into an "if-statement" could clearly be
 visualized, instead of appearing like a big chunk of code were COMPLETELY
 rewritten (when in reality it was just indented.)

 For other tree structured formats, if nothing else, efficient standardized
 tree-representation could significantly boost performance of some
 protocols. (XML, I'm looking at you)

 I know, it's not going to happen, but one can dream?


Yea, I've sometimes felt the same way. There's a program out there called 
JetBrains MPS that's sort of similar to that. It's interesting as a 
proof-of-concept, but it's so rediculously slow and bloated it makes a 
fully-loaded Eclipse seem as quick and lean as windows notepad (Just 
creating a new project took about half-an-hour, IIRC. 'Course, I'm on a 
32-bit single-core, but even still...) Been awhile since I tried it though, 
maybe it's gotten better since then.
Apr 03 2011