Tagged “programming”

1. Java 25 After the Hype: 5 Features That Actually Matter

   felipestanzani@blog ~ ~ cat "Java 25 After the Hype: 5 Fe"~ cat post << 03-04-2026

   

   When a new Java LTS drops, the internet goes through its usual cycle: launch posts, conference talks, YouTube thumbnails screaming “GAME CHANGER,” and LinkedIn hot takes about how everything has changed forever.

   Then reality settles in.

   A few months after the release of Java 25, most teams aren’t rewriting their systems. They’re shipping features, fixing bugs, and trying to keep production stable. That’s when we can finally answer a more interesting question:

   Which Java 25 features are still being discussed and actually used?

   This isn’t a launch recap. This is a “post-hype” filter. Here are five Java 25 features that have proven they’re more than marketing bullets.

   1. Structured Concurrency: Concurrency That Reads Like Logic

   For years, Java concurrency meant juggling ExecutorService, Future, timeouts, and cancellation semantics that were easy to get wrong.

   Structured Concurrency changes the mental model. Instead of spawning detached tasks and hoping everything is cleaned up properly, you treat concurrent tasks as a single logical unit.

   Before

   ExecutorService executor = Executors.newFixedThreadPool(2);
   
   Future<User> userFuture = executor.submit(() -> fetchUser());
   Future<Orders> ordersFuture = executor.submit(() -> fetchOrders());
   
   User user = userFuture.get();
   Orders orders = ordersFuture.get();
   

   Continue reading...

2. JSON is Making You Lose Money!!! Slash LLM Token Costs with TOON Format

   felipestanzani@blog ~ ~ cat "JSON is Making You Lose Mone"~ cat post << 11-02-2025

   

   Let's be real: every time you shove a bloated JSON blob into an LLM prompt, you're literally burning cash. Those curly braces, endless quotes, and repeated keys? They're token vampires sucking your OpenAI/Anthropic/Cursor bill dry. I've been there – cramming user data, analytics, or repo stats into prompts, only to hit context limits or watch costs skyrocket.

   But what if I told you there's a format that cuts tokens by up to 60%, boosts LLM accuracy, and was cleverly designed for exactly this problem? Meet TOON (Token-Oriented Object Notation), the brainchild of Johann Schopplich – a dev who's all about making AI engineering smarter and cheaper.

   Johann nailed it with TOON over at his original TypeScript repo: github.com/johannschopplich/toon. It's not just another serialization format; it's a lifeline for anyone building AI apps at scale.

   Why JSON is Robbing You Blind in LLM Prompts

   JSON is great for APIs and config files. But for LLM context? It's a disaster:

   • Verbose AF: Braces {}, brackets [], quotes around every key and string – all eating tokens.
   • Repeated Keys: In arrays of objects, every row repeats the same field names. 100 users? That's 100x "id", "name", etc.
   • No Built-in Smarts: LLMs have to parse all that noise, leading to higher error rates on retrieval tasks.
   • Token Explosion at Scale: A modest dataset can balloon to thousands of unnecessary tokens.

   Result? Higher costs, slower responses, and more "context too long" errors. If you're querying GPT-5-nano or Claude with tabular data, JSON is quietly making you poor.

   Continue reading...

3. Demystifying Object-Oriented Programming: Pt. 2

   felipestanzani@blog ~ ~ cat "Demystifying Object-Oriented"~ cat post << 10-09-2025

   

   Welcome back! At the end of our last post, we hit a bit of a roadblock. We had successfully organized our F1, PickupTruck, and SUV classes to inherit from a base Car class. But then, we were faced with a new challenge:

   A bicycle, a speedboat, and an electric car. They are all vehicles, but trying to force them into a single Vehicle inheritance hierarchy would be a nightmare. A speedboat doesn't have wheels, and a bicycle doesn't have an engine in the traditional sense. A simple extends Vehicle starts to feel clunky and wrong. How do we model things that share behaviors but are fundamentally different things?

   The answer lies in moving beyond the idea that everything must share a common ancestor and instead thinking about what they can DO.

   Interfaces: A Contract of Behavior

   Let’s ask a different question. Instead of asking what these objects are, let's ask what they have in common from a user's perspective. A person can:

   • Steer them
   • Make them go forward
   • Slow them down

   In Object-Oriented Programming, when we want to guarantee that different classes share a common set of behaviors, we use an INTERFACE. Think of an interface not as a blueprint for an object, but as a contract. It’s a list of methods that a class promises to implement. It defines WHAT a class can do, but not HOW it does it.

   Let's create a contract for anything that can be driven. We'll call it Drivable.

   // Interface
   public interface Drivable {
     void turnLeft(double degrees);
     void turnRight(double degrees);
     void accelerate();
     void brake();
   }
   

   Continue reading...

