Hacker News Reader

Comment by userbinator | Hacker News Reader

As someone who has done it in C, I would both agree and disagree --- reading the file format will definitely be easier since C lets you pick bits/bytes/words/etc. off the stream directly, but on the other hand the high-level structures (looping, etc.) would probably be easier with Python.

Overall, seeing as OP's Python implementation is less than 300 LoC while my C implementation was closer to 750, the Python might be easier. Then again, I followed the algorithms/flowcharts in the spec, which do a faster table-based Huffman decoding than the bit-by-bit of this Python version, and also implemented arbitrary(!) chroma subsampling as the spec allows, so it's not a direct comparison.

View on HN

Python also lets you read bytes off the stream directly.

The main benefit I see here of Python over C is when your program doesn't work (yet): Python has nicer error handling built straight into the language.

If you just want to present a working implementation, both C and Python can express readable versions.

Using Haskell and a parser combinator would probably be the easiest

Easier for whom? Most programmers would not be able to follow that code. On the other hand, a really simple C or Python algorithm is more or less universally readable.

It's not so much about the algorithm, but the parsing itself.

Parser combinators give you one of the most straightforward ways to express parsers.

You are right, that the language you express your parser combinators in vs the language you express an alternative solution in also will have an impact.

You can in theory express parser combinators in Python. But it's gonna be a bit ugly, because Python has relatively clunky syntax for functions.

Some people have tried writer parser combinator libraries for eg JavaScript. See https://github.com/GregRos/parjs

I just found a parser combinator library for Python https://pypi.org/project/parsita/ But it looks like they have to abuse some Python magic to make the code readable.

Alright, but jpeg decoding is nearly all algorithm, there's almost no parsing. Do you have a particular haskell jpeg decoder in mind that uses parser combinators?

No. But the author of the original comment mentioning Haskell https://news.ycombinator.com/item?id=23841865 might have had?

Reply on news.ycombinator.com