4 ms·

Have tried this with Common Lisp and Haskell. I think the biggest factors in adoption are: being in the right place at the right time and app/platform exclusiv

Have tried this with Common Lisp and Haskell. I think the biggest factors in adoption are: being in the right place at the right time and app/platform exclusivity. That's a lot harder to overcome these days. I'm starting to doubt if we'll ever see another popular language displace the status quo.

ghaff 7y ago
>I'm starting to doubt if we'll ever see another popular language displace the status quo. That sounds a bit the end of progress. After all, Go, Rust, and Swift haven't been around for that long. I might be open to an argument that ecosystem effects (libraries, training, etc.) lead to power law effects. But I'm not sure I believe that. I could equally well believe that the sheer scale of software development today lends itself to a lot of viable niches.
- thisisnico 7y ago
  The status quo had changed quite a lot in the past 10 years. Anything can happen.
setr 7y ago
I disagree -- software development is more fashion-driven than the fashion industry itself. Programming languages are simply interfaces into a particular tech stack. The stacks will shift as the trends come and go, and the languages will go with it. Perhaps the lowest levels of the stack have settled nice and snugly, with little hope for displacement except by extreme measures (cpu archs, kernel/os implementations, etc) but the higher layers are still rapidly changing, and dragging along new languages with them.
- rubinelli 7y ago
  That's what the industry looks like among early adopters, but most developers wait for clear winners to emerge on new niches before they commit.
  - setr 7y ago
    I'm not sure that's true -- I think most developers use whatever is fashionable in their circle at the time, and then the project gets locked into that tech. In some circles, they're old enough to stabilize: kernel developers are attuned to C, and will rarely consider anything else regardless of option-availability, because their entire ecosystem (and by virtue, culture) revolves around C. C of course was picked in the first place because of the fashion at the time kernel development got into gear. That is, kernel devs got into bed with C before it was a "clear winner", and now they're stuck with it. Ecosystems that are still developing, layered on top of these older more stabilized systems, have the freedom of choice, and they certainly make use of that freedom. And of course, by nature of a non-stabilized ecosystem, most choices made are done before a clear winner exists -- because no clear winner exists just yet. But the choice will stick, unless it was dramatically harmful to the project. The older the ecosystem, the less viable it is to select anything other than the clear winner, because the ecosystem is coupled to that clear winner, and the ecosystem is the fashion.
  - sli 7y ago
    Which is why I write Elm code at home, but Javascript at work. I'm told the latter is the right tool because the company might have to hire someone to maintain it in ten years, and there just cannot be any deviation because any other language would make that ethereal future hire too expensive. That excuse reflects very poorly on the planned future of the company I work for, but I don't think my bosses recognize that. It's apparently less important that our applications are crash-resistant by design of the platform rather than the application itself. I'll admit I'm a bit of a diva with regards to available tools but it's getting really tiresome.

ghaff 7y ago

>I'm starting to doubt if we'll ever see another popular language displace the status quo. That sounds a bit the end of progress. After all, Go, Rust, and Swift haven't been around for that long. I might be open to an argument that ecosystem effects (libraries, training, etc.) lead to power law effects. But I'm not sure I believe that. I could equally well believe that the sheer scale of software development today lends itself to a lot of viable niches.

thisisnico 7y ago
The status quo had changed quite a lot in the past 10 years. Anything can happen.

setr 7y ago

I disagree -- software development is more fashion-driven than the fashion industry itself. Programming languages are simply interfaces into a particular tech stack. The stacks will shift as the trends come and go, and the languages will go with it. Perhaps the lowest levels of the stack have settled nice and snugly, with little hope for displacement except by extreme measures (cpu archs, kernel/os implementations, etc) but the higher layers are still rapidly changing, and dragging along new languages with them.

rubinelli 7y ago
That's what the industry looks like among early adopters, but most developers wait for clear winners to emerge on new niches before they commit.
- setr 7y ago
  I'm not sure that's true -- I think most developers use whatever is fashionable in their circle at the time, and then the project gets locked into that tech. In some circles, they're old enough to stabilize: kernel developers are attuned to C, and will rarely consider anything else regardless of option-availability, because their entire ecosystem (and by virtue, culture) revolves around C. C of course was picked in the first place because of the fashion at the time kernel development got into gear. That is, kernel devs got into bed with C before it was a "clear winner", and now they're stuck with it. Ecosystems that are still developing, layered on top of these older more stabilized systems, have the freedom of choice, and they certainly make use of that freedom. And of course, by nature of a non-stabilized ecosystem, most choices made are done before a clear winner exists -- because no clear winner exists just yet. But the choice will stick, unless it was dramatically harmful to the project. The older the ecosystem, the less viable it is to select anything other than the clear winner, because the ecosystem is coupled to that clear winner, and the ecosystem is the fashion.
- sli 7y ago
  Which is why I write Elm code at home, but Javascript at work. I'm told the latter is the right tool because the company might have to hire someone to maintain it in ten years, and there just cannot be any deviation because any other language would make that ethereal future hire too expensive. That excuse reflects very poorly on the planned future of the company I work for, but I don't think my bosses recognize that. It's apparently less important that our applications are crash-resistant by design of the platform rather than the application itself. I'll admit I'm a bit of a diva with regards to available tools but it's getting really tiresome.