Re: [tlug] "Go Considered Harmful"

["Curt J. Sampson" <cjs@example.com>]

On 2020-09-03 12:07 +0900 (Thu), Stephen J. Turnbull wrote:

> One of those famous programming theorist types said something along the
> lines of "show me your algorithms and I remain mystified, but show me
> your data structures and the algorithms write themselves."  I wouldn't go
> that far....

Yeah, I wouldn't go that far either, but it's certainly often true that
data structures (if well designed and described) are significantly better
at communicating what's going on than algorithms, and (as I mentioned) I
have had cases where once I got the types right parts of the algorithm
almost did write themselves.

> I'm not sure I'd call Haskell's typing system "strong typing" or "strict
> typing" though -- they seem like awfully weak statements about what it
> does for you (if you choose to take advantage of it, of course).

Yeah, I was struggling with the terminology earlier, too, and I went with
"more powerful" and "less powerful." Most languages, including ones such as
Python and Ruby, have what I would call strong/strict typing: you can't
(without a bunch of work digging into the system internals) use an object
outside the ways defined for its type without throwing an exception. (E.g.,
there's no way to have the integer `+` operation applied to two strings.)

So where things really differ is:
- Are variables (i.e., names to which you bind values) typed or untyped?
- Is type checking done at compile time or run time?
- How powerful is the type language?

> Extending typing to higher-order functions is a difference
> of kind rather than of strength.

I think here you mean not that higher-order functions can be assigned a
type (C can do that), but that the _type language_ also has variables for
types and functions taking and returning types, just as the _data language_
or _runtime language_ (or whatever is a good name for that) has variables
for data and functions taking and returning data.

I'm not totally sure that that's a qualitative difference rather than
a quantitative difference in expressive power, but it probably doesn't
matter because if it's quantitative, it's sufficiently large to feel
qualitative anyway.

And yeah, people who say they don't need that sound to me like BASIC
programmers who say they don't need functions and don't see why anybody
would bother with them.

>  >> The rule of thumb in Clojure is data structures over functions, and
>  >> functions over macros.
> ...
>  > ISTR Paul Graham saying something along the lines that he rarely had
>  > more than a handful of macros even in a large program.
> 
> defun is a macro ....  (I'm not a big fan of Paul Graham.)

Well, I think that Paul Graham meant what I meant and what I think the rule
of thumb means: when _writing new code_, one generally should prefer data
structures over functions, and functions over macros. Once a macro is there
and well-debugged, the forces that make the rule of thumb useful aren't in
play (at least not to anywhere near the same degree).

> I haven't seen all that many macros that do more than take advantage of
> deferred evaluation, except those that implement control structures, and
> there are very few of them even in Emacs.

Oh, come to think of it, I wonder what fraction of macros are for new
control structures? That generally isn't an issue in Haskell since when you
can easily create and use monads you can embed arbitrary control structures
in those. (That's probably the primary use of monads.)

>  > Yeah, Lisp does have certain awesome things. It looks to me like
>  > the macro system in Lisp
> 
> s/Lisp/Scheme/, please (even though I don't use Scheme much, hygenic
> macros rule).

Well, I was speaking of Lisps in general. I do agree that Scheme's macro
system is better than that of the Common Lisp family (as is much else about
Scheme).

> as Bugs Bunny would say.  Lisp is a great language, but it's hard to
> beat Python for teaching Chinese students who majored in Japanese
> translation in college how to code.

Well, I think that much of the "difficulty" in teaching Lisp, functional
programming in general, or even simple things such as recursion is due to
having to overcome existing experience on the student's part and the
general environment that considers things like recursion to be "harder"
than while/for/etc.

I've met at least some programmers with no FP or comp. sci. background who
eventually come around and agree that recursion is indeed simpler (and
simpler to think about) than while/for/etc., after perhaps a half hour of
patient explanation and discussion.

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch