finally there is a perfect monitor for Java programmers

Like A Duck@programming.dev to Programmer Humor@programming.dev – 1209 points –
117

Program in assembly, 40 columns is plenty. You just need an awful lot of rows.

As someone that first learned to program in 8008 machine code, you aren't really wrong, but formatting is and always will be for the weak.

3 more...

I have a monitor that's almost like this and it's surprisingly nice. It feels like a two-monitor setup. Two actual monitors would probably have been cheaper, but I got mine from work, so it wasn't a factor.

The real advantage of having two actual monitors is being able to flip one vertically for reading code.

EDIT: a word

Everyone at my work who has this runs into issues whenever they need to share their screens, apologizing for low resolution or painstakingly resizing every window to mimic multiple screens anyway.

I just share one window at a time. I put the meeting on one half and the window I want to share on the other, which makes it 16:9 and works perfectly for what I need to share.

Yeah people do that, until you're sharing a code window and then need to see if it works on a browser and then your dev tools are popped out so you have three windows...or you don't want to just have one meeting and one window visible, you also want slack or a window for googling or something similar...

It's all workaround-able, it's just minor annoyance after minor annoyance lol.

So new technology will require new solutions to operate more effectively? Just another turn of the wheel.

Yeah, the benefit of the new technology doesn't outweigh the slew of minor annoyances associated with making it work in a world designed for regular sized monitors.

If just sharing one window isn't feasible for these reasons, my go-to is to use OBS.

I bought one after some months of remote work in 2020. Then when I started my new job they gave me another one (different manufacturer but exact same panel size). I needed to rearrange my desk a lot, but holy shit so much room for error messages!

Yes, I'm a Java developer ¯\_(ツ)_/¯

It was either that or a C++ programmer. Those template error messages are gnarly.

The real advantage of two monitors is that you can turn one off if you don’t need the full 50000px width.

As far as I'm concerned the advantage is I can have three windows (or three editor views) tiled horizontally and each one is the perfect width. A half width (half of 1080p/16:9) is too narrow and a full width window wastes space, but a 2/3 (of 1080p) width window is about perfect. If I tried to do that with two regular monitors, the middle window would be split across the bezel.

*When I say 1080p, I really mean the aspect ratio. My monitor is effectively a double width 1440p monitor, but with the display scaling I use the space is effectively 1080p.

Jfc. Do people really write code like this? I’ve been writing code in Java for 15+ years and have never seen anything like this.

You need more skill, not a wider monitor. SMH.

Hello world in Java:

class 9-A {
    public static endangered therefore protected final void main(String[] args) {
        System.prepareTheOutputBufferForPrintingAsTheNextStatementWillDoSo(args);
        System.in.out.in.out.shake.it.all.around("Java is a programming language " +
            "invented by the intelligent monkeys " +
            "working at Sun Microsystems.");
        return void; // duh!
    }
 }

ROFL you’ve proved my point. Just because Java gives you an opportunity to hang yourself doesn’t mean you should or have to.

You took one line of code and turned it into a novel. Bad programmers do this and then ignorant folks blame it on the language when it’s really just a lack of knowledge/skill.

You must be fun at parties! Seriously, this is a meme sub and the wildly exaggerated helloworld example I pasted (from this hilarious article) is obviously satire. I agree, that

  1. There are way worse programming languages than Java
  2. The verbosity is not the biggest problem of java, it is rather the dogmatic OOP paradigm that sucks.

I get making fun of java's verbosity for things like checked exceptions but hello world really isn't that much worse than most other languages especially considering all the "boilerplate" is required for any program more complicated than hello world in pretty much every language. But if a useless program really is too verbose for you see java 21.

void main() {
  System.out.println("hello world");
}

Yeah, you never see this in enterprise settings. Sure builders or streams can get a bit long but you just pop each .x() on a new line.

And when they're on new lines intellij has a cool feature where it creates a little UI only comment next to the line showing what type it returns.

