3 ms·

Fitting more on screen is not objectively better, otherwise people would be talking about minified javascript is so much easier to read than python, since pytho

by NateDad 12y ago

Fitting more on screen is not objectively better, otherwise people would be talking about minified javascript is so much easier to read than python, since python wastes all that horizontal space with its newlines. And defining what is signal and what is noise is pretty subjective. Pythonistas would say that braces are noise. Most people who use languages with braces would say they're signal.

nailer 12y ago
You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: - Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue, with a very different effect on parsing efficiency, than the use of unnecessary tokens. - Of course existing programmers have biases. Measure parsing efficiency using people who aren't already programmers. Responding to natedad below (rate limit): > There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. Which ones? > There's more to designing a language than making it use as few tokens as possible... Yes, but none of those things mean that efficiency is not important. Responding to reitanqild: My statement 'Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue' also neatly covers J/K/APL. If there's anything else you've think I've not responded to, please actually state exactly what it is.
- skybrian 12y ago
  Measurement is a tricky problem. You wouldn't measure efficiency in various human languages by testing using people who don't know the language. Similarly we would need to use people who have a basic competency (at least) in the same computing language being tested. But then you still need to adjust for skill levels, and that seems a bit circular. I think we're far from being able to measure this accurately.
  - nailer 12y ago
    Assuming the people being tested are English speakers, code has key words, which are already in your native language, and symbols, which to some extent echo their use in English. Japanese does not have key words that are already in English. This is why it's generally considered harder for an English speaking person to read Japanese than to read some simple code. There are orders of magnitude more people who will program in future than which program now. We should absolutely design things around those people. Edit for natedad: 100% of people that fixed a bug were non-programmers at some point.
    - skybrian 12y ago
      I agree that how easy something is to learn depends on what you're previously familiar with. English certainly helps. Also, if you're already comfortable with math then you'll be more comfortable with symbol manipulation. But that's a separate question from how easy it is to use a language after you've already learned it. The studies to measure these questions would need to be designed differently. On the other hand, these questions do overlap. People who know a language don't stop learning; they get better at using it with practice. Also, people who use a language occasionally need to switch gears going back to it and need to relearn things.
  - NateDad 12y ago
    +1 when non-programmers start fixing bugs, I'll worry about how hard it is for them to read the language.
- NateDad 12y ago
  There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. There's more to designing a language than making it use as few tokens as possible. A programmer's job involves a lot of different things - merging two pieces of code, reading and editing someone else's code, viewing diffs of code, moving code from one place to another, searching large amounts of files for specific code. A lot of the choices in Go (and its standard formatting with gofmt) were made with all of these things in mind, not just the raw textual efficiency in mind.
- reitanqild 12y ago
  >> nailer: Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. > NateDad: You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: Careful. You might be the one here who haven't considered some obvious things. I think parent as well as dagw's comment (Does that mean that J/K/APL are the objectively best programming languages?) explaint perfectly well why what you wrote where flawed.

by NateDad 12y ago

nailer 12y ago

You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: - Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue, with a very different effect on parsing efficiency, than the use of unnecessary tokens. - Of course existing programmers have biases. Measure parsing efficiency using people who aren't already programmers. Responding to natedad below (rate limit): > There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. Which ones? > There's more to designing a language than making it use as few tokens as possible... Yes, but none of those things mean that efficiency is not important. Responding to reitanqild: My statement 'Minified code, including code written by humans that don't know how to name things, is quite obviously a separate issue' also neatly covers J/K/APL. If there's anything else you've think I've not responded to, please actually state exactly what it is.

skybrian 12y ago
Measurement is a tricky problem. You wouldn't measure efficiency in various human languages by testing using people who don't know the language. Similarly we would need to use people who have a basic competency (at least) in the same computing language being tested. But then you still need to adjust for skill levels, and that seems a bit circular. I think we're far from being able to measure this accurately.
- nailer 12y ago
  Assuming the people being tested are English speakers, code has key words, which are already in your native language, and symbols, which to some extent echo their use in English. Japanese does not have key words that are already in English. This is why it's generally considered harder for an English speaking person to read Japanese than to read some simple code. There are orders of magnitude more people who will program in future than which program now. We should absolutely design things around those people. Edit for natedad: 100% of people that fixed a bug were non-programmers at some point.
  - skybrian 12y ago
    I agree that how easy something is to learn depends on what you're previously familiar with. English certainly helps. Also, if you're already comfortable with math then you'll be more comfortable with symbol manipulation. But that's a separate question from how easy it is to use a language after you've already learned it. The studies to measure these questions would need to be designed differently. On the other hand, these questions do overlap. People who know a language don't stop learning; they get better at using it with practice. Also, people who use a language occasionally need to switch gears going back to it and need to relearn things.
- NateDad 12y ago
  +1 when non-programmers start fixing bugs, I'll worry about how hard it is for them to read the language.
NateDad 12y ago
There are a lot of tokens which are not strictly necessary, but which make a programmer's job easier. There's more to designing a language than making it use as few tokens as possible. A programmer's job involves a lot of different things - merging two pieces of code, reading and editing someone else's code, viewing diffs of code, moving code from one place to another, searching large amounts of files for specific code. A lot of the choices in Go (and its standard formatting with gofmt) were made with all of these things in mind, not just the raw textual efficiency in mind.
reitanqild 12y ago
>> nailer: Fitting more on screen, and having a higher signal/noise ratio is /objectively better/ than otherwise. > NateDad: You state your view as fact, but you haven't considered some very obvious things that would normally be prerequisites to having that level of confidence: Careful. You might be the one here who haven't considered some obvious things. I think parent as well as dagw's comment (Does that mean that J/K/APL are the objectively best programming languages?) explaint perfectly well why what you wrote where flawed.