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?
> 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.
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)
Without trying to defend this particular carve-out, I would suggest that things like computers and video game consoles are improving in capability over a much faster time scale than TVs and video cameras. Hence there is much less of an expectation of longevity / relevance than with other tech goods.
That said, the same argument could be made for mobile phones as well, so it's clearly spurious.
Technically speaking, batteries do get lighter when discharged! But not in any useful way, and entirely unlike the situation with aeroplanes, of course.
That's not really fair. systemd does a lot more, and with good reason (among other reasons: there are many, many economies that can be made when "booting" and "managing" services happens in the same hat)
Actually, if you start working out which one is the next to run, you have reinvented selection-sort and you are no longer linear time. (Hence why this is not a sensible sorting algorithm in reality :) )
Godot is a super impressive piece of kit. I'm waiting for a reason to start a new game project so that I can get to grips with it more firmly, but what they've been able to do with a relative small team puts Unity to shame. (Even more than Unity puts itself to shame)
> 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!