Ragmaanir's Blog

Ghost Logic

2025-06-06T02:00:00+02:00

Ghost Logic is dead or unnecessary code that leads the reader to make false assumptions about values and states.

An example is better than a thousand words:

def recalculate_score(age : Int32?, iq : Float32, wealth : Money?) : PersonalScore
  return PersonalScore.UNKNOWN if !age
  return PersonalScore.UNKNOWN if !money

  if(age < 18)
    return PersonalScore.CHILD
  end

  if(iq > 200)
    Log.info { "Unusual IQ: #{iq}" }
    return PersonalScore.OUTLIER
  end

  age_factor = (1 / (age - 18))

  # the formula is not important for the example
  PersonalScore.new(age_factor * iq / 100 + Math.log(wealth.amount))
end

Ignore the formula for the score. The point is this: What if the system only handles people 18+, every person has an age, all IQs are normalized to be lower than 200 and every person has a money amount set? All of the if-statements are now effectively dead code (without the compiler knowing). But this is not obvious to the reader that is not familiar with the entire system / code-base. The reader starts making assumptions from reading the conditions:

It looks like there are people without known age
It looks like it is possible for children (age < 18) to be in the system
It looks like there might be people with IQ > 200
It looks like there might be people with an unknown amount of money

This is ghost logic. The worst thing is that this ghost logic can spread throughout the code base. The programmer learns the ghost logic from this method and later does modifications in other parts of the program. He notices that those special cases above were not handled and adds logic for that into other places, even in tests. The ghost logic spreads kinda like a meme or a myth.

The ghost logic is more likely to spread if the logic is:

very believable
hard to debunk

E.g. the parameters for recalculate_score might be deserialized from a queue made up of JSON messages. Then there is no easy way to use tooling to check for possible values and where they might come from. In addition, the values might be exceptionally rare, so you might not see them during testing.

The Ultimate Martyr

2023-07-05T02:00:00+02:00

Jesus was not really a martyr. His sacrifice was small. Here is the Ultimate Martyr.

Jesus Did Not Die

When you “die”, but then you actually go to heaven, that’s not “dying”. You are just being teleported to a different place. Therefore Jesus isn’t really a martyr. Not just that. He is teleportet to heaven, which by definition is a better place than earth. So it isn’t really a sacrifice. The only thing that you can count in his favor is the torment that he endured while on earth.

The Ultimate Martyr

Infants go to heaven when they die or are killed. If they grow up, there is a chance that they could end up in hell. So the ultimate martyr would deliberately kill infants to guarantee that they end up in heaven (possibly baptizing them first, depending on the myth you subrscribe to). For killing the infants, the ultimate martyr would go to hell as an eternal punishment. So, this martyr sacrifices his possible place in heaven for a definite place in hell in order to guarantee a place in heaven for all the infants he kills. Therefore, he is the Ultimate Martyr.

Java Teaches Bad Habits

2022-09-02T02:00:00+02:00

Java is a popular programming language, but it teaches bad habits and bad OOP. Here are my reasons and opinions.

Interface Inflation

Because Java was designed without lambda functions/closures, hundreds of unnecessary single-method interfaces had to be added. E.g. all kinds of XyzListeners. If the language had lambdas from the start, these interfaces could have been replaced by simple function signatures. Instead they now haunt the standard APIs.

Naming Things In Java Is More Than Just ‘Hard’

Here are some examples that make me want to cry:

AbstractCookieValueMethodArgumentResolver
AbstractEncoderMethodReturnValueHandler
RequestMappingInfoHandlerMethodMappingNamingStrategy
TimeoutDeferredResultProcessingInterceptor
TransactionalApplicationListenerMethodAdapter

These are straight from the spring framework. These kind of naming patterns seem to be very common in Java in general. I rarely see similar patterns in other languages. Why is that?

I think there are multiple reasons to this:

Unique Names and Packages
General Verbosity

Unique Names and Packages

