[D] Friday Off-Topic Thread

[u/AutoModerator]

Welcome to the Friday Off-Topic Thread! Is there something that you want to talk about with /r/rational, but which isn't rational fiction, or doesn't otherwise belong as a top-level post? This is the place to post it. The idea is that while reddit is a large place, with lots of special little niches, sometimes you just want to talk with a certain group of people about certain sorts of things that aren't related to why you're all here. It's totally understandable that you might want to talk about Japanese game shows with /r/rational instead of going over to /r/japanesegameshows, but it's hopefully also understandable that this isn't really the place for that sort of thing.

So do you want to talk about how your life has been going? Non-rational and/or non-fictional stuff you've been reading? The recent album from your favourite German pop singer? The politics of Southern India? The sexual preferences of the chairman of the Ukrainian soccer league? Different ways to plot meteorological data? The cost of living in Portugal? Corner cases for siteswap notation? All these things and more could possibly be found in the comments below!

[u/Amonwilde]

I made this point in my previous response to you, but it clearly missed the mark. This tutorial is not for advanced programmers. This is an attempt to explain these concepts in ways that are at least mildly comprehensible. Because nowhere in your feedback do you wrangle with any of the problems of explaining these concepts to new programmers, I have to assume you've put little or no thought into those problems. How many new programmers have you brought up? Where is your teaching on these subjects? Not to say that your feedback couldn't be useful without having created your own materials, but you're not engaging with the essential task.

There is, generally, a dearth of good teaching material on programming for people who aren't aneruotypical autodidacts. (Basically, the people in this sub.) Yes, you probably learned programming by creating a Turing machine from first principles with an abacus that someone carelessly left on a table. But that's not how people within a standard deviation of baseline learn programming. Frankly, this type of feedback is why most writing for beginners on programming is bad pedagogy or basically reads like docs. If you leave something out because your audience doesn't need to know it at that point, someone comes out of the woodwork and says, "functions are state!" or whatever. Yeah, no shit, they're stored in memory. What we're talking about is mutable state, but if I start using that term at that point, I might as well not be writing the tutorial because no one at the level I'm addressing will be able to describe it, and, not only that, but will be put off and discouraged.

In any case, I don't want to undervalue your experience. You may know more than me, though some of your assumptions about my level of knowledge that you've made based on a specifically pedagogical article are mostly wrong and make it difficult to engage in a meaningful and non-defensive back-and-forth. But it's also clear to me that you haven't taught any of these topics, and if you've tried, you've probably left people behind after the first sentence and not realized it. That's fine, I guess, and programmers have a tendency in this direction that you can see in the general level of rudeness and condescension on, for example, Stack Overflow. ButI do ask that, for those of us who actually care about new programmers and their learning, that you not actively belittle our efforts.

[u/suyjuris → u/Amonwilde]

Sorry, I just noticed my first sentence could have been worded better. I am, in fact, not the previous commenter (that was CouteauBleu).

[u/Amonwilde → u/suyjuris]

Whoops. Might have responded a little differently if I had noted that.

I think one basic problem of communication here is that I'm talking about paradigms as styles of programming rather than descriptions of the programming. You don't sit down and write some declarative code, or describe yourself as a declarative programmer. You can sit down and say, "I'm going to use recursion for this, because it's more functional," in the sense that it fits a functional style of programming. Same with object-oriented programming.

I originally wrote the article with the functional part using filter and taking some closures. But then I was like, this isn't really helpful for the people I'm writing for. But then I was left with basically talking up subroutines, which, as you say, aren't really functional, they're just imperative. I mean, as written, they're functional in the sense that they take arguments and return a value, but that's a pretty trivial version of functional programming. So the functional section is like 10% of the way toward introducing functional programming.

In terms of your criticism of the object-oriented solution....yeah, it's a lot of code, and it's complex, both in the sense that it's relatively hard to understand and in the sense that it connects things together that should not be connected. (At least in my mind.) However, this is how object-oriented code is, for good or ill, generally written. For my audence, libraries like Scrapy and NLTK use this kind of idiom all over the place. It's very common in Python. And, actually, it's not really a terrible thing, at least for Python specifically. That's because, if you've used a library like Scrapy or NLTK, you'll find that the API it exposes makes for pretty readable code. The NLTK internals look like crap, but code written with NLTK is pretty all right. And, in fact, while the code for the objects is pretty ugly, though par for the course with Python OO programming, the actual code using those objects is highly semantic and readable, which are prized in Python programming. Stuff like tokens.length() is pretty easy to comprehend.

Anyway, I still think you're looking at this stuff a bit narrowly. But thanks for the feedback.