HN user
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.
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?
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?
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.
1: http://www.brandonbloom.name/blog/2013/06/24/code-density/
This is just fuel in search of fire.
"OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it."
Close, but no pants, Buckwheat!
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
Haskell.
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.
Further, CSPI's history is more than a little sketchy: https://en.wikipedia.org/wiki/CSPI
Mark Sisson has a lot of good material if you're interested in saturated fats and other food info. This article is even from 2009: http://www.marksdailyapple.com/saturated-fat-healthy/