Autocomplete as an Interface (2015)

Re:Autocomplete as an Interface (2015) by lgessler on Thursday January 16, 2020 @12:55PM (#22067022)

I don't think there's anything inevitable about AbstractSingletonProxyFactoryBean. This absurd design pattern has its roots in Java's misguidedly restrictive approach to abstraction, which all but requires classes and inheritance to be the primary units of abstraction. More graceful abstractions are unergonomic or impossible since Java was not designed e.g. for higher order functions. The requirement that everything be in a class and the ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.

[ Parent | on HN ]

Re:Autocomplete as an Interface (2015) by eitland on Thursday January 16, 2020 @02:31PM (#22067984)

> ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.

Is it really that hard to create a Helpers class with static methods?

I'm back on Java now after a rather long detour and I say I happily accept the verboseness of it for

- the niceness of having a IDE that can almost replace pair programming

- an ecosystem were dependency resolution works

[ Parent | on HN ]

Re:Autocomplete as an Interface (2015) by tlarkworthy on Thursday January 16, 2020 @02:49PM (#22068160)

> an ecosystem were dependency resolution works

My coffee just shot out my mouth.... What?

Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much).

I really like that nodejs can handle diamond dependancies.

sidenote: I do like the simplicity of Java code though too.

[ Parent | on HN ]

Re:Autocomplete as an Interface (2015) by eitland on Thursday January 16, 2020 @02:59PM (#22068256)

I think the real trick is avoiding trickery in the first place.

If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it.

Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%.

It is now upgraded, faster and easier to understand and upgrade :-)

[ Parent | on HN ]

Re:Autocomplete as an Interface (2015) by jzoch on Thursday January 16, 2020 @09:42PM (#22071390)

That’s just simply not true. Diamond dependencies are an all too common occurrence in java if you are writing anything serious. It doesn’t happen everyday but when it does it’s a serious PITA. It’s not a “you’re doing something wrong” but a “someone did something weird somewhere but now it’s up to you to solve”. You just pray it’s someone in your company who was the careless one.

[ Parent | on HN ]

Re:Autocomplete as an Interface (2015) by Macha on Thursday January 16, 2020 @09:44PM (#22071399)

Or you just have dependencies in your chain which require different versions of guava, or Jackson, or Lombok, or any of the other very common dependencies that still get changes

[ Parent | on HN ]