5 ms·

Why Paul Graham Is Wrong About Choosing an Esoteric Language (2018)

24 points by shubhamjain 4y ago

throw03172019 4y ago
Clojure (dialect of Lisp) has been a great choice for us.
- shubhamjain 4y ago
  I worked at a company where it was used. I was on the front-end team, so I didn't really get to understand the perks really well, but overall, it was frustrating how difficult it was for us to work on that codebase. It felt like to even get started I had switch my editor from VS Code to emacs. It was impossible to hire Clojure devs directly. They had to go through this training period. And honestly, it never felt like the choice of language had reduced the number of problems we encountered. That's my personal take though.
  - jacquesm 4y ago
    I tried contributing to a project a friend of mine worked on and it had the same requirement: change to emacs first. I'm not going to get rid of 35 years of muscle memory for common tasks just to work on something so that didn't pan out. But that doesn't stop me from appreciating the care and experience that went into designing Clojure, it's full of very nice balances, especially in the data structures and other low level implementation details.
  - ergocoder 4y ago
    Emacs is the only ide for closure? Wow.
    - closeparen 4y ago
      There is also Cursive, an IntelliJ plugin/distribution. It's commercial though, perhaps why the parent dismissed it. https://cursive-ide.com/ https://cursive-ide.com/
      - throw03172019 4y ago
        Yes, we use Cursive in IntelliJ and love it.
      - ergocoder 4y ago
        It is pretty bad when there is no free dev tool, and you would have to go hardcore by using Emacs.
        ravi-delia 4y ago
        Eh a simple cider config is hardly hardcore. Not quite as easy as a VSCode package install, but honestly pretty close. With a company config file to start you off it's just fine.
  - nathants 4y ago
    there is a critical mass of devs who want clojure[script] but not emacs: https://github.com/BetterThanTomorrow/calva https://github.com/BetterThanTomorrow/calva
  - throw03172019 4y ago
    We use Clojurescript on the frontend as well. Clojure everywhere! IntelliJ with Cursive plug-in is great. I never got into emacs.
jleyank 4y ago
I suspect it has to be an esoteric language that’s used in more than the hiring company. Otherwise, you take nothing away with you other than reputation when you leave. This could occur if, say, the compiler is licensed as part of their software offering.
karmakaze 4y ago
This post seems even less valid than in 2018. > Hiring is Harder [...] When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t. However, the hiring pool itself would shrink massively. [...] The company has to lower the criterion and train engineers in functional programming instead. Many mainstream languages now support functional constructs, so there should be plenty of developers that could readily pick up an actual functional language that uses those now familiar constructions. > Less Resources > [...] If an open source solution already has solved a problem that you’ve, you don’t have spend hours doing the same thing. And this is not just about libraries. [...] everything is better for a mature language. We now have choices like Clojure with the Java ecosystem behind it, or F# with .NET ecosystem behind it. The choice is not either-or. > Familiarity of a Language Isn’t a Great Criterion > Preferred language/framework is a personal choice. I prefer to choose a stack that has worked for me for all the years, while somebody may believe that newFooLang benefits in the longer run. I don’t think it’s wise to sideline all programmers who are perfectly happy with their choice of technology. So it comes down to the stated preference of the author vs the preference of PG or others. Good luck convincing Jane Street to use Python instead of OCaml. > [...] Facebook was pretty successful [...] PHP. > Good engineers must be concerned with solving problems that users have, not the tooling used in the solution. Paul Graham’s idea promotes a wrong order of priorities. If you want to hire a very talented small team to do some very complex work, you don't want good engineers, you want great ones. Great engineers won't choose to use PHP because they have the choice to work at practically any company. They could also learn a new language without much fuss. The important factor here is that by having a small team there are much less 'communication losses' that occur by having more bodies. If the company you're building is well served by a React front-end on a CRUD api, by all means choose whatever tech you can get good and average developers for. I know I wouldn't work for Facebook using PHP.
ezoe 4y ago
If you chose an esoteric language to solve your core business, never let existing programmers to leave your company no matter what: higher wages, unlimited paid leave, anything. Because once the original programmers leave the company, nobody can maintain that massive technical debt. In fact, even the original programmers could not maintain the code. That's why they leave. They run away before their bad job became apparent. That is, they quickly wrote a barely working code without considering the long-term sustainability, get paid, and run away... to be hired by another victim. Because it's written in an esoteric language, you can't easily notice how bad it was written. Then your company will be filled with decent but low-motivated programmers who does the barely minimum job to keep the code running. Their motivations are low because it's a complete mess of a technical debt. Nobody understand how the code works and worse. Debugging feature is limited because it's an esoteric language. It's running on a decade old software stack because upgrading any OS or software break the code. It's a dead end. No way to solve the root of the problem. It kept running until your business became too obsolete to earn money or epic fail happens.
- closeparen 4y ago
  My experience in hypergrowth-to-IPO world is everything gets rewritten a little while after its original authors move on, no matter the language. My experience is also that picking up a working familiarity with esoteric languages, while more demanding than shitting out boilerplate-heavy code in non-expressive languages, is considerably less demanding than leaning to pass LeetCode interviews. Plenty of people seem willing to do the latter!
  - ezoe 4y ago
    Well, people who can write in less popular languages are definitely above average programmers. But I think it just mean they can write code in their own instead of copy&pasting from the random web sites. Being a less popular languages means you can't find convenient example codes from the Internet. Still, being able to write code in their own doesn't mean they can write a good code. I witnessed a complex recursive code with a bug on edge case in a functional language. It could be easily and cleanly written by using common practice of that language and its standard library, like foldl. Also, code lives longer than you expected.
