[gravypod]

> AFAIK people still complain about the GC. I've noticed that more modern languages don't have advanced GC like Java's.

I don't know many people who complain about Java 8.

> Mid-level code doesn't necessarily know what the appropriate response to an error is, so it shouldn't have to have to check for them. If things are working as expected, no exception. If something goes awry, let the calling code figure out the right response.

That said Null is still a valid responce. Sometimes it gets out of hand from implementation buy specifically .INI file readers I'd expect to return Null or Default if available for an unset property. There are many cases for null but that doesn't mean that it isn't abused.

> So, you have to encode in the name of the function the type of parameters it takes? And what's the point of classes if you can't take advantage of them?

I think your usecase there is indicative of a lack of understnading about the abstraction that classes present. Onesuch representation would be to not expose internal datasets. Another is to, if you need to exept a generic dataset make your function generic.

> Let me help you understand. A programming language like Java consists of many parts, but in the end, it is a program that takes a bunch of text files and converts it into bytecode that the CPU can understand and execute. Why do you insist on using an inferior programming language that requires the use of specialized tools, when those tools can be built directly into the programming language itself? IE, if I want to create a class, I'll just type "class A", not load up an IDE, click around a few times and hope I fill in the boxes right to have a hundred lines of boiler-plate code autogenerated for me. It's not the 1960s anymore. We can write code that writes code. Let's do more of that and less fussing with the minor details that no one cares about.

To quote you: you sound like someone who only uses vim. There is much more to an IDE then clicking New File. Again I do most of my prototyping outside of IDEs and move it into IDEs for the features that it provides.

VCS, static analysis, type checking, refactoring, debugging. All of this at your finger tips.

> It is if you have to type those names.

These are bad naming standards: __init__, __name__, __eq__

Magic names are not the answer. Names are only a problem if they are the only source of meaning.

Java's naming is a convention to help you be a better programmer but you don't need to use it. In python, some naming is forced on the programmer with no say inherintly in the language. The language will not work if you don't use their naming. This is not the case in Java.

> I'm not familiar with Java 8, but it sounds like they realized how bad of an idea it was if they're moving away from it.

If they are moving away from it then does it still "suck"?

> So you're saying I shouldn't use iterators because it's easier just to code around them? Iterators can be a powerful programming paradigm that is a major head-ache saver and time saver, but Java's implementation is so horrible you're recommending avoiding it. Got it.

I'm commenting on your iterator implementation. It's incorrect and not the best way to do it. The iterator is an abstraction and using a 1-item-stack is not an idea implementation. Compounding other datastructures to implement your data structure is the less-harmful alternative.

> I bow to your superior arguing skills.

I see no point in arguing against something that is correct. I also don't see how one flaw can make something suck. If you feel that way you should re-evaluate your love for JavaScript.

[grkvlt]

> That said Null is still a valid response. [...] I'd expect to return Null or Default if available for an unset property. There are many cases for null but that doesn't mean that it isn't abused.

We use a `Maybe<X>` return type that can handle returning a value (including `null`), an absence of value, or an exception. It extends `Optional<X>` and adds a new `isPresent()` method, and wraps the exception in such a way that the result `isAbsent()` and calling `get()` will rethrow the exception. Very useful...

[gravypod]

Null is meant to be used when it is likely there is a default handling for the responce. For instance

   String favoriteColor = accounts.get(username);
   if (favoriteColor == null) favoriteColor = "blue";
   setWindowColorTo(favoriteColor);

Removing null does not make your code more safe. Wrapping Null in more code does not make your code more safe.

You get null for free. I could write the same think that optionals do in Java with 1 static method

    public static boolean isAbsent(Object o) { return o == null; }

    public static <T> T get(T o) {
        if (isAbsent(o)) throw new RuntimeException();
        return o;
    } 

Now you get your nice abstraction from an inlined function. Wrapping it in an object in my opinion is bloat around seomthing that doesn't need it.

The best chance your have to sell all Java devs on something is @Nullable which is a fantastic idea. It lets you know where null WILL propegate so you know where to control it. IT will also help you get out of "I see NullPointerException so therefor null is the problem, not my code!"