Bollocks. Maintainable code is maintainable. Unmaintainable code is unmaintainable. In 20 years of writing software, I've dealt with Java code that was impossible to understand which made it painful make even simple changes, and I've dealt with Python code that was trivial to reason about so changes were easy and fast.
Invariably, the ugliest code I've seen has always come from "we must move fast at the expense of everything else" startups. I worked at a startup that combined the worst of architectural temple building with the worst of "maintaining code is a Maserati problem" (e.g. by the time somebody has to maintain it, I'll be driving a Maserati and not caring). The company almost folded due to the weight of the code base preventing features from being released. Did I mention this was all Java?
Many fast-moving startups choose dynamic languages to do their ultra-fast, sloppy iterations on. Fast-moving startups tend to write code that is unmaintainable. Later in the lifecycle, as the maintenance nightmare hits, these same companies move to static languages to "fix their problem", but they've also introduced a lot more discipline in their engineering process. Afterwards, the dynamically typed language gets the blame for the lack of maintainability and the static language gets props for being maintainable.
Correlation is not causation. The engineering practice has far more to do with maintainability than the language itself. It just happens that, in the last 10 years, dynamic languages have been chosen more often during periods when companies write poor code. My Java example above was from 1998 to 2001 , when Java was the hot language for building the dotcom boom.
Hi, author here. I agree you can have bad code in any language. I also agree that it's possible to build large applications in dynamic languages.
Really, the main point I'm trying to make is that when you have millions of lines of code spanning a decade, it's WAY easier to have a compiler guiding you through certain types of refactorings than a test suite that takes half an hour to run. (If you search the internet for things like IMVU tests buildbot continuous integration you'll see how large our test infrastructure is.)
Our newest language at IMVU is Haskell, and the earliest Haskell written was quite nasty. We hadn't figured out the structure we wanted. But it's shockingly refreshing to be able to lean on the compiler to quickly restructure all of that old code.
Code without types is orders harder to maintain and modify, even with extensive code coverage (because you can never really now how extensive that coverage is).
Also, the absence of type annotations make the simple human understanding of such code extremely harder.
I hear you. Overuse of "Spring" configuration makes me crazy. It's like some terrorist organization where you never know your contact's real name, and nobody knows anybody else in the organization, in case the "coupling police" try to bust up a cell. "We always just called him Otto" (autoinject)
Every claim that's been made in this thread is based on anecdotal experience. Maybe in 50 years software will be mature enough that we'll have actual empirical data to back up our design/tooling decisions. But for now, almost no one is seriously interested in testing this stuff with well designed (and well funded) studies.
Except that one person actually made an anecdote and the other is making unsubstantiated claims. I would like to know if there is any truth in their claims or is it just another anecdote.
Programs that contain more semantic information are easier for both humans and tools to reason about, it didn't even occur to me that this would be a controversial statement.
Your point isn't well supported by citing Java code though. Java's type system gives you almost nothing in terms of what modern type system's promise, and it does so at the expense of a vast amount of unnecessary boilerplate.
At least with Java 8 lambdas FINALLY coming out, maybe we'll get more frameworks like "Spark" (register callbacks in actual code) and fewer like "Spring" (reflect in classes from XML gobble-de-gook).
Invariably, the ugliest code I've seen has always come from "we must move fast at the expense of everything else" startups. I worked at a startup that combined the worst of architectural temple building with the worst of "maintaining code is a Maserati problem" (e.g. by the time somebody has to maintain it, I'll be driving a Maserati and not caring). The company almost folded due to the weight of the code base preventing features from being released. Did I mention this was all Java?
Many fast-moving startups choose dynamic languages to do their ultra-fast, sloppy iterations on. Fast-moving startups tend to write code that is unmaintainable. Later in the lifecycle, as the maintenance nightmare hits, these same companies move to static languages to "fix their problem", but they've also introduced a lot more discipline in their engineering process. Afterwards, the dynamically typed language gets the blame for the lack of maintainability and the static language gets props for being maintainable.
Correlation is not causation. The engineering practice has far more to do with maintainability than the language itself. It just happens that, in the last 10 years, dynamic languages have been chosen more often during periods when companies write poor code. My Java example above was from 1998 to 2001 , when Java was the hot language for building the dotcom boom.