7 ms·

This article is a good example of why I don’t use uncommon programming languages for actual projects. I watched an Elm-based project steadily slip behind schedu

This article is a good example of why I don’t use uncommon programming languages for actual projects. I watched an Elm-based project steadily slip behind schedule while the team insisted that Elm and FP were actually going to save us a lot of time… eventually some day. These uncommon FP frameworks and languages can be good tools in the right, experienced hands. They can also be fun for side projects and as learning exercises. But every time I’ve watched programmers try to use uncommon functional languages for real projects they end up like this article: > More accurately, learning Functional Programming concepts used in Haskell in 3 months after having thrown out 30,000 lines of code on a project that was now monumentally behind schedule was the hardest thing I had to do in my career. When you’ve reached the point of being severely behind schedule, throwing out mountains of code along the way, and struggling mightily just to get basic things accomplished: It’s time to stop. Don’t double down on a new language that you also have to learn from scratch. Pick something tried and true and get the work done. Revisit the functional language at a later time for an unimportant project or a side project, not something with a deadline. If the programming language or ideology has become more important than shipping the project, we’ve lost the point.

guerrilla 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. 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.
Igelau 5y ago
Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.
- adregan 5y ago
  I agree. Assuming this article is about the author’s experiences in early 2019, Elm has only had one release since then. They wouldn’t have missed out on much at all by shipping with a forked compiler but would have gained a lot of time to migrate. The fork wouldn’t necessarily need to be public either.
- sam0x17 5y ago
  Yeah I was literally expecting the next paragraph to be "and that's how elixir was born!"
- PragmaticPulp 5y ago
  > Really I think the mistake there was not forking Elm. Forking a framework and trying to maintain a new, separate open source project is a huge burden. There is no way that would have fixed their problems of being behind schedule, but it definitely would have permanently worsened their maintenance overhead. They needed to scrap the alternate language/framework plans and return to something safe and proven as soon as it became obvious that they were too far off track. Continuing to double down on commitments to unpopular frameworks (or worse, creating your own niche fork to maintain) would only worsen the problem.
- dimator 5y ago
  Rather than forking elm, there's purescript, which is unlike elm in all the restrictive ways. It seems to have regular releases and plenty of packages as well. https://www.purescript.org/ https://www.purescript.org/ https://pursuit.purescript.org/ https://pursuit.purescript.org/
  - yawaramin 5y ago
    Or port over to bucklescript-tea (a port of the Elm architecture to the OCaml-to-JS compiler BuckleScript) using the Philip2 migration tool, which was announced almost a year before OP was published: https://medium.com/darklang/philip2-an-elm-to-reasonml-compiler-a210aaa6cd04 https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...
cerved 5y ago
I wouldn't say the used an uncommon language. They build some kind of tool to run on top of Elm which wasn't inline with the goals of the Elm project (unlcear how). Seems like something that should've been investigated before commiting
- emodendroket 5y ago
  It is inevitable that someone will use a language in the way the developers didn't intend, but this is the only time I've heard of the developers specifically setting out to break their language for some users.
  - cerved 5y ago
    that seems to be the angle presented by the author but that doesn't mean that is what happened
    - alisonkisk 5y ago
      Elm author is quite vocal about wanting people to only be able to do things one way. It's the reason people choose Elm.
  - 3836293648 5y ago
    The Elm guy is infamous for this kind of thing
  - theCodeStig 5y ago
    That's not functional programming at fault; that's a case of hostility toward users.
