On Thu, Mar 16, 2017 at 6:22 PM, Ben Franksen <ben.franksen@online.de> wrote:

Am 11.03.2017 um 01:42 schrieb JK:

*Yes.* I've been teaching not just "data processing" - after all almost
everything we program is "data processing", no?... but such concrete
stuff as physics simulation (diff. eqs.), some other numerics
(asymptotic expansions, etc.) signal processing (including sound
generation), and I liked to present several examples in a *dataflow
style* with plenty of co-recursive contraptions. Haskell lazy lists were
natural, concise, and easy to manipulate. We enjoyed it, wrong or not.
Jerzy, i have always liked your style and i am very glad you wrote this response, the attitude of which i find refreshingly unconventional. (Note i am not free of the sin of, sometimes hastily, condemning what i find distasteful.)

I'd just like to add:

- if it gets the job done, it's not wrong.

- it's my opinion that programs are best written for clarity; the *compiler* should be optimizing, not the programmer, whenever possible. Yes, there are exceptions. But how many programs really *need* something like Duff's Device? Save the cleverness for those. This doesn't necessarily justify using an inherently wrong data structure (e.g. alist for a large keyed map), but if the flow is best understood via lists, that counts for more. (Consider that it may be *your* sanity that will be saved a year down the road when you have to revise it.)

brandon s allbery kf8nh sine nomine associates

allbery.b@gmail.com ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net