12 ms·

This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. Also check

by nxc18 10y ago

This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. Also check out F#, especially if you already have a code base involving .NET in any way. The CLR makes it super easy to write some parts in a functional language and other parts in more traditional OO - after all, the right approach often varies even within projects. As a personal anecdote, taking the time to learn Haskell or any other functional language makes you a better programmer. The concepts often apply to less'pure' languages and certainly stretch you to think in new ways.

conistonwater 10y ago
Shenanigans is a good word for that. So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. It does not help that theoretical and academic are so often used as slurs.
- ebola1717 10y ago
  Haskell has its own share of shenanigans. Pragmas being the most blatant one, but also package management, the cumbersome-ness of some libraries, seq, and the number of operators (specifically the functorial ones).
  - axman6 10y ago
    Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except package management, which I find stack's solution works incredibly well in practice.
    - tmptmp 10y ago
      Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.
      - tmptmp 10y ago
        It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
      - joseph 10y ago
        I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
        mercurial 10y ago
        > Chaining a monadic sequence can feel magical at times. The issue is when this monad is actually a monad transformer tower, in which case there is actually a bunch of "magic" happening at each line.
        tome 10y ago
        > what do you do when the libraries that you depend on throw exceptions instead of using Either? File a bug on them
        krotton 10y ago
- Dr_tldr 10y ago
  JS runs natively on the web, it embraces multiple paradigms, it has a huge community, and you can get a job in almost any city on earth if you know how to use it. Haskell may be "better" as a language, (just as Esperanto may be superior to English) but if you want the widest range of opportunities in your life and not just in your language, Javascript/English beats Haskell/Esperanto. Why not help bring some of Haskell's concepts to a more relevant language instead of bemoaning the entirely rational decisions made by millions of junior and senior developers? Edit: the rabid insularity of the Haskell community definitely doesn't help. The Python community was dissatisfied with JS and created Coffeescript, and as of ES6 now everyone can enjoy the fat arrow syntax. Less pleasantly, the Java community got class syntax added to ES6, but at least they're trying to contribute. I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them, because all the Haskell community wants do is talk about how JavaScript sucks instead of embracing the functional side of it.
  - sotojuan 10y ago
    I don't know where they came from, but these projects and libraries seem to be influenced by Haskell (maybe?): https://github.com/folktale https://github.com/folktale https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary
  - PeCaN 10y ago
    Firstly, poor analogy—English is a much superior language to Esperanto in terms information density over seconds per syllable in addition to being more expressive (it's easier to talk about a wide variety of topics and abstractions). Possibly more importantly than that, it takes a lot of people to make a spoken language useful for doing business but far far fewer for a computer language. > instead of bemoaning the entirely rational decisions made by millions of junior and senior developers I think people are bemoaning the stupid shit and not the entirely rational decisions. JS makes the former a bit easy. > Python community was dissatisfied with JS and created Coffeescript Nitpicking, but the first CoffeeScript compiler was written in Ruby and the language was largely inspired by Ruby. > the Java community got class syntax added to ES6 Huh that's a new one pretty sure that's not just the Java community, given that JS developers have been independently inventing class libraries (starting with Prototype, if not earlier) for ages. > I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them Underscore, lazy.js, other popular JavaScript libraries have some Haskellisms; LiveScript is a fork of CoffeeScript that used to be moderately popular and very Haskelly; React takes a lot of ideas from Haskell; immutable.js is quite Haskellian…. I think you're just not looking. > all the Haskell community wants do is talk about how JavaScript sucks You can drive a go cart on the highway, and you can keep modding your go cart, but at some point you might want to not be driving a fucking go cart on the highway.
- logicallee 10y ago
  Hey how's that new patio coming along? The carpenter blew us away. They don't allow publication of a preprint, but it was just accepted into the Journal of Patio Support Design!! Which, I'm told, is the third most-prestigious journal in the business... No I meant like can we have a barbecue?
- tmptmp 10y ago
  >>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest. Yet, other languages support records flawlessly and almost out of the box. The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost? The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code. So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so. [1] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
  - thinkpad20 10y ago
    > The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.
jjzieve 10y ago
Isn't JS functional?
- sotojuan 10y ago
  JavaScript has functional features (first class functions for one are done well) but I think that's about it. Side effects, mutability, etc all are allowed. Compare with Haskell, Elm, or Clojure where those things are either not allowed at all or discouraged. The recent trend of "functional JavaScript" is mostly using third party tools that emulate feature from other languages (like Immtutable.js or Ramda), but IMO the core language cannot be called a proper functional language.
  - theGimp 10y ago
    It is a proper functional language, just not a "pure" functional language.
    - platz 10y ago
      Define proper functional language, as opposed to an improper one
      - sotojuan 10y ago
        To be fair, everyone has their own definition of FP. For me, it just feels weird to call JS functional when it only has one "feature" of most functional languages. And at least in my college studies, the discouragement of side effects was stressed as the main feature of them.
      - theGimp 10y ago
        To me, as long as functions are first class members, and higher-order functions are possible, I consider a language to be functional. Everything else is a convenience and not a requirement for the functional paradigm. Mind you, I do much prefer a Lisp or Scala to Javascript, but I face no trouble writing functional code in Javascript.
catnaroek 10y ago
> The concepts often apply to less'pure' languages and certainly stretch you to think in new ways. Purity is great help, but it isn't essential. The essential part is having a type system that actually captures what's going on in your program, without burdening you with manual annotations, and ML-family languages in general do very well in this regard.
- sheepmullet 10y ago
  I've gotten much more value from purity and immutability than I ever have from advanced types although I'm speaking from a F#/Clojure background rather than a Haskell one.
  - catnaroek 10y ago
    I'm not talking about fancy types either. Standard ML's type system is dead simple (no higher-kinded types, no GADTs, no type families, not even type classes), and I got a lot more value from it than from Haskell's type system, mostly thanks to: (0) Abstract types, generated by means of opaque signature ascription, which Haskell doesn't have. This ensures that different modules can't “accidentally” each other's internal invariants. (1) The fact variables stand for values (due to ML being strict), rather than potentially diverging computations (due to Haskell being lazy), which makes useful algebraic laws sound even in the presence of nontermination or whatever effects.
joe_the_user 10y ago
This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. What do you mean? As far I can tell, functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn but Haskell would. And it's not that I think this is necessarily a bad thing - functional is the "next big thing" for taming the insanity of programming and even sixty years in, we need still new models because programming is still a mess. But let's frame things the way they are "here's an concrete argument the hype might be justified" or something like that.
- chc 10y ago
  > functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn JavaScript topics do make it to the front of HN. For example, https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS was the top article on June 24. If you mean that simply writing about using JavaScript without any particular angle probably wouldn't make it to the front page, you're right. But that's actually proportionate to the two languages' usage. It's similar to how "I drank some water" is less interesting than "I drank a rare Japanese whiskey" — absent of context, they're equivalent, but because everyone has done the former, the fact that you did it too is boring on its own.
  - clishem 10y ago
    He said using JS won't get you to the top of HN.
- nxc18 10y ago
  I would expect you're right that functional languages get more coverage than they would warrant based on usage, at least in industry and the startup scene. I was referring more to people dismissing the benefits of functional programming as they dismiss the benefits of strictly typed and compiled languages. Many of the benefits of functional are the result of restrictions far more 'onerous' than knowing the type of an object at compile time. Those 'restrictions' make you think about your code more carefully and catch huge classes of bugs. Using strings to access object properties in JS (to me) feels like shenanigans.
wslh 10y ago
> functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm The issue is that many times the programming languages don't matter, what matters are the libs written for that language. For example, there are cryptocurrency libs for Ethereum and Bitcoins that are only available for JavaScript/Node. Like it or not the better decision will be to use JavaScript only for this reason.
- axlprose 10y ago
  I would argue that it's less about the libraries, and more about platforms and branding. Judging languages on their popular libraries can be a bit misleading, since not all languages need libraries for some of the stuff other languages need them for, they're often already baked-in to the language. F#'s Type Providers basically make ORMs, query builders, scrapers, web request libs, parsers, etc, largely unnecessary, because they enable the language to have built-in support for fully typed foreign data sources. Dart meanwhile, makes a large chunk of typical boilerplate js libs like jquery, underscore, promises, requirejs, etc, all obsolete while still being relatively similar to js. However, js is still the language of the largest platform out there (the browser), and the F# community still doesn't push it's branding and marketing towards trendy startup engineers very much, compared to a community like ruby's.
  - aninhumer 10y ago
    I don't think those kind of libraries are what the parent is talking about though. They're talking about when you need to interact with some interface, or implement some specific non-trivial algorithm, how likely is it that there's already a library for that.
    - axlprose 10y ago
      I hear this argument a lot too, but when you think about it, what would pull the original authors of those rarer libs to use the languages they chose in the first place? R is clearly geared and marketed towards statisticians, which have in turn given it a lot of such algorithms. Python has SciPy, which was also marketed similarly and has practically become its own platform. And Python itself was marketed towards academic types as 'executable pseudo code' that's easy to understand, which then culminated in NumPy and such. Also, I would argue that what op was talking about did fall more in line with platforms than algorithms, despite what the libs actually did, because Ethereum and Bitcoin are themselves platforms that spark those kinds of libs. Not to mention that you're always liable to run into situations where some obscure algorithm isn't available in your language of choice, regardless of how popular it is (unless you're using c++, which marketed/encouraged the kitchen-sink approach to development, and has had a lot of time to build quite a few kitchens). As for interfaces, I'm not sure exactly you mean that hasn't been covered already, like in the case of F# being able to smoothly interface with external data (which also includes the ability to interface with libraries from entirely different languages like R and Python). And interfacing with hardware is also a lot like a platform issue similar to the browser situation, except with C instead of js. And then there's stuff like arduino, which is also very clearly a platform. All in all, branding and marketing shouldn't be underestimated as the driving forces behind a lot of tech decisions, because software development does have a very strong social component that shouldn't be ignored. I mean, just look at the type of site we're on...
