This article/paper/draft was a bit of a strange read. Just looking at Experiment 1: it seems like he is taking weird / baseline-acceptable code for fizzbuzz (perhaps warranting a PR to frege) and refactoring to make it more flexible/production-friendly (overkill for fizzbuzz). He then argues that the latter isn’t clever? Honestly, it seems too clever for fizzbuzz! If I asked fizzbuzz in an interview and the candidate told me the final solution, I'd think it was very clever and very overkill. I guess I don’t understand what he means by clever!
I like that he made an attempt to make this language-agnostic, the final example, but now he's introducing the idea of "elegance," (missing a definition) and kind of saying that "cleverness == elegance == overfitting?" I think the problem here is that he's _too_ generic (might I say, he's trying to be too clever : P) and pulls in a third field to make his abstract "cleverness" case. But, from my understanding, I'm under the assumption that cross-validate is a given for models: overfitting is for chumps and students. I'd give that a "to be improved" for draft 1.1.
---
Overall, from the recap:
> “Clever” code tends to exploit explicit and implicit symmetries in the problem structure, building highly-symmetrical solutions by exploiting highly-symmetrical library functions / types.
and from the abstract:
> Unfortunately, people tend to assume that the style of such (supposedly) clever code is representative of “good” functional programming.
The main issue here is that clearly the first part is correct and makes for fragile code (given context), but he’s completely opinion based on the latter. What he needs to do is find “production-level code" or “education-level practices” that are handed down to new FP developers and taken as “truths." After reviewing the citations, I think that his points on [6] and [7] are weak: he needs to show more than just comments and one-offs, and needs to hammer in the "why this is bad" more. Instead, it feels like he's just trying to show his contempt for haskell. I'm also thinking that, if he wasn't just trying to run haskell through a ringer, you'd think he'd use other functional languages / language-features (frege is designed as "a Haskell for the JVM").
His opening line of 'there is a deluge of “clever” code constantly pushed down from gurus to hipsters to innocent readers' also primes me to think that this is more of a cathartic article than a useful one.
I'd love to agree with him, say that "stupid code, everywhere" is a problem in educating new devs for pure-functional languages, then spider the internet, comment/fix all these code examples, and finally make all my friends haskell developers : P (disclaimer: I'm just an enthusiast). However, I remain unconvinced — I think the problems in haskell education is elsewhere. Perhaps I have simply been lucky in finding sane, good resources, and all the production code I study is uncommonly blessed. Looking forward a 2.0 so that I can convert all my friends.
(I redacted some more thoughts since this is my first real post to HN; be nice!).
- The job is currently loosely defined — we have projects that are hitting higher scale and others that are much smaller. Various jobs have different needs.
- We tend to have a couple of major projects and a few minor projects moving at once (some of our projects start as small personal explorations), but one project usually hits scale once a year.
- Every project has its own model, some rely on internal funding, some on grants, some on private partnerships.
Hope this answered your questions!
If you have more please write to us here: [email protected]
Personal interpretation here, but I believe it's because when you structure data too early into the program's process you wind up constricting yourself too tightly.
An easy example would be when you have sections of your program hardcoded. Alternatively, when your code is too generic - you can simply lock it down when needed.