First of all, package names are horribly long. Everything starts with the domain. This makes the navigation in the project tree annoying too. But the big problem is:

In other languages we would have something like Server.Context.Factory. We would be able to nest classes or namespaces inside other classes or namespaces. And then we would be able to import Server.Context.Factory as Factory or give it an alias in the case that there is another imported type Factory. In Java though, you can not import two types with the same name. This means there are basically two options. Either you give the classes a more unique name, or you have to refer to the class using the full package qualifier. Now remember that package names are generally really long. This creates pressure to create long unique class names.

Technically, you could use nested static classes. This is actually really useful. E.g. using User.Id instead of UserId. One drawback and limit of this approach though is that a nested static class has to be in the same file as the outer class. So you can’t have dozens of nested classes in the same outer class because it makes the file unreadable.

General Verbosity

Java is extremely verbose in general compared to other languages (e.g. crystal, ruby, kotlin). The verbosity kicks in on every level, e.g. the language constructs, the APIs, the build process (XML), package names. Death by a thousand cuts.

A lot of classes are only necessary because of shortcomings of the language. Those classes dont even exist in other languages because they are just not needed. Suffixes like Handler, Holder, Resolver, … are often indicators of that. In addition, many architectural design decisions are only necessary in Java.

Many statements are overly verbose and complex too. Just look at the Stream-API:

var interestingCustomers = customers
  .stream()
  .filter(c -> c.getMoney() > 100000)
  .collect(Collectors.toList()); // in later java versions: .toList()

Compare that to ruby/crystal:

interesting_customers = customers.select { |c| c.money > 100_000 }

And these are the simpler examples.

The java standard libraries are old, and the age is visible. Collection handling is ugly, even when using Streams and e.g. Guava. Is it Collections.xyz or Lists.xyz? Or is it in our own CollectionUtils? Or was it CollectionsHelper? Or ListUtils? When the standard library lacks fundamental everyday-features, everyone adds patchwork libraries to fill the gaps. Everyone is reinventing the missing wheels in every project, but with different names. Same problem in Javascript/Typescript. At least in JS/TS it is possible to monkeypatch some functions into the existing Arrays and Maps. No need for ArrayHelper/Utils/Whatever.

Then there are builders and fluent-interfaces. These are complete abominations too. Not just are they hard to use, they require a whole bunch of additional strangely-named classes, hierarchies and boilerplate code. Here is - i think (im not even sure) - one of those beauties related to builders/fluent interfaces:

public final class ExpressionUrlAuthorizationConfigurer.ExpressionInterceptUrlRegistry
extends AbstractInterceptUrlConfigurer.AbstractInterceptUrlRegistry<
ExpressionUrlAuthorizationConfigurer.ExpressionInterceptUrlRegistry,
ExpressionUrlAuthorizationConfigurer.AuthorizedUrl
> {
  ...
}

Other verbosity annoyances are:

Writing constructors (1)
Getters and setters (1)
Repeating types as well as lots of modifiers
Statements not being expressions
Lack of default arguments and named parameters (causing lots of boilerplate overloads; and often overload-variants are missing)
Variables captured in closures required to be effectively final
Having to use equals instead of overloading ==
No operator overloading, which makes types like BigDecimal annoying to use
Lack of Map-literals
Boxing/Unboxing
Probably a lot more …

(1) Lombok and records help, but both have their own limitations (naming of getters, ability to use inheritance and call super)

And of course, there is the lack of null-safety. You can try to make things null-safe by using @NonNull from Lombok (different than @NotNull). But this means you have to add annotations everywhere. More boilerplate. Plus, if you start using @NonNull in e.g. a method, then you have to be consistent and mark everything that should not be nullable as @NonNull. You can’t just add @NonNull to one parameter that you are certain should never be null. The existence of one @NonNull implies that all other parameters without this annotation are supposed to be nullable.

And in addition there is Optional. Lots of different incomplete solutions for one problem.

In languages like crystal, everything is non-nullable by default. Declaring something as nullable is just:

