Emil Szpakowski

@emilszpakowski
75 Followers
99 Following
205 Posts
Java 26 / JDK 26: General Availability - jdk-dev - openjdk.org

The third golden age of software engineering – thanks to AI, with Grady Booch

YouTube

"I hate planning meetings!"

Maybe. Maybe it would help if you saw people actually _planning_:

- changing the plan to reflect changing reality
- taking our anxiety seriously about missing deadlines
- figuring out what to say "No" to, then actually saying it

What do you think?

Seems painfully obvious that, whatever you think about #genai code, anyone using it is heading for a code-review logjam. Assuming that the org requires code review; if yours doesn’t, nothing I can say will help you. Anyhow, Rishi Baldawa writes smart stuff about the problem and possible ways forward, in ˚The Reviewer Isn't the Bottleneck”: https://rishi.baldawa.com/posts/review-isnt-the-bottleneck/

[My prediction: A lot of orgs will *not* do smart things about this and will suffer disastrous consequences in the near future.]

The Reviewer Isn't the Bottleneck

AI tools are flooding PR queues and the instinct everywhere is to call review the bottleneck. I think that’s the wrong question. The reviewer is the last sync point before production changes. The goal shouldn’t be how to remove the gate, but how to make it cheaper to operate.

Rishi Baldawa
A GitHub Issue Title Compromised 4,000 Developer Machines

A prompt injection in a GitHub issue triggered a chain reaction that ended with 4,000 developers getting OpenClaw installed without consent. The attack composes well-understood vulnerabilities into something new: one AI tool bootstrapping another.

@kentpitman @screwlisp @cdegroot @ramin_hal9001 Your understanding is mostly faulty. The original GC was written by me, and I'm no Lisp GC expert. I was (and still am) an admirer of Lisp. I wrote the code for my whole PhD thesis in Lisp. My admiration for garbage collection started earlier, when I was a big user of Simula in the 70s. But the motivation for GC in Java was different: the motivation was all about reliability and security. A leading cause of security vulnerabilities as always been buggy code. And one of the leading root causes of many long standing, hard to diagnose and fix, bugs has been flakey storage management. Garbage collection goes a long way to increasing system reliability, and hence security. I had always wanted to make GC more mainstream.

When you described garbage collection to senior management back in the day, their reflexive judgement was: "bullshit! Lazy engineers just don't want to clean up their mess". But when they see measureable improvements in system robustness, and corresponding decreases in failures, they Notice.

a detail you probably didn't know: nowhere in any #curl documentation do we use the word "very". It is a banned word enforced by a CI check. This rule encourages us to rewrite and instead use more appropriate words. Makes us write better English.

New article about Optimizing GPU Programs from Java using Babylon and HAT.

Using the matrix multiplication as an example, this article explains how Java developers can tune GPU workloads from the Java compute-kernels to achieve performance close to native cuBLAS, scaling from 7 GFLOP/s on CPUs to 14 TFLOP/s on an NVIDIA A10 GPU, just using Babylon's code reflection APIs and careful designed APIs for GPUs.

https://openjdk.org/projects/babylon/articles/hat-matmul/hat-matmul

#java #gpu #babylon

Optimizing GPU Programs from Java using Babylon and HAT

“Systems are seductive. They promise to do a hard job faster, better, and more easily than you could do it by yourself. But if you set up a system, you are likely to find your time and effort now being consumed in the care and feeding of the system itself." — John Gall

A nice summary of:

“Lessons from John Gall”

here:

https://www.antoinebuteau.com/lessons-from-john-gall/