3 ms·

Million loc systems are a symptom of cultural disease, they are not something to celebrate. Take a step back and seek the root cause of the problem. The whole p

Million loc systems are a symptom of cultural disease, they are not something to celebrate. Take a step back and seek the root cause of the problem. The whole point of Java was to let companies throw bodies at a problem and not have the result segfault or get hacked. It succeeded, and now all those bodies are generating all those lines, just as intended. Clojure shows us, I think, a different way. One in which a small team with a small amount of money can out perform a billionaire's body shop.

mikekchar 8y ago
Not to be disagreeable (because I think I agree with your main point, even though I've never used Clojure, or any similar language, in anything but toy programs), but we were writing million line pojects in C++ long before Java came out ;-) There were really 2 main points to java (as I understand it). The first was to have a statically typed language that had a relatively fast runtime that could easily be ported to many platforms. Indeed, the killer application for Java, IMHO, was the idea of implementing that run time in hardware (and it's a shame that Sun never really pushed that angle very hard). The other main point of Java was to codify a set of "best practices" as a kind of "defence against the bad programmers". The intent was to reduce the difficulties of hiring programmers by making the programming language less expressive (compared to C++, for instance). IMHO, this largely failed as programmers are creative and will always find ways to be expressive. So on one had we got C++ template crack and on the other hand we had abstract factory factories. Basically, though, I don't think there was ever a real intent to allow Java (the language) to make it easy to scale development to larger teams, or larger code bases. The success that Java had in getting into large enterprises just meant that the normal Java user was interested in that, because it's the environment that they were working in. The idea is attractive to enterprise people because they already have a lot of people and they want to get a lot done in a short period of time. Most managers (and many influential programmers) do not understand the loss of productivity that accompanies communication overhead from having larger teams. The large code bases are the necessary result of programmers trying to isolate themselves from the hundreds or even thousands of other programmers that they are working with. By building complex boundaries, they can reduce the communication complexity at the cost of increasing the program complexity. This is usually a good trade off if you are stuck having to work with an insane number of people. BTW, in case you think that it is only non-technical people who fall into this trap, I will provocatively mention 2 words: micro services. The way micro services are usually designed and implemented, they are usually the very definition of premature subsystem decomposition. This premature decomposition is chosen so as to allow a few people to "lock in" design decisions and reduce the need to communicate with a whole bunch of people who might ruin their architectural vision. Basically, same problem, same result. Technical people (who didn't live through the CORBA years) drink it up like the yummy, yummy cool aide it is, though ;-)
- tragomaskhalos 8y ago
  From my experience, Java's killer feature was and always has been that you can throw significanty less capable programmers into the pool and not have such obviously catastrophic outcomes with doing this as with C or C++. This mostly comes down to taking memory management off the table, although the smaller set of features in Java (compared to C++) is surely also a factor. I suspect that platform portability is a bit like database portability - it sounds nice but in practice most projects will have committed to a platform up front. Technical people understand that a technology that can drastically reduce LOC is a game-changer: you can hire far fewer programmers - these need to be better than your bucket-brigade Java folks of course, but that's OK because you're saving money on the quantity of them; you need fewer managers to coordinate everyone; the product itself will be better because it's had fewer fingers in the pie, and internal comms during development will have been better because the team was so much smaller. No, the big problem with this is that management in big corps simply do not believe that these sorts of savings are possible - it just seems too good to be true, and they are too risk-averse to rejig their organisations to the required extent; they also fear being beholden to a small priesthood of very clever technical people from which there is no way back - eg we can't ship our Clojure codebase back offshore to some commodity programmers because they won't be able to make head or tail of it.

mikekchar 8y ago

Not to be disagreeable (because I think I agree with your main point, even though I've never used Clojure, or any similar language, in anything but toy programs), but we were writing million line pojects in C++ long before Java came out ;-) There were really 2 main points to java (as I understand it). The first was to have a statically typed language that had a relatively fast runtime that could easily be ported to many platforms. Indeed, the killer application for Java, IMHO, was the idea of implementing that run time in hardware (and it's a shame that Sun never really pushed that angle very hard). The other main point of Java was to codify a set of "best practices" as a kind of "defence against the bad programmers". The intent was to reduce the difficulties of hiring programmers by making the programming language less expressive (compared to C++, for instance). IMHO, this largely failed as programmers are creative and will always find ways to be expressive. So on one had we got C++ template crack and on the other hand we had abstract factory factories. Basically, though, I don't think there was ever a real intent to allow Java (the language) to make it easy to scale development to larger teams, or larger code bases. The success that Java had in getting into large enterprises just meant that the normal Java user was interested in that, because it's the environment that they were working in. The idea is attractive to enterprise people because they already have a lot of people and they want to get a lot done in a short period of time. Most managers (and many influential programmers) do not understand the loss of productivity that accompanies communication overhead from having larger teams. The large code bases are the necessary result of programmers trying to isolate themselves from the hundreds or even thousands of other programmers that they are working with. By building complex boundaries, they can reduce the communication complexity at the cost of increasing the program complexity. This is usually a good trade off if you are stuck having to work with an insane number of people. BTW, in case you think that it is only non-technical people who fall into this trap, I will provocatively mention 2 words: micro services. The way micro services are usually designed and implemented, they are usually the very definition of premature subsystem decomposition. This premature decomposition is chosen so as to allow a few people to "lock in" design decisions and reduce the need to communicate with a whole bunch of people who might ruin their architectural vision. Basically, same problem, same result. Technical people (who didn't live through the CORBA years) drink it up like the yummy, yummy cool aide it is, though ;-)

tragomaskhalos 8y ago
From my experience, Java's killer feature was and always has been that you can throw significanty less capable programmers into the pool and not have such obviously catastrophic outcomes with doing this as with C or C++. This mostly comes down to taking memory management off the table, although the smaller set of features in Java (compared to C++) is surely also a factor. I suspect that platform portability is a bit like database portability - it sounds nice but in practice most projects will have committed to a platform up front. Technical people understand that a technology that can drastically reduce LOC is a game-changer: you can hire far fewer programmers - these need to be better than your bucket-brigade Java folks of course, but that's OK because you're saving money on the quantity of them; you need fewer managers to coordinate everyone; the product itself will be better because it's had fewer fingers in the pie, and internal comms during development will have been better because the team was so much smaller. No, the big problem with this is that management in big corps simply do not believe that these sorts of savings are possible - it just seems too good to be true, and they are too risk-averse to rejig their organisations to the required extent; they also fear being beholden to a small priesthood of very clever technical people from which there is no way back - eg we can't ship our Clojure codebase back offshore to some commodity programmers because they won't be able to make head or tail of it.