[HN Gopher] Mostly adequate guide to FP (in JavaScript)
___________________________________________________________________
Mostly adequate guide to FP (in JavaScript)
Author : JNRowe
Score : 52 points
Date : 2023-03-21 20:55 UTC (2 hours ago)
(HTM) web link (mostly-adequate.gitbook.io)
(TXT) w3m dump (mostly-adequate.gitbook.io)
| Osiris wrote:
| Every time I read articles about functional programming, I feel
| like I'm being talked down to. There is always an air of
| condescension, which, honestly, makes the content hard to get
| through. This article uses a lot of this type of language calling
| one way of doing something "insane". He says things like "dirty
| nappy" and "or just get rid of it".
|
| If functional programming is so great, it should be able to stand
| on its own merits without the constant insults thrown at other
| programming paradigms.
|
| I lean more towards FP than OOP but there are times when each
| paradigm makes sense in a specific situation (especially because
| we rely on a lot of third party code we can't control).
|
| > Who on earth would craft such a ghastly abomination?
|
| > It may come as a surprise to hear that we can write full,
| everyday applications along the lines of the functional analog
| above.
|
| > It is obnoxiously verbose and, as it happens, bad practice
|
| > I avoid using this like a dirty nappy. There's really no need
| when writing functional code.
|
| > If you are the micro-optimization sort, please close this book.
| If you cannot get your money back, perhaps you can exchange it
| for something more fiddly.
|
| To be fair, the later chapters are much more focused solely on FP
| without the disparaging comments toward OOP.
| Osiris wrote:
| Here are some of my favorite quotes from this article:
|
| > Who on earth would craft such a ghastly abomination?
|
| > It may come as a surprise to hear that we can write full,
| everyday applications along the lines of the functional analog
| above.
|
| > It is obnoxiously verbose and, as it happens, bad practice
|
| > I avoid using this like a dirty nappy. There's really no need
| when writing functional code.
|
| > If you are the micro-optimization sort, please close this
| book. If you cannot get your money back, perhaps you can
| exchange it for something more fiddly.
|
| To be fair, the later chapters are much more focused solely on
| FP without the disparaging comments toward OOP.
| hising wrote:
| Using abbrevations for something that is not common knowledge is
| a way to shut out people from discussion IMO - change my mind.
| [deleted]
| mcdonje wrote:
| I agree in principle, but I'd figure most people on HN would
| know what FP and OOP are.
| hising wrote:
| Maybe, I have 20+ years of work experience as a software
| engineer and love functional programming, but nothing
| triggered my brain when seeing "FP" in the title, may of
| course saying more about me than the community. I just dont
| like when people use abbrevations as it is common knowledge,
| more junior peers may feel it is common knowledge, why not
| just being a bit more expressive?
| serial_dev wrote:
| Who is this IMO?
| user3939382 wrote:
| I wish the standard language in the browser was statically typed,
| immutable data, and purely functional. Not what we have, which is
| a language that is not only OO, but a crazy version of it, that
| "can" also be used quasi-functionally.
|
| There's a lot more to developing large projects than your own
| code. What about the ecosystem? What about everyone else's code?
| JS IMHO is just a complete mess. That's not at all to belittle
| the size of the problems it is tasked with solving, which are
| hard and complex. The difficulty is precisely why the right tool
| for the job is something that really insists on some level of
| correctness, in the vein of what rust tries to do at the systems
| level.
|
| This is all IMHO and there's a lot of room for different opinions
| here, but I'm guessing we have a consensus, even among JS's
| biggest advocates, that it can't be described as "insisting on
| correctness".
|
| Unfortunately the more relevant follow-up question might be: okay
| it's the wrong tool for the job, so what? It's what we have.
| eddsh1994 wrote:
| Can it really be called the wrong tool when so many huge
| businesses and essentially the entire globe are powered by it?
| It's certainly worked imo
| OkayPhysicist wrote:
| I'd bet good money you could go back in time and swap out JS
| with just about any relatively high-level language (maybe the
| original Scheme plan, maybe Java, literally anything with
| managed memory) and that language would enjoy JavaScript's
| popularity today.
|
| JavaScript's ubiquity has everything to do with its monopoly
| in the browser, and nothing to do with any specific features
| of the language.
| hombre_fatal wrote:
| That was once true.
|
| But Javascript has grown into a language that makes some
| solid and unique trade-offs including its simple single-
| threaded concurrency, modern language features, async-
| everything, first-class Promise, and Typescript.
|
| "Javascript sucks and people only use it because they have
| to" is both wrong and boring. We, as a community, have to
| stop trotting out this tired comment any time a submission
| has the word Javascript in it.
| OkayPhysicist wrote:
| I don't think JavaScript sucks. But it certainly did suck
| when in it was first introduced, and it only got better
| because of the "I have to use it" -> "I'll fix the worst
| mistakes" -> "still kinda sucks" -> repeat loop that was
| enforced by its monopoly on the browser space. Any
| language in its situation would have been refined at
| least to the level of mediocrity we enjoy in JavaScript
| today.
|
| If you look at the post I replied to, I was countering
| the idea that "JavaScript must be good because lots of
| people use it". JavaScript is popular today because it
| was popular yesterday, and the roots of that chain is
| JavaScript was popular in late 90's because it was your
| only real choice.
|
| I've used actually bad languages professionally.
| JavaScript today is merely mediocre, thanks to nearly 30
| years of fixing. But it's still held back by its roots of
| being kinda awful. There are unambiguously better choices
| for non-browser codebases, unless "whatever is popular"
| is a primary driver.
| mixedCase wrote:
| TypeScript is not a feature of JavaScript, and the
| ability to have single-threaded IO event loops is far,
| far, far from something modern, unique or remarkable
| about a language, the fact that it's limited to single-
| threads actually makes it something you really do not
| want to bring up as a "pro" but rather as "it's something
| you'll have to keep in mind".
| hombre_fatal wrote:
| Typescript is certainly a feature of the Javascript
| ecosystem. Typescript's success and maturity easily puts
| it ahead of other dynamically-typed languages that tried
| to bolt on static typing support. Not including TS with
| JS just seems like a pointless "well actually" quibble.
|
| Single-threaded + async-everything is a unique and
| powerful feature of Javascript. You might not like it
| every time, but it's useful most of the time. Most other
| languages make it easy to write single-threaded but
| blocking code where you need to reach for an extra
| solution to write async code, and not everyone needs to
| even use the same solution, and it doesn't necessarily
| work with the default blocking ecosystem.
|
| We take that for granted in Javascript.
|
| Once again, this is a very tired thread. Sometimes you
| just have to admit there are trade-offs and that you
| aren't going to have a taste for every decision on every
| trade-off every time. And that's okay.
|
| Nobody in this thread is even interacting with TFA.
| actionfromafar wrote:
| It's a feature which follows from how web browsers work.
|
| I agree with above comments that you could have taken any
| language. But you have a point, making async mandatory is
| a powerful thing.
|
| This could have been done to any language tho, Java, TCL,
| Scheme, whatever.
| adamnemecek wrote:
| Might be despite of it.
| tikhonj wrote:
| There's a pretty big gap between "this tool is so bad it's
| impossible to use" and "this tool is quite bad but determined
| people can still make it work"--my experience is that the
| latter is totally sufficient for a tool to go mainstream, but
| it can still be fair to call it the _wrong_ tool :P
| tshaddox wrote:
| Can any situation that exists in the world be bad? Yes,
| indeed. If anything, the ubiquity of JavaScript makes its
| shortcomings _a worse problem_ than if JavaScript weren 't so
| widespread.
| sodapopcan wrote:
| "Essentially the entire globe" is way off. In the web world,
| yes, and some niche people doing stuff with JS because they
| can, maybe. I don't think you find much, if any, of it in
| cars, planes, telecom, robotics and other areas of computing.
| Correct me if I'm wrong, though.
|
| And just because something is ubiquitous doesn't mean there
| doesn't exist anything better.
| asddubs wrote:
| I think its functional parts are some of its best qualities.
| Even before we got let and const, function scope was a really
| nice treat that many many other languages from around the same
| time got wrong(er)
|
| what I really detest about javascript is its inability to say
| no to the programmer (most dominantly typing woes), and how
| incredibly late it got some super basic features for code
| organization. private class members (in a way that isn't
| syntactically insane) got added to the language figuratively
| two days ago. what the hell?
| adamrezich wrote:
| > This is all IMHO and there's a lot of room for different
| opinions here, but I'm guessing we have a consensus, even among
| JS's biggest advocates, that it can't be described as
| "insisting on correctness".
|
| this was pretty much the result of the XHTML debacle as well,
| and I know the reasons why that went down the way it did, but
| it's kind of weird to me that We Just Can't Have Enforced
| Correctness In The Browser.
| markeibes wrote:
| Please use PureScript with us and lead a happy life
| quaunaut wrote:
| PureScript has what I'd call some stark issues.
|
| 1. Its maintenance/activity appear sporadic at best. 2. It's
| inscrutable. Whenever I've had issues, I don't have any idea
| even how to approach solving them. Half the time they
| reference in-depth mathematical terms that just are not
| relevant to anyone who isn't implementing the language 95% of
| the time. 3. The tooling often just... doesn't work. I'll go
| to run a commend given in the official tutorial, and it fails
| in a way that is just beyond me, as an experienced engineer.
|
| TBH, I'd really love to use it. I've been finding myself
| using `fp-ts` on many of my projects for just such a reason,
| and have even set up `unplugin-auto-import` to automatically
| detect and import those modules, so it's like I have more in
| my stdlib. I've even thought of making a _true_ language out
| of these primitives.
| srcreigh wrote:
| When JS was made, Andreesen wanted to implement Scheme but his
| boss asked him to make it look like Java.
|
| Is it crazy? yeah. But it's not quasi functional.
| aranchelk wrote:
| > Chapter 04: Currying
|
| Allowing a chain of fat arrows and parentheses-free parameters
| was one of the nicer choices they made for ergonomic functional
| programming -- being able to concisely write:
|
| const add = x => y => x + y;
|
| Ends up looking similar to Haskell type signatures.
| somewhereoutth wrote:
| Probably its time somebody wrote something that could be titled
| 'The Unreasonable Effectiveness of JavaScript' - the language has
| of course been wildly successful, if measured in terms of
| adoption at any rate, and it might be good to try to understand
| why (beyond 'it's on every browser, dummy').
|
| Enjoy:
|
| - record and array literals
|
| - arrow syntax for lambdas
|
| - spread operator
|
| - map, reduce, forEach
|
| - string template literals
|
| - default values with ||
|
| - single thread memory model
|
| - all the pretty colours
|
| Avoid:
|
| - Formal OO constructs, i.e. 'class' and whatever goes on inside
| it. They feel out of place, and e.g. the this.function() syntax
| is clanky. Special hate reserved for those magic proxy getters -
| breaks the simple record model.
|
| - Formal typing, i.e. Typescript. Becomes unnecessarily verbose
| and boilerplated, tooling is not quite there, and you almost
| always need to poke holes in the type system to do anything
| interesting anyway.
|
| - Lodash and friends. Not needed now the core language has so
| much out the box.
|
| Where Javascript seems to shine is in being a simple, functional
| language, with concise syntax, and without heavy OO or type
| formalisms.
| sergiomattei wrote:
| You lost me at avoid formal typing and lodash.
|
| At least to me, Lodash is absolutely necessary even in new
| projects -- such a wealth of functionality and most of it isn't
| available OOB in the standard library. It's easily tree
| shakable as well.
|
| As for formal typing, TypeScript was a boon for my
| productivity. Curious about any examples of use where it's been
| inadequate?
| Osiris wrote:
| The lodash functions have built in guards so you can do
| _.map() and not have to care if the argument you pass in is,
| in fact, an Array.
|
| I can't tell you how many times I see "can't call function
| toLowerCase of undefined", etc.
|
| "but Typescript!", doesn't do runtime type checking.
|
| I very much prefer defensive programming. Assume nothing.
| factormeta wrote:
| >I can't tell you how many times I see "can't call function
| toLowerCase of undefined", etc.
|
| Think that should be addressed by optional chaining now.
| somewhereoutth wrote:
| Perhaps avoid lodash _if possible_ , i.e. prefer the new
| built-ins. Otherwise it becomes _yet another_ way of doing a
| simple thing.
|
| Typescript is another language layer, devs will tend to write
| _even more_ code for a given problem - often not helpful. It
| should be possible to do a lot of static type checking
| without annotations.
| yamtaddle wrote:
| Shit, TypeScript's the first time JavaScript's been _not-
| terrible_. If I squint and tilt my head it sometimes even
| looks _almost good_.
|
| I'm also a fan of "class" since it makes the deeply-embedded-
| but-awful OO system actually usable without twisting into a
| pretzel or engaging in a whole lot of "OMG why, why did you
| do that?".
| zanethomas wrote:
| I'm quite happy with javascript as it is but I understand you
| might prefer other languages.
|
| I haven't had occasion to use wasm but it seems that it provides
| the ability to run most (all?) languages in the browser.
|
| Here, for example, is f# wasm.
|
| https://fsbolero.io/
| user3939382 wrote:
| Your point touches on the hardest part of solving the problem.
| Even if we could all agree that JS needs to be replaced, which
| of course we can't, and we had a perfect ideal replacement that
| we all agreed upon, that already works -- what about the
| ecosystem? All the tutorials, videos, articles helping
| newcomers, all the libraries, linters, IDE integrations, build
| tools, etc.
|
| The only way I can see the problem (assuming someone agrees it
| is) of JS getting solved is if something comes along that's so
| amazing and blows it out of the water so hard that adoption
| explodes and browsers start natively migrating to it, along the
| lines of what we've seen with TypeScript, but instead of a
| bandaid a full replacement.
| zanethomas wrote:
| I would be very unhappy with a suggestion to replace
| javascript. I like that I can mix functional, object-
| oriented, and procedural type code where each seems to be the
| best fit.
|
| If something else comes along, gains a lot of traction, and
| develops its own ecosystem then javascript could conceivably
| eventually just fade into the background. But that's going to
| take time.
| Bellend wrote:
| todo app has always been the least inspiring demo that has ever
| existed.
|
| Are there any wasm demos (not necessarily source code) to try
| that would blow my mind? Genuinely interested. Maybe I have
| seen dozens and it's not obvious.
| zanethomas wrote:
| I've only briefly looked at wasm and haven't used it at all
| so I can't recommend anything.
| Osiris wrote:
| The big missing FP features in ECMAScript are pattern matching
| and pipe operator.
|
| I know there are proposals but neither seems to be making much
| progress.
|
| I like FP but shoehorning it in with libraries is ugly compared
| to having native syntax.
| AlexITC wrote:
| While it isn't mainstream, I encourage people to look into
| https://scala-js.org, I can't find any more practical language
| where you can take advantages of FP + the js ecosystem.
| layer8 wrote:
| All the *.md links give a 404.
| TurningCanadian wrote:
| Anyone know if Record & Tuple (deeply immutable primitive values)
| is moving ahead or stalled?
|
| https://tc39.es/proposal-record-tuple/tutorial/
| SlimTim10 wrote:
| Nice! This looks great for experienced programmers. I also wrote
| functional programming JavaScript lessons, only mine are meant
| for beginners and don't place an emphasis on comparing FP to
| other paradigms, but rather treating programming in FP from first
| principles as an intuitive approach.
|
| https://intuitivejs.info/
___________________________________________________________________
(page generated 2023-03-21 23:00 UTC)