Live data from Hacker News

Why Isn't Functional Programming the Norm? [video]

youtube.com

341–350 of 417 posts

Re: Why Isn't Functional Programming the Norm? [video]

#341
post #335

Earlier quoted context omitted.

Just because you don't see it, doesn't mean it's not happening. - Have you ever heard about how Walmart handles Black Fridays? - Do you even know what's behind Apple's payment system? - You ever used Pandoc, Couchbase, Grammarly, CircleCI, Clubhouse.io, Pandora, Soundcloud, Spotify? - Have you ever asked a question - what is an app like WhatsApp that was sold for $19 Billion runs on? - or How Facebook fights spam, Ci…

I said: it's not _that_ useful. I did not say it's completely useless. Every large (or even small) company has people writing stuff in Perl, Bash, Haskell, Ruby, Rust, VBA, Scala, Lua or what not. I've been that guy, too. More often than not it is a distraction more than anything, and it ultimately ends up being rewritten in C++, Java or Python. I think there are some niches where it helps; OCaml has had some success…

Honestly, do you really think a company with only 35 engineers could build, scale and sell a product like WhatsUp for even a fraction of that amount but using C++, Java or Python? I seriously doubt that.

Look, I've seen both sides and I know this for sure (this isn't a mere opinion, this is a certain fact) - FP allows to build and maintain products using smaller teams.

You don't have to trust my word, do your research, google "companies using Clojure" (or Haskell, OCaml, Erlang, etc). You will see that either those companies are not too big, or the FP teams in large companies not very large. Skeptics often cite this fact, claiming it to be the proof that FP codebases don't scale to large teams. The truth is - you don't need a big team to build a successful product with FP language. And the number of startups using FP langs is steadily growing.

Re: Why Isn't Functional Programming the Norm? [video]

#342
post #287

Because it's not that useful. There is an contest organized by the International Conference on Functional Programming: https://en.wikipedia.org/wiki/ICFP_Programming_Contest It was more or less designed to show the superiority of functional programming languages. Yet in that contest C++ has done better than OCaml or Haskell... The FP crowd seems to be more active doing advocacy than writing code. Yes, we know, there…

> A new browser to compete with Chrome

Firefox is written in Rust

> a video game that can dethrone Skyrim or the Witcher 3.

afaik latest "God Of War" is written in Rust

> Maybe a DBMS that's even better than PostgreSQL?

Datomic - Clojure, Mnesia, Riak, CouchDB - Erlang

Yeah, I know that Rust is not FP lang, it's imperative, but it does adhere to FP principles.

"it's not that useful"? Heh.

Re: Why Isn't Functional Programming the Norm? [video]

#343

Earlier quoted context omitted.

They already said they were working in games. None of what you said applies to that field.

Here's a talk on making real world commercial games with Clojure on top of Unity. https://www.youtube.com/watch?v=LbS45w_aSCU

I think you are seriously overselling the talk, and what Arcadia is ready for.

you: Here's a talk on making real world commercial games with Clojure

video: dozens of game jam games have been made

Re: Why Isn't Functional Programming the Norm? [video]

#344

Earlier quoted context omitted.

come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps

That's just moving goalposts. The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019. If you're doing triple-A game development, maybe you need to get down to the metal, but for tons of games you'll be perfectly fine with FP. Also worth noting that the idea is to use FP around stuff like the actual game logic, and then handle rendering details imperatively…

The Poker prototype could be from 30 years ago, and drops to 15FPS on any game action! Arcadia is a neat toy at this point, but run far away if you are looking to do real world commercial development.

Re: Why Isn't Functional Programming the Norm? [video]

#345
post #106
post #67

Earlier quoted context omitted.

I never understood the point of Ramda. It's like it's trying to replace the core functionality of JS with something that's completely orthogonal to what the language actually is, but it's just a bolted on library. I've worked on codebases where people ignore all built-in JS functions (like Array.map/filter) and write Ramda spaghetti instead with multiple nested pipes and lens and what not to show off their FP purism.…

Maybe to avoid questionable behaviors, like in the article posted 3 months ago "Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript" [0] [0] - https://news.ycombinator.com/item?id=20242852

