johnday

"This is impolite" is not a truth statement, it is a value judgment. It can be impolite to do something even if someone has said that they don't mind.

There are a few confounding factors here:

1. It may be legally permissible, but it is impolite, to change the license away from the well-known Apache software license towards something which has not been legally vetted, and is in fact generated entirely by AI with minimal oversight.

2. There is an open question of what the supposed value add is here from the Pear team, that could not have been achieved by the people whose work they are co-opting.

3. Without a clear value proposition, the oversight given to projects by YC is called into question. I think this is the point most people are concerned by.

This seems like too much effort has been put into it for it to be a purely satirical exercise, but I really cannot see why anyone would prefer to use this within Python, rather than (say) reaching for a proper type-safe functional language and either using that directly, or calling out to it from Python code.

As a person who teaches functional programming at degree level, this is the kind of thing that would put people off FP before they even get in the door. It is obviously less ergonomic than standard Python, and the code you end up with is no safer or more abstracted than what you started with.

That said, if the authors really do think it's a better way for programming in Python, and it works for them, then more power to 'em.

Describing something in the imperative voice doesn't make sense.

Why would you ever say "TL;DR perform this action" instead of "TL;DR performing this action", when trying to describe something that people should not do?

No? It's in the imperative voice, it wouldn't make sense to read "do this" as a description of an antipattern.

That's older than the median age of a human being. Granted, people don't tend to play games before the age of about 7, but that still seems suspect.

> It has 995 open issues in its Github repository.

This is not a sensible metric for code quality. For one thing, only about 20% of the currently open issues are tagged as bugs - more than that are suggested improvements.

> Haskell program was supposed to work right if it compiles, wasn't it?

No. Especially for tasks like string manipulation and format munging, you cannot capture the complexity of the domain into types.

Then a very recent _increase_, even beyond that, is notable, no?

Sorry, but no. Edmonds clearly maps "efficiently-solvable problems" onto the notion of P in a complete way, not only as a subset of P.

> The question being asked

Where was that question asked?

P vs NP is not an "in practical terms" question. It is a theoretical question with theoretical definitions of theoretical terms, including "efficient", which directly corresponds to the class P by definition.

> Even a P=NP result doesn't tell us that NP problems have efficient solutions.

Yes it does. That is literally exactly what it means. The class P is the class of problems which are considered theoretically "tractable"/"efficiently solvable"/"feasibly solvable" (Cobham-Edmonds thesis). Hence, if NP=P, then that same definition extends to all problems in NP.

The value of purely functional programming languages, as opposed to functional programming languages like lisps, is that you get referential transparency, which means that when you define `a = b`, you know that you can always replace any instance of `a` with `b` and get the same answer. This is a very natural property in mathematics (algebraic rewritings are basically just this property writ large) and so it helps to draw nice parallels between the familiar notation of functions from mathematics and the "new" and "confusing" notion of functions in functional programming and other declarative languages.

As other posters have said, strong typing is also a nice property for lots of reasons, most notably it gives a platform to talk about ad-hoc and parametric polymorphism.

(I lecture on Functional Programming at the University of Warwick, where we use Haskell.)

Subtraction is truth preserving on the sign bit. It's not truth-preserving in the actual subtractive bits.

(I disagree with their claim that the subtractive bit is functionally complete on its own - you're right, since it's truth-preserving, it clearly is not functionally complete)