6 ms·

What do you mean by "powerful"? How is a language powerful? Or not?

by bborud 10y ago

kuschku 10y ago
I mean that you will need to write more, and more duplicate code, to express the same, it’ll be less clear, and less safe. Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this. Haskell obviously is a lot better even. Additionally, it’s also a question if, in the language, any state of the program is immediately obvious from the code – or if the syntax hides things (such as Go’s multi-return errors vs. Java’s exceptions, although Java could use an "ignore" keyword to ignore any error happening in a block or statement) A powerful static type system can express everything a dynamic type system can, and more. (That’s why I tend to err towards static typing)
- amelius 10y ago
  > Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this. I think it is fair to point out that generics were not part of the first Java spec. They were added in version 5, see [1]. [1] https://en.wikipedia.org/wiki/Generics_in_Java https://en.wikipedia.org/wiki/Generics_in_Java
  - kuschku 10y ago
    Of course not. Early Java was comparable to today’s Go in many ways, and Generics is part of that.
- cube2222 10y ago
  Very little people who have tried errors by value or Either monads (they are basically the same concept in some sense) think that exceptions are better. Exceptions cause your code to be non-linear. Also, it makes them seem like something exceptional (pun intended), whereas you should really carefully handle each error and decide what it implies. Also, just something I noticed after almost two years of Go. Thanks to library quality I usually end up writing much less Go than Java/Scala for similar applications.
  - kuschku 10y ago
    Go does not have Either monads, or real errors by value. It has a multi-assignment syntax similar to tuple return, but nothing else. For Java, with a tiny library, you can have real Either monads: https://github.com/spencerwi/Either.java https://github.com/spencerwi/Either.java I use them in lots of code. For Go, you end up with an assignment syntax where you have to manually check, and get no compiler safety. At all.
    - cube2222 10y ago
      You do have errors by value. You return for example two values, the response and error. What do you mean with no compiler safety exactly?
      - kuschku 10y ago
        I mean that the compiler does not check if I’m handling the error. I can easily just ignore the error and work with the value, and therefore have code that breaks if the value might not be there. Any code that compiles should not be able to ever segfault or have NullPointerExceptions or similar.
        cube2222 10y ago
        Well, I never had segfaults. Anyways, it's true, I miss pattern matching on errors. However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it.
        kuschku 10y ago
        > However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it. But with the same argument, you could as well use PHP7. And this still doesn’t allow you to replace all stdlib datatypes with your own implementations without using custom precompilers.
base698 10y ago
From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y. By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.
- bborud 10y ago
  So when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.
  - kuschku 10y ago
    Definitely, the measurement of how "powerful" a language is directly corresponding to its level of abstraction. It does not necessarily mean that any dev can code faster – or even similarily fast. But it means that much of refactoring usually is easier (as you’ll have less duplicated code), that you get more guarantees, that you have less boilerplate, etc.
    - bborud 10y ago
      Then I'm not sure if "powerful" is necessarily what I look for in a language. I have three priorities when programming: 1. Correct 2. Understandable 3. Fast Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years. Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above. Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction. (Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.) Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson. For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count. Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.

What do you mean by "powerful"? How is a language powerful? Or not?

by bborud 10y ago

What do you mean by "powerful"? How is a language powerful? Or not?

I mean that you will need to write more, and more duplicate code, to express the same, it’ll be less clear, and less safe. Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this. Haskell obviously is a lot better even. Additionally, it’s also a question if, in the language, any state of the program is immediately obvious from the code – or if the syntax hides things (such as Go’s multi-return errors vs. Java’s exceptions, although Java could use an "ignore" keyword to ignore any error happening in a block or statement) A powerful static type system can express everything a dynamic type system can, and more. (That’s why I tend to err towards static typing)

amelius 10y ago
> Generics, and annotation processing with code generation integrated in the compiler, are two example features supported by Java that improve this. I think it is fair to point out that generics were not part of the first Java spec. They were added in version 5, see [1]. [1] https://en.wikipedia.org/wiki/Generics_in_Java https://en.wikipedia.org/wiki/Generics_in_Java
- kuschku 10y ago
  Of course not. Early Java was comparable to today’s Go in many ways, and Generics is part of that.
cube2222 10y ago
Very little people who have tried errors by value or Either monads (they are basically the same concept in some sense) think that exceptions are better. Exceptions cause your code to be non-linear. Also, it makes them seem like something exceptional (pun intended), whereas you should really carefully handle each error and decide what it implies. Also, just something I noticed after almost two years of Go. Thanks to library quality I usually end up writing much less Go than Java/Scala for similar applications.
- kuschku 10y ago
  Go does not have Either monads, or real errors by value. It has a multi-assignment syntax similar to tuple return, but nothing else. For Java, with a tiny library, you can have real Either monads: https://github.com/spencerwi/Either.java https://github.com/spencerwi/Either.java I use them in lots of code. For Go, you end up with an assignment syntax where you have to manually check, and get no compiler safety. At all.
  - cube2222 10y ago
    You do have errors by value. You return for example two values, the response and error. What do you mean with no compiler safety exactly?
    - kuschku 10y ago
      I mean that the compiler does not check if I’m handling the error. I can easily just ignore the error and work with the value, and therefore have code that breaks if the value might not be there. Any code that compiles should not be able to ever segfault or have NullPointerExceptions or similar.
      - cube2222 10y ago
        Well, I never had segfaults. Anyways, it's true, I miss pattern matching on errors. However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it.
        kuschku 10y ago
        > However, in practice, you just get used to it. I haven't had a situation in the past half year where I'd forget to handle the error / check it. But with the same argument, you could as well use PHP7. And this still doesn’t allow you to replace all stdlib datatypes with your own implementations without using custom precompilers.

base698 10y ago

From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y. By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

bborud 10y ago
So when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.
- kuschku 10y ago
  Definitely, the measurement of how "powerful" a language is directly corresponding to its level of abstraction. It does not necessarily mean that any dev can code faster – or even similarily fast. But it means that much of refactoring usually is easier (as you’ll have less duplicated code), that you get more guarantees, that you have less boilerplate, etc.
  - bborud 10y ago
    Then I'm not sure if "powerful" is necessarily what I look for in a language. I have three priorities when programming: 1. Correct 2. Understandable 3. Fast Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years. Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above. Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction. (Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.) Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson. For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count. Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.