Hacker News Reader

Comment by grahamlee | Hacker News Reader

It's interesting when the creators had a clear intention to shepherd people one way and the programming community went another. Both Objective-C and Java (which was informed by ObjC significantly, including having a few implementors hired from NeXT) clearly intend for low level, C-style imperative code to be isolated early behind a message-passing interface and for systems to be built out of message-passing between objects. This is most explicit in Brad Cox's book describing the ObjC way, "Object-Oriented Programming: an Evolutionary Approach". In practice, a lot of Objective-C software and quite a lot of Java software is designed as big C-style procedures which call into APIs using object methods.

Similarly, the OP describes Perl, which is designed using a postmodern philosophy: however you think about your problem, you can solve it that way! In practice as OP describes many people reach for regex.

View on HN

>...clearly intend for low level, C-style imperative code to be isolated early behind a message-passing interface and for systems to be built out of message-passing between objects.

>...Java software is designed as big C-style procedures which call into APIs using object methods.

Do you mind going into more detail regarding those two styles in Java? I wouldn't exactly say that Java shepherd's its programmers towards the message passing style at all.

The default scope of everything is package level. If one writes all of their code in one directory, Java is basically procedural code with syntactic sugar for functions with structs as the first parameter. The moment you want to share with other packages, one has to use the public keyword. I'd argue what Java 'wants' you to do is to have a few public methods that operate on internal state, but it doesn't care too much if state is shared within a package. A good Java API wouldn't have many Setters/Getters that do nothing but set/get references to internal objects, but rather ones that parse and make sense of it's internal state.

In practice, I've found most codebases don't care about any of that so every variable is private, they all have public getters/setters (so it's NOMINALLY encapsulated) and most methods are public with a few private methods strewn about.

Thanks for the explanation. I got caught up on the "message passing" vs "api" part of your original comment and was wondering how you differentiated between the two.

>A good Java API wouldn't have many Setters/Getters that do nothing but set/get references to internal objects, but rather ones that parse and make sense of it's internal state.

I completely agree. Getter/Setter obsession often leads to breaking the Law of Demeter in most Java code bases I've seen.

I'm not the original poster so you should wait for their reply, hah! They may have meant something else. This is just a topic I've spent some time thinking on and wanted to share my own $0.02.

My go-to language for personal projects/small tools at work is Java. I think if one looks at Java codebases as strict encapsulation at the package level it becomes a lot more bearable.

Conveniently I gave a talk on exactly this a few years back :) https://youtu.be/_BbGxpiYFDg

Hey there, just thought I'd let you know. I'm getting a 404 when I try to go the bitbucket repo in the video. Otherwise, enjoyed your talk :)

Very cool, Graham, checking it out now!

Reply on news.ycombinator.com