In an enterprise setting we'd definitely create a method in that object what would have that chain in it, and call that instead... It seems like it's used over, and over again.

Anyhow, we're sitting here trying to make sense of something that obviously some sort of joke haha.

Man we're such fucking nerds.

Somewhere someone probably does... But this piece of code really look like someone either tried to inline a bunch of calls or this is code generated object mapper from json or other nested model.

Nobody with a sane mind and serious attitude will use this code as a "real" code. (I still believe in people, despite all the evidence to the contrary I get every day)

As a fun bit though this taken some dedication.

Is this a good thing I’m looking at or a bad thing? I don’t get it but then again, I’m not a programmer.

Java is a programming language that is notorious for being verbose, the joke is that you need a massively wide monitor to view it without the text being cut off

I don't understand why people don't break stuff like this up with newlines

We would. And we'd tend not to be using such verbose variable names. Avoiding abbreviation in the method and type-names is idiomatic though.

The joke is Java is verbose. It takes many characters to accomplish simple routines. Depending on your view that could either be good or bad for reading the code later.

Sure, but most of the lines in the screenshot break down to:

object1.setA(object2.getX().getY().getZ().getI().getJ().getK().getE().getF(i).getG().toString())

Aside from creating a method inside the class (which you should probably do here in Java too) how would another language do this in a cleaner way?

You shouldn’t reach through an object to invoke a method. That tightly couples the classes which getJ and getG (for instance) return.

It's sad that it took getting so far down the thread before somebody pointed out the obvious program design flaw.

If you're digging many levels down into your datamodel from high up for lots of datapieces, it's probably the case that both the data is unnecessarily framented and the code design itself doesn't have proper OO isolation of responsabilities.

If you're designing for performance (a well know raeson to screw OO design), then the datamodel itself would be a lot flatter (because you get more performance on the DB by trading it for space), whilst if you're not then you break the thing into parts as you have functions were you fetch intermediate objects into memory and handle the data in them (a Visitor Pattern would probably make this a lot cleaner).

I bet whomever designed the datamodel isn't the same as those doing the coding.

To be fair, probably hardly anyone actually looked at the code. And now that I did, I think this is compiled, not source code.

That is an interesting point, but it's not Java specific, you could do this exact thing in most other languages and it would look pretty much the same.

Considering the fact that in a lot of enterprise projects the data structures are not necessarily open to change, how would you prevent reaching through objects like this?

This is why I wasn’t too critical of Java. Java is verbose by convention and other languages are more terse by convention. You could just as easily write some nasty ‘snake_cased_object_abstract_factory_adapter_facade_broker_manager’ in python or any other language. There are a few things syntax wise working against it but you can still write (overly) terse Java and it’s just as annoying to read as in any other language. IMO it’s convention and style not the language itself. You can also say some mean things about languages with less verbosity but more operators and keywords like C++/rust. It’s a funny meme tho lol anyone who has worked in Java knows there’s at least a bit of truth to it

I’ll shrink your example. Suppose you have an object A which has a B which has a C, which is what you need.

By writing a.getB().getC(), you are implicitly coupling A and C together without A noticing. All A knows is that it is coupled to B. Should B ever decide to use a different C', which would make more sense for B, it may break your code without noticing it.

The solution is to make the coupling explicit. A should define a getC function that observes the needed contract. For the time being, it may get its C from B (which is fine, because C is under B’s immediate control), but if B changes, and wants to use C', you know to look into A (which is already explicitly coupled to B) and see if it can still function. You’d notice that it relied on B’s returning C and can find a solution to this.

An example with fewer variables: You have a shopping cart, which manages items. Implicit coupling translates to knowing and relying on the fact that the items are stored in an array. Adding an item the bad way would be shoppingCart.getItems()[shoppingCart.getItems().getLength] = item;*

The proposed solution adds the function ShoppingCart::addItem. Should ShoppingCart switch to a linked list, it can change the implementation of addItem accordingly. Instead of reaching through the cart into the items, you make dealing with the items the problem of ShoppingCart.

