4 ms·

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people. To be honest, writing a jpeg decoder in C seems easier and more natur

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people. To be honest, writing a jpeg decoder in C seems easier and more natural than doing it in python.

userbinator 6y ago
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.
- a_t48 6y ago
  Python also lets you read bytes off the stream directly.
- smabie 6y ago
  Using Haskell and a parser combinator would probably be the easiest
  - enriquto 6y ago
    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.
    - eru 6y ago
      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 https://github.com/GregRos/parjs I just found a parser combinator library for Python https://pypi.org/project/parsita/ https://pypi.org/project/parsita/ But it looks like they have to abuse some Python magic to make the code readable.
      - enriquto 6y ago
        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?
        eru 6y ago
        No. But the author of the original comment mentioning Haskell https://news.ycombinator.com/item?id=23841865 https://news.ycombinator.com/item?id=23841865 might have had?
- eru 6y ago
  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.
pansa2 6y ago
If you’re trying to describe a file format or algorithm in the most accessible way, wouldn’t pseudocode be the best thing to use? If that’s not an option (because you want the code to be executable), I think Python is the closest popular language to pseudocode.
- kerkeslager 6y ago
  I think being executable is really key, because one way I check my understanding of code is to make modifications to the code and see if they do what I expect them to do.
  - pansa2 6y ago
    IMO the ideal setup would be for an article to contain pseudocode and to have supplementary executable code. This would allow the article to explain concepts without boilerplate and unnecessary details, but also ensure that those details are available for readers who wish to investigate further. I still think it's an advantage to write the executable code as close to pseudocode as possible. There is further discussion of pseudocode vs executable code at https://academia.stackexchange.com/q/140986 https://academia.stackexchange.com/q/140986.
    - kerkeslager 6y ago
      So, what elements of Python do you consider boilerplate? I say this not as someone defending Python, but as someone writing a programming language.
      - smabie 6y ago
        Lack of function currying and anonymous function arguments. Also having to explicitly convert a zip, map, etc to a list. Also the lambda keyword.
        kerkeslager 6y ago
        Hmm, I think you're using the word "boilerplate" differently than it is usually used. The changes you're proposing are functional changes that can't be transparently applied by a compiler/interpreter without changing behavior. Currying is a subset of partial application, which Python supports via the standard library. Universal currying would be terser in some situations, but it conflicts with Python's args/kwargs implementation. Frankly, I don't think currying is a good thing even in languages such as Haskell where it doesn't conflict, as it makes it much less clear what the flow is when functions can be called with different signatures. Anonymous function arguments, I'm just not sure what you're talking about there. Explicitly converting higher order function results to lists is not boilerplate, it's a meaningful difference. The explicit conversion allows you to determine when code is actually executed, instead of having it executed eagerly. Universal lazy application like in Haskell has broader implications which are generally negative, particularly with regards to performance and being able to reason about execution: production Haskell often turns this off, and for good reason. The lambda keyword is arguably boilerplate, but I'm skeptical of whatever alternate syntax you're proposing there. C#-style anonymous functions wouldn't work with Python syntax. If you're proposing people use the λ symbol, I'm going to frankly say that's a bad idea, because most developers' keyboards don't have that symbol. Like it or not, English with a latin keyboard is the lingua franca of software--if you want to target another language that would be reasonable, but that's a big choice with broader implications.

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people. To be honest, writing a jpeg decoder in C seems easier and more natural than doing it in python.

userbinator 6y ago

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.

a_t48 6y ago
Python also lets you read bytes off the stream directly.
smabie 6y ago
Using Haskell and a parser combinator would probably be the easiest
- enriquto 6y ago
  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.
  - eru 6y ago
    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 https://github.com/GregRos/parjs I just found a parser combinator library for Python https://pypi.org/project/parsita/ https://pypi.org/project/parsita/ But it looks like they have to abuse some Python magic to make the code readable.
    - enriquto 6y ago
      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?
      - eru 6y ago
        No. But the author of the original comment mentioning Haskell https://news.ycombinator.com/item?id=23841865 https://news.ycombinator.com/item?id=23841865 might have had?
eru 6y ago
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.

pansa2 6y ago

If you’re trying to describe a file format or algorithm in the most accessible way, wouldn’t pseudocode be the best thing to use? If that’s not an option (because you want the code to be executable), I think Python is the closest popular language to pseudocode.

kerkeslager 6y ago
I think being executable is really key, because one way I check my understanding of code is to make modifications to the code and see if they do what I expect them to do.
- pansa2 6y ago
  IMO the ideal setup would be for an article to contain pseudocode and to have supplementary executable code. This would allow the article to explain concepts without boilerplate and unnecessary details, but also ensure that those details are available for readers who wish to investigate further. I still think it's an advantage to write the executable code as close to pseudocode as possible. There is further discussion of pseudocode vs executable code at https://academia.stackexchange.com/q/140986 https://academia.stackexchange.com/q/140986.
  - kerkeslager 6y ago
    So, what elements of Python do you consider boilerplate? I say this not as someone defending Python, but as someone writing a programming language.
    - smabie 6y ago
      Lack of function currying and anonymous function arguments. Also having to explicitly convert a zip, map, etc to a list. Also the lambda keyword.
      - kerkeslager 6y ago
        Hmm, I think you're using the word "boilerplate" differently than it is usually used. The changes you're proposing are functional changes that can't be transparently applied by a compiler/interpreter without changing behavior. Currying is a subset of partial application, which Python supports via the standard library. Universal currying would be terser in some situations, but it conflicts with Python's args/kwargs implementation. Frankly, I don't think currying is a good thing even in languages such as Haskell where it doesn't conflict, as it makes it much less clear what the flow is when functions can be called with different signatures. Anonymous function arguments, I'm just not sure what you're talking about there. Explicitly converting higher order function results to lists is not boilerplate, it's a meaningful difference. The explicit conversion allows you to determine when code is actually executed, instead of having it executed eagerly. Universal lazy application like in Haskell has broader implications which are generally negative, particularly with regards to performance and being able to reason about execution: production Haskell often turns this off, and for good reason. The lambda keyword is arguably boilerplate, but I'm skeptical of whatever alternate syntax you're proposing there. C#-style anonymous functions wouldn't work with Python syntax. If you're proposing people use the λ symbol, I'm going to frankly say that's a bad idea, because most developers' keyboards don't have that symbol. Like it or not, English with a latin keyboard is the lingua franca of software--if you want to target another language that would be reasonable, but that's a big choice with broader implications.