What kind are you after? There's sort of two: 1. The Philosophical OOP, brought to us by Alan Kay's mind, which probably has to be experienced through a language with sufficient OO-ness. It's always the ship on the horizon.

2. Working OOP, which you can learn in an afternoon from a handful of blog posts and/or library examples.

Or maybe it will invite them to try it out themselves?

I think the 'which is clearer' thing is up to personal choice and experience. And personally, often when I'm programming in one not-Lisp, I'm often bitten by things which would have been explicit in Lisp, and the other way around - sometimes I really wish that different things looked different, as in Perl.

You're at least not alone.

I used Clojure for a while and we didn't get along despite my attraction to the language, and the hype, I guess. Clojure makes a lot of trade offs to run how it does and where it does and those choices don't necessarily add up to the experience I, or others who seem to crop up here, prefer.

While I haven't tried Kotlin, I'm aware of it and know that it isn't all that different from Scala, which is a bit more my style.

Only if you would feel bad that the sites you visit with your ad blocker enabled all died because they didn't get enough funding.

I think it's easy to misinterpret any of the "Unix philosophies". It's Ye Olde "MIT vs New Jersey" again, and Unix is relentlessly straight out of NJ. Simplicity in the "NJ" sense isn't what you'd expect if you're of the "MIT" mindset.

That's a good point. Makes me think again of "slow devices" and interrupts leading to EINTR or partial reads/writes. In my eyes a beautifully pragmatic solution to a real world problem, and yet at some point SA_RESTART was devised.

> I always thought that this article read more like "How to become Eric S. Raymond".

That seems like quite the coincidence given that Eric S. Raymond is the author of the article itself. Maybe there's something to that.

> For instance, he gives the monoculture that all hackers speak English

No. He doesn't give anything. He suggests that learning English is useful because the internet and hacker culture are dominated by it.

> But this essay is not that.

The scope of the document is clearly stated under the "Why This Document?" header.

I'm always interested in the suckless projects. I like emacs and vim, too, but it's interesting to see projects made which can just grab the fork, a sharp knife, and a good pan and make do instead of necessarily including the kitchen sink, if I may get the analogies out.

Also, no tests? Phew!

Slackware might be something to look into. While everything you might want isn't going to be a binary, there's some pretty good third party sources that regularly package things up for each release and the recommended full install is quite complete.

I used it as a desktop for a while and it was as rock solid as any good distribution can be.

The value in FizzBuzz is the iteration process.

What's the first step? Well, you probably make a stream of numbers. And then a set of if blocks to test and return strings. Why not keep going?

What happens if you want more fizz buzz strings? Does the giant if-or statement seem a little unwieldy? Okay, pull the rules out and see if that's better. Is it easier to test now that it's a function and not a little stateful object? Do you want your fizzbuzz function to concatenate the strings or use explicit replacement? Can you make a switch for that? And so on.

That stuff only scratches the surface. I'm sure there's some brain burning fizz-buzz interviewers out there. It really puts you on the spot to deal with a stateful program.

One thing that seems really weird to me is this: given the first set of rules, why does almost everyone write the program that is the least extensible? Is it the way the question is phrased or scar tissue from imperative programming?

YAGNI.

You shouldn't find it odd.

The course is about teaching interesting paradigms and how they can be used to solve problems, not teaching the easiest thing to beginners.

The why not procedural/imperative answer /might/ be: we already know how to do that. That stuff is everywhere. Why not take a little time to learn something different that may in fact have some real benefits?