4 ms·

We have had these discussions for many years (even pg wrote about Blub IIRC), but the real reason (IMO) is that language choice matters far less than we like to

We have had these discussions for many years (even pg wrote about Blub IIRC), but the real reason (IMO) is that language choice matters far less than we like to think. What business we choose to build with the language will outweighs the impact of language choice a hundredfold. Our decisions on CI/CD, our discipline on building clean architecture with whatever language we like matters more. In short, the things that make development a productive and enjoyable experience are linked less to the language than to the skill and professionalism of the development team - and "weird" languages tend to have more skilled and professional developers working in them, so the causality / correlation tends to get mixed up. The upshot is, worry less about learning Lisp at work, and more about fighting your corner on why we should rewrite that 3,000 line monster engine module that we all call each day but making changes to it is a nightmare.

Toine 6y ago
Amen. Or as Jobs said, "You've got to start with the customer experience first and work backwards to the technology. You can't start with the technology and try to figure out how you're gonna sell it" https://youtu.be/FF-tKLISfPE https://youtu.be/FF-tKLISfPE
- SiVal 6y ago
  And yet, iPad.
  - yibg 6y ago
    What about it? Are you claiming the iPad started from the user experience or technology?
  - qubex 6y ago
    What do you mean by that? I’ve been using iPads as my main computing devices for the past five years (and almost exclusively for the past three). It depends on your workflows.
  - SiVal 6y ago
    I'm responding to "You can't start with the technology and try to figure out how you're gonna sell it", not saying iPad is bad. I was referring to the remarkable history of iPad, which was designed to have certain features, not designed for a particular use. Jobs started on it before iPhone, attempting to combine his and Ive's favorite features: simple, multitouch, thinner!, no keyboard, no mouse, no stylus, no buttons, lightweight, handheld (not used plugged it), great screen, etc. It was not designed as a "solution" but as a great...thing...that would turn out to be great for...something. It was his baby, and he insisted that they keep working on it until they found a use, which they did: they turned it into an iPhone. That was smaller (screen size) than Jobs had planned, so he made them keep going on bigger versions. They would be so wonderful, they would be great at...something. When they released the first one in 2010, they were intentionally vague about its target market. They presented it as maybe a substitute for laptops for productivity apps, they presented it as sort of a better Kindle for reading, as an artist's tool (for artists who fingerpaint), etc., with the hope that with such a great collection of features, it would be like the original LaserWriter and turn out to be perfect for some market. Regardless of what that market would end up being, it did in fact start with the technology that two passionate designers wanted to exist for its own sake without knowing in advance what it would end up being used for.
logicchains 6y ago
>What business we choose to build with the language will outweighs the impact of language choice a hundredfold. This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that". Or for that matter if I decided to start a company to build a web browser in pure Ruby.
- thu2111 6y ago
  I kinda agree but can't help observing that quite a few HFT firms use Java, where it's also hard to write allocation free code. They use various approaches like pauseless GCs or just sizing the heap so that they don't need to collect during the day. HFT is also a continuum. There's a latency/strategy iteration tradeoff involved. Going "quite fast" can be better than going "super fast" if your quite fast strategy is better, but keeping at the edge of good strategies requires constant code changes. Hence the benefits of high level statically typed GCd languages.
bad_user 6y ago
> "What business we choose to build with the language will outweighs the impact of language choice a hundredfold." This is on one hand a truism that actually adds nothing to the discussion. In achieving success, of course the business matters. Even more so the best simplifications come from understanding the business domain, not from the tools used. --- On the other hand it's also patently false. Build a web browser in Ruby. Build an operating system in JavaScript. Build your average web app in C/C++. The tools used have inherent limits, being optimized for certain domains and not others, can make us more productive, can lower the defect rate and can keep us happy enough to see the project released. In my experience _some_ static FP languages can lower the defect rate, can make certain problems easier to tackle, can make the code easier to maintain and refactor and due to performance being reasonable, they tend to be more general purpose than other languages — this trait being a consequence of static typing, making performance good enough, coupled with the languages themselves still being high level enough. --- > "learning Lisp at work" Ah, I see the problem ... many of you thought Lisp is some sort of secret sauce. It isn't, it never was, Lisp is a freaking mess. The real problem in our industry is not applying the scientific method for advancing it. We thus rely on fashion and salesmen to sell us magic pills.
- pron 6y ago
  > On the other hand it's also patently false. The sentence "language choice matters far less than we like to think", which means something like "switching between most pairs of languages in most situations doesn't make a big difference", and your examples which mean "there exist pairs of languages as well as situations where switching between them makes a big difference" are completely compatible. In fact, I would say that the latter is not interesting because of course we know there are situations where high-performance languages are more or less appropriate, but the interesting question is whether languages that have similar aims and performance, and differ mostly in their linguistic features make a big difference. > In my experience Unfortunately, people will also support the effectiveness of homeopathic medicine based on their experience, and much more enthusiastically. I'm not doubting your sincerity, nor even the facts of your situation, but this doesn't count as evidence. On the other hand, the fact that different languages are tried in different places, in an industry with strong selective pressures, the fact that no single language or paradigm completely overtakes all others is evidence in favor of there not being a very big bottom-line impact.
