4 ms·

That's a very unappealing title for a very interesting subject, which is that there are complexity barriers that get in the way of creating larger programs. Fo

That's a very unappealing title for a very interesting subject, which is that there are complexity barriers that get in the way of creating larger programs. For the sake of illustration, he says a novice may hit a brick wall at 2,000 lines of code, and be unable to add features after that without breaking things. The next level for a more experienced programmer might be 20,000 lines of code, and he describes some things that helped him get there. Then there's his personal breakthrough to 200,000 lines of code. etc. (I add this gloss to spur people to read the piece, which is interesting, and add their own ideas, not because I am claiming the above is some kind of absolute truth.)

AnimalMuppet 11y ago
And that's exactly what's wrong with all the syntactic-sugar-based language marketing. "Write your code using X, and you go from 10 ugly lines of C++ down to 3 beautiful (if syntactically weird) lines of X!" Great. Now tell me how X scales on a 200,000 line project. One of the places people make this mistake is with Go. Go isn't designed to make your 2,000-line project shorter or easier. It's designed to make Google's 20,000,000-line projects maintainable for a couple of decades.
- DougMerritt 11y ago
  The traditional wisdom (backed by multiple studies starting decades ago) is that the language used doesn't statistically change the number of debugged lines of code per day, but may often change the number of machine instructions executed per line of high level code written. We are digressing here, yes? I read the article quickly, admittedly, but I didn't notice him doing language advocacy.
  - AnimalMuppet 11y ago
    Yes, I'm digressing. Guilty as charged. Nevertheless, I think it's a somewhat-on-topic digression. If there's a wall at 2,000 lines, almost all language-advocacy examples are below that wall. That's the first wall. But language choice doesn't get interesting until you ask what the language does at the 20,000-line wall or the 200,000-line wall. Nobody talks about this when they advocate a language (except, as I said, Go). The closest are Haskell and Lisp, and their claim is that you can write the same program in fewer lines (so that you don't hit any of the walls as quickly).
    - tokenrove 11y ago
      It's worth noting that a big part of the Common Lisp spiel was that it was suitable for very large applications which needed to be maintained for a long time. So the two (terseness and large-scale development) need not be mutually exclusive. (On the line of your point, though, maybe it's a shame that relatively-verbose languages like Ada and Modula-3 became social pariahs because their virtues are hard to demonstrate in the small.)
  - btilly 11y ago
    The traditional wisdom and this article are mostly orthogonal. To hit one of the complexity walls in this article you need to be consistently doing certain things right until your project becomes large enough that you hit new types of scaling problems. That isn't a day to day productivity issue. That's a project lifecycle issue. That said, there are claims about how language features and project scale interact. People have strong opinions, but I do not think that anyone has studied this rigorously. That said, I know plenty of successful 2+ million line projects that exist in C. I've seen data suggestive that projects written in scripting languages fall apart at that scale. So the traditional wisdom suggests that a 100k project written in Python will cost the same as 100k lines of C, and does more. However there are projects that you don't want to write in Python. Really.
    - msellout 11y ago
      Citation needed? It is common for a large Python project to use some modules with C extensions. There are many examples of people able to write more sophisticated programs in Python than C. Comparing PyPy with CPython, the choice of Python enabled writing a JIT compiler.
      - btilly 11y ago
        I don't have a publicly available citation. The conclusion about relative costs of maintenance for Python versus both C++ and Java was in an internal analysis that I saw from a retroactive look at company wide averages at Google. This was not due to a lack of talent among the Python programmers. This was back when Guido worked there, and projects with people like him did not mature amazingly better.
        msellout 11y ago
        In that case, I'm very curious about what measurements were used for the costs of maintenance and the size of the project. It's often very difficult to disentangle a single project from all its dependencies and that shouldn't necessarily be at the language boundaries.

AnimalMuppet 11y ago

And that's exactly what's wrong with all the syntactic-sugar-based language marketing. "Write your code using X, and you go from 10 ugly lines of C++ down to 3 beautiful (if syntactically weird) lines of X!" Great. Now tell me how X scales on a 200,000 line project. One of the places people make this mistake is with Go. Go isn't designed to make your 2,000-line project shorter or easier. It's designed to make Google's 20,000,000-line projects maintainable for a couple of decades.

DougMerritt 11y ago
The traditional wisdom (backed by multiple studies starting decades ago) is that the language used doesn't statistically change the number of debugged lines of code per day, but may often change the number of machine instructions executed per line of high level code written. We are digressing here, yes? I read the article quickly, admittedly, but I didn't notice him doing language advocacy.
- AnimalMuppet 11y ago
  Yes, I'm digressing. Guilty as charged. Nevertheless, I think it's a somewhat-on-topic digression. If there's a wall at 2,000 lines, almost all language-advocacy examples are below that wall. That's the first wall. But language choice doesn't get interesting until you ask what the language does at the 20,000-line wall or the 200,000-line wall. Nobody talks about this when they advocate a language (except, as I said, Go). The closest are Haskell and Lisp, and their claim is that you can write the same program in fewer lines (so that you don't hit any of the walls as quickly).
  - tokenrove 11y ago
    It's worth noting that a big part of the Common Lisp spiel was that it was suitable for very large applications which needed to be maintained for a long time. So the two (terseness and large-scale development) need not be mutually exclusive. (On the line of your point, though, maybe it's a shame that relatively-verbose languages like Ada and Modula-3 became social pariahs because their virtues are hard to demonstrate in the small.)
- btilly 11y ago
  The traditional wisdom and this article are mostly orthogonal. To hit one of the complexity walls in this article you need to be consistently doing certain things right until your project becomes large enough that you hit new types of scaling problems. That isn't a day to day productivity issue. That's a project lifecycle issue. That said, there are claims about how language features and project scale interact. People have strong opinions, but I do not think that anyone has studied this rigorously. That said, I know plenty of successful 2+ million line projects that exist in C. I've seen data suggestive that projects written in scripting languages fall apart at that scale. So the traditional wisdom suggests that a 100k project written in Python will cost the same as 100k lines of C, and does more. However there are projects that you don't want to write in Python. Really.
  - msellout 11y ago
    Citation needed? It is common for a large Python project to use some modules with C extensions. There are many examples of people able to write more sophisticated programs in Python than C. Comparing PyPy with CPython, the choice of Python enabled writing a JIT compiler.
    - btilly 11y ago
      I don't have a publicly available citation. The conclusion about relative costs of maintenance for Python versus both C++ and Java was in an internal analysis that I saw from a retroactive look at company wide averages at Google. This was not due to a lack of talent among the Python programmers. This was back when Guido worked there, and projects with people like him did not mature amazingly better.
      - msellout 11y ago
        In that case, I'm very curious about what measurements were used for the costs of maintenance and the size of the project. It's often very difficult to disentangle a single project from all its dependencies and that shouldn't necessarily be at the language boundaries.