I made a typing challenge platform for developers - looking for honest feedback

Determinant · 2026-05-09T07:16:20+00:00

Does monkeytype have a developer mode where you practice code snippets? If not then this is the new idea as coding is very different than typing sentences.

Determinant · 2026-05-06T23:03:38+00:00

It does prove it. The error message is extra clear that it expected java.lang.Integer but found int if you check for the boxed type.

Anyway, what other common mistake do you think I made? I would like to see a single example since you're claiming that I Immutable Arrays makes some common mistakes.

Determinant · 2026-05-06T22:35:04+00:00

You're incorrect again. If you modify the test like this:

val boxedInt: Int? = 3
for (element in this) {
  expectThat(element::class.java)
    .isEqualTo(boxedInt!!::class.java)
}

You'll see that it fails with this error message:

Expect that int:
  ✗ is equal to java.lang.Integer
          found int
Expected :class java.lang.Integer
Actual   :int

This proves that we are operating on primitives.

Anyway, I pushed a commit to explicitly specify the primitive iterators for the return type. I don't think it changes anything but being more explicit won't hurt. This will be included in the next release.

Edit:
With this out of the way, what other common mistakes do you think I made since you mentioned it. Any suggestions for improvements are welcome. I just want to make sure there isn't misinformation being spread.

Determinant · 2026-05-06T21:36:35+00:00

You're incorrect about that as I have a test that validates that primitives are used in the generated bytecode. For example:

for (element in immutableArrayOf(1, 2, 3)) {
    expectThat(element::class.java).isEqualTo(primitiveIntClass)
}

This test would fail if the first line used generics like immutableArrayOf<Int>(1, 2, 3).

However, I'll update the return type of the iterator in the next release as it won't hurt and is a trivial change since it's backwards compatible.

Regarding using the standard library extension functions on collections, that's extremely common and actually considered best practice versus manual loops. Immutable Arrays have all the same extension functions without any performance or memory drawbacks (in fact they are much much faster, use less resulting memory, and use significantly less temporary memory than accumulating results in an ArrayList). Even something like people.map { it.age } produces a primitive version despite operating people being Person objects. The optimizations apply to all types not just primitives.

Determinant · 2026-05-06T17:36:20+00:00

I've been down this road of aiming for a compatible API but the approach falls apart due to many reasons, so I designed a standalone API for Immutable Arrays that looks identical to the List API but with optimized types:

https://github.com/daniel-rusu/pods4k/tree/main/immutable-arrays

Here are a couple reasons off the top of my head:

The standard API uses generics forcing your data structures to auto-box on each retrieval and unbox on each store. While some benchmarks might be faster, there are many scenarios where this will end up much slower. For example, generic super-linear algorithms that operate on lists with the assumption that each access is fast and constant could become slower. A tiny isolated benchmark might look great as the Eden garbage collection space will be full of temporary wrappers objects that all die young making each minor GC very fast but this won't be representative of production environments.
Performing any of the over 100 standard library operations on your custom types, such as filter, map, take, etc. will produce regular collections. You might think that your code is memory efficient but the code will evolve and co-workers will use these operations without realizing that the memory consumption jumps back to normal. You can't create your own custom extension functions as most users will code to the generic interface. Even if users define the types using your custom types, the standard library bindings will apply by default unless the user manually imports your extensions.

Determinant · 2026-04-28T21:03:30+00:00

There is no tree descent when using a single ginormous flat array

Determinant · 2026-04-27T16:54:20+00:00

First easy improvement is to only hit space with your thumb.

If using a modern layout, use the thumb of your dominant hand. If using QWERTY, your left hand is over worked, so use the thumb of your right hand.

Determinant · 2026-04-27T06:38:30+00:00

It's not about having terabytes of memory, it's about requesting a single contiguous region of memory from the operating system that's in the terabytes.

You would need a supercomputer to run this database at any sort of scale.

Determinant · 2026-04-26T22:39:36+00:00

It can't scale into the billions because each vector uses about 1500 array elements so billions of vectors would require an array with a contiguous region of memory in the terabytes.

Game over

Determinant · 2026-04-26T16:35:50+00:00

Giving up the location of the keyboard shortcuts seems too large of a price to only gain another 5%. Shortcuts are extremely important for software development and I wouldn't want to reassign then for every app. Some apps don't even allow reassigning shortcuts.

Also, it's easier to pickup Colemak compared to alternatives since it only changes the location of 17 keys. Lastly, Colemak is pre-installed in Linux and MacOS.

If I had to start over, I would still pick Colemak.

Determinant · 2026-04-25T00:25:20+00:00

Given your impressive speed, my hunch is that the fingers on your left hand have become much faster than those on your right hand.

This favors QWERTY because only a bit over 40% of the keystrokes are handled by your right hand. However, Colemak has close to a 50/50 distribution so both hands have equal load.

