Live data from Hacker News

Javapocalypse

jz13.java.no

81–90 of 129 posts

Re: Javapocalypse

#81
post #68

This is irrelevant, but I just had my first Java experience yesterday. I decided to make an Android app, it's a simple remote control for hobby projects (Raspberry Pi/etc) that gives you a customizable UI with buttons that perform API calls. It'd be pretty simple to do in Python, which is the language I am proficient in, but Android development sounds fun so I wanted to get started in that. Creating the UI was easy e…

The standard method for getting around this in the java world is to create 'sane' libraries (in the case of android http, something like http://loopj.com/android-async-http/ ) and then just use the library. The strong point of Java is just how many libraries there are - you often don't need to touch the actual built in Java APIs. On the server side (non-android) this has gone even further through the use of new annot…

I feel something as commonplace as making a HTTP GET or POST should be standardized at this point. There are many implementations which still require a decent amount of boilerplate.

Re: Javapocalypse

#82

Earlier quoted context omitted.

I heard that that had very large startup costs due to the Scala VM (IIRC), which is unfortunate for what I'm making (a remote control app) :/

AFAIK everything on Android runs on the Dalvik VM.

Yep, even Clojure does, but have never tried it really for Android, but it's just as possible as Scala. Jython has been possible in the past, but I haven't seen any recent projects updated to use it in the past 1-2 years.

Re: Javapocalypse

#83

And here I was thinking these airport towers run COBOL.

You could say Java is the new COBOL :)

More like, "ha ha, only serious"

Object fields = Data Division; Bean = Copy Book

Practices that actively discourage functional style programming in favor of procedural style programming with widely scoped variables.

I'm glad Java is more widely used than C++, but it's a hard language to really love, despite being (mostly) how I earn my living.

Re: Javapocalypse

#84

Earlier quoted context omitted.

What you described is mostly a problem of the standard library. Sometimes it's too low-level and it's better to use 3rd pary libraries for things like HTTP. There should definitely a way to create urls without having to check exception (ie. it would throw a RuntimeException that doesn't need to be checked). Java 7 also lacks very useful features like lambdas, mixins, nested methods etc. However, Java is a good choice…

Scala is such a language, at least to me it was a pain to go back to Python after learning Scala. And Scala's tooling is IMHO better than Python's these days, although still not as smooth as Java's.

I experimented with Scala for a while but got turned off by 1) very slow compilation 2) complicated and unelegant syntax.

Re: Javapocalypse

#85
post #67
post #54

Earlier quoted context omitted.

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't ha…

Java has polymorphism, your type can implement (I think) comparator and that should be it.

Of course, that doesn't work for int, float, etc because those types aren't objects, but then you typically don't have an array of those.

Re: Javapocalypse

#86

Earlier quoted context omitted.

No, that will force whoever is calling your method to handle that exception, now without knowing the actual context ("why does getWeatherForecast() throw MalformedURLException?" etc.). It also leaks an implementation detail, i.e. the use of URL-whatever. A RuntimeException, and any subclass of it, is unchecked and so the compiler does not force you to handle it.

Oh, right, you convert it to RuntimeException (ostensibly in multiple places where you don't want to handle the exception) and catch that one as a general exception. It makes sense now and sounds like a good solution, thank you.

It is a horrible solution, but it does work.

IMHO, go was right to get rid of exceptions (stack traces are useful) and just return two values.

Re: Javapocalypse

#87

Earlier quoted context omitted.

What you described is mostly a problem of the standard library. Sometimes it's too low-level and it's better to use 3rd pary libraries for things like HTTP. There should definitely a way to create urls without having to check exception (ie. it would throw a RuntimeException that doesn't need to be checked). Java 7 also lacks very useful features like lambdas, mixins, nested methods etc. However, Java is a good choice…

Hmm, yeah, I see what you mean. I think Go does a pretty good job of being a middle ground between Java and Python, it has the static typing with all the tooling advantages it brings, without the annoying need to be explicit about everything. I think you'll like it.

I quite like Go but I see it mostly as a C++ replacement, not Java or Python replacement. Java has far better tooling. It also has quite weak type system (no gnerics).

Dart is closest to my ideal of a general purpose language.

Re: Javapocalypse

#88
post #69
post #14

Earlier quoted context omitted.

>What attracts people to the Java world? Portability, security (automatic memory, static typing, etc.): you cannot bore a hole in your feet when shoving a nail. And backed by a huge company. Relatively fast. More reasons there: http://c2.com/cgi/wiki?WhyJavaIsGreat > exception-related problems A common hack it to wrap your code in a dumb try/catch block at the uppermost level. That way there is no scope-related probl…

What's sad about Java is that the whole type-safety, compile-time-checks, minimal-runtime-surprises etc has gone out of the window since the DI craze, so now we have a platform that is as "unsafe" as Python et al, whilst still being relatively heavy to set up etc.. I guess there's still the advantage of having extensive libraries..

DI = dependency injection, right?

How does dependency injection throw type safety out the window? You can only inject types that are a subtype of the declared type. Overridden methods can't extend the types of checked exceptions that are thrown [1]. I fail to see the hole in the type system here.

I'm not a Java programmer, but I use dependency injection all the time in other language, including dynamic languages like Ruby. I find it very helpful for isolating bits of code and making extendable interfaces. I'm genuinely curious if there's a major weakness lurking in DI that I haven't discovered yet. Please help me remove my blinders.

[1] http://stackoverflow.com/questions/5875414/method-overriding...

Re: Javapocalypse

#89
post #67
post #54

Earlier quoted context omitted.

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't ha…

What you are describing (calling it overloading,) having different functions of the same name implement different algorithms based on types, is called "ad-hoc" polymorphism, but Java isn't limited to that, and it isn't the best way to do things, because you invariably end up duplicating parts of the algorithm.

Java is very capable of writing parametrically polymorphic functions — on object types. They are called Generics, in Java-Parlance. Primitive types are excluded from that, but as you've already pointed out above, one can write ad-hoc polymorphic functions (methods.)

Finally, Java has subtype polymorphism — that kind of polymorphism that allows you to write a `Comparable` interface and have your class implement it, so the generic sorting function will work.

So in a sense, Java has "more" polymorphism than most other languages: ad-hoc, subtype, and polymorphic. With the exception of primitive types, for which only ad-hoc polymorphism works. Arrays are another icky area, you should avoid using them with Generics (parametric polymorphism) if at all possible. Generally, you would want to use primitive types and arrays in performance-critical areas of your code. Ideally, those shouldn't be many, so in practice, I found that to be a non-issue.

What is an issue is that Generics (parametric polymorphism) are a bit weird in Java-land, mostly because of type-erasure, their poor interaction with Arrays, and weird stuff with static and/or child classes.[1]

BTW, Haskell only has (bounded) parametric polymorphism. The "bounded" here is actually pretty important. The languages you mention implement some variant of System F as their type system. Haskell has System FC, and IIRC, OCaml has System F_ω. Java's Generics were inspired by Haskell's type system (Phil Wadler was one of the driving forces behind Java's generics.)

[1] Note: type erasure isn't a problem per se. Haskell has type erasure, and it's all well and good. The problem really comes from mixing type-erased generics with subytping and dynamic casts. That's just a mess.

Re: Javapocalypse

#90
Yay Oracle! Save us from the 42 year lag to create an open source alternative.

I know the video is a joke, but that was harsh. I think there are quite a few good open source languages that only took about 5 years or so to get going with a decent runtime library. What takes years is to get adoption of new tools from the grass roots up, more so than implementation.

Post reply on HN