Things like Ramda and jquery help avoid fighting against IE and other browser nuances, as well.

Even when there seem to be native functions/ methods to do something. That’s where the monster lives.

Re: Why Isn't Functional Programming the Norm? [video]

#346
post #92

Earlier quoted context omitted.

Personally I find functional style awkward in js. Mostly because data is not immutable, there are no functional operators (composition, application etc.) and no algebraic data types + pattern matching. But most importantly, prototypal inheritance, in other words invoking the object's own methods as if they were pure functions is what really puts me off.

A lot of that stuff is pretty modern in terms of FP, though. It's definitely not a pure functional language, though quite a lot of the data is actually immutable. It was really surprising to me that strings are immutable (but as the other commenter pointed out, they don't throw if you try to mutate them, so it's not that convenient). "Objects" and arrays are mutable, but it's pretty easy to avoid mutating them if you…

Look into Ramda.js if you haven’t yet. It adds partial function application / currying capabilities, as well as composition support.

E.g.

https://ramdajs.com/docs/#partial

https://ramdajs.com/docs/#pipe

Re: Why Isn't Functional Programming the Norm? [video]

#347
post #323
post #308

Earlier quoted context omitted.

I validate your assumption against reality. If FP is not mandatory at Google-scale, it isn’t mandatory at your scale. The kind of problems that emerge at scale are not the kind of problems FP tackles.

Sorry, I mean scale as in "large scale projects". Spark is the quintessential Google-scale FP project - it was even born out of the MapReduce paper by Google! And there's plenty of other large-scale projects that are arguably in an FP style specifically to deal with the problems associated with scaling them: the Agda/Isabelle proof checkers, the seL4 kernel, the Chisel/FIIRTL project, Erlang/OTP, the Facebook Anti-Sp…

It is also intellectually dishonest to strawman an argument.

I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP. You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.

Every single large scale problem is a distributed problem simply because human societies are multi-agent distributed systems and programming languages are human-computer interfaces.

The issues at scale are systemic and arise from the design trade-offs made when your system's requirements bumps against the limits of computation. No language/paradigm can work around those.

The best a language can do is abstract-away the complexities behind a problem - solve it once (in the language/paradigm's preferred way) and give the human an interface/concept to work with.

Re: Why Isn't Functional Programming the Norm? [video]

#348

Earlier quoted context omitted.

come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps

That's just moving goalposts. The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019. If you're doing triple-A game development, maybe you need to get down to the metal, but for tons of games you'll be perfectly fine with FP. Also worth noting that the idea is to use FP around stuff like the actual game logic, and then handle rendering details imperatively…

> The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019

I mean, fucking todo apps are making "good money" in 2019, it does not mean that they are good examples. These kind of presentations should improve on the state of the art, not content themselves with something that was already possible a few decades ago. No one gets into game dev to make money, the point is to make better things than what is existing - be it gameplay wise, story wise, graphics wise...

Re: Why Isn't Functional Programming the Norm? [video]

#349

This video exists in an alternate reality where marketing departments do not. Many of these languages became popular not because of some intrinsic property, but because of a strong marketing push by one or more backing companies. There was a period of time, not so long ago, where "object oriented" was basically a checkbox on language marketing copy, and if your language didn't have it you would get scoffed at.

Can you give contemporaneous examples? I'm curious if there are companies out there actively pushing their language/framework, as opposed to sort of passively posting/updating without marketing.

The lines between marketing and "passively posting" are very blurry, especially in the tech world. Is Linus T. marketing, when in a technical presentation about git he says "if you like SVN you might wanna leave"? Is Mozilla marketing, when they claim in technical blog posts that rust provides system language level performance while being safe?

Re: Why Isn't Functional Programming the Norm? [video]

#350

Earlier quoted context omitted.

They already said they were working in games. None of what you said applies to that field.

I would say "real time graphics" is one of the niches FP is not well suited for, most business software doesn't need to work at the level of the machine.

Ironically the first CAD workstations were developed in Lisp, and Naughty Dog is famous for their Lisp/Scheme based engines.
Post reply on HN