8 ms·
I recently watched this talk- Why Isn't Functional Programming the Norm? (https://youtu.be/QyJZzq0v7Z4 https://youtu.be/QyJZzq0v7Z4) Here's the HN thread- htt
by rg111 5y ago
I recently watched this talk-
Why Isn't Functional Programming the Norm? (https://youtu.be/QyJZzq0v7Z4 https://youtu.be/QyJZzq0v7Z4)
Here's the HN thread- https://news.ycombinator.com/item?id=21280429 https://news.ycombinator.com/item?id=21280429
I learned in that talk, among other things that Oracle spent $500 million to promote and market Java.
- https://www.theregister.com/2003/06/09/sun_preps_500m_java_brand/ https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...
- https://www.wsj.com/articles/SB105510454649518400 https://www.wsj.com/articles/SB105510454649518400
- https://www.techspot.com/community/topics/sun-preps-500m-java-brand-push.5852/ https://www.techspot.com/community/topics/sun-preps-500m-jav...
- shaklee3 5y agoC++ and C have spent $0 on marketing and are more popular, so I don't think this is a good indicator of success.
- kaba0 5y agoNever heard of any conference starting with Cpp or the like, nor does it have a website I guess..
- cjfd 5y agoThat you have never heard of things does not mean they do not exist.... https://cppcon.org/ https://cppcon.org/
- Jensson 5y agoThose exists because the language is popular, they weren't created to market the language before it was popular.
- kaba0 5y agoMy point is that OP’s comparison is useless because Java most definitely has marketing costs mostly associated with that 8+ million Java developers, the same as other popular languages.
- Jensson 5y agoHow is this relevant when the topic was that Oracle literally spent $500 million marketing Java? The community of anything popular is marketing itself, yes, but that is a very different thing from having an actual marketing budget to push it to popularity.
- pjmlp 5y agoThis is what made C++ popular, Apple: https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works... https://en.wikipedia.org/wiki/PowerPlant https://en.wikipedia.org/wiki/PowerPlant Borland: https://en.wikipedia.org/wiki/Turbo_Vision https://en.wikipedia.org/wiki/Turbo_Vision https://en.wikipedia.org/wiki/Object_Windows_Library https://en.wikipedia.org/wiki/Object_Windows_Library IBM: https://en.wikipedia.org/wiki/IBM_Open_Class https://en.wikipedia.org/wiki/IBM_Open_Class Microsoft: https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Lib... https://en.wikipedia.org/wiki/Active_Template_Library https://en.wikipedia.org/wiki/Active_Template_Library
- Jensson 5y agoThe fact that you linked so many different companies is evidence that this wasn't just some push by a single company. Those things happened in parallel because the language was popular and is evidence of a vibrant community more than anything else. Being popular means many will want to make things with it yes, saying that it got popular since many people did things with it doesn't make sense.
- pjmlp 5y agoIndeed, C came for $0 with UNIX that AT&T wasn't allowed to sell and provided source tapes alonside a symbolic price, in a time where systems cost several hundreds $$$$. C++ came on the same package as C compilers, some of which it was a compiler switch away. Both were picked by OS vendors that tried to cater on top of UNIX clones. Yep, zero marketing.
- deepsun 5y agoI thought Java was once the most popular language before Oracle bought it from Sun Microsystems.
- Nursie 5y agoThey bought the whole of sun! And yes, it was, though in the intervening years they've improved the language a lot IMHO.
- endymi0n 5y agoIt's way simpler actually. Functional programming isn't the norm because — while it's extremely good at describing "what things are and how to describe relationships of actions on them" — it sucks at "describing what things do and describing their relationships to each other". Imperative programming has exactly the opposite balance. I find the former to just be more valuable and applicable in 80% of real world business cases, as well as being easier to reason about. Entity Relationship Diagrams for example are an extremely unnatural match to FP in my eyes, and they're my prime tool to model requirements engineering. Code in FP isn't structured around entities, it's structured in terms of flow. That's both a bug as well as a feature, depending on what you're working on. Most of the external, real world out there is impure. External services, internal services, time. Same thing for anything that naturally has side effects. If I ask an imperative programmer to turn me on three LEDs after each other, they're like: Sure, boss! for led in range(3): led.turn_on(); time.sleep 1; led.turn_off() If I ask an FP guy to turn me on three LEDs after each other, first they question whether that's a good idea in the first place and then they're like... "oh, because time is external to our pure little world, first we need a monad." Whoa, get me outta here! Obviously with a healthy dose of sarcasm. Don't get me wrong, for the cases where it makes sense, I use a purely functional language every day: it's called SQL and it's awesome despite looking like FORTRAN 77. I also really like my occasional functional constructs in manipulating sequences and streams. But for the heavy lifting? Sure give me something that's as impure and practical as all of the rest of the world out there. I'll be done before the FP connaisseur has managed to adapt her elegant one-liner to that dirty, dirty world out there.
- dnautics 5y agothere are FPs that have and embrace side effects, not everything is haskell.
- yomly 5y agoYour LED example is an interesting one. In the basic model of a computer architecture, the screen is abstracted as a pixel array in memory - set those bits and the screen will render the pixels. The rest is hand waved as hardware. A pixel array can be trivially modelled as a pure datastructure and then you can use the whole corpus of transformations which are the bread and butter of FP. A screen is as IO as it comes for the most average consumers of a screen, we aren't peeking into its internals. And for me, that's the point of FP - it's not that IO is to be avoided, it's about finding ways of separating your IO from the core logic. I loosely see the monad (as used in industry) as a formalised and more generic "functional core imperative shell" Now when it comes to pure FP languages, they keep you honest and guide you along this paradigm. That said, it's perfectly possible to write very impure imperative Haskell - I've seen it with my own eyes in some of the biggest proprietary Haskell codebases But imperative languages don't generally help you in the same way, if you want to do functional core imperative shell, you need a tonne of discipline and a predefined team consensus to commit to this
- platz 5y agothis is also a good talk in a similar vein, although aimed at haskell programmers, is really about any technology looking to grow into the mainstream Gabriel Gonzalez – How to market Haskell to a mainstream programmer - https://youtu.be/fNpsgTIpODA https://youtu.be/fNpsgTIpODA