5 ms·

I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organizati

I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. About the last point, my tiny observations is that language too advanced don't get used as dependencies.. they get ignored until the crowd matures enough to get the ideas in their own ways and pull a gene transfer. - lisp idioms (map, filter, destruct) => all dyn langs - react / vue .. basically let over lambda and closure based programming (I even believe vue provide/inject is near equal to dynamic variables) wait until someone there likes to thread state or rng seeds through 'chains of functions' and you'll see monads pop up

armchairhacker 4y ago
Haskell does have advanced tools though. Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Haskell’s LSP is making rapid progress and there are many formatters and linters. Tooling still has a way to go, but I don’t think that’s all. Haskell’s abstraction is just too much when you need to design something which is ultimately kind of straitforward, and most apps are (design app, game, utility app, web server, etc.) I do think Haskell is more than a research language, it does have some use in practical, mainstream programming. In particular, Haskell is great at anything which is “input to output”, like compilers or document converters. Or in a program which is ultimately complex, and not just for optimization but “math” complexity, like math programs or simulators. In those programs the implicit laziness actually comes in handy. But Haskell for a real-time video game or editor, and you’re just wrapping everything in an IO monad or some restricted stateful equivalent, and executing most of the instructions in sequence anyways.
- tinco 4y ago
  Why would you wrap things in an IO monad for a real time video game? There's a whole lot of code you can do purely functionally in video games that can make it very nice. I've done a couple small projects in Blueprint which is a purely functional programming language embedded in UnrealEngine 4 and I enjoyed it a lot. Blueprint notably does not expose any type classes, at least not when I tried it a couple years ago, but it felt very expressive for building complex game logic.
  - Arelius 4y ago
    FYI, Blueprint is very much not purely functional and has exposed type classes since it changed from Kismet IIRC.
    - tinco 4y ago
      Maybe I'm not remembering it correctly. Basically you had colored wires representing values flowing through functions, and then you had white wires that represented ordered execution, much like the IO monad. Is it possible to have side effects from nodes without the white wire?
- Zababa 4y ago
  > Stack / cabal, haddock, htest can be comparable to Rust’s tooling. I don't think they are. Having used both, Rust's tooling is more accessible to beginners, which makes a big difference. I find it even easier to use than npm, while I find Haskell's tooling harder (on roughly the same level as OCaml with dune, or Maven). > Haskell’s LSP is making rapid progress and there are many formatters and linters. Haskell's LSP is good, however it's not as good as rust-analyzer, and has a habit of chewing through a lot of RAM.
- kahnclusions 4y ago
  > Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Disagree from me. I spent a year writing Haskell professionally, and from my own personal experience Haskell's tooling was overly complicated and difficult to use. Maybe my impression is totally wrong or outdated, and it's surely not applicable to the whole community, so I'm sorry if this is a little out of touch now, but I sometimes got the sense that Haskell's community just doesn't care about the developer experience. They hold to this false dichotomy that if you make tools easy to use, then you can't have advanced features. Or simply, Cabal works just fine the way it is, why do we need Stack? Why would you need more than one GHC installation on a machine? Holy wars on the mailing lists re: Stack, Cabal, Haskell Platform. And if someone tells me to "just use Nix" one more time I will cry... Rust feels like a breath of fresh air. The community seriously cares about their developer experience both for newbies and experienced professionals, and it really feels like a lot of work has gone into making the tools and documentation accessible and useful.
Karrot_Kream 4y ago
> I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. I feel like "not tending to companies needs for profits" is a way to elevate Haskell and monadic FP abstractions with appeal to conspiracy/(postmodern) ideology. I don't mean this to be a pro-or-anti capitalism sentiment, but the excuse here is that "in a more just/less captalist/<other> world, Haskell would be a great tool, but our flawed world makes it not so" and I disagree with that. I just don't think Haskell is that good of a tool regardless (and I see the Haskell community these days appealing to this take a lot, trying to blame anyone but themselves.) I think that people genuinely don't derive much value from Haskell and monadic FP. My experience, having written and maintained non-production-grade Haskell code, has been that the community is obsessed with toys and small examples, derives a lot of pleasure from clever abstractions which don't materially affect development (like Lenses), and most importantly doesn't really care about shipping software. There's exceptions like SPJ and Joey Hess who definitely ship useful Haskell, but the community doesn't care nearly enough about making it easy to actually produce software that a non-Haskell enthusiast would care about using. Libraries are often created for a Masters project and abandoned. Even if a library works, debugging edge cases is never thought of. Almost nothing is written about testing in Haskell. No two libraries can agree on which monad stack to use, so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting). There are very few examples of organizational patterns for Haskell codebases for folks trying to create a project other than GHC itself, Pandoc, and perhaps XMonad. The community loves talking about abstractions and unifying concepts but doesn't really seem to have any practical tips about writing software. The string types in the language are confusing and poorly differentiated. The cabal and stack split is confusing and makes no sense to outsiders. The weird cargo-cult obsession in the community about category theory from people with little formal mathematical knowledge is bizarre. I can go on and on, but I don't want to dunk on the language endlessly (and I can certainly do this to any language I've used in love or anger :) Fundamentally I don't think Haskell offers the programmer much more than what you'd get out of a language like Rust, Java, or Go (yes even Go) as the GP said. It's a language with a lot of interesting concepts that's fun for folks who like to solve algebra problems and is certainly a clean introduction to monadic FP. I'm looking forward to a successor that takes its concepts, cleans them up, and offers a way to write actual software with them. Then again, Multicore Ocaml is landing soon...
nine_k 4y ago
We already sort of see threading state through chains of (pure) functions; it's how you write React, especially if you use Redux instead of hooks. You lug props around, they are explicitly immutable because you always get a copy, and it's fine, nobody complains much. It feels logical. Some more effort in packaging this ergonomically, and we'll see purity annotations in TS and explicit passage of state objects around.
- agumonkey 4y ago
  redux is another part of the 'gene transfer idea', nobody used reducers for anything except maybe rich hickey