xupybd 4y ago
I picked up F# over a year without much focus. It really isn't that hard to learn a functional language if it interests you. I don't think training staff would be that hard. The advantage of a functional language is not all the crazy things you could do, it's the things you can't do. Well, in the case of F# the things that are harder to do. You have immutability and a preference for pure functions. All of that means it's easier to reason about the code. Of course you can write super complex functional code that no one can understand but from what I've found it's easier to create something simple and easy to maintain. There is also something about documentation in the F# world that I've not seen before. The docs read like a class on the tools https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/

24 points by shubhamjain 4y ago

throw03172019 4y ago

Clojure (dialect of Lisp) has been a great choice for us.

shubhamjain 4y ago
I worked at a company where it was used. I was on the front-end team, so I didn't really get to understand the perks really well, but overall, it was frustrating how difficult it was for us to work on that codebase. It felt like to even get started I had switch my editor from VS Code to emacs. It was impossible to hire Clojure devs directly. They had to go through this training period. And honestly, it never felt like the choice of language had reduced the number of problems we encountered. That's my personal take though.
- jacquesm 4y ago
  I tried contributing to a project a friend of mine worked on and it had the same requirement: change to emacs first. I'm not going to get rid of 35 years of muscle memory for common tasks just to work on something so that didn't pan out. But that doesn't stop me from appreciating the care and experience that went into designing Clojure, it's full of very nice balances, especially in the data structures and other low level implementation details.
- ergocoder 4y ago
  Emacs is the only ide for closure? Wow.
  - closeparen 4y ago
    There is also Cursive, an IntelliJ plugin/distribution. It's commercial though, perhaps why the parent dismissed it. https://cursive-ide.com/ https://cursive-ide.com/
    - throw03172019 4y ago
      Yes, we use Cursive in IntelliJ and love it.
    - ergocoder 4y ago
      It is pretty bad when there is no free dev tool, and you would have to go hardcore by using Emacs.
      - ravi-delia 4y ago
        Eh a simple cider config is hardly hardcore. Not quite as easy as a VSCode package install, but honestly pretty close. With a company config file to start you off it's just fine.
- nathants 4y ago
  there is a critical mass of devs who want clojure[script] but not emacs: https://github.com/BetterThanTomorrow/calva https://github.com/BetterThanTomorrow/calva
- throw03172019 4y ago
  We use Clojurescript on the frontend as well. Clojure everywhere! IntelliJ with Cursive plug-in is great. I never got into emacs.

jleyank 4y ago

I suspect it has to be an esoteric language that’s used in more than the hiring company. Otherwise, you take nothing away with you other than reputation when you leave. This could occur if, say, the compiler is licensed as part of their software offering.

