An eCommerce framework is never going to have a small footprint, for one example. That's why Java or other strongly typed/structured languages get used in enterprise software.

Java is used in enterprise software primarily because it's what gets used in enterprise software. Language popularity is a positive feedback loop, and once a language establishes itself in a sector to the point universities start to teach it with that sector in mind, it's hard to unseat it. Businesses, especially large ones, don't choose tech based on technical merits; they tend to focus on aspects like "can we get support with SLA for parts of our tech stack", and "how easy to find/cheap the developers specialized in that stack are", and "let's do what the IBM/Oracle salesman says we should, that must be the right thing to do".

I don't see a reason an eCommerce framework couldn't have a small footprint. The lower bound is the amount of actual, necessary complexity in the problem space. But that's usually orders of magnitude less than the size of the codebase, because of all the boilerplate and greenspunning that happens in Java, Enterprise Java in particular.

(Note that in commercial work, I moved from Java to Common Lisp, so I have a different view than typical about just how much boilerplate and repetition can be simplified and removed when your language lets you do it.)

You're not going to cut your lines of code by an order of magnitude by switching from Java or C# to JavaScript or Python, but I would say you do get an order of magnitude increase in ease of managing large code bases with the popular statically typed languages.

I'd rather have 1M lines of Java than 100k lines of JavaScript, and if essential complexity took 1M lines of Java to flesh out, you aren't reaching parity with 100k lines of JS.

> You're not going to cut your lines of code by an order of magnitude by switching from Java or C# to JavaScript or Python

Why not? I can easily see reducing SLOC 10-50x by switching from Java to JavaScript.

> if essential complexity took 1M lines of Java to flesh out

I very much doubt that in a 1M SLOC Java codebase - at least in pre-Java 8 codebase - the essential complexity is any more than 1% of that. My work experience with Java suggests that the language and the surrounding ecosystem and practices promote extreme proliferation of accidental complexity.

I am sure you could reduce complexity quite quickly but then you are building a different product. The selling point of an eCommerce framework is the structure and existing feature toolkit. Like modules, events, mechanisms to safely override core functionality and all of that. I am also sure you could build a more compact eComm framework, but I think you would start to trade off structure for reduced complexity. For me though, more structure equals less need to worry about the complexity as that's been abstracted away.

I wouldn't mind seeing the other side of the fence though, I will admit I have worked in enterprise codebases for most of my career so I am definitely biased.

Yes, the secret is to write software that is composed of several modules that operate independently. Java's culture is to write a big ball of classes that are combined to everything you need. In other languages you can create different programs that compose to provide the desired functionality. This was the original "aha" moment of C and UNIX designers. Even though C is a brittle language, it allows the decomposition of systems into small programs thanks to files and filters.

There's nothing stopping you from writing uncoupled classes that work like small modules and maintaining them in one repository. Tightly coupled classes are a code smell even in Java, I wouldn't say it's the languages fault, more that the language is used more often in enterprise software and so all the frameworks/libraries/tooling is geared toward monoliths.

From a sample size of one - My Python and Go code tend to be fewer lines per file compared to Java, for projects that are similar in complexity. This is not about the terseness/dense nature of the language, but the sheer simplicity in other languages to decouple file structure from class structure (at least within a given directory)

What about Java do you think adds lines in regards to file structure?

I must also admit I woild rather ten lines of code and be clear and certain, so being verbose doesn't bother me much.

With respect to verbosity: Certain, yes. Clear, no. Boilerplate is a thing.

> Yes, the secret is to write software that is composed of several modules that operate independently.

This isn't a secret, and in certain corners not even considered generally true -- backlash against microkernels and microservice architectures have intensified in the last half-decade, to give two examples.

90% of code bases that attempt modulability get it wrong. The idea is to be able to lift out functionality to be reused elsewhere. But what 90% of code bases do wrong is that they move code into modules, but you can not lift out those modes as they depend on all other modules. It might help if you use the words library instead of module. And public API instead of micro service.

The famous UNIX mantra hardly seen in commercial UNIX settings, but cargo cult across the FOSS UNIX community.

> Other languages may be able avoid having a large code base entirely. I recall reading some stories of people rewriting giant Java code bases into very small Clojure programs that were more flexible, maintainable, and scalable.

I can rewrite any bad written code in less lines, same language same framework as initial code.

disclaimer: elixir fanboi here just trying my best to temper my bias for this comment.

I recently rewrote a c# project that had not been completed in elixir. Hugely, anecdotal (as all of these types of stories are) but the project went from ~5kLoC to <800LoC when rewritten in elixir. That's after the elixir app was feature complete too. Now you might believe that's a developer experience gap, but the c# dev had way more experience with c# and in my experience this other dev is much better than me generally. Within a week of learning elixir he was catching my bugs all over the place.

Neither 800LoC nor ~5kLoc qualifies as a large codebase. In my experience sh*t starts to get real when you go beyond 30-50kLoC, at least that's when I start losing the needle in the haystack. I've done that with Erlang and it's not really fun.

In comparison, my current project in TypeScript is at this stage now and by using an IDE things are quite under control. Refactoring is easy and even major architectural changes are manageable (we did ~5 so far, depending on how you count).

Wasn't the case with Erlang. We only managed to do one such major change and it almost killed the project. It probably even actually killed the project as we were late to the party and failed afterwards.

Why was dealing with a large project in erlang so difficult?

No type system means an Erlang developer has to keep a lot of things straight in their head. It's not unique to Erlang.