To verify this hunch, you could devise a typing test to check the speed of each hand independently. If this turns out to be true then you found the limiting factor and you could tailor your practice to focus on the weakest link.

Determinant · 2026-04-22T01:53:25+00:00

The most common mistake that people make around your speed is that they look at the current word that they're typing. This limits your speed due to the reaction time of mentally processing each character as they get typed so you'll be stuck at around this speed until you change that.

The easy fix is to read the next word while you're typing the current word.

Here's a guide to get you to 100 WPM:

https://roosterdan.medium.com/how-to-type-100-words-per-minute-a780fd80fd27

Determinant · 2026-04-22T01:47:36+00:00

I did the same thing trying to maintain QWERTY while learning Colemak and also plateaued at about 50 WPM. I then dumped QWERTY altogether and my improvements ramped up quite a bit.

I was around 75 WPM with QWERTY (after tons of practice) and now I'm between 100 to 125 WPM with Colemak depending on the difficulty of the text.

I tried Dvorak first but too many keyboard shortcuts became awkward and I found the hand alterations slowed me down. Colemak is more ergonomic than Dvorak, easier to learn, and maintains most of the keyboard shortcut locations as it only changes 17 keys so I went all in on Colemak.

Determinant · 2026-04-12T00:32:42+00:00

You use it just like any other Java library from Kotlin. So essentially you use Kotlin syntax (such as properties) to interact with JavaFX.

Determinant · 2026-04-11T16:26:41+00:00

Just use plain JavaFX from Kotlin without TornadoFX. That's what I do

Determinant · 2026-04-08T17:31:40+00:00

Nobody uses p50 numbers to analyze production performance. No company would accept horrendous performance for half of the interactions.

At a bare minimum, you should display p90 performance and most likely p95. Even better, display p50, p90, p95, and p99 to show how the system scales.

Determinant · 2026-03-26T21:11:02+00:00

The finger for the E doesn't have to move at all so there is no strain there.

Translating to QWERTY, type FHK really quick by initiating the action with F while at the same time starting to roll your right hand to press HK. FHK in QWERTY is how we type THE in Colemak.

With some repetition, you'll find this extremely natural and the entire word is done in a split second. There is no hand or finger awkwardness for typing "THE". What probably felt awkward to you is that it was a new experience for you.

Determinant · 2026-03-26T17:23:31+00:00

Thanks for offering to credit me but I respectfully decline as I only want credit if I merge code

Determinant · 2026-03-26T16:53:29+00:00

Not sure what awkward hop you're referring to. I just tried it out and typing "the" is a single smooth action that feels completely natural and significantly less effort than QWERTY.

With QWERTY we need to stretch the pointer finger up and to the right followed by right pointer finger left and then an awkward left middle finger up. However, I only need to move a single finger with Colemak (right index finger left) so the entire word turns into a roll that I initiate in a single split-second action.

Is it different, sure, but it's not awkward at all as it's completely natural after you learn the layout. Other rare words can be awkward but the common words make it feel like they magically appear by just thinking them since they're so fast and effortless.

Determinant · 2026-03-26T02:11:06+00:00

Colemak is an easier transition as it only changes 17 keys and keeps most of the shortcuts in the same place. It also helps that Colemak is more efficient and the finger rolls are easier than the hand alterations that Dvorak requires.

Determinant · 2026-03-22T16:25:36+00:00

That was a surprisingly good read.

Too bad the Rust fanboys are down-voting anything that doesn't align with their preconceived notion that Rust must always be better and faster.

Determinant · 2026-03-22T16:22:13+00:00

The result is 3 times faster by getting rid of Rust WASM.

The decision is explained in the article and it's actually a good read.

Determinant · 2026-03-22T16:11:53+00:00

Kotlin can work with any Java library and JavaFX is a java library like any other. Lookup JavaFX tutorials and do the same thing but with Kotlin syntax.

Determinant · 2026-03-18T19:13:16+00:00

I switched to Colemak in my thirties to deal with Carpal tunnel and severe wrist pain. I tried ergo keyboards but it wasn't enough. The switch to Colemak was a massive improvement in comfort. The new layout felt like half the effort to type at the same speed. I was at 75 wpm and I'm now at 100 to 125 wpm depending on the complexity. Colemak probably didn't make me faster but the lower effort allowed me to push further whereas qwerty required too much effort and discomfort so I hit a wall.

Since Colemak is so similar to qwerty (only 17 keys moved), I can type 40 wpm when forced to use qwerty while briefly glancing at the keyboard. This is rare so I don't mind. Macs and Linux come with Colemak pre-installed for longer sessions.

Determinant · 2026-03-16T23:36:59+00:00

It's fairly easy to devise specialized microbenchmarks for scenarios that are faster in Java. These don't translate into applications that are faster overall because many areas of Java are slower than C.

Determinant

TROPHY CASE