class Point
  getter x : Int32? # same as Int32 | Nil
end

Bloated Dependency Injection

Dependency injection is fine, usually. Just not in Java. I am not a programming-language historian, so i might be wrong here. But my impression is this: One of the main reasons for the push for heavy dependency injection in Java was that testing was difficult or even impossible without it. You could not easily swap out a component for a fake-component in tests, unless you used very general dependency-injection solutions.

The problem is that this turned into a “we need DI for everything”-thinking. Whats with all the crazy and confusing annotations? Where the hell are my instances being injected from? Often it is really hard to follow the crazy DI injection flow. I wish people would just instantiate the simple stuff with new and pass in parameters. Do people even inject different objects? Often that is not the case. YAGNI.

Date And Time API Labyrinths

Dates and Times were always a mess in Java. Here are some of the classes related to time handling:

Date
Time
Instant
Timestamp
LocalDate
LocalTime
LocalDateTime
ZonedDateTime
OffsetTime
OffsetDateTime
TimeZone
ZoneId
ZoneOffset
Period
Duration
Calendar
Clock
TemporalField
TemporalUnit
TemporalAmount
TemporalQuery
TemporalAdjuster
TemporalAccessor

These are just the classes. Each of those classes has a bunch of methods.

Documentation

Is the java documentation good? In my experience: no. This has multiple reasons.

Unnecessary Complexity: Since Java code is generally more verbose and unnecessarily complicated, it naturally needs more documentation from the start. In other languages, you can often just look at the implementation to figure out what a method does. In Java you usually go down a rabbit-hole of crazy AbstractBaseFilterChainInterceptorSupervisorFactory (can you tell from the name whether this is a real class or i just made it up?).
Difficult Concepts: You will often find classes that are hard to understand. The name does not really give much away. In addition, the class is embedded in an even weirder class-hierarchy. These classes typically exist to work around some shortcommings of java, to make things injectable or to adhere to some interface. These classes are often so abstract and nebulous, that they are hard to even describe - and therefore hard to understand and document.
Fake Documentation: A lot of the Javadoc documentation is kinda fake. It just repeats parameters and return types as well as class-hierarchies. That is not real documentation. What is the purpose of this class? What exactly does parameter config do? What (unchecked) exceptions will be thrown, and when?

Existing Libraries

As a popular and old language, Java has a lot of libraries. This is true. Unfortunately, a lot of these libraries are … no that great.

One example is WebClient:

var result = client.post()
    .uri(new URI("https://example.com/post"))
    .body(BodyInserters.fromFormData(values))
    .retrieve()
    .bodyToMono(Result.class)
    .block();

Of course, a builder is involved. And you have a new strange terminology like retrieve/exchange and Flux/Mono.

Compare this to crystal:

response = HTTP::Client.post("http://example.com/messages", body: "Hello!")
response.status_code #=> 200
response.body #=> "..."

How many hidden and unintentional bugs fit in the former example and how many in the latter?

New Features

Java has been adding lots of features like the var keyword, new methods to String and other standard classes, default methods for interfaces (kinda like mixins), record-classes, pattern-matching, multiline string literals, … These features might look great for someone who wasn’t used to them. But in my opinion, it’s just lipstick on a pig. And why wait for these features to be introduced step-by-step and only half-complete when you can use more modern languages like kotlin?

Even the new and shiny features are poisoned (often due to backwards-compatibility) by having lots of caveats and limitations. Take switch-expressions: Are null-values allowed in the switch? How many different variations are there? Plus, all of these different variations will now probably linger in java libraries for the next 20 years.

Conclusion

The intention of this post is not to degrade other peoples work. I know that a lot of smart people are working on all these things, be it the language itself or libraries and applications. And i don’t want to pretend like i am the super-smart developer who has it all figured out. But i need to point out that - in my opinion - there are a lot of really deep flaws in Java that lead people (me included) to write really bad code. A messy language makes you write messy code and come up with messy solutions.

