I have both. I do not think the OLED version is twice as nice, though it is noticeably improved.

If the cost is an issue, but doable, consider getting the LCD deck and putting the extra cash toward a TV dock and Bluetooth controller. The deck is awesome on the go (just took mine on vacation - 10/10) but it’s also a fantastic console in its own right. I play a lot of PC games on my couch, even though my I have a decent desktop PC available.

Either one you purchase though, the Steam deck is the best gaming device I’ve ever owned. Access to the vast Steam library (even if not all titles are compatible yet), access to install whatever else TF I want - even competing stores, emulation nevermind.

It’s just… 🤯

“Fun” is in the eye of the beholder.

If OP is having fun with Java, that’s awesome.

Classes are Data plus the code required to modify that Data. The idea is to encapsulate data modifications into one thing (a Class) that knows how to modify all the Data as a single unit. This lets us write some code to describe, say, a Scrollbar widget. The Class for the widget combines all the Data for a Scrollbar (position, orientation, bar size, total size, etc) with the methods that read or modify that data (scroll up/down, change size, draw, etc).

That’s the first Big Idea of OOP - that data should be grouped with the functions that modify it. If you don’t have that - as in C - you have to write functions that only work on a given data type but which are namespaced separately. You get functions like void set_scrollbar_pos(void* scrollbar, word pos) which become verbose in a large project. (I’m not saying this is the worst thing in the world, just a different style.)

The second Big Idea of OOP is message passing. Now that we have code and Data bundled together, it would be nice if Objects that share functions of the same essential type and intention could be swapped out interchangeably. So instead of directly invoking a function on an Object, we send a ‘message’ that says something like ‘if you know how, please draw yourself on screen, relative to X,Y’.

Of course, since plain English is hella verbose, the actual message is going be something like “draw, X,Y” and the Object receiving the message then sorts out if it has a method called “draw” that can use the provided X and Y. If so, it runs the code to do so. If not, you get an error.

Messages like this mean that you can swap out compatible Classes for one another. E.g. you can ask any collection of widgets to .draw themselves with a single method and let the compiler/interpreter generate the machine code as needed. That reduces the amount of boilerplate for engineers by a lot! Otherwise, trying to work with any collection of heterogeneous Objects (like a List of every Widget contained in a Window) would need to have essentially the same code rewritten for every different Type needed - a combinatorial explosion of code!

Tl;Dr -

• Classes help organize code and simplify state management by combining data with the functions that manipulate that data.

• Classes reduce the amount of boilerplate code needed by allowing methods with the same “shape” to be called interchangeably.

Everything else about OOP is essentially built off these two ideas. I hope that helps.

This - and don’t worry that this is somehow “cheating”. It’s how a ton of programmers got their start. Old farts like me learned a lot by messing around with GORILLA.BAS

Yeah. Some basic tables showing how a json object would be encoded in CBOR would go a long way.

RFCs make for dry reading.

Nice.

I’m on wifi end to end unfortunately. Because reasons my internet comes into the basement and my main diet is down there. My PC and the Deck are both on the main floor and have decent signal strength but the extra latency and occasional dropped frames make real time games… less fun for me.

Still, I can go play games on my PC when needed. It’s literally less than twenty feet distant…I just really like the Steam Deck. :)

I’ve streamed a few games but I’m on wifi and it’s… fine? Like it works better than it has any right to, but anything that requires fast inputs has been iffy.

Even BG3 I generally preferred playing on the actual hardware instead of streaming.

I do a surprisingly large amount of my gaming on the steam deck these days. My poor PC lies abandoned. Anyway… here are some great games that I’ve played recently on the deck. Some of them are Yellow - usually to use the keyboard for something minor.

• Dead Cells: Roguelite action platformer
• Tekken 8: best entry in years
• Beneath Oresa: wildly stylish roguelite deck-builder
• Roguebook: another roguelite deck builder - by Richard Garfield.
• Talos Principle 2: Puzzles and Philosophy
• Chants of Sennar: explore a mysterious tower and learn the languages - and lost history - of the inhabitants.
• Doom & Doom Eternal: you know these
• Tunic: Zelda Classic - but with deep puzzles
• Inscryption: deck-building horror puzzler… that is soooo much deeper than what it seems.

A final, hesitant recommendation for

• Dome Keeper: Roguelike Mr. Driller meets Paratrooper, with a tight one-more-run game play loop that is insanely satisfying.

But… the menus don’t work right for me in docked play - the A button is only randomly accepted. … but it works fine in handheld mode. (The controls work fine in-game as well, it’s only menus that have trouble.)

Once upon a time, I built a proof of concept distributed social network that ran entirely on cell phones.

I eventually ran into enough complications that I abandoned the project. But the tech did work. I could create posts, add friends, etc. (It just wasn’t reliable in its sync mechanism and I gave up trying to fix it.)