mercurial 10y ago
> a world where JavaScript's shenanigans are the accepted norm. Hey, we have Typescript nowadays, which does help a lot.

by nxc18 10y ago

conistonwater 10y ago

Shenanigans is a good word for that. So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. It does not help that theoretical and academic are so often used as slurs.

ebola1717 10y ago
Haskell has its own share of shenanigans. Pragmas being the most blatant one, but also package management, the cumbersome-ness of some libraries, seq, and the number of operators (specifically the functorial ones).
- axman6 10y ago
  Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except package management, which I find stack's solution works incredibly well in practice.
  - tmptmp 10y ago
    Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.
    - tmptmp 10y ago
      It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
    - joseph 10y ago
      I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
      - mercurial 10y ago
        > Chaining a monadic sequence can feel magical at times. The issue is when this monad is actually a monad transformer tower, in which case there is actually a bunch of "magic" happening at each line.
      - tome 10y ago
        > what do you do when the libraries that you depend on throw exceptions instead of using Either? File a bug on them
        krotton 10y ago
Dr_tldr 10y ago
JS runs natively on the web, it embraces multiple paradigms, it has a huge community, and you can get a job in almost any city on earth if you know how to use it. Haskell may be "better" as a language, (just as Esperanto may be superior to English) but if you want the widest range of opportunities in your life and not just in your language, Javascript/English beats Haskell/Esperanto. Why not help bring some of Haskell's concepts to a more relevant language instead of bemoaning the entirely rational decisions made by millions of junior and senior developers? Edit: the rabid insularity of the Haskell community definitely doesn't help. The Python community was dissatisfied with JS and created Coffeescript, and as of ES6 now everyone can enjoy the fat arrow syntax. Less pleasantly, the Java community got class syntax added to ES6, but at least they're trying to contribute. I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them, because all the Haskell community wants do is talk about how JavaScript sucks instead of embracing the functional side of it.
- sotojuan 10y ago
  I don't know where they came from, but these projects and libraries seem to be influenced by Haskell (maybe?): https://github.com/folktale https://github.com/folktale https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary
