[bitc-dev] White space
bklooste at gmail.com
Mon Aug 9 20:58:44 PDT 2010
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
>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
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
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
>bitc-dev mailing list
>bitc-dev at coyotos.org
>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
More information about the bitc-dev