rileyphone 4y ago
The "fungible programmer" theory [0] is one of the better explanations for the unpopularity of languages like Haskell and Lisp. Ultimately, making software that's large enough will become an organizational problem as well as technical one, and developers will get funged into being blub programmers [1], though RoR is a pretty nice way to do that all things considered. I would argue Go was designed for maximum fungibility. [0] http://www.loper-os.org/?p=69 http://www.loper-os.org/?p=69 [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- Karrot_Kream 4y ago
  Lol the fungible programmer theory is one of the most disrespectful theories of programmer choice out there. It assumes that, by default, everyone is a bad programmer and that only people that use "non-blub languages" are good programmers. Blub itself is vaguely defined or generally never defined rigorously. I never find a theory that has contempt for so much of an industry has any real explanatory benefit.
  - astrange 4y ago
    It's largely a demonstration that if you give pg an incredible amount of money by accidentally inventing online stores, he will develop an incredible ego and decide it was all due to his personal technical brilliance.
  - rileyphone 4y ago
    It's not necessarily that they are worse programmers, but rather represent the industrialization of building software, as outlined by Brad Cox [0]. Partially driving this is the shorter tenure of today's software engineers. How many beautiful things have had to be completely rewritten because the original creator had left, and no one could grok it? Not that there is no way to reconcile fungibility with expressiveness and beauty, but the tradeoffs involved are tricky and will always end up disappointing somebody. [0] https://www.researchgate.net/publication/3246772_Planning_the_software_industrial_revolution https://www.researchgate.net/publication/3246772_Planning_th...

armchairhacker 4y ago

Haskell does have advanced tools though. Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Haskell’s LSP is making rapid progress and there are many formatters and linters. Tooling still has a way to go, but I don’t think that’s all. Haskell’s abstraction is just too much when you need to design something which is ultimately kind of straitforward, and most apps are (design app, game, utility app, web server, etc.) I do think Haskell is more than a research language, it does have some use in practical, mainstream programming. In particular, Haskell is great at anything which is “input to output”, like compilers or document converters. Or in a program which is ultimately complex, and not just for optimization but “math” complexity, like math programs or simulators. In those programs the implicit laziness actually comes in handy. But Haskell for a real-time video game or editor, and you’re just wrapping everything in an IO monad or some restricted stateful equivalent, and executing most of the instructions in sequence anyways.

tinco 4y ago
Why would you wrap things in an IO monad for a real time video game? There's a whole lot of code you can do purely functionally in video games that can make it very nice. I've done a couple small projects in Blueprint which is a purely functional programming language embedded in UnrealEngine 4 and I enjoyed it a lot. Blueprint notably does not expose any type classes, at least not when I tried it a couple years ago, but it felt very expressive for building complex game logic.
- Arelius 4y ago
  FYI, Blueprint is very much not purely functional and has exposed type classes since it changed from Kismet IIRC.
  - tinco 4y ago
    Maybe I'm not remembering it correctly. Basically you had colored wires representing values flowing through functions, and then you had white wires that represented ordered execution, much like the IO monad. Is it possible to have side effects from nodes without the white wire?
Zababa 4y ago
> Stack / cabal, haddock, htest can be comparable to Rust’s tooling. I don't think they are. Having used both, Rust's tooling is more accessible to beginners, which makes a big difference. I find it even easier to use than npm, while I find Haskell's tooling harder (on roughly the same level as OCaml with dune, or Maven). > Haskell’s LSP is making rapid progress and there are many formatters and linters. Haskell's LSP is good, however it's not as good as rust-analyzer, and has a habit of chewing through a lot of RAM.
kahnclusions 4y ago
> Stack / cabal, haddock, htest can be comparable to Rust’s tooling. Disagree from me. I spent a year writing Haskell professionally, and from my own personal experience Haskell's tooling was overly complicated and difficult to use. Maybe my impression is totally wrong or outdated, and it's surely not applicable to the whole community, so I'm sorry if this is a little out of touch now, but I sometimes got the sense that Haskell's community just doesn't care about the developer experience. They hold to this false dichotomy that if you make tools easy to use, then you can't have advanced features. Or simply, Cabal works just fine the way it is, why do we need Stack? Why would you need more than one GHC installation on a machine? Holy wars on the mailing lists re: Stack, Cabal, Haskell Platform. And if someone tells me to "just use Nix" one more time I will cry... Rust feels like a breath of fresh air. The community seriously cares about their developer experience both for newbies and experienced professionals, and it really feels like a lot of work has gone into making the tools and documentation accessible and useful.

