Comment by jowiar | Hacker News Reader

Comment by jowiar | Hacker News Reader

Parent Full thread

It's disingenuous to say that this is included in a "bachelor's degree in STEM" -- it's part of a specific course of study.

Part of the reason this issue pisses me off so much is that I have a degree from one of the top CS programs in the world. I was definitely more of a theory than a systems person. And yet it still feels like a pile of unnecessary ego-stroking gibberish.

I feel comfortable saying most people who make software are less-experienced in this area than I am. When I run into this, I can at least say: "This is bullshit", and not feel the imposter syndrome of "It's just me -- I'm not smart enough for this" that I imagine most people feel.

Beyond that, functional programming is, by and large, easier than imperative programming. I love writing Scala -- It's honest about side effects, honest about concurrency, and has one of the better type checkers around. And I'm sick of seeing people try to "fence off the riffraff" by raising the barrier of entry to the Scala community.

  Beyond that, functional programming is, by and large, easier than imperative programming.

You say this but dislike even a bit of abstract algebra? I see a conflict here; anyone that likes FP, moreso, typed FP, should be familiar with simple concepts like monoids, functors, and monads. Honestly, I don't understand how someone can write in a functional language and not know these concepts.... they're literally Haskell 101. That doesn't even scratch the surface of what FP can do...

Nothing that jowiar wrote suggested to me that he or she dislikes abstract algebra. I think their point is orthogonal to personal preferences.

Hmmm in hindsight you're probably right. Though he does refer to libraries using abstract algebra as having "meaningless terms," which doesn't really sound like a positive opinion about the subject. It's important to have the correct terms, and watering them down just creates ambiguity. If software abstractions stem directly from math, there's no reason to hide the fact. But, like you said, it seems like his point is that using abstract math in libraries raises the barrier of entry for new developers and that they shouldn't need to learn abstract math to be able to be productive, not that he personally dislikes the topic.

It's definitely is possible to go overboard with operators, making a codebase very confusing. Case in point: the lens library. Though those are optional, and the best practice is to just use the actual word functions.

If they're just terms, then it doesn't matter that they're terms from abstract math. However, this way there's the benefit that it's super easy to find resources, since you have all of the mathematical literature.

To me, functional programming's advantage comes from avoiding reasoning about state. Everything else is gravy.

Beyond that, it's very easy to go down a rabbit hole of terminology. Javascript programmers write functors all the time, but I don't know if I've ever seen the word "functor" written in a JS context by anyone other than raganwald. They're just functions, and the fact that they return functions is damn useful.

Yup I've never seen functors mentioned in anything JS-related. I bet there's more Haskellers writing Scala than JavaScript though.

Being pedantic: functors don't return functions, functors let you map over structures.

"Honestly, I don't understand how someone can write in a functional language and not know these concepts"

I totally support @jowiar on this. I have about 4 years of experience of writing in Scala and I don't think there was even one day when I needed to know monoids, functors and monads :) I have a blurry idea what monads are about but, honestly, I could have done without it.

In my work, when I make code reviews, I emphasize simplicity and readability. And I wouldn't want to see anyone of my coworkers using scalaz or a similar library. It's not true that if you don't like it you don't have to use it. If in a team of developers one person starts to use them, it's eventually going to propagate: After some time someone will have to write code accessing the code written with scalaz, then another person will have write something using that, and so on, and so on. And then it is enough that an experienced developer goes to another project and a new one takes her place (and this is not a rare situation - it's just something that happens every few months). And then the new developer looks at the code and is unable to say what is happening there without learning what all those cryptic operators and weird classes names are about.

The strength of a programming language lies not in how few times you have to push keyboard keys in order to write an application. It lies in how practical it is for a team to collaborate using it. If a team decides that the language is hard to read and hard to learn, they will search for another one. If enough teams decide that, the language dies.

I didn't say it's included, I'm saying anyone capable of a bachelor's degree in STEM is capable of picking it up. And if you think you were a "theory" person, but don't know the basics of abstract algebra, then you have an incredibly naive idea of what theoretical computer science entails. Hint: there's a lot of abstract algebra.

Reply on news.ycombinator.com