5 ms·

I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. Just know what you're doing or do

I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. Just know what you're doing or don't do it.

PragmaticPulp 5y ago
> I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. These two points are closely related, though. Common tools will always have more available programmers, more documentation, more tutorials, more help, more libraries, more maturity. We had a server written in a functional language at a company I worked at. It was fine, but when the two people who wrote it left the company it became a huge pain point to even hire someone to work on it. Consultants knew this and demanded exorbitant fees for basic work on the project. Eventually we just rewrote it from scratch in a common language and saved a huge amount of time and money compared to trying to build teams and schedules around this obscure language.
- deleted 5y ago
  [deleted]
- cerved 5y ago
  which language?
- AzzieElbab 5y ago
  What if I told you that common languages are rapidly adopting futures from functional languages? Go being a notable exception.
  - Jasper_ 5y ago
    As far as I know, the Future concept for async/await started with Twisted's Deferred, which is a framework for Python. It's not really from functional land.
    - cerved 5y ago
      futures have been around since the 80s afaik
    - nextaccountic 5y ago
      Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing". [0] Applicative programming is an older term for functional programming[1], but note this isn't pure functional programming like in Haskell; it's functional programming like in Scheme and Javascript. [0] I can't find a pdf of the book, but it was mentioned here https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises - the book calls it promises [1] https://en.wikipedia.org/wiki/Applicative_programming_language https://en.wikipedia.org/wiki/Applicative_programming_langua...
      - dragonwriter 5y ago
        > Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing". According to Wikipedia, Promises were, Futures (which are similar but not identical) were proposed in a 1977 paper. All of the closely related concepts of promises, futures, logic variables, and dataflow variables were used in functional languages first, and long before their use in, or the existence of, Twisted.
    - rowanG077 5y ago
      I don't think python invited a single thing tbh.
  - PragmaticPulp 5y ago
    > What if I told you that common languages are rapidly adopting futures from functional languages? I use functional paradigms in mainstream languages. No need to be snarky or sarcastic. That’s not what this article is about, though. Using Elm and Haskell for projects is not mainstream.
  - AzzieElbab 5y ago
    lol I meant to say "features", not futures. Sorry
  - jatone 5y ago
    id tell you duh, and go actually has (or will have soon) the pieces for the majority of the daily useful functional programming concepts. namely first class and polymorphic functions.
- guerrilla 5y ago
  > more documentation, more tutorials, more help, more libraries, more maturity. Haskell's got all that but I can't argue with it needing more programmers.

I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. Just know what you're doing or don't do it.

PragmaticPulp 5y ago

> I think it's more that you shouldn't use a tool that you're incompetent at. It has nothing to do with how common or not it is. These two points are closely related, though. Common tools will always have more available programmers, more documentation, more tutorials, more help, more libraries, more maturity. We had a server written in a functional language at a company I worked at. It was fine, but when the two people who wrote it left the company it became a huge pain point to even hire someone to work on it. Consultants knew this and demanded exorbitant fees for basic work on the project. Eventually we just rewrote it from scratch in a common language and saved a huge amount of time and money compared to trying to build teams and schedules around this obscure language.

deleted 5y ago
[deleted]
cerved 5y ago
which language?
AzzieElbab 5y ago
What if I told you that common languages are rapidly adopting futures from functional languages? Go being a notable exception.
- Jasper_ 5y ago
  As far as I know, the Future concept for async/await started with Twisted's Deferred, which is a framework for Python. It's not really from functional land.
  - cerved 5y ago
    futures have been around since the 80s afaik
  - nextaccountic 5y ago
    Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing". [0] Applicative programming is an older term for functional programming[1], but note this isn't pure functional programming like in Haskell; it's functional programming like in Scheme and Javascript. [0] I can't find a pdf of the book, but it was mentioned here https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises - the book calls it promises [1] https://en.wikipedia.org/wiki/Applicative_programming_language https://en.wikipedia.org/wiki/Applicative_programming_langua...
    - dragonwriter 5y ago
      > Futures were first proposed in 1976, in a book called "The Impact of Applicative Programming on Multiprocessing". According to Wikipedia, Promises were, Futures (which are similar but not identical) were proposed in a 1977 paper. All of the closely related concepts of promises, futures, logic variables, and dataflow variables were used in functional languages first, and long before their use in, or the existence of, Twisted.
  - rowanG077 5y ago
    I don't think python invited a single thing tbh.
- PragmaticPulp 5y ago
  > What if I told you that common languages are rapidly adopting futures from functional languages? I use functional paradigms in mainstream languages. No need to be snarky or sarcastic. That’s not what this article is about, though. Using Elm and Haskell for projects is not mainstream.
- AzzieElbab 5y ago
  lol I meant to say "features", not futures. Sorry
- jatone 5y ago
  id tell you duh, and go actually has (or will have soon) the pieces for the majority of the daily useful functional programming concepts. namely first class and polymorphic functions.
guerrilla 5y ago
> more documentation, more tutorials, more help, more libraries, more maturity. Haskell's got all that but I can't argue with it needing more programmers.