Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Java? Tales from a Python Convert

sookocheff.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Why Java? Tales from a Python Convert

#91

Post by wtetzner »

dozzie wrote: post #85
sytelus wrote: post #37

OP is glossing way too many things. 1. Desktop users are tricked in to installing Ask toolbar crapware. Which other language tricks users in to doing that? 2. Java development actually have languished for very long time and it is very recent that it started to catch up with C# and other modern languages. Java forums are filled with cries and screams for adding these improvements for years on. 3. Java is built on lang…

> 1. Desktop users are tricked in to installing Ask toolbar crapware. Which other language tricks users in to doing that? .NET requires you to install Windows. I think it's the same category.

Maybe even worse.

Re: Why Java? Tales from a Python Convert

#92

Post by wtetzner »

ubercow wrote: post #4

The one thing keeping me away from Java still is the awful experience around modeling data. Compared to something like a case class in Scala or even autoproperties in C#, writing classes with a bunch of getter and setter methods just to keep state is really tedious.

Yes, in the Java projects I work on we use Lombok [1], which is nice, but is also a hack around the fact that Java makes these things hard.

https://projectlombok.org/features/index.html

Re: Why Java? Tales from a Python Convert

#93

Post by wtetzner »

zo1 wrote: post #22
cballard wrote: post #18

Earlier quoted context omitted.

If it can be generated, why doesn't the compiler do it for you? This shouldn't be done at the IDE level.

Because it's not about tooling, it's about being explicit vs implicit. Though, there is something to be said about having a nice default that you can easily invoke at the code-level.

Having the ID generate getters and setters makes it difficult read your data types, and adds additional work when modifying them.

Re: Why Java? Tales from a Python Convert

#94

Post by wtetzner »

hodwik wrote: post #53
pzone wrote: post #31

Earlier quoted context omitted.

That's because Java is pedantically and obsessively object-oriented

I've found that most people who think Java is overly OO are actually writing procedural programmers, who use objects as ornamentation. It is fundamental to OO that implementation details are not exposed. Accessor methods are, by their very definition, not Object Oriented. It's okay to use them, but you're not doing OO, and you very likely shouldn't be using Java if that's the case.

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.

Re: Why Java? Tales from a Python Convert

#95

Post by wtetzner »

elchief wrote: post #75
ajnin wrote: post #36

Earlier quoted context omitted.

... which is a hack using undocumented/non-public APIs of the Java compiler, so that's not really a viable solution.

except that, you know, it works.

Yeah, the hack makes me nervous, but not nervous enough to write Java without it.

Re: Why Java? Tales from a Python Convert

#96

Post by TheCoelacanth »

alexkindel wrote: post #63
angryasian wrote: post #52

Earlier quoted context omitted.

Now with Optional in Java 8 its not an issue.

Optional is great, but it would be far more powerful if types not wrapped in Optional were guaranteed to not be null.

And if Optional values themselves were guaranteed not to be null.

Re: Why Java? Tales from a Python Convert

#97

Post by hodwik »

wtetzner wrote: post #94
hodwik wrote: post #53

Earlier quoted context omitted.

I've found that most people who think Java is overly OO are actually writing procedural programmers, who use objects as ornamentation. It is fundamental to OO that implementation details are not exposed. Accessor methods are, by their very definition, not Object Oriented. It's okay to use them, but you're not doing OO, and you very likely shouldn't be using Java if that's the case.

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 do it if it isn't obvious.

Low-level accessors to an "object's" state are almost never an accurate representation of the domain you are modeling -- they're bad design.

If you need them, you've probably missed a piece of the puzzle.

That being said, most programmers don't need to be doing OO at all. The level of guarantee it provides is, for most people, not worth the cost. In those cases, don't use Java.

We will all be having this same argument about functional languages in 10 years. Mutability is not functional, if you're relying on mutability you're probably just doing procedural code wrapped up in functional decorations.

Re: Why Java? Tales from a Python Convert

#98

Post by csense »

Maven's one of the most disgustingly over-engineered, obtuse, verbose, tightly coupled pieces of s...oftware I've ever seen. From the project's own 5-minute introduction [1]:

If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds...The POM is huge and can be daunting in its complexity...You executed the Maven goal archetype:generate, and passed in various parameters to that goal. The prefix "archetype" is the plugin that contains the goal... the second [command] is simply a single word - package. Rather than a goal, this is a phase. A phase is a step in the build lifecycle, which is an ordered sequence of phases. When a phase is given, Maven will execute every phase in the sequence up to and including the one defined. For example, if we execute the compile phase, the phases that actually get executed are [list of 6 items]...Although hardly a comprehensive list, these are the most common default lifecycle phases executed [list of 10 items]...

So in order to use this, I have to understand its own specialized non-standard vocabulary, like artifact, repository, archetype, plugin, goal, package, phase, lifecycle...the build configuration is in XML...it does a lot of stuff automagically, like executing five extra phases or downloading dozens or hundreds of executable files from the Internet.

People love Maven for some reason, but I'll use shell scripts or Ant for my Java builds, because when the build breaks [2], I want to be able to understand what's going on without having to read a few hundred pages of the build system manual.

[1] https://maven.apache.org/guides/getting-started/maven-in-fiv...

[2] Anyone who's ever worked with any build system knows the build will break.

Re: Why Java? Tales from a Python Convert

#99

Post by codingbinary »

potatosareok2 wrote: post #77
codingbinary wrote: post #76

Earlier quoted context omitted.

And don't forget Java's type erasure. Still wondering how they could actually call that a FEATURE.

Was erasure necessary to maintain backwards compatibility? Also what are you doing that you need type information at runtime?

Type Erasure is the reason you can't use builtin types as generic arguments. And in a lot of cases it forces you to cast.

And as type erasure happens very, very early in the compilation process, you lose a lot of static type information the compiler could act on or give you warnings.

Re: Why Java? Tales from a Python Convert

#100

Post by codingbinary »

wtetzner wrote: post #89
dmm wrote: post #86

Earlier quoted context omitted.

No it wasn't necessary to maintain backwards compatibility. Type erasure was implemented to allow libraries to upgrade to generics without breaking compatibility with existing applications.

How is that not backwards compatibility?

The one is on a language level, the other on an application/framework level.
Post reply on HN