Python-like tabs instead of curley brackets?

Pragma ericanderton at yahoo.removeme.com
Fri Oct 27 09:38:31 PDT 2006


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



More information about the Digitalmars-d mailing list