I don’t have copy at hand, so I can’t check. I think this advice stems from “The Pragmatic Programmer” by David Thomas and Andrew Hunt.

* I don’t actually know Java, so please forgive if this example wouldn’t really work.

Well I guess the point is that you shouldn't need all these method calls to achieve simple goals. Most of those "getF" are calls to some SystemFactory to get a GenericObjectFactory and so on and so forth.

This just tells me you don't use Java. Factory classes are just used to create objects in a standardized way, but this code isn't creating anything, it's just getting nested fields from already instantiated objects.

Thos code is obviously nonsense to show the issue.

But other languages would simplify stuff. For example, some languages call getters implicitly, so .getField() becomes .field. Same with list indexing, which could be done with operator overloading, so x.get(i) becomes x[i].

In this situation that would be able to reduce the character count a fair bit.

But that's functionally no different than what's already there...

The reason the lines are so long isn't because of anything Java related, it's because of the field names themselves.

Your post doesn't seem to answer to anything I said in my post. Did you answer to the wrong post?

The new convention in modern Java is to use .field() instead of .getField().

What you're complaining about isn't Java, it's object oriented programming, which Java basically forces on you. Verbosity is a flaw of OOP.

Compare:

x.field[5]

with

x.getField().get(5)

Both are exactly the same level of OOP, but the Java version is roughly twice as long. Add operator overloading to the mix and it becomes much worse:

x.getField().get(5).multiply(6).add(3)

vs

x.field[5] * 6 + 3

All this has nothing to do with OOP, but with syntactic sugar that is applied.

As I said, the convention is now x.field() not x.getField()

What language are you comparing against here? x.field[5] is valid Java if field is a public array, but that's not OOP, at least not in a pure sense.

It's not valid Java for e.g. Lists, Maps, Strings or any programmer-defined classes.

Same with operator overloading.

myVectorA + myVectorB is not valid Java, but it is valid OOP in e.g. Python or C++. And this kind of syntactic sugar reduces verbosity enourmously, while still being OOP.

If you have ever worked in e.g. Python, Groovie or Kotlin you notice quickly how non-verbose OOP can be.

It seriously is just Java.

And Javas insistance on having you wrap non-OOP things in fake OOP constructs (e.g. static methods, which are just functions in modules, but you have to uselessly abuse classes as modules) isn't helping either.

Kotlin would represent the getter/setters as synthetic properties (and do so automatically, since Kotlin interops with Java).

object1.A = object2.X.Y.Z.I.J.K.E.getF(i).G.toString()

Of course it's still not great (there's still too much nesting, there's something fundamentally wrong with how the data is structured) but at least the code is less noisy.

Had an ultra wide for a while, went back to 2 27" monitors after 2 years. 2 monitors is more convenient imo. I can flip one vertical whenever. Less fiddly to have multiple things open at once. One is centered while the other is on the side and angled, much nicer way of separating what's my focus. Easier to screen share. I always found the curve distracting for text.

The ultra-wide's big appeal is definitely more for gaming than programming.

I have a 49" ultrawide, running a tiling window manager under Linux.

I heavily utilize virtual desktops in my workflow. Always 10 on each monitor, accessed by Ctrl-{0..9}. Switching between monitors by AltGr+{1..n}. Programs always stay on the same virtual desktop no, so terminals on 2, browsers on 3 and so on. This enables me to access more or less any window in under a second, never having to look for it visually.

I usually work with 4 or 5 24" monitors, as a single program seldom needs more space for me. What he ultrawide brings to the table is the capability under Linux to create arbitrary virtual monitors.

I can for example have two evenly created monitors (two 27"). My usual for development is three, split as 2:3:2.

Another possibility is using a small script that analyses movie resolution and creates two monitors, one with the exact aspect ratio of the movie, eliminating black borders, and another for using while watching said movie :)

As Linux sees them as separate monitors, I can also have easily managed screen sharing.