I even think that the main pushback against OOP that we can observe in developer communities from time to time, comes from witnessing Java code.

I do not have a simple solution to these problems that exist in Java. Maybe just use Kotlin instead if possible?

Keyboard Improvements

2021-03-03T01:00:00+01:00

Typing is an important part of programming. Regular keyboards are oversized and have horrible layouts. These are my thoughts about improvements regarding keyboard layout, keybindings, timings etc.

How I Type

I do not acutally type much. And I type in bursts.
I do not have and never had RSI.
I did never type with 10 fingers. I have some weird typing behaviours. I jump around the keyboard with both hands and mainly use three fingers on both hands to type. With my newer GergoPlex keyboard this might change though.
I have used the same keyboard for about 15 years (Trust KB-1800S Slimline).
I play computer games (Strategy like Oxygen Not Included and Factorio, but also FPS like Natural Selection 2, Team Fortress 2, Left 4 Dead 1 & 2, …).
I am of average body size (height and weight) and have no particularly broad shoulders or other attributes that might tilt my keyboard preferences to more exotic builds/layouts.
I do not worship mechanical switches. My Trust Slimline keyboard with scissor-switches served me very well for 15 years.
Functionality first! I do not care about the color of my keyboard, the LED lighting, typing noise, stickers, “funny” keys, brands or other irrelevant crap. I want to emphasize this once more: If it does not serve a purpose - i do NOT care! I even dislike features if they do not serve a purpose.
I do not use many keyboard shortcust (especially not complicated ones like shift+ctrl+alt+9).

Why Standard Keyboards Are 💩

Generally, standard keyboards are too big and use keys inefficiently. E.g. programming related keys like Arrows/Pos1/End/Backspace are positioned badly. And you can’t really change the keybindings. You would have to resort to some weird linux-keybinding configuration files that are annoying to research/write/read. And they only work under linux. Also, most mechanical keys are annoying because they are too tall.

QMK

With QMK you can write firmware for your qmk-capable keyboard. Unfortunately, the project is in C and is therefore horrible to read and write. Lots of strange macros and weird namings for everything. Nevertheless, you can basically implement a program that reacts to keypresses and then sends keycodes to your computer. This gives you a lot of flexibility. You can implement any keybindings, key-combinations and key-sequences. You can control the timing too.

Gaming vs Writing

I dont think i would use the same keyboard for gaming and writing. In gaming i do not need a tactile feedback for WASD. And most other game-action keys dont need it either. Im slamming them hard anyway. For programming though, a tactile feedback could be helpful to confirm that you actually pressed the key. But if the tactile feedback makes the keypress a little slower (mechanically), I am not sure it would be worth it.

Simplifying The Keyboard

Here are some things you find on a standard keyboard that can be simplified:

