4 ms·

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible min

by yanilkr 10y ago

This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.

kmiroslav 10y ago
> There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.
- yanilkr 10y ago
  javascript and python would disagree with you.
  - gagege 10y ago
    A lot of people are perfectly happy if Javascript and Python disagree with them.
  - Jtsummers 10y ago
    Parent's claim: Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones. Your response: javascript and python would disagree with you. My question: How so? Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particularly expressive ones, but even of less expressive ones like C, is that a large class of errors can never occur in run-time code. You cannot, possibly, without deliberate effort to defeat the type checker do the following in a statically typed language without at least a compile time warning (to permit C and its weak type system and occasional implicit casting): Define a function in your language of type: int -> int -> int [or (int, int) -> int]. Pass in something that is not an int to either parameter. Python will happily accept this code: def add(a,b): a + b ... some context add("aoeu", 3) And not tell you until that add call occurs. A run-time error. Could be very infrequent, which makes it really hard to reproduce. In C: int add(int a, int b) { return a+b; } ... some context add("aoeu",3); the add call won't even make it past the compiler. JavaScript is even worse: You won't get an error at all! function add(a,b) { return a + b; } ... some context add("aoeu",3) // results in "aoeu3" as the return! Dynamic and weak typing! This doesn't mean python and javascript are bad. But it does mean they possess disadvantages relative to statically typed languages. Their type systems mean that significant testing has to be put in to verify/validate your program for guarantees that are baked into statically typed languages (caveat for implicit conversions of certain types, again, in languages like C, but this usually gets at least a warning if not an error).
    - yanilkr 10y ago
      "insurmountable advantage" - I don't think so. the simplicity that javascript and python provides is an enormous advantage to many kinds of projects.
      - kmiroslav 10y ago
        These languages stopped being simpler when type inference became mainstream in statically typed languages about ten years ago.
      - Jtsummers 10y ago
        It's not simple when you have to maintain it or debug it. There are many classes of errors that can occur when writing software. Languages with implicit variable creation like python obscure errors like mistyping the name of a new variable (versus an explicit declaration like in C or an ML where the mistyped name will result in an error immediately modulo name conflicts). It looks correct at a glance, but: def foo(a_name, b_name): # computations a_nam = #some more computations # computations using a_name, not a_nam, returns # erroneous values (NB: The above is bad practice anyways, an advantage of the single static assignment of the dynamically typed erlang.) Oops, we forgot an 'e' at some point. Now we have a new variable, but we used the old variable name for future computations and returned a result based on that. Type errors, I've already discussed. Logic errors like: if(a < b) // when we meant a <= b Are universal to all languages, they can't eliminate these. Actually, this leads to a major gripe I have with C. The duplication of meaning for = as both initial value assignment and later reassignment paired with the use of non-zero values to indicate true. if (a = b) // well, shit. a has a wrong value, and we go // down the wrong branch now depending on the // value of b. Good practices only get us so far. Moving those good practices (static typing paired with type inference for simplicity, single static assignment or immutability by default, etc.) into the language does add mental overhead to programming. But it also produces less errorful final products. As a guy who writes software that can literally save or kill someone depending on how well or not it functions, I'm in favor of better languages.
        10y ago
jdmichal 10y ago
> Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. I find the opposite for practical arts: The better the practitioner, the more reliable their tools must be, not less. A beginner painter might not be able to point out a bad brush from a good one; a master absolutely will. Furthermore, a bad brush won't necessarily hinder a beginner painter, but it will absolutely hinder a master painter. There are simply some techniques that the master will not be able to execute unless the brush is of a good enough quality.
rdtsc 10y ago
> There is no universal best language nor there will ever be the one. But there are better languages for some task than others. Having a better type systems suites many types of tasks and environments. So making that observation seems rather rational.
kmiroslav 10y ago
> If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. That's a flawed analogy. Here is a better one: If you need to drill something, do you consider a screwdriver and an electric drill equally?
- elbear 10y ago
  I don't agree with this analogy, because languages overlap a lot more. You could choose one of several different languages to build a web app (Python, JavaScript, Ruby, PHP, etc.). Only particular tasks have languages that fit best. Many other tasks can be solved in multiple languages. In that case, the best tool for the job is the language you know best.

