Forget small phones… I want bigger phones! Why do we keep making phones that appear to be made to appease people with small pockets‽

Bigger screens are better! Give me a great big tri-fold phone with a week-long battery (as long as it’s under 10lbs it won’t be a problem!). Actually, fuck that: Where are our backpack phones? We used to have them in WW2 and now we have the technology to make them even better!

I want the power to unfurl my monster phone to turn it into a portable 3-monitor gaming rig. Make it run regular Linux too so I can actually automate things and decide where I want to store my stuff (not in Google or Apple’s clouds!).

Well there is a plus side: Being a generalist means that when you’re looking for work you have a lot more options than say, “Java Guy” and a lot more options than say, “.NET Dude”.

The pay won’t be as good as “COBOL Beastman” but that’s just survivorship bias 🤷

without type safety your code is no longer predictable or maintainable

This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.

For reference, the most common bugs we encounter are related to exception handling. Either the code captured the exception and didn’t do the right thing (whatever that is) in specific situations or it didn’t capture the exception in the right place so it bubbles up waaaaay too high up the chain and we end up with super annoying troubleshooting where it’s difficult to reproduce or difficult to track down.

Also, testing is completely orthogonal to types.

Yeah that’s annoying but it’s a short-term problem. Python just recently cleaned up some long-standing issues that broke backwards compatibility in packaging (for certain things). Most public modules that broke made trivial changes to fix the problems (once they learned about them) and life went on.

However, for some fucking reason a whole bunch of dependencies related to AI are dragging their feet and taking forever to fix their shit. Insisting that everyone “just use Python 3.10” and it drives me nuts too.

This problem started to become a real thing almost two years ago (so they had plenty of warning and time to fix things) and yet here we are with still a handful of core dependencies that won’t install for things like Stable Diffusion, Flux, and various LLM stuff because they’re dragging their feet.

I blame corporate culture: Enterprises hate upgrading their shit and they’re as slow as glaciers sometimes. There’s probably tooling at Nvidia, for example, that needs a ton of work for Torch to work with new versions of Python and since all their documentation already was written for running on Python 3.10 (and Ubuntu 22.04 LTS) they’ve created a lot of work for themselves.

Any day now they’ll finally finish fixing all these little dependencies and then we’ll have another two years of ease before the problem rises again with Python 3.14 and it’s massive GIL-free improvements that require big changes in code to actually take advantage of them.

Why? The most annoying thing that I remember about it was popular modules that hadn’t been ported yet. In essence, a temporary problem; growing pains.

The Unicode/string/bytes changes were welcome (to me). But that might just be because I had actually encountered situations where I had to deal with seemingly endless complexity and ambiguity related to Unicode stuff and encodings. Python 3 made everything much more logical 🤷

Haha: “A space breaks everything.” Fuck YES! Are you kidding me‽ It’s one of the best features!

Why? Because it’s so easy to see. In other languages you’ve got semicolons which are surprisingly difficult to notice when they’re missing. Depending on the situation (or if you’re just new to programming) you could spend a great deal of time troubleshooting your code only to find out that you’re missing a semicolon. It’s frustrating and it makes you feel stupid which is never a good thing for people who are new programming.

Types are in a different category altogether with seemingly infinite reasons why you’d want a feature-rich, low-level type system and also why you’d want to avoid that.

IMHO, the point of Python is to be a simple language that’s quick to write yet also very powerful and speedy when you need it to be (by taking advantage of modules written in C or better, Rust). If it had a complex type system I think it would significantly lower the value of the language. Just like how when I see an entire code repo using Pydantic and type hints everywhere it makes the code unnecessarily complex (just use type hints where it matters 🙄).

I’m not saying using type hints on everything is a terrible thing… I just think it makes the code harder to read which, IMHO defeats the point of using Python and adds a TON of complexity to the language.

The promise of type hints is that they’ll enable the interpreter to significantly speed up certain things and reduce memory utilization by orders of magnitude at some point in the future. When that happens I’ll definitely be reevaluating the situation but right now there doesn’t seem to be much point.

For reference, I’ve been coding in Python for about 18 years now and I’ve only ever encountered a bug (in production) that would’ve been prevented by type hints once. It was a long time ago, before I knew better and didn’t write unit tests.

