3 ms·

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 t

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.

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.