10 ms·
From a practical perspective, one should probably learn procedural/OOP first, it's the de-facto industry standard, and thus better for one's early career. Wheth
by tabtab 3y ago
From a practical perspective, one should probably learn procedural/OOP first, it's the de-facto industry standard, and thus better for one's early career. Whether functional is "better" in the longer term, I won't get into here, only to say I have skepticism.
- mcdonje 3y agoThere are jobs for pretty much all established technologies. And if there aren't currently, there could be in the future. I primarily work on procedural & OO projects, but I disagree with your position. I've seen job postings for all sorts of things; Things that interest me, things that don't, things that are hot, things that are old hat, things that have an air of prestige, things that look like a coffee stain on your resume...
- marginalia_nu 3y agoWell if you're learning computer science, what does it matter what is industry standard? Computer science doesn't really have very much to do with the programming industry.
- whateverman23 3y agoBecause when we're talking about CS education, it's usually in preparation for a software engineering career. Whether that should be the case is another story, but that's the reality.
- flaminHotSpeedo 3y agoI think the reality is that computer science is only tangentially useful preparations for a career as a software engineer. There's some courses that are inarguably fundamental, some which "separate the good from the bad," but there's also many which are simply not practical, besides the fact that they teach you how to learn. It's a flawed analogy but I'd liken it to mechanics vs automotive/manufacturing engineers. There's a good bit of overlap, but lots that isn't shared. And software engineering as an industry doesn't always do a good job differentiating between the two
- aiscapehumanity 3y agoBurn computer science. Like unironically it's so grown into an awful patchwork of dogmas. It sells itself as a software engineers degree, but if it's not really then it's effectively an incidental scam.
- still_grokking 3y agoImho it's exactly the other way around: Imperative programming is an implementation detail and nothing you should care at first. If you want to learn proper abstractions you should start with something FP-ish. This also avoids to get your head messed up with the imperative kind of "reasoning". Besides this: FP is much simpler to learn, so much better suited for newcomers. One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math. On the other hand imperative thinking makes absolutely no sense when looked at it intuitively. It looks more like complete nonsense: `x = x + 1` isn't true for any `x`… So imperative programming is at it's core contrary to logical reasoning. I would try to avoid it as long as possible.
- Aerroon 3y ago>One just needs to follow up on what every child learns since first grade in school, namely the substitution model found in math. Considering how much people struggle with learning math I'm not sure that this is a good way of going about things. I don't think functional programming classes have much more success either.
- nequo 3y agoCreating connections in the curriculum between math and other subjects is a good way to help students better understand both math and other subjects. I don’t have literature to cite on this though.
- OkayPhysicist 3y agoMy position is that for university students, you should start with FP. You have them for 4 years anyway, they'll have plenty of time to learn imperative programming. But FP both distills essential CS concepts, putting them front-and-center, and it puts your freshman on a more even playing field between those with existing programming experience and those who don't.
- Xeamek 3y agoIf by FP we mean Monads recurrence and no single drop of state, then yes. If by FP we mean "Let's write our functions as pure (and leave IO as a magic box for time being)", then this is undeniably more straightforward then getting head deep into side effects that procedures can create, not to mention the entangled web of dependencies in OOP, and other messy stuff it promotes
- akavi 3y ago"De-facto industry standard" is heavily a function of what slice of the industry you're looking at. It feels like the dominant style of programming in the companies I've worked at (YC startups and FAANG) is "functionalish" procedural, with a sprinkling of objects-qua-objects to interface with libraries and frameworks (Eg, react class components or rails ActiveRecord models). Note I'm distinguishing between objects-qua-objects (data coupled tightly to methods that operate on them) from structs-implemented-via-objects (eg, ruby's `Struct` or Java "beans") or modules-implemented-via-objects (like a class with a bunch of static methods used as a namespace). I only see the first one as "object-oriented".