Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding and writing a JPEG decoder in Python

yasoob.me

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Understanding and writing a JPEG decoder in Python

#41

Post by kerkeslager »

smabie wrote: post #39
kerkeslager wrote: post #37

Earlier quoted context omitted.

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 im…

How about some variation of: (x, y) -> x*y for lambdas? Scala's method for dealing with laziness through views and iterators works really well.

> How about some variation of: (x, y) -> x*y for lambdas?

Why? What problem are you trying to solve here?

That syntax is inconsistent with other syntax in Python and is harder to type (lambda gets tab-completed after typing two home-row characters).

> Scala's method for dealing with laziness through views and iterators works really well.

If you're okay with generic iterables in Scala, I'm unsure what your objection to iter types in Python is.

Re: Understanding and writing a JPEG decoder in Python

#42

Post by smabie »

kerkeslager wrote: post #41
smabie wrote: post #39

Earlier quoted context omitted.

How about some variation of: (x, y) -> x*y for lambdas? Scala's method for dealing with laziness through views and iterators works really well.

> How about some variation of: (x, y) -> x*y for lambdas? Why? What problem are you trying to solve here? That syntax is inconsistent with other syntax in Python and is harder to type (lambda gets tab-completed after typing two home-row characters). > Scala's method for dealing with laziness through views and iterators works really well. If you're okay with generic iterables in Scala, I'm unsure what your objection t…

lambda's take up too much space and are really ugly. They're visual noise and serve no purpose. Besides, the name 'lambda' is bad, and intuitive. There's a reason why no new languages have chosen 'lambda' for anonymous functions. Python:

map, filter, zip, etc should produce concrete values, not iterators. It's annoying to constantly turn iterators into lists. Like if scala's map or fold took in a list and produced an iterator, that would be super annoying. There's no point. If you want an iterator, turn the collection into an iterator. There's no reason for a function to take a list and return an iterator, unless that function is 'toIter.'

Ugly python:

    list(map(lambda x: 2*x, [1, 2, 3, 4]))
Julia:

   map(x -> 2*x, [1, 2, 3, 4])
Or even better Julia:

   2*.[1, 2, 3, 4]
I dunno, it's like Python tries its best to make code super verbose and ugly. I just don't understand why it is the way it is. It doesn't make sense.

Re: Understanding and writing a JPEG decoder in Python

#43

Post by smcl »

cgrealy wrote: post #40
smcl wrote: post #29

Earlier quoted context omitted.

Equally there are millions who don't use C or C++. I think it’s pretty fair to describe this as a "wide group of people" who would consider C or C++ inaccessible.

That’s a nonsense argument. For any given programming language, the number of people not using it outweighs the number of people using it by several orders of magnitude. It’s hard to get accurate numbers, but a quick google estimates there is roughly double the number of Python programmers than C++ programmers. I find it very difficult to imagine there isn’t some overlap there and even more difficult to imagine a com…

There is definitely a substantial number of people who know Python and have had little to no exposure to C or C++. To the point where they'd really rather see something like this presented in a language they're familiar with and that they can try out in an environment they've already got setup.

There's no harm in having many articles on a given subject (think how many monad posts there are) - if you dislike one you don't have to read it, there's plenty of other interesting stuff out there :-)

Re: Understanding and writing a JPEG decoder in Python

#44

Post by cgrealy »

smcl wrote: post #43
cgrealy wrote: post #40

Earlier quoted context omitted.

That’s a nonsense argument. For any given programming language, the number of people not using it outweighs the number of people using it by several orders of magnitude. It’s hard to get accurate numbers, but a quick google estimates there is roughly double the number of Python programmers than C++ programmers. I find it very difficult to imagine there isn’t some overlap there and even more difficult to imagine a com…

There is definitely a substantial number of people who know Python and have had little to no exposure to C or C++. To the point where they'd really rather see something like this presented in a language they're familiar with and that they can try out in an environment they've already got setup. There's no harm in having many articles on a given subject (think how many monad posts there are) - if you dislike one you d…

I don't have a problem with someone writing an article on whatever for whatever language. Go nuts.

I just think saying "articles written in C++ are inaccessible" is kinda dumb.

