5 ms·

Why can't we accept that programming languages are just tools and we should pick the best one for the job? If I'm only going to run a script every few months a

Why can't we accept that programming languages are just tools and we should pick the best one for the job? If I'm only going to run a script every few months and high performance isn't necessary, why should I pick a "hard" language like C rather than a scripting language like Python? The same holds true conversely; I don't want to use Python for code that has to run close to the metal. Furthermore, if I need to iterate quickly, I wouldn't use something like C where there are too few abstractions for me to program at a quick-enough rate. If I work at a company like Google I presumably have enough money to buy all the computing power I should need, so performance of the code isn't as important as developer time. Or, if I'm prototyping some software and I want to work out the kinks in the architecture, why should I spend more time programming in C than just throwing together a quick solution in Python? Something else: >If you do anything I am relying on, I do not want to hear that you use such "easy" language, period. If you are careless enough to rely on people not making mistakes, I do not want to deal with you. Most mature, high level ("easy") languages are relatively bug free for most use cases. Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself?

slavapestov 10y ago
> If I work at a company like Google I presumably have enough money to buy all the computing power I should need, so performance of the code isn't as important as developer time. Google and other big cloud shops care a lot about energy usage actually, and contrary to popular belief many server-side applications are CPU and memory-usage bound. Energy consumption is important on mobile as well.
- fiedzia 10y ago
  > Google and other big cloud shops care a lot about energy usage actually, Indeed they do. If you have one server, or a 100, doubling that is not a problem. If you are Google, doubling your energy use requires finding new country to provide it.
- sargun 10y ago
  Often times energy converts directly CPU, and therefore to $$$. I think I heard a quote that a 1% CPU utilization change in search was a $100M+ spending change. While the specifics are lost to me, in general, I'm not at all surprised. Latency a major contributor as well. Sometimes, you're just up against CPU, and latency can be closely tied with revenue.
fiedzia 10y ago
> Most mature, high level ("easy") languages are relatively bug free for most use cases. Languages and their libraries - yes. That's because they were battle-tested by users for a long time (and failed them many times). New programs written in those languages do not inherit those properties. However I referred to C here. Consequences of mistakes there are serious, modern high level languages (probably most, if not of them) do not have such problem. > Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself? I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try.
- tylerhou 10y ago
  > I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try. What if those proofs have a mistake, or the program you use to verify those proofs has a bug in it? What if the machine you're using has a bug in its processor, or somewhere else? You said that you won't deal with anyone who relies on other people. Your criterion of "anyone" also implies "yourself". By your own argument, unless you yourself personally have verified that every single line of code in your program, every single assembly instruction in your machine code, every single molecule in your computer is correct, you cannot even "deal with" yourself. Have you verified those things yet? It's simply not feasible to trust nobody when nowadays there are so many layers of abstraction. (Not to mention that your original comment was somewhat pretentious.)
skybrian 10y ago
The reason this is political is that it's a group decision. As a solo hobbyist you can choose whatever you like. But once you write code someone else will read or maintain (at least potentially), then it becomes a political decision within a community of maintainers. Successful languages create their own ecosystems. It's odd to focus on syntax or concepts when the ecosystem built around the language (tools and libraries) is usually just as important.
- tylerhou 10y ago
  Yeah, I can see how being in a team would make the decision different; I'm still a student and haven't had the chance to work on production projects. Yet I don't agree with OP that higher level => harder to maintain. I guess my reasoning comes from your second point: Good ecosystems create ways for programs written in high level languages to maintain maintainability (see Flow.js).

slavapestov 10y ago

> If I work at a company like Google I presumably have enough money to buy all the computing power I should need, so performance of the code isn't as important as developer time. Google and other big cloud shops care a lot about energy usage actually, and contrary to popular belief many server-side applications are CPU and memory-usage bound. Energy consumption is important on mobile as well.

fiedzia 10y ago
> Google and other big cloud shops care a lot about energy usage actually, Indeed they do. If you have one server, or a 100, doubling that is not a problem. If you are Google, doubling your energy use requires finding new country to provide it.
sargun 10y ago
Often times energy converts directly CPU, and therefore to $$$. I think I heard a quote that a 1% CPU utilization change in search was a $100M+ spending change. While the specifics are lost to me, in general, I'm not at all surprised. Latency a major contributor as well. Sometimes, you're just up against CPU, and latency can be closely tied with revenue.

fiedzia 10y ago

> Most mature, high level ("easy") languages are relatively bug free for most use cases. Languages and their libraries - yes. That's because they were battle-tested by users for a long time (and failed them many times). New programs written in those languages do not inherit those properties. However I referred to C here. Consequences of mistakes there are serious, modern high level languages (probably most, if not of them) do not have such problem. > Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself? I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try.

tylerhou 10y ago
> I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try. What if those proofs have a mistake, or the program you use to verify those proofs has a bug in it? What if the machine you're using has a bug in its processor, or somewhere else? You said that you won't deal with anyone who relies on other people. Your criterion of "anyone" also implies "yourself". By your own argument, unless you yourself personally have verified that every single line of code in your program, every single assembly instruction in your machine code, every single molecule in your computer is correct, you cannot even "deal with" yourself. Have you verified those things yet? It's simply not feasible to trust nobody when nowadays there are so many layers of abstraction. (Not to mention that your original comment was somewhat pretentious.)

skybrian 10y ago

The reason this is political is that it's a group decision. As a solo hobbyist you can choose whatever you like. But once you write code someone else will read or maintain (at least potentially), then it becomes a political decision within a community of maintainers. Successful languages create their own ecosystems. It's odd to focus on syntax or concepts when the ecosystem built around the language (tools and libraries) is usually just as important.

tylerhou 10y ago
Yeah, I can see how being in a team would make the decision different; I'm still a student and haven't had the chance to work on production projects. Yet I don't agree with OP that higher level => harder to maintain. I guess my reasoning comes from your second point: Good ecosystems create ways for programs written in high level languages to maintain maintainability (see Flow.js).