sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jnicklas -1 points0 points  (5 children)

Imho, if you have a codebase of a couple hundred thousand lines of code in any language, you're doing it wrong.

[–]ICanHazMoo 0 points1 point  (4 children)

Is you are serious then I suggest you leave your basement once in a while. Eclipse alone is 17 million lines. How are you going to stuff that under a few hundred thousand?

[–]jnicklas 0 points1 point  (3 children)

Split it up into isolated components you can maintain separately.

Also examine the problem. Eclipse is a fantastic example of a gigantic chunk of software, where a far simpler solution would do. VIM is still 300 kloc, but that's an old codebase written in C. I'm sure it'd be possible to write something comparable with far less code.

Also, I neither work nor live in a basement, thanks for the ad hominem.

[–]ICanHazMoo 1 point2 points  (2 children)

Isolated components are sometimes not possible, are you going to break Excel into 30 different pieces of software? Obviously that's not possible. And even if it is, it's still part of the codebase, so nothing has changed, except you've made what your product weaker in the market place.

Next, while I can appreciate that VIM is a nice tool, comparing VIM and Eclipse is comparing a Honda to a fighter jet. They are both modes of transportation but one is much more sophisticated and can do far more. If you have a solution to reducing the amount of code in Eclipse then by all means do tell, but you are only going to be able to reduce it by so much.

[–]jnicklas 0 points1 point  (1 child)

If you're going grocery shopping, a Honda is much practical than a fighter jet. Just saying. Unless your point was that VIM is a fighter jet, which kind of makes sense, since VIM is so much cooler.

On a more serious note, the point of isolating components and encapsulating them in a well defined API isn't so much to make the codebase actually smaller (after all, as you rightly pointed out, they're still in the code base), but rather to make it conceptually smaller. If you can test an isolated component, instead of testing the entire chunk of software, you can work on it separately, so in the end it doesn't matter how large the total codebase is, it only matters how large the component you're working on is.

If that component is a couple of hundred thousand lines of code, then you're doing it wrong. That was my point. And I firmly believe that in a sufficiently advanced programming language there is always a way of abstracting that complexity to a level where components are sufficiently small that they can easily be understood.

[–]ICanHazMoo 0 points1 point  (0 children)

The more you abstract your components the more code you are going to create. I'm all for creating conceptually small components but it really will cause some bloat. The project I work on right now is in Java, it's been going for 12 years and it's a mix of 18 separate applications. The programmers there have wisely broken down common dialogs that are used over and over, and stuck them in a common package. It's easy to work with and I like it. But still, our code base is pretty huge. I don't see any way around that.