StreamBright 6y ago
Yes, most languages you can use functional style
raverbashing 6y ago
Language choice matters. But, except for specific cases, and within an usually wide margin, it matters less than you think. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Yes, you'll shoot yourself in the foot if trying to write a website in C++ or maybe Java. But between Python/Ruby/Modern PHP, they will probably work fine. And the main issue I think is that, while some languages like Haskell (or Elixir, though it seems much better than Haskell) or Lisp or F#, etc might excel at some places, their advantages won't compensate for their disadvantages in the 80% of cases you don't need them (this is comparing with the modern language landscape - and even Java now is much better than Java 20yrs ago). I love this phrase from the article above: "The safest kind were the ones that wanted Oracle experience." though I think there's a deeper meaning: they're not safer because they're using Oracle. They're safer because they're picking Oracle (hence showing that their world view is narrow). Sure, they could be geniouses in disguise and picking Oracle for that 1% where it really is way better than the competition, but most likely they aren't.
deleted 6y ago
[deleted]
mythz 6y ago
That's basically the crux of it, syntax matters a lot less in language adoption. Most mainstream languages benefit from a "killer" app, feature, software-class or platform, which is what sees Swift become hugely popular because of iOS, Java/Kotlin getting a boost from Android, Browsers popularizing JS and many games & OS Software still written in C++ for its zero overhead abstractions. Ecosystem, native libraries, community, knowledge, tooling, familiarity, domain suitability, hireability and overall general dev productivity & UX matters a lot more in language adoption. I'm not seeing any big draw card from a Killer App that clearly highlights its superiority over more popular alternative languages. There's many niche areas where FP shines like implementing compilers, statistics & math models, but I don't see much appeal in mainstream usage where it adds enough value over dominant languages to overcome its deficiencies in other areas. A clear example is AI which is an area that FP would excel at but is still dominated by Python & its dominant ecosystem. The value proposition of pure FP languages also gets diminished as mainstream languages adopts FP language features.
mrobot 6y ago
My feeling right now is i disagree with this. I think there is a certain amount of clarity in functional languages that more imperative languages are striving for as they develop maybe. You seem to be able to express more for less in most functional languages. Out of curiosity, do you yourself work well and quickly in functional languages? CI/CD is also separable from this issue, i think. But the thing that you can do well with it which is write and regularly run tests is not. My thinking is the main problem is people just aren't exposed to functional languages enough and get stuck working to line theirs and other peoples' pockets before they have had enough exposure. I also have some gripes with the actual document which i will post in a top-level reply.
leandot 6y ago
While true for the more trivial cases there are examples that show the opposite e.g. Whatsapp's choice of Erlang allowed it to scale up easier with less engineers - https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/ https://www.wired.com/2015/09/whatsapp-serves-900-million-us...

Toine 6y ago

Amen. Or as Jobs said, "You've got to start with the customer experience first and work backwards to the technology. You can't start with the technology and try to figure out how you're gonna sell it" https://youtu.be/FF-tKLISfPE https://youtu.be/FF-tKLISfPE

SiVal 6y ago
And yet, iPad.
- yibg 6y ago
  What about it? Are you claiming the iPad started from the user experience or technology?
- qubex 6y ago
  What do you mean by that? I’ve been using iPads as my main computing devices for the past five years (and almost exclusively for the past three). It depends on your workflows.
- SiVal 6y ago
  I'm responding to "You can't start with the technology and try to figure out how you're gonna sell it", not saying iPad is bad. I was referring to the remarkable history of iPad, which was designed to have certain features, not designed for a particular use. Jobs started on it before iPhone, attempting to combine his and Ive's favorite features: simple, multitouch, thinner!, no keyboard, no mouse, no stylus, no buttons, lightweight, handheld (not used plugged it), great screen, etc. It was not designed as a "solution" but as a great...thing...that would turn out to be great for...something. It was his baby, and he insisted that they keep working on it until they found a use, which they did: they turned it into an iPhone. That was smaller (screen size) than Jobs had planned, so he made them keep going on bigger versions. They would be so wonderful, they would be great at...something. When they released the first one in 2010, they were intentionally vague about its target market. They presented it as maybe a substitute for laptops for productivity apps, they presented it as sort of a better Kindle for reading, as an artist's tool (for artists who fingerpaint), etc., with the hope that with such a great collection of features, it would be like the original LaserWriter and turn out to be perfect for some market. Regardless of what that market would end up being, it did in fact start with the technology that two passionate designers wanted to exist for its own sake without knowing in advance what it would end up being used for.

logicchains 6y ago

>What business we choose to build with the language will outweighs the impact of language choice a hundredfold. This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that". Or for that matter if I decided to start a company to build a web browser in pure Ruby.