- PeCaN 10y ago
  Firstly, poor analogy—English is a much superior language to Esperanto in terms information density over seconds per syllable in addition to being more expressive (it's easier to talk about a wide variety of topics and abstractions). Possibly more importantly than that, it takes a lot of people to make a spoken language useful for doing business but far far fewer for a computer language. > instead of bemoaning the entirely rational decisions made by millions of junior and senior developers I think people are bemoaning the stupid shit and not the entirely rational decisions. JS makes the former a bit easy. > Python community was dissatisfied with JS and created Coffeescript Nitpicking, but the first CoffeeScript compiler was written in Ruby and the language was largely inspired by Ruby. > the Java community got class syntax added to ES6 Huh that's a new one pretty sure that's not just the Java community, given that JS developers have been independently inventing class libraries (starting with Prototype, if not earlier) for ages. > I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them Underscore, lazy.js, other popular JavaScript libraries have some Haskellisms; LiveScript is a fork of CoffeeScript that used to be moderately popular and very Haskelly; React takes a lot of ideas from Haskell; immutable.js is quite Haskellian…. I think you're just not looking. > all the Haskell community wants do is talk about how JavaScript sucks You can drive a go cart on the highway, and you can keep modding your go cart, but at some point you might want to not be driving a fucking go cart on the highway.
logicallee 10y ago
Hey how's that new patio coming along? The carpenter blew us away. They don't allow publication of a preprint, but it was just accepted into the Journal of Patio Support Design!! Which, I'm told, is the third most-prestigious journal in the business... No I meant like can we have a barbecue?
tmptmp 10y ago
>>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest. Yet, other languages support records flawlessly and almost out of the box. The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost? The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code. So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so. [1] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
- thinkpad20 10y ago
  > The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.

jjzieve 10y ago

Isn't JS functional?

sotojuan 10y ago
JavaScript has functional features (first class functions for one are done well) but I think that's about it. Side effects, mutability, etc all are allowed. Compare with Haskell, Elm, or Clojure where those things are either not allowed at all or discouraged. The recent trend of "functional JavaScript" is mostly using third party tools that emulate feature from other languages (like Immtutable.js or Ramda), but IMO the core language cannot be called a proper functional language.
- theGimp 10y ago
  It is a proper functional language, just not a "pure" functional language.
  - platz 10y ago
    Define proper functional language, as opposed to an improper one
    - sotojuan 10y ago
      To be fair, everyone has their own definition of FP. For me, it just feels weird to call JS functional when it only has one "feature" of most functional languages. And at least in my college studies, the discouragement of side effects was stressed as the main feature of them.
    - theGimp 10y ago
      To me, as long as functions are first class members, and higher-order functions are possible, I consider a language to be functional. Everything else is a convenience and not a requirement for the functional paradigm. Mind you, I do much prefer a Lisp or Scala to Javascript, but I face no trouble writing functional code in Javascript.

catnaroek 10y ago

> The concepts often apply to less'pure' languages and certainly stretch you to think in new ways. Purity is great help, but it isn't essential. The essential part is having a type system that actually captures what's going on in your program, without burdening you with manual annotations, and ML-family languages in general do very well in this regard.

sheepmullet 10y ago
I've gotten much more value from purity and immutability than I ever have from advanced types although I'm speaking from a F#/Clojure background rather than a Haskell one.
- catnaroek 10y ago
  I'm not talking about fancy types either. Standard ML's type system is dead simple (no higher-kinded types, no GADTs, no type families, not even type classes), and I got a lot more value from it than from Haskell's type system, mostly thanks to: (0) Abstract types, generated by means of opaque signature ascription, which Haskell doesn't have. This ensures that different modules can't “accidentally” each other's internal invariants. (1) The fact variables stand for values (due to ML being strict), rather than potentially diverging computations (due to Haskell being lazy), which makes useful algebraic laws sound even in the presence of nontermination or whatever effects.

joe_the_user 10y ago

This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. What do you mean? As far I can tell, functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn but Haskell would. And it's not that I think this is necessarily a bad thing - functional is the "next big thing" for taming the insanity of programming and even sixty years in, we need still new models because programming is still a mess. But let's frame things the way they are "here's an concrete argument the hype might be justified" or something like that.

chc 10y ago
> functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn JavaScript topics do make it to the front of HN. For example, https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS was the top article on June 24. If you mean that simply writing about using JavaScript without any particular angle probably wouldn't make it to the front page, you're right. But that's actually proportionate to the two languages' usage. It's similar to how "I drank some water" is less interesting than "I drank a rare Japanese whiskey" — absent of context, they're equivalent, but because everyone has done the former, the fact that you did it too is boring on its own.
- clishem 10y ago
  He said using JS won't get you to the top of HN.
nxc18 10y ago
I would expect you're right that functional languages get more coverage than they would warrant based on usage, at least in industry and the startup scene. I was referring more to people dismissing the benefits of functional programming as they dismiss the benefits of strictly typed and compiled languages. Many of the benefits of functional are the result of restrictions far more 'onerous' than knowing the type of an object at compile time. Those 'restrictions' make you think about your code more carefully and catch huge classes of bugs. Using strings to access object properties in JS (to me) feels like shenanigans.

wslh 10y ago

> functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm The issue is that many times the programming languages don't matter, what matters are the libs written for that language. For example, there are cryptocurrency libs for Ethereum and Bitcoins that are only available for JavaScript/Node. Like it or not the better decision will be to use JavaScript only for this reason.

axlprose 10y ago
I would argue that it's less about the libraries, and more about platforms and branding. Judging languages on their popular libraries can be a bit misleading, since not all languages need libraries for some of the stuff other languages need them for, they're often already baked-in to the language. F#'s Type Providers basically make ORMs, query builders, scrapers, web request libs, parsers, etc, largely unnecessary, because they enable the language to have built-in support for fully typed foreign data sources. Dart meanwhile, makes a large chunk of typical boilerplate js libs like jquery, underscore, promises, requirejs, etc, all obsolete while still being relatively similar to js. However, js is still the language of the largest platform out there (the browser), and the F# community still doesn't push it's branding and marketing towards trendy startup engineers very much, compared to a community like ruby's.
- aninhumer 10y ago
  I don't think those kind of libraries are what the parent is talking about though. They're talking about when you need to interact with some interface, or implement some specific non-trivial algorithm, how likely is it that there's already a library for that.
  - axlprose 10y ago
    I hear this argument a lot too, but when you think about it, what would pull the original authors of those rarer libs to use the languages they chose in the first place? R is clearly geared and marketed towards statisticians, which have in turn given it a lot of such algorithms. Python has SciPy, which was also marketed similarly and has practically become its own platform. And Python itself was marketed towards academic types as 'executable pseudo code' that's easy to understand, which then culminated in NumPy and such. Also, I would argue that what op was talking about did fall more in line with platforms than algorithms, despite what the libs actually did, because Ethereum and Bitcoin are themselves platforms that spark those kinds of libs. Not to mention that you're always liable to run into situations where some obscure algorithm isn't available in your language of choice, regardless of how popular it is (unless you're using c++, which marketed/encouraged the kitchen-sink approach to development, and has had a lot of time to build quite a few kitchens). As for interfaces, I'm not sure exactly you mean that hasn't been covered already, like in the case of F# being able to smoothly interface with external data (which also includes the ability to interface with libraries from entirely different languages like R and Python). And interfacing with hardware is also a lot like a platform issue similar to the browser situation, except with C instead of js. And then there's stuff like arduino, which is also very clearly a platform. All in all, branding and marketing shouldn't be underestimated as the driving forces behind a lot of tech decisions, because software development does have a very strong social component that shouldn't be ignored. I mean, just look at the type of site we're on...

mercurial 10y ago

> a world where JavaScript's shenanigans are the accepted norm. Hey, we have Typescript nowadays, which does help a lot.