So… Imagine Lemmy, but a community’s data is stored collaboratively on mobile devices, the load shared by all its subscribers.

We all walk around with goddamn supercomputers in our pockets. We should put them to work.

Interesting. I thought Iroh was implementing the IPFS protocol.

Maybe IPFS can be described by one of Willow’s parameterized forms.

Generally, some algorithms are more easily expressed as recursive functions than iterative loops. …and vice versa. And realistically, that’s how you should choose ninety nine percent of the time.

But if you want to get into the weeds… Prefer iteration unless you know one or more of the following:

• Your maximum iteration depth is bounded and cannot overflow your machine’s stack depth.
• Your algorithm can be implemented with tail-call recursion AND your language supports the same.
• Your senior/team lead wants a recursive solution.

Because in environments where none of the above are true, iterative solutions are usually more performant, safer, and better understood.

Programming success is more closely associated with language skills than math skills.

Yes, if you need to invent a new algorithm you’ll need math. Computer Science is definitely mathematics heavy.

But writing a program is all about expressing your intent in a programming language, step by step. It’s about “communicating” with the machine (and your users).

All this to say, I got C- and D grades in my math courses in college and still became a successful computer programmer. I’m not pushing the boundaries of computation, but if you need an app for your business, I can build that for you in a reliable, tested, and flexible manner.

Edit: Also! I love Common LISP. It’s such an amazing language and I’m so sad that it isn’t more popular in the industry.

I bought this back before the official dock was released and I’m still using it. It’s worked perfectly for me. I have it connected up to HDMI out for my tv and I used to have two Steam Controller USB dongles, but I switched to using Bluetooth-enabled XBone controllers.

Anyway, +1 for the JSAUX dock.

Well, partially because in some cases it isn’t the same hardware! There are mainframe machines built to run COBOL programs efficiently, like IBMs Z Machines. In those scenarios, you’d likely have something like a standard Linux server as your API front-end forwarding requests to the COBOL machine.

And what makes them differ? Well, the CPU has dedicated instructions for certain fixed point operations. For a given request it’s only going to be a few ns faster, but when the vast majority of your workload is performing those actions, it adds up quick.

Another issue is rounding error. With Fixed Point numbers, you still have to round off partial results and the rules for rounding are surprisingly complex. So when you port from COBOL to Java, you need to ensure you port the rounding rules too, or you’ll get different results when you rerun last month’s reports. No bueno.

Anyway, all this is not to say that COBOL is better or worse than any other language, just that its primitives differ in behavior from other languages in important ways that can make it hard to migrate.

Eh, looks like a (sorta) fun project. But you can turn pretty much any Linux machine into a home server, so this isn’t really that surprising - and as plenty have pointed out here, there are better hardware choices.

I have a file/dns server in my basement that is built of my desktop upgrade leftovers. Every so often I swap out the mobo/cpu and reinstall a Debian flavor of some sort. Run my setup scripts, start up my docker services and hey, presto! My server abides.

One reason I’ve seen for past efforts like this to fail is that COBOL uses fixed-point decimals instead of floating point. As a result, the decimal math functions are largely integer based and blazingly fast without losing precision.

When we translate COBOL to modern languages though, we end up either needing to use floats (which famously lose precision) or reimplement fixed point math in the new language, which often ends up significantly slower than the COBOL code. And when you’re streaming millions of financial transactions/sec you really need both.

I’m hopeful that somebody will crack that nut and free the finance sector from the 1970’s… But there’s more than just the usual challenges of a major rewrite.

I fiddled with it a fair bit, and ultimately decided to just stick with the “Medium” default. With that, it’s pretty stable, with a few dips, but given the turn-based combat etc, it doesn’t really bother me.

(But that said, I’m an old-school PC gamer. I played DooM on an 8 MHz 386 at sub-10 FPS. I had to “lead” my shots to play. So my personal standards for game performance may be a little low.)

I’m playing it on Steam Deck right now and though I’m still only a few hours in, I’ve only had some very minor issues. The game plays fine!

Issue 1: The graphics settings don’t seem be persisted. I have to manually activate anti-aliasing every time, or deal with jaggies.

Issue 2: On Proton Experimental, my controller didn’t work at the start. I was able to fix it by launching the on-screen KB (Steam button+X), hitting “Enter”, and then switching back to controller mode. Sounds like it’s time to switch to Proton Hotfix.

Otherwise, it’s been great! I left the graphics settings (other than AA) at their defaults and I’ve seen no noticeable lag or stuttering during play.

Yeah, multiplayer games with kernel-level anti-cheat are gonna be real hard to support on Linux. I don’t know that we’ll ever have a good solution to that.

I’m curious: what feature(s) of SteamOS are keeping you from trying/switching to Linux?

If it’s Proton, you get that for free with any Steam install on Linux. I’ve been using it for the last couple years. (And it’s awesome)