3 ms·

I like Scala and Haskell. The selling points of high assurances by their compilers appealed to me. Opinion: Something I did not anticipate is these languages a

I like Scala and Haskell. The selling points of high assurances by their compilers appealed to me. Opinion: Something I did not anticipate is these languages allow a high degree of individual choice in coding style by a programmer, and companies tend to dislike this. I have read this sentiment about Clojure shops; the original authors are very capable in the codebase but it can be hard to bring in new team members later. It seems to me most companies prefer less expressive languages with opinionated style guidelines. I have never worked with Python professionally, but apparently there is a high emphasis on style consistency in the community. Obviously there exist projects in less expressive languages that are hard to maintain, so maybe ease-of-onboarding and ease-of-maintenance depend on something else. I still believe the type system of Haskell can provide great benefits to codebase maintenance over the long term. If the coding style were restricted and opinionated, it might assist with company adoption.

Tanjreeve 3y ago
If your products biggest concern is fungibility of developers and controlling what developers can do then you likely wouldn't be getting any value from any of the group of expressive languages anyway. >Obviously there exist projects in less expressive languages that are hard to maintain This is the flip side of more conservative language choices. The moment you're off the beaten path you're doing way more custom stuff to work around the language. My favourite one I point at is Instagram's use of Python is commonly held up as "Python can do everything" but when you read their tech blogs you're basically reading "here's how we got some extremely skilled specialist language Devs to Jerry rig custom functionality onto python to create a flavour that could be doing absolutely anything. All to avoid hiring a few devs with a copy of a standard manual for some other language. > I still believe the type system of Haskell can provide great benefits to codebase maintenance over the long term. If the coding style were restricted and opinionated, it might assist with company adoption. Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack.
- peterbecich 3y ago
  All good points. Very interesting point about Instagram. The solution to that IMO is building upon a language-agnostic messaging system. I believe the Bezos API mandate addressed this. This would allow a small team to use a better-suited language and still interface with the rest of the company. > Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack. Interesting point; that there is no general-purpose language that perfectly encodes every business domain. I disagree with giving the developers the tools and getting out of the way. The management is still responsible for the outcome of the project and needs more control than this. Yes, fungibility of developers is a concern. If the developers hold equity in the project, they are incentivized to support fungibility as well, to allow the company to grow. IMO start-ups should reduce the proprietary code opinions as much as possible, and rely on well-publicized code patterns as much as possible. This both grows the hireable talent pool, and makes it easier for new hires to understand the system once inside. Since start-ups tend to pay less than large companies and the equity is high risk, it is unfair IMO to require new employees to learn a highly-opinionated proprietary start-up tech stack. The requirement to learn a proprietary stack is more justifiable in large companies where the financial compensation is more reliable and often higher.

Tanjreeve 3y ago

If your products biggest concern is fungibility of developers and controlling what developers can do then you likely wouldn't be getting any value from any of the group of expressive languages anyway. >Obviously there exist projects in less expressive languages that are hard to maintain This is the flip side of more conservative language choices. The moment you're off the beaten path you're doing way more custom stuff to work around the language. My favourite one I point at is Instagram's use of Python is commonly held up as "Python can do everything" but when you read their tech blogs you're basically reading "here's how we got some extremely skilled specialist language Devs to Jerry rig custom functionality onto python to create a flavour that could be doing absolutely anything. All to avoid hiring a few devs with a copy of a standard manual for some other language. > I still believe the type system of Haskell can provide great benefits to codebase maintenance over the long term. If the coding style were restricted and opinionated, it might assist with company adoption. Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack.

peterbecich 3y ago
All good points. Very interesting point about Instagram. The solution to that IMO is building upon a language-agnostic messaging system. I believe the Bezos API mandate addressed this. This would allow a small team to use a better-suited language and still interface with the rest of the company. > Counterpoint. What if it's an impossible task for languages to encode a business domain and they should give your developers the tools to do it and then get out of the way? Its still opinionated. Its just that the opinions are coming from your businesses stack. Interesting point; that there is no general-purpose language that perfectly encodes every business domain. I disagree with giving the developers the tools and getting out of the way. The management is still responsible for the outcome of the project and needs more control than this. Yes, fungibility of developers is a concern. If the developers hold equity in the project, they are incentivized to support fungibility as well, to allow the company to grow. IMO start-ups should reduce the proprietary code opinions as much as possible, and rely on well-publicized code patterns as much as possible. This both grows the hireable talent pool, and makes it easier for new hires to understand the system once inside. Since start-ups tend to pay less than large companies and the equity is high risk, it is unfair IMO to require new employees to learn a highly-opinionated proprietary start-up tech stack. The requirement to learn a proprietary stack is more justifiable in large companies where the financial compensation is more reliable and often higher.