7 ms·

Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and J

Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

enneff 12y ago
The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.
- pjmlp 12y ago
  > In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
  - oblio 12y ago
    True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.
    - pjmlp 12y ago
      Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers. Anyway Go has its use cases, and it is already an improvement if less C code gets written.
  - enneff 12y ago
    I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.
    - pjmlp 12y ago
      What leads you to believe the same won't happen to Go? I have seen this happen in C codebases before Java took the enterprise. Its own little macro based DSL and pointers that were actually handles for the real data.
      - enneff 12y ago
        Java's sin is a fetish for over abstraction. Go has a strong cultural emphasis on avoiding unnecessary abstraction.
        pjmlp 12y ago
        Enterprise architecture is traversal to the languages being used.
- reverius42 12y ago
  I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.
  - f2f 12y ago
    your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.
    - meowface 12y ago
      So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is. Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both the praise and the criticism. Powerful languages can cause other issues, but they do enable certain things that weaker languages simply never can.
      - f2f 12y ago
        C and Java are not the subject here.
      - melling 12y ago
        You're being a little vague. Can you give a couple examples where software projects were done in "powerful languages?" I can certainly appreciate that higher level languages are better. However, it seems like in practice they are not used as often as you would hope.
    - codygman 12y ago
      Do you have a source? I don't find your claim implausible, however I would like to know how you came to that conclusion.
AnimalMuppet 12y ago
The problem with the Blub essay is precisely the assumption that all languages can be ranked on a one-dimensional axis called "power". That assumption is false. (I know this is heresy to say on HN, but in this essay, PG is simply wrong.) I'm repeating myself here, but: A Haskell user and a Lisp user are both sure that they're at the top of the power curve, and they're both sure that they're looking down when they're looking at the other language, and they can both tell you precisely why they're sure they're looking down ("It doesn't even have a decent type system" and "It doesn't even have macros", respectively). But they can't both be looking down. What's wrong here? What's wrong is the assumption that all languages can be ranked by a one-dimensional attribute called "power". Or look at it another way: Power? Power for what? Well, for writing programs. But what kind of programs? General programs? I've never written a general program in my life; I've only written specific ones. Then "power" is whatever's going to make it easier to write the program I need to write. Whatever language does that is the "most powerful" language for the problem I'm facing. What power is Go shooting for? It's the power to write a ten-million-line application and have it be maintainable for two or three decades. (That's not my guess; it's what Rob Pike said the language goals are.) If you face that kind of problem, Go may in fact be a very powerful language.

enneff 12y ago

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

pjmlp 12y ago
> In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
- oblio 12y ago
  True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.
  - pjmlp 12y ago
    Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers. Anyway Go has its use cases, and it is already an improvement if less C code gets written.
- enneff 12y ago
  I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.
  - pjmlp 12y ago
    What leads you to believe the same won't happen to Go? I have seen this happen in C codebases before Java took the enterprise. Its own little macro based DSL and pointers that were actually handles for the real data.
    - enneff 12y ago
      Java's sin is a fetish for over abstraction. Go has a strong cultural emphasis on avoiding unnecessary abstraction.
      - pjmlp 12y ago
        Enterprise architecture is traversal to the languages being used.
reverius42 12y ago
I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.
- f2f 12y ago
  your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.
  - meowface 12y ago
    So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is. Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both the praise and the criticism. Powerful languages can cause other issues, but they do enable certain things that weaker languages simply never can.
    - f2f 12y ago
      C and Java are not the subject here.
    - melling 12y ago
      You're being a little vague. Can you give a couple examples where software projects were done in "powerful languages?" I can certainly appreciate that higher level languages are better. However, it seems like in practice they are not used as often as you would hope.
  - codygman 12y ago
    Do you have a source? I don't find your claim implausible, however I would like to know how you came to that conclusion.

AnimalMuppet 12y ago

The problem with the Blub essay is precisely the assumption that all languages can be ranked on a one-dimensional axis called "power". That assumption is false. (I know this is heresy to say on HN, but in this essay, PG is simply wrong.) I'm repeating myself here, but: A Haskell user and a Lisp user are both sure that they're at the top of the power curve, and they're both sure that they're looking down when they're looking at the other language, and they can both tell you precisely why they're sure they're looking down ("It doesn't even have a decent type system" and "It doesn't even have macros", respectively). But they can't both be looking down. What's wrong here? What's wrong is the assumption that all languages can be ranked by a one-dimensional attribute called "power". Or look at it another way: Power? Power for what? Well, for writing programs. But what kind of programs? General programs? I've never written a general program in my life; I've only written specific ones. Then "power" is whatever's going to make it easier to write the program I need to write. Whatever language does that is the "most powerful" language for the problem I'm facing. What power is Go shooting for? It's the power to write a ten-million-line application and have it be maintainable for two or three decades. (That's not my guess; it's what Rob Pike said the language goals are.) If you face that kind of problem, Go may in fact be a very powerful language.