[pansa2]

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]

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]

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.

[kerkeslager]

So, what elements of Python do you consider boilerplate?

I say this not as someone defending Python, but as someone writing a programming language.

[pansa2]

It’s not so much that Python requires boilerplate - all executable code does. For example, the article includes code to read the input data from a file, which is not relevant to the algorithm and could be omitted from a pseudocode version.

Similarly, executable code requires unnecessary detail, like the article’s `Stream` class. In pseudocode this could be replaced by simply saying “get the next N bits”.

[kerkeslager]

I don't think we're defining "boilerplate" the same way, then. Reading from a file isn't something that every executable does, so when you add code for it, it's because you want your program to do it. Boilerplate is things that have to be added to every program regardless of whether they communicate anything that differentiates your program: main(), for example, or class in Java when you're not actually trying to define a class that will be instantiated by later code.

[smabie]

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]

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.

[smabie]

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.