5 ms·

> Whatever you're using it for, clearly it's the 1%. This was on a small - fairly certain <1MLOC - codebase. I'm small fry. The only unusual thing would perh

> Whatever you're using it for, clearly it's the 1%. This was on a small - fairly certain <1MLOC - codebase. I'm small fry. The only unusual thing would perhaps be having small enough compilation times (due to e.g. incremental compiles and small changes not rebuilding the world) for linking of multiple projects to overlap. Boost and the Linux Kernel, noodling in at closer to ~20MLOC, or VS2012's ~50MLOC, might spend more time compiling in their typical edit cycles. > Expecting Apple to completely gimp the macbook for the average pro user (dev, photoshop, video editing) I suppose I'm having difficulty here seeing how a small weight and size increase for more DDR chips, or a larger battery, is going to "completely gimp" the macbook. Since I already touched on dev - I'll let someone else touch on video editing: https://www.youtube.com/watch?v=eJtrQ5CcCN0&feature=youtu.be&t=124 https://www.youtube.com/watch?v=eJtrQ5CcCN0&feature=youtu.be... . Things will only get worse on that front as 4K becomes popular. > They can't cover all use cases, but they can cover most. Agreed. I'm just not sure they have covered most "pro" users.

mpweiher 10y ago
Maybe the problem isn't Apple's hardware, but 20-50MLOC code bases? Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack. MS Office alone is >400MLOC. That's 20000x the code, or 20KLOC^2. There is no way it is 20000 times better or more useful. However, let's assume for the sake of argument that it is 100x better/more useful (something I'd consider dubious, but it's a good upper bound). That still leaves a factor 200x unaccounted for. Or 99.5% of the code. TBL's first web-browser was ~5KLOC, took him a couple of months to write, in his spare time IIRC. It included editing. NCSA Mosaic took a team of five one year to complete, was 100KLOC and did not include editing. The current (last time I checked) version of Firefox is 13MLOC. Is it 2500x better? And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention.
- deleted 10y ago
  [deleted]
- MaulingMonkey 10y ago
  > Maybe the problem isn't Apple's hardware, but 20-50MLOC code bases? As written, I'm running into issues in <1MLOC codebases, on hardware just a touch more limited than the max spec of Apple's latest line. The 1MLOC equivalent would break on Apple's hardware, I'm sure. So, no - I don't think 20-50MLOC code bases are to blame. > Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack. It's fine and all to pine for the good old days when computers were simpler than the computer within even your lowly modern hard drive - which is itself inside your modern computer - all in the name of the ever increasing performance we today take for granted. But it's sheer fantasy to think we can support the cambrian explosion of hardware options out there since then (all from different vendors with different interests and standards) with the same sized codebases as we had back then. Simply working around the hardware errata will take more code for many individual pieces of hardware - much cheaper and easier to fix things in software than fab a new revision of chips and toss out all the old, after all. Nobody's claiming linear relationships between source quantity and product quality. Nobody goes to an all you can eat buffet expecting caviar. Hell, most would argue an inverse relationship - the less code you have, the better you can polish it. But can a modern kernel work with thousands of times more unique hardware SKUs? Wouldn't surprise me. And hardware's expensive to design! If the hardware options out there can multiply by such magnitudes, take a fraction of a second to think what must have happened to software options - relatively cheap by comparison. It's a miracle we're not measuring individual software projects in BLOCs. Yet - give it time. If such compatability, flexibility, choice, and performance concerns don't interest you - well, I'd be quite interested in what you found necessary to get your Alto talking to the HN website! > And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention. I have mastered the skill of caring about a second problem at a time. I've heard legends of masters who could care about a third problem, but I have no evidence nor belief in such myths. But yes - link-times are worse ;). And refactoring. And testing. Security. And...

mpweiher 10y ago

Maybe the problem isn't Apple's hardware, but 20-50MLOC code bases? Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack. MS Office alone is >400MLOC. That's 20000x the code, or 20KLOC^2. There is no way it is 20000 times better or more useful. However, let's assume for the sake of argument that it is 100x better/more useful (something I'd consider dubious, but it's a good upper bound). That still leaves a factor 200x unaccounted for. Or 99.5% of the code. TBL's first web-browser was ~5KLOC, took him a couple of months to write, in his spare time IIRC. It included editing. NCSA Mosaic took a team of five one year to complete, was 100KLOC and did not include editing. The current (last time I checked) version of Firefox is 13MLOC. Is it 2500x better? And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention.

deleted 10y ago
[deleted]
MaulingMonkey 10y ago
> Maybe the problem isn't Apple's hardware, but 20-50MLOC code bases? As written, I'm running into issues in <1MLOC codebases, on hardware just a touch more limited than the max spec of Apple's latest line. The 1MLOC equivalent would break on Apple's hardware, I'm sure. So, no - I don't think 20-50MLOC code bases are to blame. > Xerox PARC had, effectively, a simple version of what we consider "Personal Computing": word-processing, E-Mail, laser printers, software development, proto-Internet. Alan Kay claims it was less than 20KLOC, and that's a plausible figure considering the Alto had 128K RAM and a 2.5MB disk pack. It's fine and all to pine for the good old days when computers were simpler than the computer within even your lowly modern hard drive - which is itself inside your modern computer - all in the name of the ever increasing performance we today take for granted. But it's sheer fantasy to think we can support the cambrian explosion of hardware options out there since then (all from different vendors with different interests and standards) with the same sized codebases as we had back then. Simply working around the hardware errata will take more code for many individual pieces of hardware - much cheaper and easier to fix things in software than fab a new revision of chips and toss out all the old, after all. Nobody's claiming linear relationships between source quantity and product quality. Nobody goes to an all you can eat buffet expecting caviar. Hell, most would argue an inverse relationship - the less code you have, the better you can polish it. But can a modern kernel work with thousands of times more unique hardware SKUs? Wouldn't surprise me. And hardware's expensive to design! If the hardware options out there can multiply by such magnitudes, take a fraction of a second to think what must have happened to software options - relatively cheap by comparison. It's a miracle we're not measuring individual software projects in BLOCs. Yet - give it time. If such compatability, flexibility, choice, and performance concerns don't interest you - well, I'd be quite interested in what you found necessary to get your Alto talking to the HN website! > And if you think compile-times are the biggest problem with multi-MLOC code-bases, you're not paying attention. I have mastered the skill of caring about a second problem at a time. I've heard legends of masters who could care about a third problem, but I have no evidence nor belief in such myths. But yes - link-times are worse ;). And refactoring. And testing. Security. And...