[bitc-dev] White space

[Ben Kloosterman]

Disclosure My functional experience is limited to Lisp and Ocaml and the
learning curve was steep...and hence my comments :-)

 >Often, succinctness breeds legibility. By reducing syntactic overhead,
 >readers can focus on the real content of the code.

In C like languages this is the case but in functional languages the symbols
are key to the logic eg Ocaml
map and match are ok but 

::  ,   --> ,    and |>  etc are key to the logic and don't read easily or
naturally.

 >In functional languages an additional reason is that high levels of
 >abstraction often mean that there is no good "English" name for things.
 >For example, the (>>=) operator in Haskell. It actually does have a
 >pronouncable name, but the name isn't enlightening as to the function's
 >purpose or meaning. Because it's so general, just calling it (>>=) is
 >better than trying to make something up. As a good counterexample,
 >attempting to Englishify things as with Haskell's 'mempty' and 'mappend'
 >often leads to confusion in learning what the functions mean (I'll give
 >you a hint: appending is only one small and very particular
 >specialization of 'mappend'). We're currently in the process of trying
 >to fix that one because of how many newcomers get confused by it.

For >>= to 90% of  the population this means greater than and greater than
or equal then  or to a C programmer >>= is shift and assign.  In other words
the mathematical symbols already have meaning in peoples head and worse in
functional languages the pre-existing meaning has nothing to do with what
they do. 

Take the C# example they didn't choose enumerate they chose foreach and not
just for brevity sure there are some concepts not covered like enumerating
over null , and the fact the collection needs to be IEnumerable  but at a
few millisecond glance you know what's going on . They also use foreach with
a predicate as a parameter instead of map on collections etc Note while in
each case the definition is not precise it roughly conveys what is going on.


 >In OCaml, they have a lot of ad-hoc mechanisms for succinctness because
 >the basic syntax is so verbose (by FP standards). A lot of other
 >languages (both functional and not) have similar problems. To pick
 >another functional example, the Lisp abbreviations cdar, cddar, cadr,...
 >stem from the excessive verbosity due to not having pattern matching.
 >But you have plenty of non-functional languages that are also obsessed
 >with succinctness. E.g., Perl. And, frankly, Awk and Sed aren't exactly
 >legible either.
 >

The thing is most of these operators just end up abbreviations for runtime
methods ( which users can shorten anyway via operator overloading if they
desire)  , especially with modern auto completing IDE's isn't it better to
use the function name for all but the most common shortcuts ? Im a big fan
of fewer keywords.. 

In the case of vectors since the data type is known isn't first  , last  and
map ( or foreach)  more readable and hence easy to learn ?  While I do agree
a experienced user will see it quickly , the number 1 issue for a language
is adoption and hence I would prioritise  them.  Any modern language with c
class performance will do well in the market place , make it easy for the
most wide spread adoption. 

 >(Full disclosure: I was an avid Perl junkie prior to discovering Haskell
 >:)
 >
 >--
 >Live well,
 >~wren
 >_______________________________________________
 >bitc-dev mailing list
 >bitc-dev at coyotos.org
 >http://www.coyotos.org/mailman/listinfo/bitc-dev
 >No virus found in this incoming message.
 >Checked by AVG - www.avg.com
 >Version: 9.0.851 / Virus Database: 271.1.1/3060 - Release Date: 08/10/10
 >02:35:00