emodendroket 5y ago
I'll say this though: functional techniques really can save a lot of time. I'm not sure I'd recommend Scala for a new project if you don't have Scala experts already, but I apply ideas I got from my experience using it to projects all the time.
- isbvhodnvemrwvn 5y ago
  The question then is whether it was functional programming that actually made the difference, or the people who had enough perseverance and skill to actually learn Scala in the first place running the project. I've found that people who go out of their way to learn things like that would be more productive regardless of the language itself.
  - emodendroket 5y ago
    Well, the ideas I liked, stuff like deferring side effects and avoiding state, were functional ideas. You see a lot of functional concepts and constructs bleeding out into mainstream languages (just look at the last few C# releases, for instance, which look like a list of features borrowed from Scala), which I think will be their legacy more than widespread adoption.
    - andrekandre 5y ago
      > stuff like deferring side effects and avoiding state is that really "functional programming" or just good practice?
      - emodendroket 5y ago
        To the extent it’s considered good practice now I think FP deserves a lot of credit.
        andrekandre 5y ago
        i see, thanks for the reply one reason i asked is because while i don't really come from an FP background (as a student, i started with c/obj-c), after working in the field it was always appaling at how many variables and global state people would put in their code and how many side-effects were present... its just something that seemed so obvious even in "oop-land" but maybe im just an outlier...
wyager 5y ago
FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is probably not a good idea though.
- Jare 5y ago
  That's the problem with "uncommon": how do you obtain that background and how do you learn what you're doing? (of course, not just you - you, the entire team, and future hires)
  - throwaway81523 5y ago
    The same way you learn anything else that is difficult: time and practice, and start with fundamentals. You can't put it on any work-related critical path until you have it down solid.
    - Jare 5y ago
      I mean in the context of an existing company / team of nontrivial size. Most cases I know of, the uncommon language was there from the days of it being a personal or 1-person project. For other types of tech (e.g. infrastructure) sometimes the new/different capabilities are such a defining feature that the lack of familiarity is not as scary. But in programming languages, you can fundamentally do pretty much anything in existing and well known ones.
      - throwaway81523 5y ago
        Have fun writing a web app in assembly language ;). Yes it's been done, but not often, and for good reason. Haskell is sort of a special case: it's best suited for writing compilers, but has been pressed into just about everything else because people are into it for its own sake. Yes if you're running a C++ shop and someone leaves behind a small program in Haskell, you're probably better off reimplementing it than becoming or hiring a Haskell guru just to maintain that thing. That's a question of whether to learn Haskell, not how to learn it. In the case of the linked article, the author was the one who decided to get the company involved with FP, and gave his thoughts on whether it was worth it. I can certainly support the idea that someone juggling all the plates required to keep a company running, has no time to embark on a deep and nerdy self-education project in something as abstruse as FP. Better to keep it at the level of a side interest or hobby until you're comfortable with it, before even thinking of doing anything important with it.
roenxi 5y ago
Also the basic pitch of functional programming is "we have better abstractions, you'll write better code". The basic pitch of something like Java is "everyone knows how to get things done in Java" and of Python "there is a right way to get the task done, and we will tell you what that way is". There is a fundamental mindset here that the Functional languages aren't task-first. Not in the languages, mind, it is in the community. And the tasks themselves can be so simple once the abstractions are under control that people don't write tutorials about the task. It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand.
- PragmaticPulp 5y ago
  > It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand. This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done. I think this plays into our tendency to view learning and education as investments rather than costs. That may be true on a personal level when using your own time, but using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.
  - AlexCoventry 5y ago
    I think this problem is specific to the Haskell community. No one's going to tell a brand-new Clojurist that they need to learn about reducers.
    - cutler 5y ago
      Agreed. Clojure is the most productive language I've ever used.
a9h74j 5y ago
Know when you have met your nemesis. Switching fresh to FP: Now you have two nemeses.
- fsckboy 5y ago
  viva jwz
mbrodersen 5y ago
I mostly agree. However you could use the same argument to dismiss any programming language the moment any team is failing using the language. No programming language has a zero fail track record. Because success depends on context and team much more than programming language.

guerrilla 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. 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.

Igelau 5y ago

Really I think the mistake there was not forking Elm. Maybe the fork wouldn't have been popular long term, but at least they'd ship.

adregan 5y ago
I agree. Assuming this article is about the author’s experiences in early 2019, Elm has only had one release since then. They wouldn’t have missed out on much at all by shipping with a forked compiler but would have gained a lot of time to migrate. The fork wouldn’t necessarily need to be public either.
sam0x17 5y ago
Yeah I was literally expecting the next paragraph to be "and that's how elixir was born!"
PragmaticPulp 5y ago
> Really I think the mistake there was not forking Elm. Forking a framework and trying to maintain a new, separate open source project is a huge burden. There is no way that would have fixed their problems of being behind schedule, but it definitely would have permanently worsened their maintenance overhead. They needed to scrap the alternate language/framework plans and return to something safe and proven as soon as it became obvious that they were too far off track. Continuing to double down on commitments to unpopular frameworks (or worse, creating your own niche fork to maintain) would only worsen the problem.
dimator 5y ago
Rather than forking elm, there's purescript, which is unlike elm in all the restrictive ways. It seems to have regular releases and plenty of packages as well. https://www.purescript.org/ https://www.purescript.org/ https://pursuit.purescript.org/ https://pursuit.purescript.org/
- yawaramin 5y ago
  Or port over to bucklescript-tea (a port of the Elm architecture to the OCaml-to-JS compiler BuckleScript) using the Philip2 migration tool, which was announced almost a year before OP was published: https://medium.com/darklang/philip2-an-elm-to-reasonml-compiler-a210aaa6cd04 https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...

cerved 5y ago

I wouldn't say the used an uncommon language. They build some kind of tool to run on top of Elm which wasn't inline with the goals of the Elm project (unlcear how). Seems like something that should've been investigated before commiting

