Live data from Hacker News

Why Java? Tales from a Python Convert

sookocheff.com

101–102 of 102 posts

Re: Why Java? Tales from a Python Convert

#101
I think the author has set an impossible task for the article: trying to sell Java without giving any specific use cases. Generalities don't cut it, especially if you've already invested time learning how to do something in Python, which isn't perfect, but can match the JVM in the areas that it does excel at (e.g. problems that need NumPy or Django).

Java is irritatingly pedantic about sticking to its idea of how OOP should work. It has that design by committee feel to it that enforces some idioms that please no one (like pushing object Factories). If you need to get a prototype out or want something that can let you automate a task quickly with little BS, you don't want Java.

Java is good for enterprise developers as it tends to reign alot of the cowboy tendencies of some programmers and helps to force everyone on the project to use the same clearly defined, well planned (and less elegant) APIs and other systems. And the JVM keeps you from being tied into some specific hardware that may go away in the future.

It's the difference between a toolkit to design and build a cool building, like the Space needle, or you need to coordinate a huge number of contractors because you're building the Big Dig or Chunnel.

Re: Why Java? Tales from a Python Convert

#102
post #97

Earlier quoted context omitted.

Except that encapsulation doesn't make a lot of sense when you're just modelling information. For example, suppose you have an Employee class that contains the employee ID, name, birth day, etc. Employee records don't do anything. They're just data. Hiding that data makes no sense if the point of their existence is just to hold the data.

You don't simply model information in an OO language, everything is an object, you're supposed to model your domain. I don't reach into the employee class and "get" the employee ID so I can do something with it. The employee class knows what to do with their own ID. Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to…

> everything is an object

Well, if we're talking Java, not everything is an object. None of the primitive types are, and Java has static methods.

> Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious.

OK, so I picked a bad example. What if you're dealing with records of tree data? Are you suggesting that modelling the domain means that trees should know what to do with the information about their diameter? In what way is that modelling a domain?

In software we're rarely writing simulations of the real world, and even then, it doesn't always make sense to have objects hide information that other agents could just observe about them.

We're usually dealing with information, not actors.

Post reply on HN