Arrow keys: As a programmer you spend maybe half the time typing text and half the time navigating in the code. Jumping between letter-keys and arrow-keys (as well as Pos1/End/Backspace/…) is annoying.
Num-Block: Why? The only actually good reason for the Num-Block i know is, that typing numbers on it can be faster than typing the numbers on the spread-out number-row above the letters. This is actually a good reason IMO. But you do not need an extra Num-Block for that. Especially when you hardly ever use that block.
Caps-Lock: No thanks!
Duplicate Keys: Several keys are kinda duplicated. Numbers, Alt/Ctrl/Shift
Weird keys: ´`^°

My Keyboard And Layout

I use the GergoPlex. I probably would like the Centromere-Mini more though. My criticism for the GergoPlex are:

The middle key of the thumb keys takes too much space. It should be oriented like the rightmost of the thumb keys. This would make it easiert to reach the different keys with the thumb. The Centromere Mini got this correct.
Wireless: A battery is a smaller annoyance than handling the cables. The Centromere Mini got this correct.
The keys are a tad too light to press. And there is no tactile feedback that the key was pressed.

Here are my layers for the GergoPlex (see Github). I didnt push my newest changes though.

Symbols/Keys:

👉: Tap vs hold: When tapped, write key, when held, goto layer
👇: Currently pressed key
Green background: Switch to layer when held down
⇧: Shift
⇤/⇥/↵/↹: Pos1/End/Enter/Tab
⌫⌦: Backspace/Del
❖: Windows key
WHU/WHD: Mouse Wheel Up/Down

Default [writing]

☐	w	e	r	t
👉a	s	d	👉f	👉g
☐	x	c	v	b
░	░	M5	M1	M3

z	u	i	o	☐
h	j	k	l	y
n	m	q	p	☐
⇧	M2	M4	░	░

M1 [text navigation]

pause	☐	space	☐	esc
☐	↹	☐	↵	❖
☐	⇧↹	☐	☐	☐
░	░	☐	👇M1	☐

☐	⌫	▲	⌦	☐
⇤	◀	▼	▶	⇥
☐	↤	☐	↦	☐
⇧	ctrl	☐	░	░

M2 [symbols]

&	\|	_	=	:
!	,	.	-	*
?	;	\	+	/
░	░	☐	☐	ctrl

$	[	]	<	#
"	(	)	>	%
‘	{	}	@	^
☐	👇M2	☐	░	░

M3 [numbers]

☐	.	0	,	☐
1	2	3	4	☐
☐	☐	☐	~	☐
░	░	☐	☐	👇M3

☐	⌫	9	☐	☐
↵	5	6	7	8
☐	☐	☐	☐	☐
⇧	ctrl	alt	░	░

a [shortcuts like ctrl+c]

☐	☐	☐	r	t
👇a	☐	☐	c	v
☐	☐	☐	☐	☐
░	░	☐	☐	☐

a	n	s	o	☐
p	☐	x	z	y
☐	f	☐	☐	☐
⇧	☐	☐	░	░

f [mouse]

☐	☐	☐	☐	☐
☐	☐	☐	👇f	☐
☐	☐	☐	☐	☐
░	░	☐	☐	ACL

WHU	MMB	▲	☐	☐
WHD	◀	▼	▶	☐
☐	☐	☐	☐	☐
RMB	LMB	☐	░	░

g [function-key]

☐	☐	☐	☐	☐
☐	☐	☐	☐	👇g
☐	☐	☐	☐	☐
░	░	☐	☐	☐

F1	F2	F3	F4	F5
F6	F7	F8	F9	F10
F11	F12	☐	☐	☐
⇧	ctrl	☐	░	░

s [navigation (TODO)]

☐	☐	☐	☐	alt+f4
☐	👇s	☐	☐	☐
☐	☐	☐	☐	☐
░	░	☐	☐	☐

ctrl+q	☐	alt+↹	☐	☐
☐	❖	☐	esc	☐
☐	☐	☐	☐	☐
☐	☐	☐	░	░

M5 [rare symbols]

☐	☐	☐	☐	☐
☐	☐	☐	☐	☐
☐	☐	☐	☐	☐
░	░	👇M5	☐	☐

€	~	§	´	`
☐	☐	☐	☐	☐
☐	☐	☐	☐	☐
☐	☐	☐	░	░

What I Want And What I Am Working On

Want: Keycaps that are not completely flat. Some keys should have a haptic marker on top so it is easy to feel when you misplaced your fingers.
Working on: Key-specific delay and repeat speed. Arrow keys should have a low delay and high repeat speed. Characters on the other hand should have a somewhat higher delay and lower repeat speed. Typing aaaaaaaa is usually an accident.
Want: Smaller thumb keys that are a little closer together and have different haptic surface to distinguish them.

The Argument From Fine-Tuning

2017-11-25T22:05:00+01:00

William Lane Craig often presents the fine-tuning argument: The values of the fundamental constants are fine-tuned, because if they would differ just by a tiny fraction, life would not exist.

The argument in detail:

