Hacker News Reader

Comment by jrdres | Hacker News Reader

The code makes me smile, because it's nasty. This isn't like C4, a tiny but complete C compiler which does error checking on its subset. Instead, this is worse than Sector C, which takes every shortcut and just plain assumes everything in the source is right.

This "Python" just plain assumes for keywords: Any "f" is a "for [x] in range[y]" (exactly that, no other for's). Any "w" is a "while". Any "i" is an "if". Any "d" is a "def". Any "p" is a "print("

Nasty, nasty.

(Also nasty is that the code snippets in the article has more comments than the github copy of the "readable" version. You need the article to understand what's going on.)

This is a just a bit too simple for a "Tiny Python". If somebody is willing to allow a few more K's of bytes, I'd love to see at least lists & dicts here--Lisp can do them!

View on HN

As they say in TDD, write a test, then write the simplest code that will make it pass.

Clearly supporting multiple functions starting with 'p' would be overengineering.

By that standard, this is totally over-engineered. Just hardcode it.

Good idea. Write a python script, and then code the minimal c interpreter possible to make that specific script work, utilizing the script itself as string reference (and any other way one can manage to utilize it in the interpreter itself).

Someone actually testing Kolmogorov Complexity LOL

> Any "w" is a "while"

Meaning that something as simple as "w = 4" would fail? A little too nasty for my liking. Not a choice I would have made, but admire the amount of work done here and the readability of the article. And it's more human-written code than I've done in a number of months!

If you are willing to sacrifice performance, you can implement dicts via linear lookup in much less code than a proper hash table.

It’s Python, you’ve already sacrificed performance, what a little bit more?

That's the spirit!

(Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)

Are they still? I thought this project was no longer really active.

I'm not actually sure about this specific project, but people are still hard at work making CPython faster. Many of them the same people as where in this project.

Because Python dicts guarantee iteration order is the same as insertion order (https://docs.python.org/3.7/library/stdtypes.html#typesmappi...) Python dicts aren’t just proper hash tables.

Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.

I would be very surprised if my silly suggestion would speed up some standard benchmarks, because even if you do insertion only you have to do a linear probe to find duplicates.

The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they already wanted to make for other reasons.

> because even if you do insertion only you have to do a linear probe to find duplicates.

Yes, but that is almost free for the first insert and need not be much work for the second and third. Also, that naive implementation will use less memory.

The kind of benchmark I was thinking of are the “large_random” and “Kostyra” ones from https://github.com/simdjson/json_benchmark_results that parse arrays of small objects with very short keys.

For such objects, as I said, it wouldn’t surprise me _much_ if the extremely naive implementation were faster.

Reminds me of the good 'ol Apple II BASIC. You can name your variables whatever you want, but only the first two letters matter.

Two letters is luxury, when most BASIC interpreters in those days only recognised 1-letter variables.

It looks very much like some techniques used when minifying JavaScript.

Reply on news.ycombinator.com