karmakaze 4y ago

This post seems even less valid than in 2018. > Hiring is Harder [...] When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t. However, the hiring pool itself would shrink massively. [...] The company has to lower the criterion and train engineers in functional programming instead. Many mainstream languages now support functional constructs, so there should be plenty of developers that could readily pick up an actual functional language that uses those now familiar constructions. > Less Resources > [...] If an open source solution already has solved a problem that you’ve, you don’t have spend hours doing the same thing. And this is not just about libraries. [...] everything is better for a mature language. We now have choices like Clojure with the Java ecosystem behind it, or F# with .NET ecosystem behind it. The choice is not either-or. > Familiarity of a Language Isn’t a Great Criterion > Preferred language/framework is a personal choice. I prefer to choose a stack that has worked for me for all the years, while somebody may believe that newFooLang benefits in the longer run. I don’t think it’s wise to sideline all programmers who are perfectly happy with their choice of technology. So it comes down to the stated preference of the author vs the preference of PG or others. Good luck convincing Jane Street to use Python instead of OCaml. > [...] Facebook was pretty successful [...] PHP. > Good engineers must be concerned with solving problems that users have, not the tooling used in the solution. Paul Graham’s idea promotes a wrong order of priorities. If you want to hire a very talented small team to do some very complex work, you don't want good engineers, you want great ones. Great engineers won't choose to use PHP because they have the choice to work at practically any company. They could also learn a new language without much fuss. The important factor here is that by having a small team there are much less 'communication losses' that occur by having more bodies. If the company you're building is well served by a React front-end on a CRUD api, by all means choose whatever tech you can get good and average developers for. I know I wouldn't work for Facebook using PHP.

ezoe 4y ago

If you chose an esoteric language to solve your core business, never let existing programmers to leave your company no matter what: higher wages, unlimited paid leave, anything. Because once the original programmers leave the company, nobody can maintain that massive technical debt. In fact, even the original programmers could not maintain the code. That's why they leave. They run away before their bad job became apparent. That is, they quickly wrote a barely working code without considering the long-term sustainability, get paid, and run away... to be hired by another victim. Because it's written in an esoteric language, you can't easily notice how bad it was written. Then your company will be filled with decent but low-motivated programmers who does the barely minimum job to keep the code running. Their motivations are low because it's a complete mess of a technical debt. Nobody understand how the code works and worse. Debugging feature is limited because it's an esoteric language. It's running on a decade old software stack because upgrading any OS or software break the code. It's a dead end. No way to solve the root of the problem. It kept running until your business became too obsolete to earn money or epic fail happens.

closeparen 4y ago
My experience in hypergrowth-to-IPO world is everything gets rewritten a little while after its original authors move on, no matter the language. My experience is also that picking up a working familiarity with esoteric languages, while more demanding than shitting out boilerplate-heavy code in non-expressive languages, is considerably less demanding than leaning to pass LeetCode interviews. Plenty of people seem willing to do the latter!
- ezoe 4y ago
  Well, people who can write in less popular languages are definitely above average programmers. But I think it just mean they can write code in their own instead of copy&pasting from the random web sites. Being a less popular languages means you can't find convenient example codes from the Internet. Still, being able to write code in their own doesn't mean they can write a good code. I witnessed a complex recursive code with a bug on edge case in a functional language. It could be easily and cleanly written by using common practice of that language and its standard library, like foldl. Also, code lives longer than you expected.

xupybd 4y ago

I picked up F# over a year without much focus. It really isn't that hard to learn a functional language if it interests you. I don't think training staff would be that hard. The advantage of a functional language is not all the crazy things you could do, it's the things you can't do. Well, in the case of F# the things that are harder to do. You have immutability and a preference for pure functions. All of that means it's easier to reason about the code. Of course you can write super complex functional code that no one can understand but from what I've found it's easier to create something simple and easy to maintain. There is also something about documentation in the F# world that I've not seen before. The docs read like a class on the tools https://zaid-ajaj.github.io/the-elmish-book/#/ https://zaid-ajaj.github.io/the-elmish-book/#/