Karrot_Kream 4y ago

> I wonder if the first point is due to a paradox of advanced tools.. society lives around "how do you assemble teams to solve big problems", they need organization tricks more than logic/language ones. That's why RoR, go, etc win, they allow most groups to end up with something workable. Haskell and the likes are more about exploration.. not tending to companies needs for profits. I feel like "not tending to companies needs for profits" is a way to elevate Haskell and monadic FP abstractions with appeal to conspiracy/(postmodern) ideology. I don't mean this to be a pro-or-anti capitalism sentiment, but the excuse here is that "in a more just/less captalist/<other> world, Haskell would be a great tool, but our flawed world makes it not so" and I disagree with that. I just don't think Haskell is that good of a tool regardless (and I see the Haskell community these days appealing to this take a lot, trying to blame anyone but themselves.) I think that people genuinely don't derive much value from Haskell and monadic FP. My experience, having written and maintained non-production-grade Haskell code, has been that the community is obsessed with toys and small examples, derives a lot of pleasure from clever abstractions which don't materially affect development (like Lenses), and most importantly doesn't really care about shipping software. There's exceptions like SPJ and Joey Hess who definitely ship useful Haskell, but the community doesn't care nearly enough about making it easy to actually produce software that a non-Haskell enthusiast would care about using. Libraries are often created for a Masters project and abandoned. Even if a library works, debugging edge cases is never thought of. Almost nothing is written about testing in Haskell. No two libraries can agree on which monad stack to use, so a non-trivial amount of integration code involves matching and lifting into other monads (nor the performance implications of doing all of this matching and lifting). There are very few examples of organizational patterns for Haskell codebases for folks trying to create a project other than GHC itself, Pandoc, and perhaps XMonad. The community loves talking about abstractions and unifying concepts but doesn't really seem to have any practical tips about writing software. The string types in the language are confusing and poorly differentiated. The cabal and stack split is confusing and makes no sense to outsiders. The weird cargo-cult obsession in the community about category theory from people with little formal mathematical knowledge is bizarre. I can go on and on, but I don't want to dunk on the language endlessly (and I can certainly do this to any language I've used in love or anger :) Fundamentally I don't think Haskell offers the programmer much more than what you'd get out of a language like Rust, Java, or Go (yes even Go) as the GP said. It's a language with a lot of interesting concepts that's fun for folks who like to solve algebra problems and is certainly a clean introduction to monadic FP. I'm looking forward to a successor that takes its concepts, cleans them up, and offers a way to write actual software with them. Then again, Multicore Ocaml is landing soon...

nine_k 4y ago

We already sort of see threading state through chains of (pure) functions; it's how you write React, especially if you use Redux instead of hooks. You lug props around, they are explicitly immutable because you always get a copy, and it's fine, nobody complains much. It feels logical. Some more effort in packaging this ergonomically, and we'll see purity annotations in TS and explicit passage of state objects around.

agumonkey 4y ago
redux is another part of the 'gene transfer idea', nobody used reducers for anything except maybe rich hickey

rileyphone 4y ago

The "fungible programmer" theory [0] is one of the better explanations for the unpopularity of languages like Haskell and Lisp. Ultimately, making software that's large enough will become an organizational problem as well as technical one, and developers will get funged into being blub programmers [1], though RoR is a pretty nice way to do that all things considered. I would argue Go was designed for maximum fungibility. [0] http://www.loper-os.org/?p=69 http://www.loper-os.org/?p=69 [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

Karrot_Kream 4y ago
Lol the fungible programmer theory is one of the most disrespectful theories of programmer choice out there. It assumes that, by default, everyone is a bad programmer and that only people that use "non-blub languages" are good programmers. Blub itself is vaguely defined or generally never defined rigorously. I never find a theory that has contempt for so much of an industry has any real explanatory benefit.
- astrange 4y ago
  It's largely a demonstration that if you give pg an incredible amount of money by accidentally inventing online stores, he will develop an incredible ego and decide it was all due to his personal technical brilliance.
- rileyphone 4y ago
  It's not necessarily that they are worse programmers, but rather represent the industrialization of building software, as outlined by Brad Cox [0]. Partially driving this is the shorter tenure of today's software engineers. How many beautiful things have had to be completely rewritten because the original creator had left, and no one could grok it? Not that there is no way to reconcile fungibility with expressiveness and beauty, but the tradeoffs involved are tricky and will always end up disappointing somebody. [0] https://www.researchgate.net/publication/3246772_Planning_the_software_industrial_revolution https://www.researchgate.net/publication/3246772_Planning_th...