[HN Gopher] Teach yourself Computer Science functionally
___________________________________________________________________
Teach yourself Computer Science functionally
Author : ggr2342
Score : 136 points
Date : 2023-06-13 16:25 UTC (6 hours ago)
(HTM) web link (functionalcs.github.io)
(TXT) w3m dump (functionalcs.github.io)
| imwillofficial wrote:
| Is there something like this but for traditional CompSci?
|
| Trying to change career tracks
| jcovik wrote:
| https://teachyourselfcs.com/
| CobrastanJorji wrote:
| This looks to me like a pretty traditional stack of Computer
| Science undergrad topics. A similar big list of topic/resources
| that's frequently linked to is:
| https://github.com/ossu/computer-science
|
| Could you describe a bit more about what you're looking for
| when you say "traditional CompSci?"
| _Rabs_ wrote:
| It's a cool write up, but why is this site promoting Triplebyte?
| Lol what?
| ctvo wrote:
| [flagged]
| gavmor wrote:
| Just for kicks, I applied Tufte CSS[0] onto the page using a
| browser extension. Great ROI.
|
| 0. https://edwardtufte.github.io/tufte-css/
| medstrom wrote:
| I don't have a high-res screen (just 1280x800), so to me it's
| one of the most readable pages I've ever seen. Although
| curiously, it also looks great on the iPhone by default (which
| is high-res). I assume you're on some sort of 4K external
| monitor, but I wonder why it would look small there while
| reacting well on the phone?
| zouhair wrote:
| It shows like this[0] on mine (2560x1440).
|
| [0]: https://i.imgur.com/I8bl5Es.png
| medstrom wrote:
| Well, that's ideal. IDK what their issue is.
| ReleaseCandidat wrote:
| It is small on a 'normal' (24") 1920x1080 display. So nothing
| todo with high-res at all.
| kimixa wrote:
| As far as I can see it doesn't override the default font sizes
| at all for the body text.
|
| If that's not legible I see that as a client default problem,
| not an issue with the content.
| ctvo wrote:
| Default != best or even good.
|
| The author sets the width of the content container to 40em,
| for example, to make it so lines of text are wrapped
| appropriately (a single line doesn't contain on average more
| than n words). Is it worth adding some styling around
| typography to make it even more readable? Up to the author.
| Only a suggestion from a single reader, of course.
| Zambyte wrote:
| References to the Atom editor shouls be removed
| serhack_ wrote:
| mh, maybe I'm wrong but it does not touch all of CS, does it?
| System design, distributed systems, game theory ..
| adamwk wrote:
| It seems to be pretty close to my program (UCSD). Distributed
| systems was introduced in operating systems but you had to
| elect for deeper classes. System design wasn't really taught
| unless you mean CPU architectures, which this covers. I've
| never heard of game theory being part of a CS program (I took
| it as an elective)
| pwb25 wrote:
| [flagged]
| tabtab wrote:
| I will agree it's about 30% less code on average, but whether
| it's "team friendly" or "debug friendly" is quite another
| matter. Debates over such often rage for months.
|
| If it's truly superior, then form a company called Functional
| Magic or the like and out-compete OOP rivals and eat their
| lunch. Proof will then be in the pudding, no more talk. (Some
| co's have tried similar without long-term success, at least
| outside of niches, as it does well in finance.)
|
| If FP is say 15% more productive, such a company would
| eventually just outcompete OOers by growing 15% a year. Even 5%
| a year would catch up in roughly a decade. If you truly believe
| in FP's superiority, do it! Unleash the FP Kraken! When you are
| golfing with Warren Buffett & Gates, you can say, "I toldja so,
| fore!..."
| consilient wrote:
| > If FP is say 15% more productive
|
| "more productive" is not a singular metric. What indefinite
| 15% year over year growth in mainstream tech requires is (in
| addition to favorable market conditions) the ability to get
| useful work out of huge numbers of very inexperienced people.
|
| Clearly Scheme, for instance, cannot do this better than
| Java. But this tells you next to nothing about which tool is
| more productive in the hands of a small team of people who
| know what they're doing.
| fulafel wrote:
| I guess if FP'ers didn't think it was better, we wouldn't be
| doing it. It's not like there are lots of people stuck in
| functional programming jobs wishing they could be writing Java.
| nequo wrote:
| "All" FP articles and "always" is probably broader a
| generalization than what you really mean. Can you share
| examples from the linked page that you see as smug?
| medstrom wrote:
| This can also easily be a filter on the part of the reader:
| anything FP is always close to triggering the "smug" concept,
| even if they don't use words that would be read as smug if
| the topic was something else.
|
| Same way some people are quick to read intelligent women as
| "uppity" though they say nothing that would be read as uppity
| if said by someone else.
| butterNaN wrote:
| I don't usually (get to) talk much in our team meetings.
| This one time I suggested we try FP for a new internal
| project - and the backlash I got was quite unexpected.
| Merely the mention made my teammates launch into a dozen
| different assumptions, before I even finished the sentence.
| I was shut down pretty quickly. I was surprised, because
| usually they are at least receptive to hearing out new
| ideas.
|
| I think outside of HN, there's a large chunk of people out
| there who just have this prejudice about FP. I am only
| about 10 years into the software industry and I feel like
| I'm missing some history that is not recorded anywhere, but
| lives as a tribal memory.
| sb057 wrote:
| "Like normal but worse" wouldn't entice much interest, would
| it?
| tabtab wrote:
| 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.
| marginalia_nu wrote:
| Well 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 wrote:
| Because 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.
| OkayPhysicist wrote:
| My 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.
| mcdonje wrote:
| There 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...
| Xeamek wrote:
| If 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
| still_grokking wrote:
| Imho 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 wrote:
| > _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.
| still_grokking wrote:
| > Considering how much people struggle with learning math
| I'm not sure that this is a good way of going about things.
|
| Even more are struggling with programming, no matter the
| paradigm...
|
| > I don't think functional programming classes have much
| more success either.
|
| Objectively they have. I've linked already some evidence in
| the other reply in this thread.
| nequo wrote:
| Creating 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.
| rajamaka wrote:
| Also a good way to turn off students who have no interest
| in math from subjects they have interest in. I would have
| never become a SWE if I actually attempted a CS degree.
| whateverman23 wrote:
| > FP is much simpler to learn, so much better suited for
| newcomers.
|
| I can't see how this is the case. Assignment is just one tiny
| piece of learning how to program, and is almost never a pain
| point after a small amount of instruction.
|
| Imperative programming is easier to learn because you simply
| write out the steps that you want the computer to take, and
| the computer takes them. FP requires much much more abstract
| thinking that is often difficult for newcomers to grasp.
|
| The main exception that I see is when someone who has a very
| deep mathematics education. Graduate level math folks seem to
| more easily grasp FP concepts from my experience. Almost
| everyone else seems to grasp imperative programming easier.
| weatherlight wrote:
| You don't need to know more than high school math to learn
| Functional Programming. This myth really needs to stop.
|
| All functional programing languages, have ergonomics in
| their syntax and semantics. around referential transparency
| and immutable data structures, there's nothing in there
| about Monads or Functors or Hindley-Milner type systems.
|
| Languages like Haskell do benefit from having that kind of
| experience, however, langs like, OCaml, Erlang, Elixir,
| Gleam, Racket, Clojure, Standard ML.... and the list goes
| on, doesn't require that kind of education.
|
| (Antidotally, I find FP langs much easier to reason about
| and I have a background in the humanities. I just don't buy
| the advanced math argument.)
| still_grokking wrote:
| > Assignment is just one tiny piece of learning how to
| program, and is almost never a pain point after a small
| amount of instruction.
|
| The issue isn't assignment. You have also assignment even
| in the most pure FP languages.
|
| The issue is mutation!
|
| > Imperative programming is easier to learn because you
| simply write out the steps that you want the computer to
| take, and the computer takes them.
|
| No, that's not easy given every step can change the whole
| world around and you need to _track all the changes in your
| head_.
|
| That becomes very hard to follow even after only a few
| steps. (That's why imperative programs are always so
| buggy.)
|
| FP code, which usually eschews mutation, is much simpler to
| follow as you can look at any "step" _in isolation_. No
| hidden "change the world" side-effects everywhere.
|
| > FP requires much much more abstract thinking that is
| often difficult for newcomers to grasp.
|
| No it doesn't. At least as long as you don't go nuts like
| e. g. Haskell.
|
| At the core FP is basically the same trivial concept taught
| to children in elementary school: If you have some
| expression you can mechanically substitute following
| occurrences which the value assigned to that expression.
| That's all.
|
| > The main exception that I see is when someone who has a
| very deep mathematics education.
|
| Like every child that attended math classes for many years.
| In school people are trained for a very long time in
| exactly the way of reasoning you need to write FP code.
|
| On the other hand you need to teach those people imperative
| programming form the ground up, including mayor mental
| shifts around all kinds of concepts they were taught
| previously. Only after this kind of brainwashing people
| start "to get" imperative programing...
|
| > Almost everyone else seems to grasp imperative
| programming easier.
|
| No. Quite the opposite.
|
| https://cseducators.stackexchange.com/questions/342/what-
| mak...
|
| https://stackoverflow.com/questions/778461/should-
| functional...
|
| Just go out and talk to some programming instructors...
| Everybody will tell you the same.
|
| Only people whos brains are already burned by imperative
| programming think it's easier. For everybody else it's the
| opposite. Which is perfectly logical as the FP way of
| thinking is what they practiced for many many years before,
| in math in school.
| _a_a_a_ wrote:
| You claim a lot, you've backed up none of it. This doesn't
| come across like you're a professional programmer.
|
| > `x = x + 1` isn't true for any `x`
|
| Out of interest, if this had been written x := x + 1 as in
| the style of Pascal, would that make imperative programming
| more logical?
| still_grokking wrote:
| No, it wouldn't.
|
| And it's almost tragicomic to see how imperative
| programmers struggle to even see the actual real issue
| presented in this snippet.
| _a_a_a_ wrote:
| OK, how about
|
| x <- x + 1;
|
| (BTW be careful about assuming you're the brightest guy
| in the room, how others "struggle to even see" when you
| do, and with such clarity)
| still_grokking wrote:
| Two out of three replies were talking about the
| assignment even mutation is the (obvious!) real issue.
|
| > OK, how about
|
| > x <- x + 1;
|
| Better.
|
| From such syntax you can at least guess that mutation is
| happening there.
|
| Still nothing you would show a newcomer in a FP-
| programming introduction.
|
| (I'm not sure why your comment got down-voted. I can only
| up-vote it, so I did; to battle stupid down-votes because
| "feels"...)
| akavi wrote:
| "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".
| nathants wrote:
| alternatively, just start building interesting things and follow
| all rabbit holes.
|
| computer science doesn't exist in a vacuum.
| funman7 wrote:
| Maybe it's just me... but I never have been able to immediately
| fluidly intuitively grasp any understanding when someone has
| made "in a vacuum" statements. I just think of vacuuming
| carpet.
| nathants wrote:
| perhaps better verbiage would be in the absence of a concrete
| application currently under construction.
| still_grokking wrote:
| I think you should do both! In lock-step.
|
| You won't learn anything if you don't practice it.
|
| But "learning" computer related stuff without the theory behind
| is also kind of moot. You wouldn't get the full picture this
| way, and you would end up with a lot of "knowledge" that isn't
| more than assumptions. Likely wrong assumptions...
| nathants wrote:
| why not both is a great answer.
|
| for many, a task makes the long grind of study more fun.
|
| a mission and all that.
|
| it also add success criteria to an otherwise ambiguous task.
| generalizations wrote:
| That's implied by the rabbit holes. For me, following the
| rabbit holes meant digging deeper and deeper into the
| underlying theory, but at a pace mediated by my current level
| of understanding.
| still_grokking wrote:
| > That's implied by the rabbit holes.
|
| I guess not for everyone. Frankly.
|
| I know quite some people who do programming for living but
| are more or less avert to any theory behind it. You get
| even called names if you come along with such topics... (I
| think it doesn't need to be said that it's quite difficult
| to deal with those people at times as they're kind of
| ignorant.)
| ackfoobar wrote:
| A lot of people learn best by doing. Some people, especially
| those who are more math-inclined, probably learn best starting
| from the abstract.
| kwant_kiddo wrote:
| I can tell you that math people also learn from the concrete.
| You do not learn math by reading it, but by fighting it.
___________________________________________________________________
(page generated 2023-06-13 23:01 UTC)