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.

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.

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?

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.

Where was that question asked?

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.

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.)

(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)

That said, the same argument could be made for mobile phones as well, so it's clearly spurious.

> This update fixes over 900 issues that users have reported from using Godot 4 or while helping contributors test 4.1 with pre-release builds.

Fixing that many issues while further improving performance and stability is itself worthy of commendation. Well done Godot team!