thu2111 6y ago
I kinda agree but can't help observing that quite a few HFT firms use Java, where it's also hard to write allocation free code. They use various approaches like pauseless GCs or just sizing the heap so that they don't need to collect during the day. HFT is also a continuum. There's a latency/strategy iteration tradeoff involved. Going "quite fast" can be better than going "super fast" if your quite fast strategy is better, but keeping at the edge of good strategies requires constant code changes. Hence the benefits of high level statically typed GCd languages.

bad_user 6y ago

> "What business we choose to build with the language will outweighs the impact of language choice a hundredfold." This is on one hand a truism that actually adds nothing to the discussion. In achieving success, of course the business matters. Even more so the best simplifications come from understanding the business domain, not from the tools used. --- On the other hand it's also patently false. Build a web browser in Ruby. Build an operating system in JavaScript. Build your average web app in C/C++. The tools used have inherent limits, being optimized for certain domains and not others, can make us more productive, can lower the defect rate and can keep us happy enough to see the project released. In my experience _some_ static FP languages can lower the defect rate, can make certain problems easier to tackle, can make the code easier to maintain and refactor and due to performance being reasonable, they tend to be more general purpose than other languages — this trait being a consequence of static typing, making performance good enough, coupled with the languages themselves still being high level enough. --- > "learning Lisp at work" Ah, I see the problem ... many of you thought Lisp is some sort of secret sauce. It isn't, it never was, Lisp is a freaking mess. The real problem in our industry is not applying the scientific method for advancing it. We thus rely on fashion and salesmen to sell us magic pills.

pron 6y ago
> On the other hand it's also patently false. The sentence "language choice matters far less than we like to think", which means something like "switching between most pairs of languages in most situations doesn't make a big difference", and your examples which mean "there exist pairs of languages as well as situations where switching between them makes a big difference" are completely compatible. In fact, I would say that the latter is not interesting because of course we know there are situations where high-performance languages are more or less appropriate, but the interesting question is whether languages that have similar aims and performance, and differ mostly in their linguistic features make a big difference. > In my experience Unfortunately, people will also support the effectiveness of homeopathic medicine based on their experience, and much more enthusiastically. I'm not doubting your sincerity, nor even the facts of your situation, but this doesn't count as evidence. On the other hand, the fact that different languages are tried in different places, in an industry with strong selective pressures, the fact that no single language or paradigm completely overtakes all others is evidence in favor of there not being a very big bottom-line impact.

StreamBright 6y ago

Yes, most languages you can use functional style

raverbashing 6y ago

Language choice matters. But, except for specific cases, and within an usually wide margin, it matters less than you think. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Yes, you'll shoot yourself in the foot if trying to write a website in C++ or maybe Java. But between Python/Ruby/Modern PHP, they will probably work fine. And the main issue I think is that, while some languages like Haskell (or Elixir, though it seems much better than Haskell) or Lisp or F#, etc might excel at some places, their advantages won't compensate for their disadvantages in the 80% of cases you don't need them (this is comparing with the modern language landscape - and even Java now is much better than Java 20yrs ago). I love this phrase from the article above: "The safest kind were the ones that wanted Oracle experience." though I think there's a deeper meaning: they're not safer because they're using Oracle. They're safer because they're picking Oracle (hence showing that their world view is narrow). Sure, they could be geniouses in disguise and picking Oracle for that 1% where it really is way better than the competition, but most likely they aren't.

deleted 6y ago

[deleted]

mythz 6y ago

That's basically the crux of it, syntax matters a lot less in language adoption. Most mainstream languages benefit from a "killer" app, feature, software-class or platform, which is what sees Swift become hugely popular because of iOS, Java/Kotlin getting a boost from Android, Browsers popularizing JS and many games & OS Software still written in C++ for its zero overhead abstractions. Ecosystem, native libraries, community, knowledge, tooling, familiarity, domain suitability, hireability and overall general dev productivity & UX matters a lot more in language adoption. I'm not seeing any big draw card from a Killer App that clearly highlights its superiority over more popular alternative languages. There's many niche areas where FP shines like implementing compilers, statistics & math models, but I don't see much appeal in mainstream usage where it adds enough value over dominant languages to overcome its deficiencies in other areas. A clear example is AI which is an area that FP would excel at but is still dominated by Python & its dominant ecosystem. The value proposition of pure FP languages also gets diminished as mainstream languages adopts FP language features.

mrobot 6y ago

My feeling right now is i disagree with this. I think there is a certain amount of clarity in functional languages that more imperative languages are striving for as they develop maybe. You seem to be able to express more for less in most functional languages. Out of curiosity, do you yourself work well and quickly in functional languages? CI/CD is also separable from this issue, i think. But the thing that you can do well with it which is write and regularly run tests is not. My thinking is the main problem is people just aren't exposed to functional languages enough and get stuck working to line theirs and other peoples' pockets before they have had enough exposure. I also have some gripes with the actual document which i will post in a top-level reply.

leandot 6y ago

While true for the more trivial cases there are examples that show the opposite e.g. Whatsapp's choice of Erlang allowed it to scale up easier with less engineers - https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/ https://www.wired.com/2015/09/whatsapp-serves-900-million-us...