Having the flexibility of software defining my monitors has been great as a developer; separation of many, screenwise often small, applications is highly useful to me. A couple of quick scripts to switch between different setups has integrated it nicely into the workflow, and I usually changes monitor config at least a couple of times per day.

I use a Ultrawide as my main monitor, a 1440p vertical one on the right and 2 portable 15" 1080p under the Ultrawide.

When I need to share, I share one of the 15". I keep my notes and the call on my Ultrawide. I think it's a great setup.

But if you don't want as many monitors, for sure 2x 16:9 is much better than 1x 21:9 or even 1x 32:9.

You might have just saved me a heap of money.

Screen sharing would suck with an ultra wide.

It does, but it depends on the tool. Zoom lets you simply draw a rectangle which will be shared, I typically select 2/3 of my screen. It's great when all have the same screen though.

I set up my wife with a single 39" ultra wide instead of two separate monitors and it lets you use two cables so each half of the display acts as it's own unit. Then it's like having two monitors without a seam in the middle and doesn't take over the whole desk. I use two 43" 4k monitors side by side in the same way as you though and definitely prefer that.

You're dangerously close to the edge there bud, what's your plan B when that starts to overflow huh?

...and that, kids, is why java has this thing called imports

Imports wouldn’t help. It’s setters with a ton of chained getters

Mostly they're all the same up to the last one or two methods - just set the common part as a variable?

Definitely. I’m pretty sure they modified the code to look as bad as possible just to take the photo though. You can clearly see all the lines are marked as modified in the gutter.

It's also a good way to potentially multiply your query costs and slow down the function, while introducing possible inconsistencies if the objects are modified between the first and last time they are requested.

This is the best answer.... Or the outer classes being delegated access to the inner ones and so on, like an onion.

I wonder if this is one of the situations that Kotlin delegated parameters were designed to handle? (I'm new to Kotlin and still don't understand that "by" construct there)

LOL, that said. The BEST thing I ever bought when WFH started was a 4k monitor.

The extra screen real estate is amazing

Oh come on, first time I actually want someone to post a link for an “ad” and not one in sight

I'm using this one, highly recommend it! 240hz refresh rate, HDR, perfect for coding and gaming. Don't know if it's the exact same as the one in OP's pic, but same concept for sure.
https://www.samsung.com/us/computing/monitors/gaming/49--odyssey-g95na-gaming-dqhd-led-monitor-ls49ag952nnxza/

I've bought one and sent it back again. I felt like I'm not utilizing most of the space since I had to move my head too much to see windows on either side.

I'm now using two 4k Screens. In in the middle and one to the side, but rotates by 90 degrees. Can recommend that. Though for gaming... I can imagine it there.

Personal preference I guess.

I recently switched desks at my company and found one with two monitors. The seam was right in front of me. So if you have a task that has you watching a single monitor most of the time, you’re always looking to one side.

I stopped wondering why the colleague who sat there before was complaining of neck pain.

Do you think this screen would cause less neck pain if you were primarily focusing on just one side?

Judging from my work – sourcecode, which has short lines and is read from left to right – I think so. I’d either have to balance the editor in the center or always look at the left edge.

For a dual screen setup, you could just offset the screens. Primary screen straight ahead, secondary on whichever side works best for you. This is how I used to work.

Oh yeah, it was brutal to play Apex on initially, but eventually you relearn where your eye needs to dart to to see your health and stuff and it gets a lot easier.

Then you learn how to process all that peripheral information and nobody can sneak up on you ever again lol.

Type aliasing in java could have saved us from the current pixel shortage, but at least kotlin is giving us a cheaper path forward.

For java programmers afraid of explicitly allocating any varables

What Dart looks like when written by ActionScript programmers

I used it with the default formater built in lsp, and it used so much space..

Yeah, better use the linter too, that way it's limited to 80 characters

Damn it hurts my eyes. I don't like when verbose languages require such long lines, it feels uncomfortable.

Will nobody comment on the level of indentation? It looks like 10 leves deep.

I work with Java almost exclusively, and I am in need.