by yanilkr 10y ago

kmiroslav 10y ago

> There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.

yanilkr 10y ago
javascript and python would disagree with you.
- gagege 10y ago
  A lot of people are perfectly happy if Javascript and Python disagree with them.
- Jtsummers 10y ago
  Parent's claim: Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones. Your response: javascript and python would disagree with you. My question: How so? Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particularly expressive ones, but even of less expressive ones like C, is that a large class of errors can never occur in run-time code. You cannot, possibly, without deliberate effort to defeat the type checker do the following in a statically typed language without at least a compile time warning (to permit C and its weak type system and occasional implicit casting): Define a function in your language of type: int -> int -> int [or (int, int) -> int]. Pass in something that is not an int to either parameter. Python will happily accept this code: def add(a,b): a + b ... some context add("aoeu", 3) And not tell you until that add call occurs. A run-time error. Could be very infrequent, which makes it really hard to reproduce. In C: int add(int a, int b) { return a+b; } ... some context add("aoeu",3); the add call won't even make it past the compiler. JavaScript is even worse: You won't get an error at all! function add(a,b) { return a + b; } ... some context add("aoeu",3) // results in "aoeu3" as the return! Dynamic and weak typing! This doesn't mean python and javascript are bad. But it does mean they possess disadvantages relative to statically typed languages. Their type systems mean that significant testing has to be put in to verify/validate your program for guarantees that are baked into statically typed languages (caveat for implicit conversions of certain types, again, in languages like C, but this usually gets at least a warning if not an error).
  - yanilkr 10y ago
    "insurmountable advantage" - I don't think so. the simplicity that javascript and python provides is an enormous advantage to many kinds of projects.
    - kmiroslav 10y ago
      These languages stopped being simpler when type inference became mainstream in statically typed languages about ten years ago.
    - Jtsummers 10y ago
      It's not simple when you have to maintain it or debug it. There are many classes of errors that can occur when writing software. Languages with implicit variable creation like python obscure errors like mistyping the name of a new variable (versus an explicit declaration like in C or an ML where the mistyped name will result in an error immediately modulo name conflicts). It looks correct at a glance, but: def foo(a_name, b_name): # computations a_nam = #some more computations # computations using a_name, not a_nam, returns # erroneous values (NB: The above is bad practice anyways, an advantage of the single static assignment of the dynamically typed erlang.) Oops, we forgot an 'e' at some point. Now we have a new variable, but we used the old variable name for future computations and returned a result based on that. Type errors, I've already discussed. Logic errors like: if(a < b) // when we meant a <= b Are universal to all languages, they can't eliminate these. Actually, this leads to a major gripe I have with C. The duplication of meaning for = as both initial value assignment and later reassignment paired with the use of non-zero values to indicate true. if (a = b) // well, shit. a has a wrong value, and we go // down the wrong branch now depending on the // value of b. Good practices only get us so far. Moving those good practices (static typing paired with type inference for simplicity, single static assignment or immutability by default, etc.) into the language does add mental overhead to programming. But it also produces less errorful final products. As a guy who writes software that can literally save or kill someone depending on how well or not it functions, I'm in favor of better languages.
      - 10y ago

jdmichal 10y ago

> Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. I find the opposite for practical arts: The better the practitioner, the more reliable their tools must be, not less. A beginner painter might not be able to point out a bad brush from a good one; a master absolutely will. Furthermore, a bad brush won't necessarily hinder a beginner painter, but it will absolutely hinder a master painter. There are simply some techniques that the master will not be able to execute unless the brush is of a good enough quality.

rdtsc 10y ago

> There is no universal best language nor there will ever be the one. But there are better languages for some task than others. Having a better type systems suites many types of tasks and environments. So making that observation seems rather rational.

kmiroslav 10y ago

> If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. That's a flawed analogy. Here is a better one: If you need to drill something, do you consider a screwdriver and an electric drill equally?

elbear 10y ago
I don't agree with this analogy, because languages overlap a lot more. You could choose one of several different languages to build a web app (Python, JavaScript, Ruby, PHP, etc.). Only particular tasks have languages that fit best. Many other tasks can be solved in multiple languages. In that case, the best tool for the job is the language you know best.