4 ms·

This is why Java is used widely. It works. It works well. And this is also why Java is great for huge systems (not in terms of users, disk space or bandwith, bu

by gordaco 13y ago

This is why Java is used widely. It works. It works well. And this is also why Java is great for huge systems (not in terms of users, disk space or bandwith, but in terms of code size). The same can be said about a lot of "old" technologies, and certainly about almost every industry standard out there. On the other hand, once in a while the Alice/Albert bet happens to win; be it because the new system is really better (as in: easy to maintain, or really being capable of managing higher amounts of workload), for non-technological reasons (Alice/Albert just happen to have a great idea), or just because of luck. Over time their technology may even become the new industry standard. The problem here is that it's the Alices/Alberts from the world who make it progress by trying new things (and failing often), but we're afraid of failure. So, yes, it's completely natural that corps resort to Java or C#, while startups use Scala or Ruby. For all of you doing startups in shiny new technologies: this means that even failure has a bright side, since even in that case you've put your grain of sand to make the technology more mature.

Retric 13y ago
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.
- pjmlp 13y ago
  > 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.
  - Retric 13y ago
    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...
    - pjmlp 13y ago
      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.
      - deleted 13y ago
        [deleted]
    - MrBuddyCasino 13y ago
      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
- fat0wl 13y ago
  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.
- ryanobjc 13y ago
  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 :-)
matt_s 13y ago
We have part of a system at work that was written in Java and it is horrible because the team that built it has a bad case of NIH. They ended up implementing a very poorly designed file system based database. Now that part of the system has horrible I/O performance because it is opening, reading, writing literally 10's of millions of files per day. The development team wanted to be clever and innovative on something that should have been a dartboard throw at Oracle, MySQL, MS SQL, or Postgresql. The analogy to plumbing and electricians is funny because typically those types of contractors are really skeptical of new-fangled products and they usually want to stick with tried and true solutions. But those are industries that have been around for a couple hundred years, right? The point of the article is to focus on your core product and leave the plumbing alone by picking boring stable stuff. You can build a business with all boring stable stuff too, but that may not attract "rock star" developers.
- collyw 13y ago
  I am seeing the same crap on a project for the opposite reasons. They want to use NoSQL for the main queries, and are actively avoiding using a relational database. Means they are going to use the filesystem as a database, whereas a relational database on top of it would be a far better system.
- matwood 13y ago
  We have part of a system at work that was written in Java and it is horrible because the team that built it has a bad case of NIH. In that case the problem isn't Java but the NIH. One of the main reasons to use Java is for all of the existing, well tested libraries.
_random_ 13y ago
C# is closer to Scala than to Java these days. The type system might not be that advanced but there are value types, nice generics, proper annotations etc., and there is quite a bit of syntax sugar with more coming: https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation https://roslyn.codeplex.com/wikipage?title=Language%20Featur... PS: quite sure at least some corps are tackling Scala, Ruby is quite good for glorified web dev which is most of modern start-ups.
outworlder 13y ago
You are placing a lot of merit on Java. Most of it should be directed to the JVM. There's nothing inherently great about Java, other than the fact that it constrains programmers so much, that the damage a bad programmer can inflict is greatly reduced. At the same time, so is productivity. This can be mitigated up to a point by having more bodies, which is a thing that bigcorp can afford but startups cannot. Replace Java with anything else running on the JVM and you'll reap most of the benefits (libraries, application servers, deployment, etc), without many of the constraints.
- mcguire 13y ago
  "it constrains programmers so much, that the damage a bad programmer can inflict is greatly reduced" I have no idea what you mean by this.

by gordaco 13y ago

Retric 13y ago

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.

pjmlp 13y ago
> 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.
- Retric 13y ago
  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...
  - pjmlp 13y ago
    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.
    - deleted 13y ago
      [deleted]
  - MrBuddyCasino 13y ago
    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
fat0wl 13y ago
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.
ryanobjc 13y ago
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 :-)

matt_s 13y ago

We have part of a system at work that was written in Java and it is horrible because the team that built it has a bad case of NIH. They ended up implementing a very poorly designed file system based database. Now that part of the system has horrible I/O performance because it is opening, reading, writing literally 10's of millions of files per day. The development team wanted to be clever and innovative on something that should have been a dartboard throw at Oracle, MySQL, MS SQL, or Postgresql. The analogy to plumbing and electricians is funny because typically those types of contractors are really skeptical of new-fangled products and they usually want to stick with tried and true solutions. But those are industries that have been around for a couple hundred years, right? The point of the article is to focus on your core product and leave the plumbing alone by picking boring stable stuff. You can build a business with all boring stable stuff too, but that may not attract "rock star" developers.

collyw 13y ago
I am seeing the same crap on a project for the opposite reasons. They want to use NoSQL for the main queries, and are actively avoiding using a relational database. Means they are going to use the filesystem as a database, whereas a relational database on top of it would be a far better system.
matwood 13y ago
We have part of a system at work that was written in Java and it is horrible because the team that built it has a bad case of NIH. In that case the problem isn't Java but the NIH. One of the main reasons to use Java is for all of the existing, well tested libraries.

_random_ 13y ago

C# is closer to Scala than to Java these days. The type system might not be that advanced but there are value types, nice generics, proper annotations etc., and there is quite a bit of syntax sugar with more coming: https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation https://roslyn.codeplex.com/wikipage?title=Language%20Featur... PS: quite sure at least some corps are tackling Scala, Ruby is quite good for glorified web dev which is most of modern start-ups.

outworlder 13y ago

You are placing a lot of merit on Java. Most of it should be directed to the JVM. There's nothing inherently great about Java, other than the fact that it constrains programmers so much, that the damage a bad programmer can inflict is greatly reduced. At the same time, so is productivity. This can be mitigated up to a point by having more bodies, which is a thing that bigcorp can afford but startups cannot. Replace Java with anything else running on the JVM and you'll reap most of the benefits (libraries, application servers, deployment, etc), without many of the constraints.

mcguire 13y ago
"it constrains programmers so much, that the damage a bad programmer can inflict is greatly reduced" I have no idea what you mean by this.