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)

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)

It's a term of art from the community, that also draws in the intellectually curious with a "wtf is half an A press?" - it's an excellent title.

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!

This is a great point! In order to find out, perhaps we should engage some experts at a leading research institution to do some wider studies that are able to account for such factors. Maybe Stanford could do it?

I fail to follow your chain of reasoning. How can the claim both be "clearly false" and unclear in its statement?

The use of "should" as the very first line of the body text actually makes the argument extremely clear, which is that there is a non-legal, non-technical imperative for API access [leaving only a moral/social imperative, as you determine]. I think you are probably smarter than the very low reading comprehension bar in order to understand what is being said, so I'm not sure what value you are deriving from pretending not to.

ULEZ and CAZ mostly force poor people to spend money on newer cars.

I don't think there's any reason to believe they mostly do this. Mostly what they do is encourage people to use public transport to get to areas well-served by public transport.

The initiative behind the ULEZ in particular is that it is a strong disincentive to owning/using a car at all in these areas, not just one that happens to be an old banger. Doubly so when considered on top of the congestion charge.

Wholly dependent on what you mean by "took off" but I'd argue Haskell qualifies. It was a nothing language for two decades before finding its footing and is now used in quite a lot of places (TIOBE puts it near TypeScript).

Most games make so much use of OS-level features (especially Windows APIs and their analogues under Wine/Proton) that a minimal system for running a game wouldn't be that much slimmer than an OS.

All you would really drop would be the window manager - and you can start X directly with a single application on Linux anyway.

The title is a bit bombastic but it's also not wrong! That vehicle looks like it's moving in all the right directions, so to speak.

Agreed, they are profoundly ugly objects. Looks like someone manifested a 3-year-old's drawing of a milk float.

Surely we as a species still appreciate things looking _good_ as part of an objective goal?

Mastodon trades one set of problems (centralised authority, terrible management, beholden to advertisers) for another set of problems (expensive n^2 bookkeeping of decentralised model, moderator fiefdoms, less polished UX). Whether you find one of those worlds easier to live with than another is up to you.

So far, the people who've moved to Mastodon seem happy with that choice, myself included.

That's not what a walled garden is.

You can't take the background from The Starry Night into the Mona Lisa either.

Yep, everything not CC is still under the sword of Damocles. The good news is that the vast majority of players and third-party publishers are using 5e, so this announcement protects them forever. It would not be unexpected for them to use this as a way to dwindle support for OGL1.0a, but either way the state of affairs today is far, far better than a few days ago.