Cal Newports Slow Productivity has a lot to say about this topic.
Creativity comes in bursts and can’t be scheduled. Happiness and health move with the seasons. Treating humans as divisible units of 1 hour blocks of factory farmed ROI will never yield amazing results.
It’s sad to see the more technology and automation we invent the more we become slaves to the cult of pseudo-productivity, virtue signalling hours at work in place of meaningful output or results.
I agree with this too, I have read a lot of academic stuff with - em dashes and it reads like the author doesn't know how to write and is just translating spoken word to text.
When you are talking, an aside can make a lot of sense because you are thinking and speaking in real time. When you write you have the luxury of time to reformulate your words more precisely. Em dashes are best kept for prose that mimics speech rather than constructing logical text.
It's no coincidence that em dashes are rare in legal texts because they are too imprecise. Where as semicolons are extremely common in legal texts.
The S in semicolon stands for S-Tier.
Maybe the E in em dash stands for E-Tier?
I 100% agree. I hear a lot of pushback from em dash lovers on the semicolon; if you can learn to love an em dash, you can learn to use and love a semicolon.
Remember, meaning is based on common usage, so now em dash is slop-nonymous, semicolons can take on a more casual vibe.
For example:
I love pizza — it's my comfort food.
Can just become:
I love pizza; it's my comfort food.
For asides:
I love pizza — especially pepperoni.
Can just become:
I love pizza (especially pepperoni).
Wow. Am I the only one who reads all those sentences differently? Either the length of the pause or the intonation is different to me. But I wouldn't be able to explain it...
Conformant OpenGL 4.6, OpenGL ES 3.2, and OpenCL 3.0? Check.
Conformant Vulkan 1.4? Check.
Proton gaming? Check.
Bravo!
Just think of the value that will have downstream for game devs or others who wish to target macOS. Apple really should do more to publicly acknowledge this kind of work and donate to these kinds of projects since they are beneficiaries.
Theres a chance here for them to open up further support for Linux across the hardware, software chain (Swift), containerization (finally) and maybe even allow app store virtualization on iOS (think running a fast linux compliant container on your phone via an intent or shortcut).
If not, perhaps DHH's Omarchy will be the Barbarians (with great hair) at the Gates which could turn the tide back away from Apple dev hardware dominance. If we could only get something like that on our phones without being blocked at every turn by "big app store".
Omarchy is just a set of defaults for an existing software stack. The problems here are at a much more fundamental level: getting devices that can be unlocked, getting device drivers/firmware that are also updated on a regular basis, supporting hardware attestation and getting app makers to support it without Google's support (assuming an Android compatibility layer), getting a healthy app ecosystem (if there is no Android compatibility layer).
Currently probably the best route is basing the OS on Android (so that you can benefit from all the existing apps), making a non-hostile reference device, and getting regulators' attention (the EU is probably the most likely to succeed) to break Google's monopoly on attestation.
This is largely what GrapheneOS is currently trying. I think what we can do as users is install GrapheneOS with sandboxed Google Play and for any apps that do not work, contact their developers. If GrapheneOS manages to get millions of users and get on the radar of app developers, that's the best shot I think.
But it feels like the window is closing quickly. So if you care at all about any of this, today is the day to get a GrapheneOS device and make yourself heard.
Great article. Lots of similarities to other terms floating around like forward deployed engineer and full stack builder. This is obvious if you ask ChatGPT to list all the professions over the years which have been combined and subsumed during technical innovation.
I think the most obvious recent event would have been the personal computer. How many office jobs that existed pre-computer were combined once they became software?
Filing clerks, switchboard operators, darkroom technicians etc.
Totally agree, the FFI escape hatch and excellent tooling from rust, maturin pyo3 etc means so many python problems can just be solved with rust. Which begs the question, has anyone tried doing a greenthread implementation in rust? Maybe offload some of the dynamically evaled python code to a seperate process maybe with https://github.com/RustPython/RustPython
Something which would be immensely helpful for the community is to create a test suite of pathological problems with existing python concurrency patterns and libraries.
At that point it should just be a matter of time before the right implementation and PEP(s) can be iterated on that solves said problems while maximizing for devex.
For anyone interested in learning more about different concurrency models I can highly recommend Paul Butcher's: Seven Concurrency Models in Seven Weeks.
It’s actually really good at small bugs but you need to make sure it can understand what’s broken by giving it context. Logs, curls, screenshots etc. The biggest problem is when it goes on vision quests and does stuff you didn’t ask.
The meme with the car and duck are basically how AI agents like to “fix bugs”, sometimes they’re like oh I fixed the bug and changed the button which you never asked for. Lol. Adding a wheel and changing the car into a cat!
Creativity comes in bursts and can’t be scheduled. Happiness and health move with the seasons. Treating humans as divisible units of 1 hour blocks of factory farmed ROI will never yield amazing results.
It’s sad to see the more technology and automation we invent the more we become slaves to the cult of pseudo-productivity, virtue signalling hours at work in place of meaningful output or results.