DEV Community: Taqmuraz

Myth we believe #2

Taqmuraz — Sun, 01 Feb 2026 13:33:28 +0000

Memory allocation in games

In my previous article I touch this question, but it wasn't the primary topic. Today we discuss garbage collection (GC) in games and graphics/physics simulation software, where program speed most important.

Where best practices come from?

Almost everywhere you may hear or read that opinion, presented as fact : "Avoid lots of allocations, reuse objects you already allocated, practice objects pool".
Those arguments (I confidently suppose) come from the world of programming languages with no default GC (C, C++, Rust and others), where memory allocations are, by default, malloc calls, which might be slow.
Today we give attention to languages with GC, such as C#, Java and Python (missed your favorite language? Ask for it in comments!).
For those languages (C#/Java/Python), advice to avoid allocations and reusing memory in object pools will lead to performance losses and unnecessary code complexity. And why so, you will know after reading this article.

Objects pool vs GC

What objects pool is? It is an optimization pattern, supposed to save time on allocating/releasing memory for massively used objects. Applying this pattern in language with GC, you have lots of long-living objects in heap and almost no short-living objects, what gives several negative effects :

objects pool

longer garbage collection for objects out of pool due to lots of old objects in heap
heap fragmentation
constantly moving objects in pool increase CPU cache misses
no predictable allocation patterns, GC can't optimize
overhead of adding/removing/searching objects in pool
reallocating memory on extending objects pool

In practice, results I observed were exactly what I describe here - less performance, less FPS.
Now, what about to not use objects pool and let GC do its work? Picture completely opposite :

GC

shorter garbage collection, because most of objects are young
no heap fragmentation
objects are allocated sequentially, perfect for CPU cache
all young objects born and die together, forming predictable patterns for GC
GC allocation generally is just increasing heap pointer, very fast
very flexible, no necessary to control object numbers

Why it doesn't work in Unity, Godot, Unreal Engine?

My advises work in context of developing the whole system in single approach. Popular game engines, such as Unity, Godot, Unreal Engine, provide ready-to-use systems, optimized for common practices. Unity engine references all active instances of GameObject, Component and other UnityEngine.Object descendants, and destroying those objects is removing references on them from engine. Those objects expected to live long, respond to engine events and change internal state accordingly. So, unity engine reminds one large objects pool in sense of negative effects for performance.
Unreal Engine and Godot both implemented with C++, so they implement own ways to manage memory, optimizing it for most common use cases, so lots of allocations will definitely reduce performance there.

Real evidence

There is a cut from GC logs one of my game demos made with Clojure and Java.
These logs demonstrate performance on 25vs25 battle scene with 50 units in total.

[50,037s][info][gc] GC(62) Pause Young (Normal) (G1 Evacuation Pause) 447M->213M(505M) 7,961ms
[51,514s][info][gc] GC(63) Pause Young (Normal) (G1 Evacuation Pause) 448M->213M(505M) 4,246ms
[52,978s][info][gc] GC(64) Pause Young (Normal) (G1 Evacuation Pause) 448M->213M(505M) 3,502ms
[54,363s][info][gc] GC(65) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 3,223ms
[55,727s][info][gc] GC(66) Pause Young (Normal) (G1 Evacuation Pause) 448M->213M(505M) 2,372ms
[57,044s][info][gc] GC(67) Pause Young (Normal) (G1 Evacuation Pause) 448M->213M(505M) 2,780ms
[58,419s][info][gc] GC(68) Pause Young (Normal) (G1 Evacuation Pause) 448M->213M(505M) 2,282ms
[59,752s][info][gc] GC(69) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 3,023ms
[61,066s][info][gc] GC(70) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 3,137ms
[62,388s][info][gc] GC(71) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 2,975ms
[63,694s][info][gc] GC(72) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 2,451ms
[65,016s][info][gc] GC(73) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 4,378ms
[66,620s][info][gc] GC(74) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 3,651ms
[67,930s][info][gc] GC(75) Pause Young (Normal) (G1 Evacuation Pause) 449M->213M(505M) 2,560ms

As you may see, garbage collection is happening approximately once in 1 second, generally taking ~3ms and collecting ~300MB of garbage. It also means, that those ~300MB were allocated during that 1 second. What do we have?

game is allocating GC memory in rate of ~300MB/sec
GC happening once each second
taking ~0.3% of all time in total
collecting ~300MB of garbage each second
keeping peak memory consumption on 505MB (perfect for systems with limited RAM)

Someone would expect me using some 16 cores 5GHz CPU for achieving those results, but no, it's this one :

lulook@lulook:~$ lscpu | grep "Model name"
Model name:                   
        Intel(R) Core(TM) m3-8100Y CPU @ 1.10GHz

Repeating my previous article

Most of programming advises work only in context, so don't believe them, always test applying to your use cases.
Limits everyone talk about may exist only because of poor system design or premature optimizations in one context, but step out that context and rules change.

Myths we believe : Stack vs Heap

Taqmuraz — Sat, 31 Jan 2026 11:01:43 +0000

Being C# programmer, I have heard a lot about stack memory, heap memory and difference between those. Usually it is "stack is faster, because no GC happens and heap is slower so you should avoid using it". This idea spreads not over C#, but also Java, C, C++, and many other compiled languages.
In this article I will speak on performance questions, not covering abstract concepts of stack and heap, and how they are different in C#/Java and C/C++.

Dare experiment

For some time I believed that, but once had courage to try using heap instead of stack, and...nothing bad happened.
I wasn't writing some ASP.NET backend, where latency 500ms is considered normal, instead I was developing a game engine, where even 10ms delay is critical for FPS.
I didn't hesitate on using heap memory, and, after I had surprisingly good performance with C# garbage collector, I kept my approaches for Java, making mobile rendering library with OpenGLES.
Still being surprised with good performance, I tried to disable Java garbage collector (-XX:+UseEpsilonGC) and see what happens.
And, I was surprised again - program terminated (due to out of memory) 5 seconds after it started. It consumed nearly 4GB of RAM in 5 sec, what is 800MB/sec.
All of this time my code was consuming that much of RAM, and still didn't have any problems with performance?

Old fairy tales

Yes, modern garbage collectors are that good. You may consume hundreds megabytes of RAM and still see no performance lost. If someone tell they have problems with slow GC, consider that as :

they consume RAM in rate about 5-10GB/sec
RAM consumption is acceptable, but they have large memory leaks
they use/used some old language or it's old compiler/runtime version
cause of performance loss is not in GC but somewhere else

So, those stories about "slow" heap memory are mostly outdated and can be considered as just fairy tales.

Is access to stack memory faster?

We covered topic on GC, but it can't be only difference between stack and heap, right?
Some of you may know that stack and heap are located on the same physical device (RAM) and approached by CPU in the same way. Difference appears when a compiler tries to optimize our code, replacing use of stack with use of registers. For an unknown reason, nobody talks about that in context of stack/heap separation.
Example :

using System;

class Program
{
    static  int SomeFunc(int a,  int b)  {
        int c = a + b;
        int d = c * c;
        int e = d <<  1;
        return e;
    }
}

If you ask a C# programmer, how much of stack space (in bytes) this function would use, answers may be different. Some would count only variables (3 x int = 12 bytes), some would count arguments as well (5 x int = 20 bytes). In fact, it's just guesswork, and all depends on compiler version and it's implementation.
I used the godbolt app to do researches on .NET compiler, and that's result I got for our C# code snippet :

Program:.ctor():this  (FullOpts):
ret

Program:SomeFunc(int,int):int  (FullOpts):
add  edi, esi
mov  eax, edi
imul  eax, edi
add  eax, eax
ret

If you can read assembly code, you already understand, what is going on. There is no stack frame at all. Arguments are passed in registers (edi and esi), and value is returned in eax register. This assembly code does not access RAM, what makes it much faster. Generally, access to stack memory is same slow as access to any other area of RAM (slow comparing to accessing a register).
So, difference between stack and heap exist only in context of specific compiler and it's optimization mechanisms. C# standard says nothing about stack being faster than heap.
CPU caches? Yes, they might make access to stack much faster, but same works with memory on heap.

Don't believe, do research

A lot of things you may hear from old Senior developers were true long time ago, but software changes and (usually) old performance problems are being solved.
Now, when I hear something like "A is slow, use B", I write a short program to compare A with B. Is B really good? By what cost? Is A really much worse than B? May A be improved? And, usually, I get contrary results, where A is same as B or even faster, because my often use case is different from common one.

Bonus content : a story about importance of doubt

A remarkable story happened with my brother, who makes games with Godot. He has heard a lot about Vulkan being faster than OpenGL because it's modern, supports parallelism and gives more control on GPU. So, he compared them, and discovered that version of game with Vulkan had much worse performance than same one but using OpenGL.
So what it tells us? Maybe, performance potential of Vulkan is real, maybe it's just marketing. Maybe, there are special cases where Vulkan in Godot is much faster than OpenGL. Maybe it is only so with specific GPU models. Maybe, Godot developers didn't manage to benefit from Vulkan speed yet.
Everything must be tested, compared and applied in supposed field, and words are just words.

Best programming paradigm?

Taqmuraz — Fri, 26 Dec 2025 08:20:12 +0000

There are many programming paradigms, but two of them have most spread : OOP (object-oriented programming) and FP (functional programming). Under OOP I use here Simula design and not Smalltalk one. They are different, so I bring clarity.
Whatever team of programmers you work in, there will prevail one of those two paradigms (today it's usually OOP). Reactive programming found popularity in the modern web and mobile programming. There's also procedural programming, that is rarely used in isolation from other paradigms. Must mention that exist aspect-oriented programming, agent-oriented programming, stack-oriented programming, event-driven programming, data-driven programming and many other paradigms, focused on problems of special fields.

What is the purpose of paradigms?

Just using of one or more paradigms doesn't make your code better. Usually it's opposite. Paradigms bring complexity, unnecessary for the most of programming problems. To bring benefits, they require theoretical understanding, experience solving simpler problems with them, and even ability to discard using them when they are not needed.
Most of modern object-oriented and functional languages give means to write procedural imperative code, and purely functional or object-oriented programs are rarely useful.
Many programmers approach paradigms like solving puzzles, making a game inside of the coding process. It's entertaining and gives feeling of doing something smart.
Many of others use paradigms to control and discipline young programmers, who would write an alien-style code impossible to understand for anyone but themselves.
If every programmer would work alone, writing all solutions by himself, there wouldn't be need in paradigms.
So, purpose of paradigms is to limit programmer's thinking, focusing on use of existing practices and standards.

What is the best programming paradigm?

Best programming paradigm is one you create yourself for yourself. Only this way you can reach top limits of your productivity and creativity. Of course, you will create better paradigm, if you already are familiar with other ones. If you know well only OOP, most likely anything you will try to invent will become OOP, same about every other paradigm. Ones who really benefit from paradigms are their creators. Many programmers may feel comfortable with them, never meeting potential ceiling of a specific paradigm, but talented minds shouldn't stay there for long.

No harm in trying

Paradigms that work bad for one languages may work great with other languages. Try other languages, experiment with ideas, or even invent your own programming language. Stack-oriented paradigm is a bright example of a daring experiment, challenging common understanding of programming. Forth language demonstrates power and elegance of stack programming.
Most of modern programming languages (C#, Java, C, C++) inherit ideas from 60 years old languages, reminding more syntactic sugar for those, not separate languages.
Good knowledge of mathematics would do great work for inventing new programming paradigms and languages.
It's common to think that abstract concepts align badly with hardware, and you should choose between programs performance and abstract ideas.
In fact, translating abstract ideas into assembly language is much more effective than doing so with C or C++ "low-level" mechanisms.
Abstract mathematical ideas give more freedom for portability over different platforms, and resulting assembly code may be better optimized and be much simpler.

Final

That's my second article, where I am trying to inspire young programmers to challenge spread ideas, experimenting and investigating. Thanks for reading.

C and C++ don't give you actual control on memory

Taqmuraz — Wed, 03 Dec 2025 16:53:31 +0000

It's common to think that Java, C# and Python have high level of abstraction over hardware, while C and C++ are low level, close to hardware, giving you full control on usage of this exact hardware -- CPU and memory.
And, it's true that you can't allocate memory manually in C#, Java or Python, same as you don't have complete control on what machine does. These languages keep enough distance from hardware, so you, programmer, may forget about memory management and platform-dependent code. Right. But, what about C and C++?

C standard and Undefined Behavior

It's also common to know that C and C++ have such thing as undefined behavior (UB). Usually people call UB something that causes weird bugs or changes program logic when switching platforms. In reality, UB means that if code logic is not defined by standard or explicitly stated as undefined, compiler may generate any code it likes and your program may do whatever compiler developers designed (or made by mistake) to do. Compiler expects that your code never has UB, so when it has, it won't warn you.
Undefined Behavior is not unique for C/C++ standards. Common Lisp standard, for example, also uses term "undefined" to define when compiler developers have freedom designing and optimizing Common Lisp implementation. Though, I am not aware of Common Lisp implementation that leaves such places undefined. In some cases they extend standard, filling "undefined" gaps, in other cases they signal an error when "undefined" scenario happens.
What is really unique about C/C++, is entering "undefined behavior" silently, considering it normal, and moving all responsibility for UB from compiler developers to compiler users. It could be kind of correct, if programs you write would do what you mean them to do. But, C/C++ programs are not the case.

Code you write is not the code you run

C/C++ compilers aggressively force bunch of optimizations, most of which are weird, unnecessary, and dangerous for most of programmers. Such optimizations may be enabled with -O, -O1, -O2, -O3 flags, and some of them may be disabled after with own dedicated flags.
Here is an example. Everyone, who programs on C and C++, knows that if pointers have same binary value, they are equal. Now it's time to surprise, because standard says :
C standard 6.5.10.7

Two pointers compare equal if and only if both are null pointers, both
are pointers to the same object (including a pointer to an object and
a subobject at its beginning) or function, both are pointers to one
past the last element of the same array object, or one is a pointer to
one past the end of one array object and the other is a pointer to the
start of a different array object that happens to immediately follow
the first array object in the address space

Nothing is said about pointers being just integer byte addresses. Instead, it treats pointers as some abstract entities on level higher than system memory control. Why it doesn't say that pointers are equal if their integer addresses are equal? Simple, because C standard thinks they don't. Don't believe me? Check that :

#include "stdio.h"

int main(int argc, char** argv) {
  int x;
  int y;
  int* a = &x + 1;
  int* b = &y;
  printf("%p, %p, %s\n", a, b, a == b ? "true" : "false");
}

Simple program. Outputs are clear for all C programmers : two same pointers and true after. Compiling, running, and...yes.

g++ pointers_eq.c -o peq; ./peq
0x7ffc4bd50194, 0x7ffc4bd50194, true

So, C standard wins? Not yet. We must enable optimizations so miracles start happening.

g++ -O pointers_eq.c -o peq; ./peq
0x7ffffb069694, 0x7ffffb069694, false

Well, we see with own eyes that a and b addresses are equal, how they aren't? Because, C compiler sees that a and b pointers have different origins, and assumes that origins are different enough to replace a == b with false.
You can tell, that nobody is going to write such a program exploiting stack layout. Then I have another example for you.

#include "stdio.h"

void fun (int* a, float* b) {
  *a = 0;
  *b = 3.33;
  *a = *a + 10;
}

typedef union {
  int a;
  float b;
} ab;

int main(int argc, char** argv) {
  ab x;
  fun(&x.a, &x.b);
  printf("%d\n%f\n", x.a, x.b);
}

Two pointers, a and b, share same memory, but point on different types. Naive logic tells, that after calling fun, x.a will have some garbage value and x.b will have corrupt float value close to 3.33.

g++ two_pointers.c -o tp; ./tp
1079320258
3.330002

Now, using -O3 flag

g++ -O3 two_pointers.c -o tp; ./tp
10
0.000000

Let me explain what happened. C standard has a rule named strict aliasing. It regulates how program must access values from memory. Behavior is Undefined, when program reads or writes values in the same memory, accessing it by pointers of incompatible types. While optimizing function fun with -O3,compiler assumed, that a and b point to different memory addresses, otherwise program would violate strict aliasing rule, causing UB. Then, it transformed fun code to the following :

void fun (int* a, float* b) {
  *a = 0;
  *b = 3.33;
  *a = 10;
}

Because *a is equal to 0, it removes addition and assigns it 10.

No real control

There is a lot more of such cases, most confusing for me is that integer numbers overflow causes UB.
Writing program causing UB is so easy that most of existing C programs have it.
You don't have real control on hardware, because when you start doing things you couldn't do in Java, C# or Python, you go beyond C standard and cause UB. C standard does not provide a sandbox, where you can do whatever you want, nobody to blame but you. Instead, it aggressively modifies your code, assuming you don't step out standard bounds. You may argue that you can avoid using compiler optimizations. Yes, you can, but, C and C++ are shamefully slow without those optimizations.

Control is a burden

Language, that would have complete control on memory (let's call it the naive C), makes programs very difficult to optimize. Usually programs don't use all language means, what allows language developers to optimize such cases (like caching short string values in processor's registry). But, the naive C allows programmer to modify any memory at any time, any function call may cause side effects, changing any byte of memory it told to change.
The naive C can't rely on aggressive optimizations, and without them programs won't show performance miracles. Then, writing originally optimized programs would require deeper knowledge of target hardware and intelligence above average (which is rare). And even if you could do so, it would require rewriting all C/C++ standard header files, because their runtime speed depends a lot on aggressive optimizations.

C is an abstract, high level language

Reading C standard, I can't erase impression of being distanced away from hardware and reality. It tries to stand close to hardware, but avoids specifying cases of exact close interaction with hardware. Forget that pointers are integer addresses, forget that integer overflow is a thing, forget that memory is just bytes and bits, with no types. Types supposed to be just hints on how to use memory, but in fact they are way more than that.
I don't mention C++ here, because it's even more distant from hardware than C. Most of C++ programmers avoid using raw pointers and C-like structs, preferring complex object-oriented models with overloaded operators/constructors/destructors. Even though C++ "extends" C, they are very different in real world code.

Final

C/C++ don't give you to actually control memory, instead they give you to play with memory. They give feeling of control, of making impact on computer's state, and nothing more than that.
Thinking there are operations you can do in C/C++ and can't do in other (better) languages is a spread fallacy, based on lack of experience with other, "foreign" languages/concepts.
I am developing graphics/games/compilers using 0 lines of C/C++ code. It is possible, and it is a pleasure.

Choosing game engine in 2025

Taqmuraz — Tue, 10 Jun 2025 10:28:59 +0000

It's just a tool

Game engine is a tool, so it may be analyzed and rated. In order to do so, we need to understand, what game engine is.

What is a game engine?

I present my own definition : game engine is an abstraction layer over separate autonomous systems : graphics, physics, sound, networking, user input, storage. Design of such abstraction layer may vary.
This is what game engine must be. Flexible, customizable for almost any needs. Now let's find a definition for modern and popular game engines, such as Unity, Unreal Engine, Godot : an ecosystem, that provides means for user to create games, including a visual editor for game contents and assets.
No access to separate engine systems, you get all systems at once, monolith. More than that, 95% of your game consists not of your code, but files generated by engine and useless anywhere beyond.
Most of game developers don't see problem here. Though, what happens if the publisher of this engine changes terms of license? Or even cancels your free license, asking for an annual subscription? Or forces you to use an updated version of the engine, which breaks your game?
When you make a game with such "game engines", you don't really have a game. You have a product, which, de facto, belongs to the engine publisher.

What code architecture is best?

Answering short, best architecture is no architecture.
Limiting yourself with specific programming patterns you decrease your own efficiency. We all love to play puzzles, but doing so while writing game code is not efficient.
Best approach is to avoid building complex abstractions, such as entity component system (ECS), MVC or OOP patterns.
Don't put strict rules on how your game works, allow each system and each entity to decide what and how to do. Especially if you are an experienced programmer.
With time you may develop your own approaches of writing code without useless complexity.
After you can write games with simple and flexible code, using libraries for graphics, physics, sound, user input -- switching to Unity or Unreal Engine will become obviously over-complicated and inefficient.

What programming language is best?

I personally would recommend dynamically typed languages with FFI (foreign function interface) to C or Java.
Python, Groovy, Lua or similar.
Most of game developers explain choosing C++ by it's performance and strict access to memory, though 99% lines of game code don't need that.
That 1% of code you can rewrite on C or Java and call it from a code in dynamically typed language.

What game engine is best?

Following idea of this article, best game engine is no game engine.
My definition of game engine is very close to that. Game engine must be a thin abstraction layer over separate independent systems, so after you just write game logic.
This way, 100% of your game will belong to you. Also, you can port your game between platforms, change rendering methods or networking technologies, encode resources or leave them accessible to user. It won't die in 5 or 10 years because of Windows update or game engine API changes (as it happened to one of my Unity games).

Ambitions

Mostly, game programmers don't understand their desires. What game they want to do. So, they choose a game engine to make an AAA game, usually it's Unity or Unreal Engine. And, usually they end up making 2D platformers or 3D hyper-casual games with low-poly graphics.
If you want to make an AAA game with a photo-realistic graphics by yourself, having no hundreds millions of dollars, think again.
And, even if you do have a lot of money, using Unity or Unreal Engine would be inefficient (look on AAA games we have in 2025).

Game engines keep you from thinking

Unity, Unreal Engine and Godot give their users an illusion of comprehension and development, while they don't clearly understand how most of systems work.
I won't say it is bad or good.
Just consider the fact. Game engines are made for amateurs, who are not capable to make even simplest games independently. As popular meme says, "If you are nothing without this game engine, then you shouldn't have it".

What then?

Instead of choosing game engine, choose programming language and libraries, and start writing games. You will thank me later.

C and C++ are really so fast?

Taqmuraz — Tue, 03 Dec 2024 17:38:29 +0000

During all that time I am engaged with programming, I hear that C and C++ are the speed standards. Fastest of the fastest, compiled straight to assembly code, nothing may compete in speed with C or C++. And, nobody seem to challenge that common belief.

Computing performance

Arithmetic operations with numbers, obviously, must work significantly faster in C than in any other language. But do they?
Some time ago I decided to write a set of simple benchmarks for many different languages to see, how large difference in speed really is.
Idea was simple : to find the sum of the one billion integer numbers, starting from zero, using straight-forward computing. Some compilers (rustc, for example) replace such simple cycles with formula expression, which, of course, will be evaluated in the constant time. To avoid that with such compilers. I used similar in costs operations with numbers, such as bitwise or.
After I got results, I was surprised very much. My world view turned upside down, and I had to reconsider everything I knew about speed of programming languages.
You may see my results in the table below :

Linux 64bit, 1.1 GHz CPU, 4GB RAM

Language	compiler/version/args	time
Rust (bitwise or instead of +)	rustc 1.75.0 with -O3	167 ms
C	gcc 11.4.0 with -O3	335 ms
NASM	2.15.05	339 ms
Go	1.18.1	340 ms
Java	17.0.13	345 ms
Common Lisp	SBCL 2.4.11.26	363 ms
Clojure	1.10.2	373 ms
Python 3	pypy 3.8.13	1.6 sec
Python 3	cpython 3.10.12	26 sec
Ruby	3.0.2p107	38 sec

All tests sources you may find here :
https://github.com/Taqmuraz/speed-table

So, as we may see, C is not very much faster than Java, difference is about 3%. Also, we see that other compiled languages are very close in arithmetic operations performance to C (Rust is even faster). Dynamic languages, compiled with JIT compiler, show worse results -- mostly because arithmetic operations are wrapped into dynamically dispatched functions there.
Interpreted dynamic languages with no JIT compiler show worst performance, not a surprise.

Memory allocation performance

After that crushing defeat, C fans would say that memory allocation in C is very much faster, because you are allocating it straight from the system, not asking GC.
Now and after I will use GC term both as garbage collector and as managed heap, depending on the context.
So, why people think, that GC is so slow? In fact, GC has pre-allocated memory, and allocation is simply moving pointer to the right. Mostly GC fills allocated memory by zeros using system call, similar to memset from C, so it takes constant time. While memory allocation in C takes undefined time, because it depends on the system and already allocated memory.
But, even considering this knowledge, I could not expect so good results from Java, which you may see in following tables :


1.1 GHz 2 cores, 4 GB RAM
Running tests on single thread.
Result format : "Xms-Yms ~Z ms" means tests took from X to Y milliseconds, and Z milliseconds in average

Allocating integer arrays

integers array size	times	Java 17.0.13 new[]	C gcc 11.4.0 malloc	Common Lisp SBCL 2.1.11 make-array
16	10000	0-1ms, ~0.9ms	1-2ms, ~1.2ms	0-4ms, ~0.73ms
32	10000	1-3ms, ~1.7ms	1-3ms, ~1.7ms	0-8ms, ~2.ms
1024	10000	6-26ms, ~12ms	21-46ms, ~26ms	12-40ms, ~7ms
2048	10000	9-53ms, ~22ms	24-52ms, ~28ms	12-40ms, ~19ms
16	100000	0-9ms, ~2ms	6-23ms, ~9ms	4-24ms, ~7ms
32	100000	0-14ms, ~3ms	10-15ms, ~11ms	3-8ms, ~7ms
1024	100000	0-113ms, ~16ms	234-1156ms, ~654ms	147-183ms, ~155ms
2048	100000	0-223ms, ~26ms	216-1376ms, ~568ms	299-339ms, ~307ms

Allocating instance of the class Person with one integer field.

how many instances	Java 17.0.3 new Person(n)	C++ g++ 11.4.0 new Person(n)
100000	0-6ms, ~1.3ms	4-8ms, ~5ms
1 million	0-11ms, ~2ms	43-69ms, ~47ms
1 billion	22-50ms, ~28ms	process terminated

All tests sources you may find here :
https://github.com/Taqmuraz/alloc-table

There I tested four languages in total : C, C++, Java and Lisp. And, languages with GC always show better results, though I tested them much stricter, than C and C++. For example, in Java I am allocating memory through the virtual function call, so it may not be statically optimized, and in Lisp I am checking first element of the allocated array, so compiler won't skip allocation call.

Releasing memory

C fans are still motivated to protect their beliefs, so, they say "Yes, you do allocate memory faster, but you have to release it after!".
True. And, suddenly, GC releases memory faster, than C. But how? Imagine, we made 1 million allocations from GC, but later we have only 1000 objects referenced in our program. And, let's say, those objects are distributed through all of that long span of memory. GC does stack tracing, finding those 1000 "alive" objects, moves them to the previous generation heap peak and puts heap peak pointer after the last of them. That's all.
So, no matter, how many objects you allocate, GC's work time is decided by how many of them you keep after.
And, in opposite with that, in C you have to release all allocated memory manually, so, if you allocated memory 1 million times, you have to make 1 million release calls as well (or you are going to have memory leaks). That means, O(1)-O(n) of GC against O(n) or worse of C, where n is the number of allocations happened before.

Summary

So, I want to consolidate the victory of garbage collected languages over C and C++. Here is the summary table :

demands	languages with GC	C/C++
arithmetic	fast with JIT	fast
allocating memory	fast O(1)	slow
releasing memory	fast O(1) best case, O(n) worst case	O(n) or slower
memory safe	yes	no

Now we may see -- garbage collection is not a necessary evil, but the best thing we could only wish to have. It gives us safety and performance both.

Tribute to C

While C does show worse results on my tests, it is still an important language and it has own application field. My article does not aim for C rejection or obliteration. C is not bad, it is just not that superior as people think. Many good projects collapsed only because some people decided to use C instead of Java, for example, because they have been told that C is very much faster, and Java is incredibly slow because of garbage collection. C is good, when we write very small and simple programs. But, I would never recommend writing complex programs or games with C.

C++ is different

C++ is not simple, is not flexible, has overloaded syntax and too much complicated specification. Programming with C++ you will not implement own ideas but fight with compiler and memory errors 90% of the time.
This article does aim for rejection of C++, because speed and performance are only excuses people give for using this language in software development. Using C++, you are paying with your time, your program performance and your mental health. So, when you have choice between C++ and any other language, I hope you choose the last one.

Why do programs wear out?

Taqmuraz — Mon, 29 Jul 2024 20:31:15 +0000

What is a program?

Program is a code. A text. How text may wear out?
Have you ever heard about a mathematical theorem that was replaced with a new one? Or, maybe, about a mathematical function becoming obsolete?
Once proven, a mathematical idea is correct forever.
Programs must be same. But, they are not. Why?
The short answer : a lack of mathematics (and abstraction) in modern programming.
Now, let us sort it out.

Speed bigotry

Machines become obsolete, we are inventing new technologies and ways of production. Software becomes outdated with its target hardware. But, why does it have target hardware? To work as fast as possible, to exploit as much implementation details as it may reach. A small abstraction level would bring loss in speed, but give independence from hardware. Written once, used forever.

Program or programmer : one must die

Well, we have C# and Java, that have abstraction layer over hardware. So, they would be good to write programs once and use forever?
Yes, they could be...but.
We don't really need programs that would work forever.
Try to imagine that. 99% of software engineering would become pointless. All those C# and Java developers would lose their jobs.
Fortunately for them, they have OOP. Software killer.
OOP was invented bad for a purpose. We are killing our software constantly, because we are getting paid for programming new software.
Eventual death for any program is essential for us, otherwise we would have no money.

How does OOP kill programs

Classes are perfect for making code rigid and useless.
Perfect example -- you may meet such classes as Vector2, Vector3, Matrix3, Matrix4, Quaternion in any library, related to computer graphics or mathematical modeling.
Why don't everyone use only one best implementation, like everyone does with int, float, char, byte? Answer is simple -- primitive types are not classes.
They were designed once to be used forever, and you can't achieve such design level with classes.
Classes are designed to make program "disabled" everywhere, excepting limited purpose, that is demanded by current moment.
OOP is about resolving thousand times the same problem, implementing brand new (one more bad) solution.

Way out

Well, let us imagine, how would look an immortal vector implementation? First, it must have no mutable state. Same as string, int, char. You can't mutate them, you can only create new.
And, we already have such vector implementation in Lisp (Clojure) :

(let [
    v [1 2 3] ; same as (vector 1 2 3)
    [x y z] v ; vector deconstruction
  ]
  (println v) ; [1 2 3]
  (println x y z) ; 1 2 3
)

So, we don't need classes. More than that : we don't even need to declare functions to calculate dot product, or vectors sum, or transposed matrix :

(let[
    a [1 2 3]
    b [4 5 6]
    c (apply + (map * a b)) ; a and b dot product
    d (mapv + a b) ; a and b sum
    e (vector a b) ; 3x2 matrix from a and b
    f (apply mapv vector e) ; transposing matrix e
  ]
)

There is no OOP, code is simple, flexible and it will never face necessity to be edited. Written once, used forever.

Does not fit for business

I frequently hear, that functional approaches do not fit for business. That OOP is only one and best choice for software design.
Well, there is a particle of truth. OOP is truly best choice for business, if you ask programmers. And, it is a deadly mistake, if you consider interests of business itself.
Do you want to pay programmers for doing same job hundred times? Or you want them to resolve actual business problems?
Choice is clear.

C++ : speed obsession in the game industry

Taqmuraz — Fri, 26 Jul 2024 16:05:24 +0000

When do we really need speed

C++ became a standard language for games and graphics software a long time ago. And, there was actual reason -- work with real-time graphics and physics requires high performance. Processing geometry, managing buffers, matrix calculations - all of that does take time.
But, what about high-level logic? Game mechanics, user interface, storage management, network requests? Stability and safety are much more demanded there, than speed.

Responsibility distribution

We may implement performance-demanding functions in a compiled language, such as C++, and call them from a program written in a dynamic language, such as Python.
But, today we already have well-documented and easy to use libraries for Python (pygame, pyopengl, pyassimp, pybullet, numpy), that are implemented primarily on C/C++ and do provide functions for heavy calculations, or physics/graphics in particular. We may never face necessity to implement such libraries on our own.

Is C++ the only choice?

It is generally accepted, that garbage collected languages, such as Java or C#, are slower than C++ and don't really meet requirements for heavy calculations. This is, of course, not true.
C++ may overcome Java or C# in performance by 20-30% in some special cases, but when it comes to runtime abstractions, such as dynamic function dispatch, languages interaction, asynchronous tasks, text or abstract collections management, Java and C# show much higher efficiency than C++.
Also, we may run our Python programs on the same runtime with Java or C#, using Jython or IronPython. It brings a lot of benefits, such as shared garbage-collected memory, types system and easy access to C# or Java libraries right out of the box. On Java are implemented such nice dynamic languages as Clojure and Groovy, that have complete access to Java Class Library and share previously mentioned benefits.

What really makes influence on performance?

Today personal computers are much faster, than 15-20 years ago. But, most of desktop programs or games do not work as fast as expected (despite that they are still mostly implemented on C/C++). Today we need good algorithms and effective approaches much more, than just language speed. Function with constant complexity on Python is more preferable than function with linear complexity on C. To paint 100 trees by 15 lines of Python code is more preferable than to paint 500 trees by 300 lines of C++ code.

Care about game, not language

It is not really important, what language you use, when you don't have any game made, right?
Making game on C++ is much more demanding and exhausting, than doing same on Python or Ruby. When you would make 1 game with C++, you would make 10 games with Python. When you would make 5 games with Python, it would be 0 games with C++.
Let us care about games and fun, otherwise what the point?

Python : advanced way to reduce the amount of repetitive code

Taqmuraz — Sat, 24 Feb 2024 18:44:36 +0000

Let us imagine, that you have some list of objects.
You need to call one specific function on each object in that list.
Here is an example :

class Dog:
    def sound(self):
        print("Woof")
class Cat:
    def sound(self):
        print("Meow")
class Cow:
    def sound(self):
        print("Mooo")

animals = [Dog(), Cat(), Cow()]
for a in animals: a.sound()

Nice. Now, imagine that each animal object must have at least two functions : sound and insight.
sound does write line to the output stream and returns nothing, insight does nothing but returns a string.
We would like to call sound in each function and to print list containing insight string of each animal :

class Dog:
    def sound(self):
        print("Woof")
    def insight(self):
        return "Humans are best!"
class Cat:
    def sound(self):
        print("Meow")
    def insight(self):
        return "Humans are slaves of cats"
class Cow:
    def sound(self):
        print("Mooo")
    def insight(self):
        return "Humans are violent indeed"

animals = [Dog(), Cat(), Cow()]
for a in animals: a.sound()
print(f"Insights : {[a.insight() for a in animals]}")

It may seem nice, but we use for loop each time we need to do the same thing with each animal. How may we reduce number of such syntax constructs? We could declare wrapper-class to wrap list of animals, intercepting function calls and returning lists of results :

class PluralAnimal:
    def __init__(self, animals):
        self.animals = animals
    def sound(self):
        for a in animals:
            a.sound()
    def insight(self):
        return [a.insight() for a in self.animals]

plural = PluralAnimal(animals)
plural.sound()
print(f"Insights : {plural.insight()}")

Looks much better? Yes, but I have one concern : now we have to declare such wrapper-class for each case of use. For animals, vehicles, employees we have to declare PluralAnimal, PluralVehicle, PluralEmployee.
How may we avoid that?

Dynamic function call interception

If we want to access some attribute of the object in runtime, using name of that attribute, we may use getattr function :

class Example:
    def func(self):
        print("Hello, example!")
obj = Example()
func = getattr(obj, "func")
func() # output : Hello, example!

Let us write wrapper-class, using getattr function :

class Plural:
    def __init__(self, objs):
        self.objs = objs
    def __getattr__(self, name):
        def func(*args, **kwargs):
            return [getattr(o, name)(*args, **kwargs) for o in self.objs]
        return func

plural = Plural(animals)
plural.sound()
print(f"Insights : {plural.insight()}")

That's all for today. Thank you for reading, I would be pleased to read and answer your comments. See you next time.

OOP via FP : functional nature of classes and objects

Taqmuraz — Wed, 07 Feb 2024 22:31:45 +0000

Topic for today

Today I would like to tell you, why such OOP concepts as classes and objects are just particular cases of functions, using examples of code in Ruby and in my own language, Jena.
Why Ruby? Despite that it is an object-oriented language, it also provides a good foundation for functional approaches. In that, I hope, my article will convince you, though it is a secondary point today.

Jena references

If you are not familiar with Jena, you may read dedicated article about this language.
If you want to try Jena, you are welcome to visit its github repository.

Object as a table of functions

Let us watch on an example of a class declaration in Ruby :

class Human
  def walk
    puts "walking!"
  end

  def stand
    puts "standing!"
  end
end

h = Human.new()
h.walk
h.stand

Class is a popular idea, that has wide spread in modern languages, such as Python, Java, C#, C++.

What exactly do we see here?
Class Human seem to be a function, that creates objects.
But, also, object h here has two functions, and we may call them by their names.

May we try to implement the same behaviour, using only functions? Let us try :

def Human
  return {
    :walk => -> do puts "walking!" end,
    :stand => -> do puts "standing!" end,
  }
end

h = Human()
h[:walk].call
h[:stand].call

I feel important to explain, what I am doing here. Function Human creates a hash-map, where symbols are associated with
anonymous functions. Yes, :walk and :stand are symbols, it is a part of Ruby syntax, very uncommon in other languages.
As you may see, I chose Ruby for a reason. This language has one thing in common with Jena -- symbol literals.

Honesty and clarity

More honest implementation of an object through a function would be this one :

def Human
  map = {
    :walk => -> do puts "walking!" end,
    :stand => -> do puts "standing!" end,
  }
  return ->key do map[key] end
end

h = Human()
h.call(:walk).call
h.call(:stand).call

Now we are not using a dedicated syntax, hiding object implementation behind a function. You may say, that Human class code does look better, and code with functions is verbose and complicated. It is true, because syntax of Ruby (and most of other object-oriented languages) is designed to make use of classes and objects easy, sacrificing for that ease and clarity of functions.

Let me demonstrate the same behaviour, implemented in Jena :

Human = () -> {
  .walk:() -> println "walking!",
  .stand:() -> println "standing!",
} =>
h = Human() => [
  h.walk(),
  h.stand(),
]

This code does exactly the same thing that the last Ruby code does : creates a Human function, that returns table of functions, calls it, storing result as h and, after that, calls walk and stand functions, taking them from table, using .walk and .stand symbols as keys.

Mutable state

You may say, that objects have a mutable state, and, sometimes, it may be very useful. Methods may change attributes of an object, but may functions do the same?
Short answer is yes. Let us write some Ruby code

class Human
  @x

  def initialize
    @x = 0
  end

  def moveLeft
    @x -= 1
  end

  def moveRight
    @x += 1
  end

  def status
    puts "x = #{@x}"
  end
end

h = Human.new()
h.moveLeft()
h.moveRight()
h.moveRight()
h.status()

How would look the same code in our approach, where object is a function?

def Human
  x = 0
  map = {
    :walkLeft => -> do x -= 1 end,
    :walkRight => -> do x += 1 end,
    :status => -> do puts "x = #{x}" end,
  }
  -> key do map[key] end
end

h = Human()
h.call(:walkLeft).call
h.call(:walkRight).call
h.call(:walkRight).call
h.call(:status).call

And, in Jena it would be implemented next way :

Human = () -> x = box(0) => {
  .walkLeft:() -> x.apply(-1),
  .walkRight:() -> x.apply 1,
  .status:() -> print ("x = " + (x.get)),
} =>
h = Human() => [
  h.walkLeft(),
  h.walkRight(),
  h.walkRight(),
  h.status(),
]

Dynamic languages, such as Ruby, provide us flexibility in control of program state, we don't have to explicitly allocate memory for a mutable state, local variables already do present a state.

Performance

Our function-based objects have one serious flaw : low performance. We are building a functions table each time we create a new object, can we optimize that? Yes, of course we can, all we need is to separate an object state from functions table :

$table = {
  :walkLeft => -> obj do obj[:x] -= 1 end,
  :walkRight => -> obj do obj[:x] += 1 end,
  :status => -> obj do puts "x = #{obj[:x]}" end,
}
def Human
  state = { :x => 0 }
  -> key do
    -> do
      $table[key].call(state)
    end
  end
end

h = Human()
h.call(:walkLeft).call
h.call(:walkRight).call
h.call(:walkRight).call
h.call(:status).call

And Jena :

Human = table = {
  .walkLeft: obj -> obj.x.apply(-1),
  .walkRight: obj -> obj.x.apply 1,
  .status: obj -> print ("x = " + (obj.x.get)),
}
=> state = { .x:(box 0) }
=> () -> key -> () -> table key state =>
h = Human() => [
  h.walkLeft(),
  h.walkRight(),
  h.walkRight(),
  h.status(),
]

Looks overloaded? I agree. But, we may simplify that. Let us create a class factory function, so we may distract from building table and state functions each time we want to create a class :

Class = table ->
  constructor ->
  args -> state = constructor args =>
    key -> arg -> table key args state arg =>

Human = Class {
  .walkLeft: () -> obj -> () -> obj.x.apply(-1),
  .walkRight: () -> obj -> () -> obj.x.apply 1,
  .status: () -> obj -> () -> println("x = " + (obj.x.get)),
} args -> { .x:(box (args.x)) }  =>

h = Human{.x:5} => [
  h.walkLeft(),
  h.walkRight(),
  h.walkRight(),
  h.status(),
]

As you see, now we even can pass constructor arguments to build our object, it is a full complete object-oriented class, implemented by functions only.

Other reasons to choose functions over objects

For many of readers solution with classes looks more familiar and pleasant, but only because you already have experience using that solution.
Functions are coming from a mathematical world, their abstraction and distraction from implementation details are attractive indeed. Functions have simple and consistent concept behind, while objects are very specific and domain-oriented.
Finally, class in most of the object-oriented languages is a separate syntax, what brings more complexity and involves a special logic for constructors, methods and attributes.

That's all for today. Thank you for reading, and please, share your thoughts in comments.

C#: functional approaches explained solving one specific problem

Taqmuraz — Sun, 04 Feb 2024 17:15:00 +0000

Today I would like to tell you about functional approaches. Why they are good, and why they are simple.

We need to write some code

Let us imagine, that we have some array of strings. It may be an array of names :

var items = new[]
{
    "Peter",
    "Albert",
    "John",
    "Jim",
    "Pavel",
    "Robert"
};

We would like to choose only names with a unique first character : "Peter", "Albert", "John", "Robert".
In C# we have LINQ to operate collections, and it has Distinct function. But, this function would compare full names, when we need to compare only their first characters.
.NET has DistinctBy function starting from .NET 6. But, what if we use another versions of .NET, or even .NET framework?
We are going to write an own DistinctBy implementation then.

Procedural approach

Many times, in someone else's code, I met exactly this procedural implementation :

using System.Collections.Generic;

static class EnumerableExtensions
{
    public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector)
    {
        HashSet<TKey> keys = new HashSet<TKey>();
        foreach(var item in source)
        {
            var key = keySelector(item);
            if(!keys.Contains(key))
            {
                keys.Add(key);
                yield return item;
            }
        }
    }
}
class Program
{
    static void Main()
    {
        var items = new[] { "Peter", "Albert", "John", "Jim", "Pavel", "Robert"};
        Console.WriteLine(string.Join(", ", items.DistinctBy(n => n[0])));
    }
}

It does work, and it is not so bad.
But, now we have two separate implementations of almost the same thing : Distinct and DistinctBy functions. How may we solve that?

Object-oriented approach

It may seem obvious to use a special overload of the Distinct function, that accepts IEqualityComparer parameter. This way we have a control over how the Distinct function compares names. Let us implement IEqualityComparer interface with a necessary logic and apply it to our solution :

using System.Collections.Generic;
using System;

class FirstCharacterComparer : IEqualityComparer<string>
{
    public bool Equals(string x, string y)
    {
        return x[0] == y[0];
    }

    public int GetHashCode(string obj)
    {
        return obj[0].GetHashCode();
    }
}

class Program
{
    static void Main()
    {
        var items = new[] { "Peter", "Albert", "John", "Jim", "Pavel", "Robert"};
        Console.WriteLine(string.Join(", ", items.Distinct(new FirstCharacterComparer())));
    }
}

Much better? I agree, but, how many classes we would create to implement such a small logic? If we would need to compare last characters, we would create a LastCharacterComparer class? And, to compare first decimal symbols of two numbers, we would create a FirstDecimalSymbolComparer? Object-oriented approach does give us a flexibility, but class declarations are too verbose.

Semi-functional approach

Let us describe our problem in a mathematical way.
We have some set X as an input (array of strings), a selector function X -> Y (where Y is a set of first characters respectively) and a distinct function (X, (X -> Y)) -> Z (where Z is a set of names with unique first symbols).
A selector function, in our case, is s => s[0], a distinct function is System.LINQ.Enumerable.Distinct.
Now, keeping this model in mind, let us implement and apply IEqualityComparer again :

using System.Collections.Generic;
using System;

class KeyComparer<TSource, TKey> : IEqualityComparer<TSource>
{
    Func<TSource, TKey> keySelector;

    public KeyComparer(Func<TSource, TKey> keySelector)
    {
        this.keySelector = keySelector;
    }

    public bool Equals(TSource x, TSource y)
    {
        return keySelector(x).Equals(keySelector(y));
    }

    public int GetHashCode(TSource obj)
    {
        return keySelector(obj).GetHashCode();
    }
}

class Program
{
    static void Main()
    {
        var items = new[] { "Peter", "Albert", "John", "Jim", "Pavel", "Robert"};
        Console.WriteLine(string.Join(", ", items.Distinct(new KeyComparer<string, char>(s => s[0]))));
    }
}

Yes, now we have a common solution to make a set with unique items from an input set, comparing content by its property.
But, expression new KeyComparer<string, char>(s => s[0]) looks redundant. C# compiler can't infer generic type arguments for a constructor call, what increases amount of code.

Functional approach

Final step to perfection is to replace a constructor call with something else, or wrap it into something.
An obvious solution -- to wrap in into a DistinctBy function. Compiler will easily infer generic type arguments, we don't even need to think anymore.

static class EnumerableExtensions
{
    public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector)
    {
        return source.Distinct(new KeyComparer<TSource, TKey>(keySelector));
    }
}

And, updated Main method :

static void Main()
{
    var items = new[] { "Peter", "Albert", "John", "Jim", "Pavel", "Robert"};
        Console.WriteLine(string.Join(", ", items.DistinctBy(s => s[0])));
}

Conclusion

Same approach may be used in many other cases. It keeps code simple, and does not repeat already existing one.
Also, we found today one more evidence that static functions are better, than constructors. If you did not read yet my article about that -- you may read it.

That's all for today. Thanks for reading this article, would be nice to read your thoughts in comments.

Modern Java - do we need explicit class declarations?

Taqmuraz — Sun, 31 Dec 2023 15:10:39 +0000

When we develop a public API, we hope it will live long or forever.
Do we? Then why do we still write and use public constructors? They do not present any abstraction. Once you mentioned in your code some constructors, you nailed them to your program for eternity.

In this article I will explain, how to create objects in a better way, without declaring constructors or classes explicitly.

We need to write a program

Now, let us imagine we want to write a program that would paint the following image :

Let us write code then.
First, we have to declare common abstractions.

import java.awt.Graphics2D;
interface Drawing
{
    void draw(Graphics2D graphics);
}

Good enough.
Now we may write a code that uses our Drawing interface to paint something into image :

static BufferedImage paint(int width, int height, Drawing drawing)
{
    var image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
    drawing.draw((Graphics2D)image.getGraphics());
    return image;
}

After that, we need an implementation for a circle drawing :

import java.awt.Graphics2D;
import java.awt.Point;
import java.awt.Color;
class Circle implements Drawing
{
    Point center;
    int radius;
    Color color;
    Circle(Point center, int radius, Color color)
    {
        this.center = center;
        this.radius = radius;
        this.color = color;
    }
    @Override
    public void draw(Graphics2D graphics)
    {
        graphics.setColor(color);
        int dr = radius << 1;
        graphics.fillOval(center.x - radius, center.y - radius, dr, dr);
    }
}

Now a box drawing :

import java.awt.Graphics2D;
import java.awt.Color;
import java.awt.Rectangle;
class Box implements Drawing
{
    Rectangle rect;
    Color color;
    Box(Rectangle rect, Color color)
    {
        this.rect = rect;
        this.color = color;
    }
    @Override
    public void draw(Graphics2D graphics)
    {
        graphics.setColor(color);
        graphics.fillRect(rect.x, rect.y, rect.width, rect.height);
    }
}

As we see, our paint method does accept only one Drawing object, so, we need an implementation that would combine many drawings into one :

class Scene implements Drawing
{
    Drawing[] drawings;

    Scene(Drawing... drawings)
    {
        this.drawings = drawings;
    }

    @Override
    public void draw(Graphics2D graphics)
    {
        for(var drawing : drawings) drawing.draw(graphics);
    }
}

And, all we have left is to write the main function :

public static void main(String[] args) throws Throwable
{
    var file = new File(args[0]);

    int width = 200;
    int height = 200;

    var drawing = new Scene(
        new Box(new Rectangle(0, 0, width, height), Color.WHITE),
        new Circle(new Point(100, 100), 50, Color.RED),
        new Box(new Rectangle(25, 25, 100, 50), Color.GREEN));
    var image = paint(width, height, drawing);
    ImageIO.write(image, "png", file);
}

It took 85 lines of code. This code is flexible, maintainable, readable. But, don't you see its redundant parts? Almost 30% of lines are about fields and constructors declaration.
Also, we have repeated code here : Graphics2D.setColor calls.
How may we improve this code?

Static functions are better than constructors

What constructor is? A function, that we call to create a new object. Wait...a function, that we call to create a new object...do we need constructors at all?

Java has a brilliant syntaxes - anonymous class expression and lambda expression. Using such expressions we may write code without declaring any classes.

What we are going to do

Here is an example :

interface FloatFunction
{
    float apply(float a);
}
class SumFloatFunction implements FloatFunction
{
    float addition;
    SumFloatFunction(float addition)
    {
        this.addition = addition;
    }
    @Override
    public float apply(float a)
    {
        return a + addition;
    }
}

Let us replace class declaration with a static function declaration inside of the FloatFunction interface :

interface FloatFunction
{
    float apply(float a);

    static FloatFunction sum(float addition)
    {
        return a -> a + addition;
    }
}

Do you see, how small our code now is?
More than that, now we may see all FloatFunction interface implementations available - we don't have to read documentation each time to refresh information about existing implementations. All what we need is declared in the one place.

Using our new approach, let us change solution with Drawing interface.

interface Drawing
{
    void draw(Graphics2D graphics);

    static Drawing box(Rectangle rect, Color color)
    {
        return graphics ->
        {
            graphics.setColor(color);
            graphics.fillRect(rect.x, rect.y, rect.width, rect.height);
        };
    }
    static Drawing circle(Point center, int radius, Color color)
    {
        return graphics ->
        {
            graphics.setColor(color);
            int dr = radius << 1;
            graphics.fillOval(center.x - radius, center.y - radius, dr, dr);
        };
    }
    static Drawing scene(Drawing... drawings)
    {
        return graphics ->
        {
            for(var drawing : drawings) drawing.draw(graphics);
        };
    }
}

And main function also has changes :

public static void main(String[] args) throws Throwable
{
    var file = new File(args[0]);

    int width = 200;
    int height = 200;

    var drawing = Drawing.scene(
        Drawing.box(new Rectangle(0, 0, width, height), Color.WHITE),
        Drawing.circle(new Point(100, 100), 50, Color.RED),
        Drawing.box(new Rectangle(25, 25, 100, 50), Color.GREEN));
    var image = paint(width, height, drawing);
    ImageIO.write(image, "png", file);
}

Looks much better? Right. And that was only a first step.

Methods with default implementation

As I said earlier, I don't like we have Graphics2D.setColor calls repeated. If we would paint 1000 boxes of the same color, do we need to call setColor method 1000 times? No.

What then we may do?

Let us create a wrapping function, that will change color as many times as we need :

default Drawing ofColor(Color color)
{
    return graphics ->
    {
        graphics.setColor(color);
        draw(graphics);
    };
}

And, we are going to change Drawing static functions as well, because now they have no business with Color.

interface Drawing
{
    void draw(Graphics2D graphics);

    static Drawing box(Rectangle rect)
    {
        return graphics ->
        {
            graphics.fillRect(rect.x, rect.y, rect.width, rect.height);
        };
    }
    static Drawing circle(Point center, int radius)
    {
        return graphics ->
        {
            int dr = radius << 1;
            graphics.fillOval(center.x - radius, center.y - radius, dr, dr);
        };
    }
    static Drawing scene(Drawing... drawings)
    {
        return graphics ->
        {
            for(var drawing : drawings) drawing.draw(graphics);
        };
    }
    default Drawing ofColor(Color color)
    {
        return graphics ->
        {
            graphics.setColor(color);
            draw(graphics);
        };
    }
}

Then code that creates many boxes of the same color would look like that :

static Drawing manyBoxes(Color color, Rectangle... rects)
{
    var boxes = Stream.of(rects).map(Drawing::box).toArray(Drawing[]::new);
    return Drawing.scene(boxes).ofColor(color);
}

Conclusion

I don't propose to always avoid use of classes. We may need them to describe data structures or program entries. But, anywhere else, I would like to use lambda or anonymous class expressions only.

After all, functions let us to decouple from a real program structure and to forget about exact implementation. You can't redirect a constructor call, but you can redirect a function call.
When you develop a large product, you can't rename class or change its accessibility, if it had once a public constructor. Give self more comfort and space, use functions instead of constructors.
That's all for today, thanks if you read this article to the end.
Please, share your thoughts in comments.