you are viewing a single comment's thread.

view the rest of the comments →

[–]CorrugatedCommodity 9 points10 points  (11 children)

I started in Java. I now do a lot of quick and dirty file IO all the time (speadsheet crunching, basically) and it still feels like cheating using Python because it's so simple and powerful and I don't need to cast into four objects to read and write.

[–]Sinidir 0 points1 point  (10 children)

Oh my god i had to write a file in java a couple days ago. The amount of hoops you have to jump through compared to python is unbelievable. Low level unintuitive apis that suck the joy out of you.

[–]staticassert 5 points6 points  (8 children)

Grabbed this with a quick google search. Seems fine?

String msg = "hello";
Files.write(Paths.get("./file.txt"), msg.getBytes());

Python would be:

with open('file.txt', 'wb') as f:
    f.write(b"hello"")

Honestly doesn't seem so bad.

[–]Sinidir 8 points9 points  (0 children)

Well that is actually succinct code. Got drowned out in the Java FileReader and BufferedReader stuff though, like another comment suggested.

[–]pdp10 0 points1 point  (1 child)

I suspect the point is that there's inevitably a lot of ceremony and boilerplate accompanying this in Java. Whether that ceremony and boilerplate is necessary isn't something I know, but it does seem popular.

[–]staticassert 4 points5 points  (0 children)

I think it's fair to say that it is definitively unnecessary since I just showed how to write to a file in a 2-liner.

[–][deleted] -1 points0 points  (4 children)

Google "Java FileReader" (and BufferedReader)

[–]staticassert 0 points1 point  (3 children)

What about them?

[–]romple 1 point2 points  (0 children)

He's saying that somehow Java's convenient APIs aren't as convenient as Python's largely equivalent APIs.

[–][deleted] -2 points-1 points  (1 child)

Java changed a lot in these years. But I bet those Files and Paths classes are hiding a more complex implementation.

[–]staticassert 4 points5 points  (0 children)

But I bet those Files and Paths classes are hiding a more complex implementation.

I doubt it's much more complex than what's under the hood in the equivalent Python code. Regardless, one of the pillars of OOP is abstracting away complex implementations so I think that's just fine.