Hacker News Reader

Comment by zeroc8 | Hacker News Reader

I'm currently a Java developer working on a large code base. This is where Java's object oriented nature really shows its weaknesses. Reading other people's code becomes a huge pain, since everything is mutable and you can never be sure what state your program is in after a function call. Even C++ is better in that regard, at least you can pass values by copy or const reference. Gleam looks really nice at first glance. The problem of course is, as long as there is no industry support, it doesn't make sense to invest into it. It may be ok for small side projects, but I wouldn't dare starting a major application in something like that. Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.

View on HN

> everything is mutable

That’s the real problem, not OOP. There is a functional-ish OOP style where most objects are immutable. Classes are used to capture invariants (in the sense of https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), or for local-only mutations (like building a collection in a local scope, which is passed on as immutable after building).

The defining characteristics of OOP are encapsulation and subtyping, not mutability.

And Java doesn’t properly support immutability :(

Encapsulation is a whole other issue, to which the ‘solution’ is almost always more encapsulation. The nice thing about immutability is that it is not really compatible with how we do encapsulation, so if you are strict about immutability then you are suddenly free from the whole quagmire as a side-effect.

I disagree on both accounts. It’s not difficult to code truly immutable classes in Java. And encapsulation is beneficial regardless of mutability.

There's a difference between something being possible vs supported. In C/C++ you can have a type, and a const version of that type. In Java you can't define a class and automatically be able make a reference to a const object of that class. You can make a final reference, but that only means you're always referencing the same (mutable) object. You could you use final fields for the entire object, but then you have to make another type for the mutable kind, or builders to go from one to an other. Another example is Unmodifiable collections, which are only views on modifiable ones, so you can't be sure it's not modified. A language that supported immutability would come with some of these batteries included.

There are places to use encapsulation with mutability, such as simulations, but having hidden mutable states is not desirable property when constructing rapidly changing applications.

I do my best to keep things sane when working with a Java or Ruby or what have you codebase, but I don't pretend it's something it's not. Just do the best that the codebase and organization can tolerate.

Right, you can’t turn a mutable object into an immutable object when other references to the mutable interface already exists. Const as in C/C++ is certainly a useful feature that Java lacks, but it’s quite a leap from that to claiming that Java doesn’t support true immutability. I develop Java applications with immutability as the default, and it works quite well. The lack of the abive-mentioned feature is not a critical obstacle.

Regarding your point about collection views, const references are often also just views on mutable objects, and this poses no particular difficulty. And you can implement truly immutable collections in Java if you really insist on it.

Yeah they seem to be trying to force the conversation into encapsulation == mutability when that flatly is just not true. There are tons of immutable objects that benefit from encapsulation and there is plenty of internal immutable state that you would want to encapsulate and not just give out.

It’s difficult in the sense that somebody consuming your class will sooner or later start relying on reflection to do something with it they shouldn’t (because they can), and then when you make a change in the future it will cause breakage downstream. Records solved this for some cases at least.

More important imo is that the standard collection classes can’t even be set to immutable with the final keyword. Sure you can use something else, but professionally you are going to have to deal with them most of the time still.

OOP is encapsulation, inheritance, and polymorphism. Polymorphism maps to behaviour which is type-based, but usually also based on the objects internal/mutable state. This is no surprise since OOP came out of Simula for doing simulations.

I really disagree. You don’t need polymorphism or inheritance. The core of OOP is objects and encapsulation. Putting behaviour next to the data. It has nothing to do with mutability.

Regarding your first point, OOP without subtyping has typically been referred to as object-based rather than object-oriented.

Sure, I just think that’s being pedantic.

I think it’s an important distinction, in particular since a significant number of people opine that subtyping is harmful, but encapsulation is not.

I don’t particularly think subtyping is harmful. It can be misused, but everything in programming can be misused.

Referring to my GP comment, subtyping subsumes inheritance and polymorphism. It is orthogonal to mutability. As an illustrative example, the Java Collection Framework makes significant use of inheritance and polymorphism, but could as well be reduced to immutable collections.

> Sooner or later you come across something you need and there is no library for it. Then you are forced to start messing around with FFI and whatnot.

I agree that it's always a little risky to bet on a young language. But I think Gleam is doing a good job of positioning itself as a smaller risk by sitting on the tried-and-true BEAM virtual machine and Javascript runtimes. If worst comes to worst you could export your compiled Gleam as Erlang or JS and it's quite readable.

And Gleam's FFI with Erlang, Elixir and Javascript is pretty good. I don't think it will take long for a wide variety of packages from those platforms to become available on the Gleam package manager. Doing your own FFI is hardly intimidating - it's essentially just writing type definitions for the functions you need.

Another factor giving me hope is that the language appears to be mostly 'done'. The author has carefully considered a minimal feature set and appears to be sticking to it, making it one of the simplest (typed) languages I've ever used syntax-wise. I think this bodes well for future growth, stability and maintainability.

Reply on news.ycombinator.com