[Melbourne-pm] Dancing around the event horizon

[Peter Lawrence]

Main comment at end...

On 05/06/2015, Kahlil Hodgson <kahlil.hodgson at dealmax.com.au> wrote:
> On 4 June 2015 at 17:30, Sam Watkins <sam at nipl.net> wrote:
>
>> For more readable LISP, I figure we need implicit parens around lines,
>> and encompassing any indented block argument:
>>
>>     define
>>         largest-two-square-sum x y z
>>         if (= x (larger x y))
>>             sum-of-squares x (larger y z)
>>             sum-of-squares y (larger x z)
>>
>> Is more readable to me than:
>>
>>     (define
>>         (largest-two-square-sum x y z)
>>             (if (= x (larger x y))
>>                 (sum-of-squares x (larger y z))
>>                 (sum-of-squares y (larger x z))
>>             )
>>     )
>>
>
> ​They look about the same to me, Sam. Perhaps throw a few list
> comprehensions in there for fairness ;-)
>
> You should really be laying out your list like so:
>
> ​(define (largest-two-square-sum x y z) (if (= x (larger x y))
> (sum-of-squares x (larger y z)) (sum-of-squares y (larger x z)) ))
> (define (larger x y) (if (> x y) x y))
> (define (sum-of-squares x y) (+ (square x) (square y)))
> (define (square x) (* x x) )
>
> Jokes aside, the above looks like a bunch of equations from high school
> algebra.  You can model the execution of the code with a process of
> recursively evaluating the inner most scopes and substituting the results.
> You get a sense that the code executes by continually collapsing in on
> itself, becoming progressively more simple. Its kinda Zen. That model works
> really well with the Virtual Machine that I'm continually running in my
> head while I cut code. I find it quite meditative and satisfying.
>

For what it's worth, a number of languages in that area - functional
languages, generally speaking - have adopted a postfix notation
approach that results in far fewer brackets (but they end up a lot
like Forth, which some people don't like). Currently, the most
practical is probably Factor, with Joy (developed here in Melbourne!)
one of the earliest ones. I even mocked up a toy one of my own,
Furphy, to investigate concepts; that only has curly brackets for data
structuring, round brackets as syntactic sugar for comments, quotation
marks as syntactic sugar for text, and square brackets as syntactic
sugar for code encapsulation (the syntactic sugar ones aren't actually
necessary, just convenient). The imperative language Euphoria drew on
functional language concepts for its data structuring, and might also
be worth a look. All these are googleable.

However, every single one of these faces those same political problems
of acceptance, and many don't have fully optimised implementations
either. Perhaps the way to go is to research the language features you
want and then implement them in what you're allowed, with as much help
at the source level as you can get from macros and preprocessors
etc.Many years ago, I did just that with a project that was commanded
to be in IBM 360 assembler and Cobol even though it really needed a
decent high level language (and could never have been the labour
saving utility the PHBs wanted anyway, as it took more work to
install); the best way out I could find was to hide a Forth
implementation inside those. PML.