Hacker News new | past | comments | ask | show | jobs | submit login

It's not just a question of language or platform but also culture.

Java is probably the #1 culprit for building huge systems to solve simple problems. The goal is small, simple, fast, cheap, and 'enterprise' solutions are rarely a good fit for new companies. Now, if your United Airlines and you have complex problems involving hundreds of systems yea your in a world of pain and Java is a great option for dealing with complexity.

That said, their are plenty of rock solid Java programs that avoid the bloat there just rarely websites.




> Java is probably the #1 culprit for building huge systems to solve simple problems.

Don't blame the language for the enterprise culture.

Before Java existed I have seen similar complex systems done in C, C++, Clipper, VB and quite a few other languages.

Just to cite a concrete example, before J2EE existed, we had CORBA and DCOM systems, plugged with distributed transactions across multiple OS systems. Great debugging experiences.


The culture, tools, and language evolve together.

How else do you explain things like:

InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter

JDBC is perhaps a better example. It's short and simple but designed around raw SQL which ends up creating a huge mess vs something like LINQ. Sure, there are hundreds of 3rd party solutions to this problem just pick one except external library's might pick something else...


This example can be quite easily explained: its generated from a designer tool, as it is part of the Nimbus LaF. Its not really part of the JRE API, even though the class may be public.

Btw., the longest name for .NET is not much shorter: UpDownBase+UpDownButtons+UpDownButtonsAccessibleObject+DirectionButtonAccessibleObject


Easy. As they have on a few CERN offices "You can write FORTRAN in any language".

I have seen InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter written in multiple enterprise languages.


There is two types of complexity:

- irreducible complexity, this is inherent to the problem space. For example, tax software cannot be simple because the tax laws are not.

- incidental complexity - this is because programmers like to prove how smart they are in code :-)


Eh I really strongly disagree with this common criticism -- "huge overcomplex etc etc". Basically if you use a tool suite properly designed for your development area, you basically need to know how to setup your project/IDE integration with server runtimes etc. (sometimes not easy to do if you don't know how but once you do it's 15 minutes, once per project... consult a senior dev for first 1 or 2 project creations).

Then you can usually plug in external systems that obscure mounds & mounds of complexity (CMS, persistence, etc.) just by making a few minimal calls to their APIs. Then extra features (caching, asset compilation) are a bonus -- the project is so rock solid to begin with that often you don't need to optimize every aspect of the code.

EDIT: I've also found this to be why corporate devs are not miserable. The tools are so reliable that the companies don't mind paying devs to use this targeted, minimal approach. And for the devs it means they can try their hand at pet projects with novel code without worrying about ever getting caught in a bad timecrunch. Corps with standard needs don't seem to require overtime work to keep the wheels spinning.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: