this post was submitted on 25 Sep 2024
855 points (87.6% liked)

Programmer Humor

19276 readers
1204 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 13 points 2 days ago* (last edited 2 days ago) (1 children)

Its standard library reads like someone's Object Oriented Programming 101 final project, and they probably got a B- for it. Everything works and follows OO principles, but they didn't stop to think about how it's actually going to be used.

Let's try to read a file line-by-line:

BufferedReader reader = new BufferedReader(new FileReader("sample.txt"));
String line = reader.readLine();

We're having to instantiate two objects (FileReader and then BufferedReader) just to get an object that has a readLine() method. Why? Can't BufferedReader take a file name on its own and work it out? Or FileReader just provides readLine() itself?

Not only that, but being parsimonious with what we import would result in:

import java.io.BufferedReader;
import java.io.FileReader;

But we're much more likely to be lazy and import everything with import java.io.*;. Which is sloppy, but I understand.

I can see what they were thinking when separating these concerns, but it resulted in more complexity than necessary.

There's a concept of "Huffman Coding" in language design. The term itself comes from data compression, but it can be generalized to mean that things you do often in a programming language should be short and easy. The above is not good Huffman Coding.

[–] [email protected] 4 points 2 days ago* (last edited 2 days ago) (2 children)

Library built this way because it supposed to be flexible and provide ground for complex usecases. It can only be flexible if your API works with simple abstractions which you can then compose. It’s not driven by “I need this specific utility for this specific scenario”. That would be zoo you have in JS where you have 10 ways to iterate over array and 9 of them wrong for your scenario.

Java’s OO is great because they design library with SRP in mind making sure there is few but good ways to do things.

BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

Having it designed the way it is, allows Java to have utilities for various scenarios. Your scenario covered by standard lib too. See Files.readAllLines which, surprise-surprise, built on top of BufferedReader.

[–] [email protected] 6 points 2 days ago (1 children)

BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

You're just describing the problem. Yes, I see where they're going with this. It's still a usability nightmare. I can't think of another language that makes you jump through hoops like this on IO, and they get along fine without it.

[–] [email protected] 2 points 2 days ago

I agree with you. It's a neat design idea to make things a bit more maintainable perhaps, but it's just annoying to program with.

[–] [email protected] 2 points 2 days ago

Library built this way because it supposed to be flexible and provide ground for complex usecases.

It’s definitely that, and not the fact that it was written in the first half of the nineties when everyone and their mother was all in on OOP/OOD to the detriment of usability.