Re: Understanding and writing a JPEG decoder in Python

#46

Post by kerkeslager »

smabie wrote: post #42
kerkeslager wrote: post #41

Earlier quoted context omitted.

> How about some variation of: (x, y) -> x*y for lambdas? Why? What problem are you trying to solve here? That syntax is inconsistent with other syntax in Python and is harder to type (lambda gets tab-completed after typing two home-row characters). > Scala's method for dealing with laziness through views and iterators works really well. If you're okay with generic iterables in Scala, I'm unsure what your objection t…

lambda's take up too much space and are really ugly. They're visual noise and serve no purpose. Besides, the name 'lambda' is bad, and intuitive. There's a reason why no new languages have chosen 'lambda' for anonymous functions. Python: map, filter, zip, etc should produce concrete values, not iterators. It's annoying to constantly turn iterators into lists. Like if scala's map or fold took in a list and produced an…

> There's a reason why no new languages have chosen 'lambda' for anonymous functions.

Beware of people who say "there's a reason" and then don't say what that reason is.

I suspect the reason in this case is that languages which use C-ish syntax it would make no senes to have lambda as a keyword. Python doesn't use C-ish syntax, so that reason doesn't apply.

> It's annoying to constantly turn iterators into lists.

So don't. Why are you constantly turning iterators into lists?

> There's no reason for a function to take a list and return an iterator,

Here are 5 reasons:

1. There are many cases where the iterator will never be evaluated, meaning you save O(n) time.

2. Even in cases where you evaluate the iterator, you'll often have performed many transformations upon that iterator. Forcing 5 transformations all at once means you have 1 loop instead of 5, meaning again you save O(n) time.

3. It encourages writing functional code, which doesn't depend on order of execution. (This is why Simon Peyton Jones says Haskell has lazy evaluation: it keeps them honest about side effects).

4. Explicit is better than implicit. Guessing that a user will want a list is a reasonable guess, but you're doing a lot of work based on that guess, and some percentage of the time you'll be wrong. It's better to do the minimum work necessary and let the user explicitly determine what type of result they want.

5. Consistent extensibility: map, zip, etc. take lots of iterable types. You could attempt to return the same iterable type as you receive, but then there isn't an easy way for users to use zip on user-defined types. It's better to call the type's __iter__ function and then just use that, as this allows users to define higher-order functions on their own types.

Re: Understanding and writing a JPEG decoder in Python

#47

Post by smabie »

kerkeslager wrote: post #46
smabie wrote: post #42

Earlier quoted context omitted.

lambda's take up too much space and are really ugly. They're visual noise and serve no purpose. Besides, the name 'lambda' is bad, and intuitive. There's a reason why no new languages have chosen 'lambda' for anonymous functions. Python: map, filter, zip, etc should produce concrete values, not iterators. It's annoying to constantly turn iterators into lists. Like if scala's map or fold took in a list and produced an…

> There's a reason why no new languages have chosen 'lambda' for anonymous functions. Beware of people who say "there's a reason" and then don't say what that reason is. I suspect the reason in this case is that languages which use C-ish syntax it would make no senes to have lambda as a keyword. Python doesn't use C-ish syntax, so that reason doesn't apply. > It's annoying to constantly turn iterators into lists. So…

Look, functors (and therefore monads as well) are closed under fmap. That should be the end of the story.

Re: Understanding and writing a JPEG decoder in Python

#48

Post by kerkeslager »

smabie wrote: post #47
kerkeslager wrote: post #46

Earlier quoted context omitted.

> There's a reason why no new languages have chosen 'lambda' for anonymous functions. Beware of people who say "there's a reason" and then don't say what that reason is. I suspect the reason in this case is that languages which use C-ish syntax it would make no senes to have lambda as a keyword. Python doesn't use C-ish syntax, so that reason doesn't apply. > It's annoying to constantly turn iterators into lists. So…

Look, functors (and therefore monads as well) are closed under fmap. That should be the end of the story.

It's pretty bizarre to assert that structures made up by some mathematician in a void should be the basis of a programming language intended to solve real-world problems, especially in response to giving real-world reasons for why it is the way it is.
Post reply on HN