6 ms·

Here's a benchmark: in 1970, I had a full-time job maintaining a 4,000-line assembler program on punched cards. Today I manage a 400,000-line system in C++. Tha

Here's a benchmark: in 1970, I had a full-time job maintaining a 4,000-line assembler program on punched cards. Today I manage a 400,000-line system in C++. That's 100:1.

santoshalper 10y ago
That's an interesting point also - scale. I don't think programming a simple "hello world" in C or C++ would be 100x faster than in assembly (assuming you were equally familiar with both languages), but I think it would be nearly impossible, or at least incredibly expensive to maintain 400 kloc of assembly. I honestly shudder at the thought.
- Someone 10y ago
  You would use a macro assembler, and if you have good programmers, they would effectively develop a DSL for writing your program in it. That would postpone the point at which that assembly program reaches 400kloc. In the end, it would probably grow as fast as a C program of the same functionality. Of course, they also would have to develop their own tooling around that DSL. That, I think is the problem lies with assembly. Higher level languages imply that more stuff gets shared between projects (even across companies; everybody will use the same C language and standard library), and that means time spent to develop tooling around and libraries on top of the shared stuff is useful for more people. Hence, tooling and libraries will generally be of higher quality. that home-grown GUI library built on top of a home-grown set of assembler macros using a home-grown ABI may be better than using, say, QT on top of X11, but it isn't that likely. On the other hand, the smaller the system, the more important memory usage, and if the system is small enough, that can and will swing the advantage to the home-grown system. That happens less and less, though.
danieltillett 10y ago
Wow that is some long career you have had. What have you done in between?
- chadcmulligan 10y ago
  assuming linear probably a 100,000 line program in C
kragen 10y ago
It's probably more like 500:1 if we're measuring by functionality rather than textual size, no? I imagine the C++ program needs more memory to run in, though. (And that a substantial part of your workload in 1970 was due to memory size limitations.)
- deleted 10y ago
  [deleted]
majewsky 10y ago
> Today I manage a 400,000-line system in C++. On your own? If yes, then that's pretty impressive. My previous team maintained 350,000-line Perl application with at least 5-6 programmers. If you're handling that C++ system alone, I'd assume it's pretty self-contained, since the complexity in large systems regularly comes from all the other systems that you interface with (at least for the aforementioned Perl app).
- 6nf 10y ago
  Ten programmers working together can get almost twice as much done as one programmer.
  - douche 10y ago
    I want to print this out and frame it for my office
  - CroCroCro 10y ago
    yes
  - mwcampbell 10y ago
    You got any evidence for that?

Here's a benchmark: in 1970, I had a full-time job maintaining a 4,000-line assembler program on punched cards. Today I manage a 400,000-line system in C++. That's 100:1.

santoshalper 10y ago

That's an interesting point also - scale. I don't think programming a simple "hello world" in C or C++ would be 100x faster than in assembly (assuming you were equally familiar with both languages), but I think it would be nearly impossible, or at least incredibly expensive to maintain 400 kloc of assembly. I honestly shudder at the thought.

Someone 10y ago
You would use a macro assembler, and if you have good programmers, they would effectively develop a DSL for writing your program in it. That would postpone the point at which that assembly program reaches 400kloc. In the end, it would probably grow as fast as a C program of the same functionality. Of course, they also would have to develop their own tooling around that DSL. That, I think is the problem lies with assembly. Higher level languages imply that more stuff gets shared between projects (even across companies; everybody will use the same C language and standard library), and that means time spent to develop tooling around and libraries on top of the shared stuff is useful for more people. Hence, tooling and libraries will generally be of higher quality. that home-grown GUI library built on top of a home-grown set of assembler macros using a home-grown ABI may be better than using, say, QT on top of X11, but it isn't that likely. On the other hand, the smaller the system, the more important memory usage, and if the system is small enough, that can and will swing the advantage to the home-grown system. That happens less and less, though.

danieltillett 10y ago

Wow that is some long career you have had. What have you done in between?

chadcmulligan 10y ago
assuming linear probably a 100,000 line program in C

kragen 10y ago

It's probably more like 500:1 if we're measuring by functionality rather than textual size, no? I imagine the C++ program needs more memory to run in, though. (And that a substantial part of your workload in 1970 was due to memory size limitations.)

deleted 10y ago
[deleted]

majewsky 10y ago

> Today I manage a 400,000-line system in C++. On your own? If yes, then that's pretty impressive. My previous team maintained 350,000-line Perl application with at least 5-6 programmers. If you're handling that C++ system alone, I'd assume it's pretty self-contained, since the complexity in large systems regularly comes from all the other systems that you interface with (at least for the aforementioned Perl app).

6nf 10y ago
Ten programmers working together can get almost twice as much done as one programmer.
- douche 10y ago
  I want to print this out and frame it for my office
- CroCroCro 10y ago
  yes
- mwcampbell 10y ago
  You got any evidence for that?