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.
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.
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.
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.
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.
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?
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?
Does anyone else feel like the only reason to choose systemd is the systemd-journal? That thing is just amazing. The amount of leverage provided by not just appending to a log file somewhere will really get the juices moving in anyone who ever had to write some ad-hoc parser to do the same thing poorly.
If anyone hasn't tried out systemd or journalctl yet, I suggest running a copy of Arch Linux in a virtual machine.
"Part of it is due to the very strict Python standard of coding."
I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.
The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.
You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.
You might want to read this paper by Matthias Felleisen,
Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi who provide interesting points about SICP as well as HTDP as an introductory course in programming:
http://www.ccs.neu.edu/racket/pubs/jfp2004-fffk.pdf
Having learned perl, ruby and python (these are all incredibly similar), and then Clojure, I've found that I really like the functional paradigm. It helped drag my attention back to thinking about data structures and functions to act on that data a lot more than a ton of bad OOP examples ever have. I'm actually excited to program now instead of feeling like, "Okay, this mess of classes I'm making is going to pay off some day..."
One negative/positive is that I now kind of recoil in distaste when I find OOP-y code that's seemingly done for the sake of jamming code into a class instead of using generic functions and data types. It's funny that there's a large swath of not so useful monad tutorials, because there's an absolute mountain of examples of classes/objects that don't make any sense at all. I didn't mean to make a tiny rant on OOP. Sorry about that.
As someone who has been using a lot of dynamic languages, I'm really interested to find out how a static type system can help me program better software.
It would seem like they got people to believe that The End Was Nigh and that they should commit suicide to avoid said End (Yeah, hold on to your logic there). If he truly believed that it was the end, why would he need to stay behind to tend to other things?
That seems like picking nits, though - these people clearly weren't the best and brightest in the first place.
> which never had a decent package manager as far as I know
This is false. The package management tools work fine, they're just different from some others. Slackware users find the design decisions in the provided tools to be a strength, but opinions may differ.
That article has so many holes in it, I don't know where to start, short of going back in time and writing it for them and then setting it on fire.
This really says it all, "An 8-ounce bag of Reese's Pieces is just a cup of candy. But with 1,160 calories and 35 grams of saturated fat, it's like eating a 16-ounce T-bone steak plus a buttered baked potato." These two things have the same amount of calories and saturated fat, but one of them is obviously real food and the other, well, you guess.
2. Working OOP, which you can learn in an afternoon from a handful of blog posts and/or library examples.