Norris Numbers • Hacker News Board

Re: Norris Numbers

#21

Post by DougMerritt » Thu, Sep 10, 2015, 2:41 AM UTC

wbillingsley wrote: post #18

Curious. I teach a second year undergraduate class in Australia, in which I put the whole class onto a single codebase, typically growing it from 1,500 lines at the start to usually around 60,000 lines by the end of term. (Possibly slightly less this term -- I've moved universities from UQ to UNE and it's a smaller class this time around) I haven't noticed students hitting a wall in that process -- the code isn't alw…

I believe the article is primarily talking about single programmer codebases, although team codebases come up at the end.

I think everyone would agree that a second year undergraduate (who had not programmed at all before university) is not generally going to be able to write 60,000 lines of code single-handedly. And certainly not in one term.

When comparing experiences, I think it's important to be careful to compare apples to apples.

Re: Norris Numbers

#22

Post by msellout » Thu, Sep 10, 2015, 3:42 AM UTC

btilly wrote: post #17

DougMerritt wrote: post #8

Earlier quoted context omitted.

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.

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. Peopl…

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.

Re: Norris Numbers

#23

Post by JesperRavn » Thu, Sep 10, 2015, 3:51 AM UTC

I think 20000 lines of code is the tipping point where code bases go from applications/libraries to frameworks. The difference is that the objects of an application/library are expressed in the raw language, while in a framework they are expressed in the framework's meta-language.

E.g. one might start out writing a machine learning library where a transformation of data is simply a function. But in scikitlearn, transformations of data are objects that implement a transform method. This, together with the implicit/explicit constraints on the semantics of the transform method, help create uniformity so that understanding of the codebase scales better than understanding an arbitrary collection of functions.

Re: Norris Numbers

#24

Post by btilly » Thu, Sep 10, 2015, 4:07 AM UTC

msellout wrote: post #22

btilly wrote: post #17

Earlier quoted context omitted.

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. Peopl…

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.

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.

Re: Norris Numbers

#25

Post by danbmil99 » Thu, Sep 10, 2015, 4:16 AM UTC

Above a certain size, don't most big projects end up as individual modules lightly coupled through well-defined API's/comm channels?

For example, I can write a quick Django site in I would assume that any big project that really requires millions of new LOC would in fact be structured as 10 or more sub-projects of I guess the rub is how quickly each subproject can iterate while maintaining stability for the other teams. I guess the OP is focusing on big projects that are expected to continue to increase in feature count, complexity etc. However I think my model still holds -- but you need to be seriously disciplined and invested at that stage wrt testing & QA, and have a strong culture of practice that supports the weight of all that legacy code but remains at least somewhat "agile".

Re: Norris Numbers

#26

Post by msellout » Thu, Sep 10, 2015, 5:05 AM UTC

btilly wrote: post #24

msellout wrote: post #22

Earlier quoted context omitted.

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.

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.

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.

Re: Norris Numbers

#27

Post by hmbg » Thu, Sep 10, 2015, 6:30 AM UTC

AnimalMuppet wrote: post #15

0xdeadbeefbabe wrote: post #12

More than 200,000 lines of kernel code support some little program, but I pretend they don't exist. For that reason, I think having a good abstraction or architecture is the key to breaking the 200K barrier.

To rephrase: Maybe the key is how many of the 200K lines I can completely ignore. Even more, how many can I ignore while still depending on them.

This is the key. I'd argue that you can keep a 20k codebase in your head. If the codebase is larger than that, you need to be confident that you can safely ignore the rest of it while working on your piece.

If you need to manually check with the rest of the codebase before making changes to the chunk at hand, you're lost.

Re: Norris Numbers

#28

Post by btilly » Thu, Sep 10, 2015, 1:40 PM UTC

msellout wrote: post #26

btilly wrote: post #24

Earlier quoted context omitted.

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.

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.

I no longer have access to that analysis so can't answer. However as a result of that study and other experiences, I've come to accept that the result was reasonable. For example while duck typing is very convenient for a developer, automatic type checking really does have a maintenance benefit.

Here is an example. It is no fun tracking down months after a change that a particular combination of code paths caused a run-time exception because developer 1 was plugging objects into code written by developer 2 where developer 2 expected a specific method to be available and developer 1 didn't do it. And this wasn't visible until you hit an error path because service 3 had a momentary outage that, in theory, the system was written to recover from.

A compile time checked type system can prevent this class of error. Scripting languages allow it. In small projects this kind of dependency is OK because they happen rarely and are reasonably easy to fix. In large projects it stops being easy to fix.