emodendroket 5y ago
It is inevitable that someone will use a language in the way the developers didn't intend, but this is the only time I've heard of the developers specifically setting out to break their language for some users.
- cerved 5y ago
  that seems to be the angle presented by the author but that doesn't mean that is what happened
  - alisonkisk 5y ago
    Elm author is quite vocal about wanting people to only be able to do things one way. It's the reason people choose Elm.
- 3836293648 5y ago
  The Elm guy is infamous for this kind of thing
- theCodeStig 5y ago
  That's not functional programming at fault; that's a case of hostility toward users.

emodendroket 5y ago

I'll say this though: functional techniques really can save a lot of time. I'm not sure I'd recommend Scala for a new project if you don't have Scala experts already, but I apply ideas I got from my experience using it to projects all the time.

isbvhodnvemrwvn 5y ago
The question then is whether it was functional programming that actually made the difference, or the people who had enough perseverance and skill to actually learn Scala in the first place running the project. I've found that people who go out of their way to learn things like that would be more productive regardless of the language itself.
- emodendroket 5y ago
  Well, the ideas I liked, stuff like deferring side effects and avoiding state, were functional ideas. You see a lot of functional concepts and constructs bleeding out into mainstream languages (just look at the last few C# releases, for instance, which look like a list of features borrowed from Scala), which I think will be their legacy more than widespread adoption.
  - andrekandre 5y ago
    > stuff like deferring side effects and avoiding state is that really "functional programming" or just good practice?
    - emodendroket 5y ago
      To the extent it’s considered good practice now I think FP deserves a lot of credit.
      - andrekandre 5y ago
        i see, thanks for the reply one reason i asked is because while i don't really come from an FP background (as a student, i started with c/obj-c), after working in the field it was always appaling at how many variables and global state people would put in their code and how many side-effects were present... its just something that seemed so obvious even in "oop-land" but maybe im just an outlier...

wyager 5y ago

FP is absolutely way more time-efficient for most kinds of projects, if you know what you’re doing. Switching without having sufficient background first is probably not a good idea though.

Jare 5y ago
That's the problem with "uncommon": how do you obtain that background and how do you learn what you're doing? (of course, not just you - you, the entire team, and future hires)
- throwaway81523 5y ago
  The same way you learn anything else that is difficult: time and practice, and start with fundamentals. You can't put it on any work-related critical path until you have it down solid.
  - Jare 5y ago
    I mean in the context of an existing company / team of nontrivial size. Most cases I know of, the uncommon language was there from the days of it being a personal or 1-person project. For other types of tech (e.g. infrastructure) sometimes the new/different capabilities are such a defining feature that the lack of familiarity is not as scary. But in programming languages, you can fundamentally do pretty much anything in existing and well known ones.
    - throwaway81523 5y ago
      Have fun writing a web app in assembly language ;). Yes it's been done, but not often, and for good reason. Haskell is sort of a special case: it's best suited for writing compilers, but has been pressed into just about everything else because people are into it for its own sake. Yes if you're running a C++ shop and someone leaves behind a small program in Haskell, you're probably better off reimplementing it than becoming or hiring a Haskell guru just to maintain that thing. That's a question of whether to learn Haskell, not how to learn it. In the case of the linked article, the author was the one who decided to get the company involved with FP, and gave his thoughts on whether it was worth it. I can certainly support the idea that someone juggling all the plates required to keep a company running, has no time to embark on a deep and nerdy self-education project in something as abstruse as FP. Better to keep it at the level of a side interest or hobby until you're comfortable with it, before even thinking of doing anything important with it.

roenxi 5y ago

Also the basic pitch of functional programming is "we have better abstractions, you'll write better code". The basic pitch of something like Java is "everyone knows how to get things done in Java" and of Python "there is a right way to get the task done, and we will tell you what that way is". There is a fundamental mindset here that the Functional languages aren't task-first. Not in the languages, mind, it is in the community. And the tasks themselves can be so simple once the abstractions are under control that people don't write tutorials about the task. It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand.

PragmaticPulp 5y ago
> It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand. This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done. I think this plays into our tendency to view learning and education as investments rather than costs. That may be true on a personal level when using your own time, but using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.
- AlexCoventry 5y ago
  I think this problem is specific to the Haskell community. No one's going to tell a brand-new Clojurist that they need to learn about reducers.
  - cutler 5y ago
    Agreed. Clojure is the most productive language I've ever used.

a9h74j 5y ago

Know when you have met your nemesis. Switching fresh to FP: Now you have two nemeses.

fsckboy 5y ago
viva jwz

mbrodersen 5y ago

I mostly agree. However you could use the same argument to dismiss any programming language the moment any team is failing using the language. No programming language has a zero fail track record. Because success depends on context and team much more than programming language.