Recently I started playing around more with my Neo Smartpen. The company makes their data storage format public and I wondered how long it would take me to write a program to show my handwritten pages within a simple app.
Given my background, I knew I could do this quickly in Java with a UI in Swing so I started there.
Parsing the data from the files was quick. You have a Page that consists of Strokes that is made up of Dots. Dots are the fundamental units the pen records as you write on a page. As you move the pen around it groups these dots up into strokes.
Since each bit is well defined in the spec you get a lot of code doing things like:
ByteBuffer.wrap(is.readNBytes(4)).order(order).getFloat();
to read x, y, and pressure data from the pen. While it’s a bit wordy, it works well enough.
Running the app however, was pretty slow. Pages didn’t just snap onto the screen as I would have expected. I can’t recall what exactly was the root cause of the slowness anymore, and I decided to try creating a Python version with a Gtk interface instead.
The first thing that impressed me with Python was how easily you can read structured binary data from a file using the struct module.
with open(self.filename, "rb") as file:
file_id, file_version, note_id, page_number, notebook_width, notebook_height, created_time, \
modified_time, dirty_bit, number_of_strokes = unpack('<3siiiffqqci', file.read(44))
Mind. Seriously. Blown.
What really stood out to me here wasn’t that Python can do something Java can’t. Java absolutely can. The difference is in the API design. Python’s struct.unpack gives you a clean, declarative way to describe the data and get back exactly what you need. In Java, you end up manually stitching that logic together step by step. Same capability, very different developer experience.
To be fair, this doesn’t mean Python is always faster than Java. In this case, the overall implementation ended up performing better, likely due to simpler parsing and a different UI stack, but the bigger win was how quickly and cleanly the code came together.
That’s really the takeaway.
This isn’t about Python being “better.” It’s about how much good API design matters. When you design for your user, in this case developers, you can take something complex like binary parsing and make it feel simple.
Python got that right.
Note (2026): This was written while I was experimenting more with Python. I still use it today for data processing and quick tooling, though most of my production systems lean toward Java and cloud-native services. The point here still stands—Python can be incredibly expressive for certain problems.