4 ms·
> Picking up the basics of a language is easy, but it's knowing the nuisance that separates the professional from the amateur. I disagree. I went from C# to N
by nulagrithom 10y ago
> Picking up the basics of a language is easy, but it's knowing the nuisance that separates the professional from the amateur.
I disagree.
I went from C# to Node.js and back to C#. I learned the hell out of JavaScript, and yet I feel like nobody will ever care that I can explain some of its nuances and gotchas. Language nuances are constantly evolving anyway.
Learning Node.js unlocked whole paradigms I didn't understand in C#. I never really "got" functional programming. Switching between the two helped me understand the pros and cons of different approaches. I discovered a lot of the things I miss from JavaScript are actually there in C#, just a little off the beaten path. On the other hand, I can appreciate "the C# way" and breathe a sigh of relief that certain gotchas do not exist in that environment.
- eptcyka 10y agoWhilst it's true that one can program in a functional style in almost any language, I fail to see how javascript would help someone learn about functional programming.
- darkkindness 10y agoIt's true that you can program in a functional style in almost any language, but it's just simpler for Javascript. Functions are first-class objects in Javascript, and arrays have built-in forEach, map, reduce, and filter -- all useful for a beginner in functional programming. C++ and Java have lambdas and foreach, but they aren't as simple to use.
- eptcyka 10y agoThere is nothing wrong with map, reduce and filter, but I believe this is just conflating nice and usable APIs for iterators with functional programming.
- sulam 10y agohttp://letoverlambda.com/index.cl/guest/chap5.html http://letoverlambda.com/index.cl/guest/chap5.html s/Lisp/JavaScript/g
- seanmcdirmid 10y agoC# on the other hand, support FP pretty well, as long as static typing without HM is acceptable.
- bad_user 10y agoFunctional Programming is about working with mathematical functions. Having "first-class functions" in the language is nice, but then passing function pointers around is nothing more than procedural programming [1] and yes, the difference is huge. As for those utilities you mention, Javascript is the most broken of them all: >>> ["10", "10", "10"].map(parseInt) [10, Nan, 2] [1] https://en.wikipedia.org/wiki/Procedural_programming https://en.wikipedia.org/wiki/Procedural_programming
- jameshart 10y agoWhy does functional programming have to be about math? That is precisely the kind of insistence that prevents people from adopting functional languages for real world programming tasks. JavaScript certainly lacks language level support for function composition, but it has the basic tools to allow you to build combinators and compositional functions yourself, and when dealing with functions as data you often find you can elegantly refactor code by building such a thing - so in terms of 'learning about functional programming' JS can be a great workbench to help procedural minded programmers discover those tools by discovering and building them. So maybe JS doesn't teach functional programming, but it does at least introduce you to paradigms from which it is possible to see the benefits of a functional language. Of course, if you then hear that those languages are only for doing math in then you'll stick with JavaScript.
- acomar 10y ago> Why does functional programming have to be about math? You've misunderstood the GP's point. It's not that FP is about math, it's that you want to emphasize mathematical functions -- functions that don't rely on inputs other than their parameters and return values in a consistent co-domain. This is just good style to improve testability and minimize sources of potential bugs.
- bad_user 10y ago> Why does functional programming have to be about math? Because that's its definition. Change that definition and it becomes meaningless. Functional programming is about working with functions that always have the same output for a given input - the definition of mathematical functions and I wouldn't have to say mathematical if software developers wouldn't feel the need to overload technical terms. Pascal and other languages had great names for pieces of code taking arguments and that aren't functions: procedures, routines, subroutines, etc. > That is precisely the kind of insistence that prevents people from adopting functional languages for real world programming tasks. So let me get this straight, in order to get people to adopt something, you want the definition changed in such a way as to become meaningless? Also, I do expect software developers to know at least high-school level math, because CS is math. Even if you lack a formal education, that's no excuse for ignoring theory that can help in your daily work, especially in this day and age with so many online resources available for free.
- aji 10y agothe way JS does closures, and the mandatory async nature of everything, leads to a world where you're working with functions a lot more than you would be in languages in the same family (garbage collected, lenient, a la python and ruby). from there, functional programming concepts like partial application and currying start to pop up. if you dive into frameworks like react.js, you start to encounter pure functions and immutability. it's not what I would call a "functional programming language", but I find the concepts show up more than usual, and I think that's because functions are one of the more advanced primitives in the language
- gkya 10y agoFirst class functions seem to be often confused for functional programming, and JS has first class functions.
- bad_user 10y ago> Learning Node.js unlocked whole paradigms I didn't understand in C#. I never really "got" functional programming Don't get me wrong, but I'm pretty sure you still don't get functional programming, because functional programming is not practiced within the Javascript / Node.js ecosystem. Yes, there are some exceptions here and there, some libraries like Facebook's React have FP-inspired ideas in them (even though those components are modelled with state and hence have nothing to do with FP) and working with asynchronous results signalled by callbacks is so freaking horrible that people have began using Promise abstractions sort of inspired by FP, except most of them broken. But no, unless you're into one of the languages that actively promote FP, like ClojureScript, PureScript, Elm, Scala.js, then you're probably not doing FP. As evidence, go to GitHub, pick any sampling of Javascript projects and witness how a vast majority have nothing to do with FP. Furthermore I think that with this argument you're proving the parent's point. If you want FP, then take the time to learn and work with one of the languages that actively promote FP and be prepared to suffer because it's not easy.