5 ms·

Because programming languages are practically irrelevant in making products. They are only important to developers. In the last thirty years of programming I ha

Because programming languages are practically irrelevant in making products. They are only important to developers. In the last thirty years of programming I have yet to see a project fail because of the programming language or code quality. More often than not it is because someone made something that no one wanted. From a reliability stand point Windows has always been a nightmare. It is still one of the best and most successful products of all time. It could be written in Urdu and no one would care. What about developer productivity you might say? Yes a consideration - one of many. The last 20 years of language design has been focused on making people uninterested in programming programmers. That is what frameworks primarily accomplish. They waste memory and processor resources - are difficult to use in ways outside of their design. But any person can pick up rails for dummies and type gem something and presto a website. Believe it or not I think this is a good thing.

joatmon-snoo 8y ago
To piggyback on this, if I have a codebase that has 10+ years worth of code in it that's been refactored multiple times, uses carefully benchmarked libraries, and has accumulated bug fixes for tricky edge cases (oh, and of course "bugs" that we can't fix because people depend on the buggy behavior), it's going to be very hard for me to justify rewriting the entire thing in a new language. Putting on my Googler hat as well, there's a lot of work that's gone into our core libraries. - Stubby, our RPC libraries, powers literally everything (Cloud, GSuite, Search, etc). I can trust that if I use it, I'm not going to be finding bugs in it - it's going to be some other big team that's got all sorts of fancy shmancy test that can and do catch strange, arcane bugs. The thought of relying on a brand spanking new implementation scares the shit out of me. - We have a lot of powerful tooling (c.f. clang-mr, errorprone) that our core language teams use to constantly improve our codebase. That's years of tooling that a new language isn't going to have. Taking the hat off, at the end of the day it's a tradeoff - either I spend my time continuing to work in a so-called boring language, or I learn a new one to use. If I choose the latter, I'm going to want it to be worth my time. And frankly, sure, I don't get stuff like currying in Java, but Java 8's streams certainly do make life more bearable.
CuriouslyC 8y ago
If you haven't seen projects fail due to code quality you're probably either on the green field end or writing well specified software. The cost of adding unexpected features or dealing with unexpected changes is directly proportional to the quality of the code-base, and in many cases a high quality code-base can make things profitable that otherwise wouldn't be (and vice versa). If software that has the ultimate goal of saving money actually costs money, I would say that it has failed, even if you ultimately produce fully functional software.
- democracy 8y ago
  I am yet to see a project that failed due to "code quality" - almost 20 years greenfield/support in corp/startup world. There are multiple ways for stakeholders on too many levels to not let it happen.
apta 8y ago
> I have yet to see a project fail because of the programming language or code quality. There was some kickstarter project a while back trying to make a game in golang and it failed because golang is not suited for that sort of stuff.
chromanoid 8y ago
It's a fallacy to compare programming languages to spoken languages. And even if you do so, is it really irrelevant in what language a book is written in?

joatmon-snoo 8y ago

To piggyback on this, if I have a codebase that has 10+ years worth of code in it that's been refactored multiple times, uses carefully benchmarked libraries, and has accumulated bug fixes for tricky edge cases (oh, and of course "bugs" that we can't fix because people depend on the buggy behavior), it's going to be very hard for me to justify rewriting the entire thing in a new language. Putting on my Googler hat as well, there's a lot of work that's gone into our core libraries. - Stubby, our RPC libraries, powers literally everything (Cloud, GSuite, Search, etc). I can trust that if I use it, I'm not going to be finding bugs in it - it's going to be some other big team that's got all sorts of fancy shmancy test that can and do catch strange, arcane bugs. The thought of relying on a brand spanking new implementation scares the shit out of me. - We have a lot of powerful tooling (c.f. clang-mr, errorprone) that our core language teams use to constantly improve our codebase. That's years of tooling that a new language isn't going to have. Taking the hat off, at the end of the day it's a tradeoff - either I spend my time continuing to work in a so-called boring language, or I learn a new one to use. If I choose the latter, I'm going to want it to be worth my time. And frankly, sure, I don't get stuff like currying in Java, but Java 8's streams certainly do make life more bearable.

CuriouslyC 8y ago

If you haven't seen projects fail due to code quality you're probably either on the green field end or writing well specified software. The cost of adding unexpected features or dealing with unexpected changes is directly proportional to the quality of the code-base, and in many cases a high quality code-base can make things profitable that otherwise wouldn't be (and vice versa). If software that has the ultimate goal of saving money actually costs money, I would say that it has failed, even if you ultimately produce fully functional software.

democracy 8y ago
I am yet to see a project that failed due to "code quality" - almost 20 years greenfield/support in corp/startup world. There are multiple ways for stakeholders on too many levels to not let it happen.

apta 8y ago

> I have yet to see a project fail because of the programming language or code quality. There was some kickstarter project a while back trying to make a game in golang and it failed because golang is not suited for that sort of stuff.

chromanoid 8y ago

It's a fallacy to compare programming languages to spoken languages. And even if you do so, is it really irrelevant in what language a book is written in?