If the fundamental constants of the universe (e.g. the gravitational constant) would differ by just a tiny fraction, life would not be possible
Life exists and therefore the constants all have special values
Special values are unlikely
Unlikely things are fine-tuned
Fine-Tuned things can only be explained by a creator
The universe as-is is unlikely (from 2 and 3)
Therefore the universe is fine-tuned (from 4 and 6)
Therefore the universe has a creator (from 5 and 7)

There are multiple counter arguments:

On (1):

Where does “tiny fraction” start? When would a fraction not be classified as “tiny”?
Every interval in the real numbers has uncountably infinite values, so the possible interval for life-containing universes has the same amount of possible values as any other interval (like -infinity..+infinity). So the classification of “tiny” does not really make sense.

On (3):

Given an uniform/even distribution of values for the constants (any real number has the same probability), it follows that every value is unlikely, whether a special value or a regular value. Even every finite interval is unlikely (improper prior).

On (4):

The event “1 million radioactive atoms in 1 m³ decay at the same time” is very unlikely. Does that mean that it is fine-tuned? Rolling a dice a thousand times with only sixes is unlikely. Does that mean it was fine-tuned?

On (5):

I do not accept that without further proof. Wouldn’t the fine-tuning argument apply to the creator too?

Here are more general arguments:

Why is it only allowed to vary the constants of physical formulas? Why not exponents? Why can’t one make up completely new formulas, particles, fields, …?
What about zero as a value for a constant? This can eliminate a physical force. This has a very interesting implication: If zero is allowed as a value for a constant, then there could be infinitely many other physical laws which constants just happen to be zero in our universe.
There is a hidden assumption in the proof: No other universes exists.

Problem Graphs

2016-12-07T01:00:00+01:00

A problem graph is a directed, irreflexive graph that is used to model the relationships between problems and their solutions.

This is a relatively simple example:

What this graph models is basically that the problem Spamming can be prevented by using Captchas. But Captchas in turn introduce a UX problem since the user is annoyed with extra input fields.

A graph like this is bipartit, since a solution only causes problems and a problem can only be fixed by a solution.

This graph shows two other properties one should be aware of:

On the left we have the Problem A which has two solutions B and C. The important thing here is that those two solutions are alternatives. While on the right we have a solution X which causes two problems Y and Z. Here the two problems are caused simultaneously and have both to be solved.

The following graph shows a dilemma:

It is the simplest version of a dilemma. A dilemma is basically a cycle in the graph. But this example is actually a bad one, because a solution for a problem that causes the same problem again is not actually a real solution. So here is a better example of a dilemma.

As one can see, we have a cycle in the graph, which is a requirement for a dilemma. There is one catch though:

Even though this graph contains a cycle, it does actually not fall prone to a dilemma. There is a cycle, but since solutions are alternatives, one can pick solution S3 which is not part of the cycle. So this graph contains a dilemma, but when trying to calculate a working solution for problem P1 it would result in S3.

Purpose

When looking at these simple graphs it seems a little stupid to create a graph since you can reason about this stuff in your head. But when the graph grows bigger and the interdependencies between problems and solutions become overwhelming, it is good to have a data structure and some algorithms to tackle the bigger graphs.

Extensions

The graphs above only display dichotomous relations, meaning that a solution either causes a problem - or - it does not. In real situations this is often not the case. Instead a solution might cause a problem with certain strength or weight. E.g. long loading times of the homepage can be addressed by several counter-measures and optimizations with different effectiveness. One also could factor in costs of problems and solutions (time, money, human resources, occupied equipment, …).

WHU	MMB	▲	☐	☐
WHD	◀	▼	▶	☐
☐	☐	☐	☐	☐
RMB	LMB	☐	░	░

WHU	MMB	▲	☐	☐
WHD	◀	▼	▶	☐
☐	☐	☐	☐	☐
RMB	LMB	☐	░	░

WHU	MMB	▲	☐	☐
WHD	◀	▼	▶	☐
☐	☐	☐	☐	☐
RMB	LMB	☐	░	░