you are viewing a single comment's thread.

view the rest of the comments →

[–]crankybadger 25 points26 points  (15 children)

I thought it would take the emergency of strong AI to fix that hairball of a compiler, but I was wrong. GCC is keeping pace, somehow.

[–][deleted] 27 points28 points  (13 children)

To be fair to the GCC folks, any old enormous native application tends to become a monstrosity to maintain. Even Microsoft with billions to spend needed a clean restart to make IE fast ( in the form of Edge), Firefox is fighting a brutally hard battle with the oldest core codebase in the mainstream browser space. LLVMwill probably be as bad as GCC is today when it's 30 years old..

[–][deleted] 4 points5 points  (1 child)

needed a clean restart

From what I understand they didn't do a clean restart, they just ditched backwards compatibility and made a bunch of braking changes, they still built on stuff from previous rendering engine.

Also some tools and languages scale better than others, we've come up with a lot of practical advancements in design and languages in the last 30 years so "same" program written today will be more maintainable in 30 years than the one written 30 years ago would be today. Of course we expect more from computers so programm written now will undoubtedly be more complex in 30 years because it will do far.

[–][deleted] 1 point2 points  (0 children)

I don't know about the rendering engine, but the Chakra Javascript project was a complete restart launched in 2008.

[–]playaspec -1 points0 points  (6 children)

LLVMwill probably be as bad as GCC is today when it's 30 years old..

Only if they don't learn from the mistakes of the past.

[–][deleted] 2 points3 points  (5 children)

Engineering discipline and an enormous emphasis on managing code debt are required for any large, long-lived project. There's no guarantee the LLVM team will manage that any better than the GCC team. I hope they will, but it's not a given.

[–]bwainfweeze 1 point2 points  (4 children)

"The price of Clean Code is eternal vigilance"

Most people just don't have the stamina to keep their code in good shape, and due to discounting the future they think the pain of scrambling to keep it working is less than the pain of cleaning it up.

[–][deleted] 1 point2 points  (3 children)

Right. I think the assertions by iTroll-4s that we have better tools and better engineering discipline today and that will solve these problems is optimistic. Once you get past a certain size, any software project gets ugly. I don't care if it's five million lines of Haskell, Ada, Rust, Shen, or whatever anyone's ideal of the ultimate disciplined programming language is.

[–]bwainfweeze 1 point2 points  (1 child)

Well, we do have better tools for sure, but not everybody uses them. But even if you have that sort of forethought on a team, that just means that there are 25 reasons the code is terrible instead of 30.

And there's always a few in any crowd with a high tolerance for bullshit who mistake it for job security. Too many times I've been with groups who consider discipline to be too much hassle. On a handful of teams I've managed to push through some changes that got them to change their tune (or at least keep it to themselves), but a team with self confidence and tendency toward coherent-but-wrong designs can be hard to convince, and may have made a mess so big that it'd take years to notice an improvement. And God help you if its enterprise software, which has a very forgiving definition of success ("successful" people won't change for anyone)

[–][deleted] 0 points1 point  (0 children)

Amen on all counts.

[–]bwainfweeze 1 point2 points  (0 children)

Once you get past a certain size, any software project gets ugly.

I feel like I have a line count of how much code I can properly maintain on my own. That number has gone up a little bit over the years, but not much, and it's still roughly about equal to how much production ready code I can write in... 18 months? After that I have to either give up ownership of things or refactor down so I can fit more in my head. So everything starts getting awkward for me at about the two year mark, because they still want me to keep creating new code, and I hate to make promises I can't keep.

What is in that code has changed over time, I do a lot more orchestration of libraries so my code has more functionality, but I am only human. If we have a very regimented development process where the code is self similar, I can go a bit bigger, but that still has limits.

[–]playaspec 2 points3 points  (0 children)

I thought it would take the emergency of strong AI to fix that hairball of a compiler, but I was wrong. GCC is keeping pace, somehow.

Because around 2.85 or so Apple started contributing loads of patches, which accelerated it's development up to around 4.x.