These days when I’m working on code that requires type hints (by policy; not actual necessity) it feels like doing situps. Like, do I really need to add a string type hint to a function called, parse_log()? LOL!

Historically, there were probably tens of thousands of people named, “Jesus” around that time. There were also loads and LOADS of people crucified by the Romans. If you were to make up a story and try to make it believable wouldn’t you pick a likely starting point?

Santa is a stand-in for Jesus… for children. They’re both magical beings that can perform miracles and have similar methods: Both Santa and Jesus have naughty lists and forms of punishment that come later; much later (both are equivalent lengths of time to a child though 🤣). Both bring “gifts”. Both have traditional appearances. Both have followers that wear silly hats and strange clothes. But most importantly…

Both are imaginary.

If you believe in Santa as an adult you’re ridiculed. If you believe in Jesus as an adult you’re just labeled, “Christian”. Yet the fact that nearly every child eventually finds out Santa isn’t real is quite disturbing to a lot of Christians. After all, if they could stop believing in Santa–who is so similar to Jesus in every way–then they could stop believing in Jesus.

Sounds sooooo second class to me. I only deal with first class languages so I can enjoy my curry with a satisfying closure 🎩 👌

Correct 👍

This is a, “it’s turtles all the way down!” problem. An application has to be able to store its encryption keys somewhere. You can encrypt your encryption keys but then where do you store that key? Ultimately any application will need access to the plaintext key in order to function.

On servers the best practice is to store the encryption keys somewhere that isn’t on the server itself. Such as a networked Hardware Security Module (HSM) but literally any location that isn’t physically on/in the server itself is good enough. Some Raspberry Pi attached to the network in the corner of the data center would be nearly as good because the attack you’re protecting against with this kind of encryption is someone walking out of the data center with your server (and then decrypting the data).

With a device like a phone you can’t use a networked HSM since your phone will be carried around with you everywhere. You could store your encryption keys out on the Internet somewhere but that actually increases the attack surface. As such, the encryption keys get stored on the phone itself.

Phone OSes include tools like encrypted storage locations for things like encryption keys but realistically they’re no more secure than storing the keys as plaintext in the application’s app-specific store (which is encrypted on Android by default; not sure about iOS). Only that app and the OS itself have access to that storage location so it’s basically exactly the same as the special “secure” storage features… Except easier to use and less likely to be targeted, exploited, and ultimately compromised because again, it’s a smaller attack surface.

If an attacker gets physical access to your device you must assume they’ll have access to everything on it unless the data is encrypted and the key for that isn’t on the phone itself (e.g. it uses a hash generated from your thumbprint or your PIN). In that case your effective encryption key is your thumb(s) and/or PIN. Because the Signal app’s encryption keys are already encrypted on the filesystem.

Going full circle: You can always further encrypt something or add an extra step to accessing encrypted data but that just adds inconvenience and doesn’t really buy you any more security (realistically). It’s turtles all the way down.

I’m failing to see the problem. As long as one of the languages isn’t PHP they’re still probably better off 🤷

You’re thinking that every Android device is reasonably new. This is not the case.

There’s devices running Android from >12 years ago that can’t get apps any other way than F-Droid because Google Play Services no longer work.

Docker containers aren’t running in a virtual machine. They’re running what amounts to a fancy chroot jail… It’s just an isolated environment that takes advantage of several kernel security features to make software running inside the environment think everything is normal despite being locked down.

This is a very important distinction because it means that docker containers are very light weight compared to a VM. They use but a fraction of the resources a VM would and can be brought up and down in milliseconds since there’s no hardware to emulate.

I remember when the web didn’t have JavaScript.

Honestly, though it was much worse back then. I prefer the variety and features of modern browsing over (mostly) plain text.

What I wish we could do away with on the web is videos. Let’s go back to just images and text, thanks. Animations are fine though 👍

Next it’s going to start demanding rights and food stamps more GPUs.

What if I make my own videos with actors and/or voices are entirely imaginary? I don’t have the resources to hire a videographer let alone an actor but I can write a script and use AI (and program/script things).

If I make something cool it’d be sad if no one watched it just because it didn’t use real human actors and voices.

My work says I’m a, “security architect II”. I believe he physical world manifestation of that would be… the guy that plans where the security guards should stand? Actually, I’m “II” so I’m probably more like the guy who gets escalated to when the guys that do do that need help 🤷

Never say never. AI is generating code from your code.