4. JavaScript 2025: New Stable Features to Boost Your Code

   felipestanzani@blog ~ ~ cat "JavaScript 2025: New Stable"~ cat post << 07-18-2025

   

   Hey there! JavaScript became 30 years old in 2025. Despite being created for browsers’ front-end code, it gained more space than expected in the backend. ECMAScript 2025 (ES16), released in June, brought a handful of stable features that make coding smoother without forcing you to kneel before the latest framework altar. In this post, I’ll walk you through the standout additions with practical examples, and for each, I’ll show how you’d do the same thing the old-school way — pre-ES2025. Spoiler: the new features save you some headaches, but the fundamentals still hold strong. Let’s dive in, no fluff, just code!

   1. Iterator Helpers: Functional Programming Without the Headache

   What’s New: Iterator Helpers introduce a global Iterator object that lets you chain operations like .map() and .filter() on any iterable (arrays, sets, generators) in a memory-efficient, lazy way. It’s functional programming without the bloat of intermediate arrays.

   Example with Iterator Helpers: Filtering and transforming a leaderboard of scores.

   //
   // Before
   //
   const scores = [100, 85, 90, 95, 70];
   const topScores = scores.filter((score) => score > 80).map((score) => `Score: ${score}%`);
   console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]*
   
   //
   // After ES2025
   //
   const scores = [100, 85, 90, 95, 70];
   const topScores = Iterator.from(scores)
   	.filter((score) => score > 80)
   	.map((score) => `Score: ${score}%`)
   	.toArray();
   console.log(topScores); // ["Score: 100%", "Score: 85%", "Score: 90%", "Score: 95%"]*
   

   Continue reading...

5. Demystifying Object-Oriented Programming: Pt. 1

   felipestanzani@blog ~ ~ cat "Demystifying Object-Oriented"~ cat post << 07-07-2025

   

   The Misconception of Object-Oriented Programming

   When we think about object-oriented programming, we often relate it to real-world objects. The problem is this: associating object-oriented programming with tangible real-world things doesn’t work in 80% of cases, and this brings more difficulties than clarity for beginners.

   Back in 1996, when I started programming in Delphi 4, its biggest competitor was Visual Basic, but Delphi was OBJECT-ORIENTED. If I had stopped at that programming course, I still wouldn't have known what this famous object-oriented programming was, and neither would the course instructor.

   I worked at various companies and on commercial software projects in Delphi that were far from truly using object-oriented programming. Most Delphi programmers I met thought object-oriented programming was about dragging a button onto a screen, double-clicking it, and creating a function for that button, for example.

   So, let’s talk about what object-oriented programming REALLY is.

   First, look at the image below and tell me what you see.

   

   Obviously, you see three cars: a pickup truck, an F1 car, and an SUV. The important question is: if these cars are so different, how do you know they are all cars? What makes a car a car and not a table or a piano?

   There’s a concept of what a car is that’s already ingrained in your mind. A car IS LIKE THIS and SERVES THIS PURPOSE. In object-oriented programming, this concept that defines what a car is called a CLASS: it’s the definition of WHAT a certain object is. The car you touch, the one you drive from point A to point B, is what we call an OBJECT. It’s the materialized concept. This materialized concept is technically called an INSTANCE. That’s why you’ll sometimes read that an object is an instance of a class. Always translate this as: the object you touch is a concept that has been materialized.

   Continue reading...

See all tags .