If we used it more than just "ok look it works, we'll standardize on this internally" we'd have been happy to buy it, as we all other open source that has a donation option. We were just getting our feet wet, tho, and that's where it seemed burdensome; heck, if it phoned home every time it was used, it would have noticed we only used it about 3 times!
I had heavily used PySimpleGUI in various work projects, and one day, when I had to run some older piece of code I had not run in a while, I get a notice that PySimpleGUI won't work, because was free, but nobody paid, and so, good luck! So I was piping mad, paid the 3-year or whatever the max license fee was, received a code, and THEN I was able to get my stuff to work, like it used to.
LESSON: N E V E R Use code that can "stop working" until you pay ransom. N E V E R.
At this point, it's irrelevant, because the LLMs can replace PySimpleGUI with PyQt etc so --- thanks but no thanks. I did like it because you could throw up something around a CLI and it looked at least presentable. Now, since 2025, nobody codes anymore, so ... seems to me, this PySimpleGUI 6 is just a bit of history.
The problem with old Python code is that you then have to hunt for exactly the right version of the right libraries that can work together when the stars are aligned.
Isn't that true of any packaging system? (npm, RubyGems, etc) Perhaps it's a bit easier, with the respective spec files, but it's still a bit of a hunt.
No. Decent packaging systems like used in the Java world have deterministic or mostly-deterministic dependency resolution; semi-decent packaging systems like the ones you mention have lockfiles. Pre-uv Python packaging is uniquely awful.
You don't need them. Maven has deterministic dependency resolution (unless you use version ranges, but don't do that), so you just write your dependencies. (The flipside is you may want to get in the habit of doing something like versions:use-latest-releases as a regular housekeeping task so that you pick up any security updates, but that tends to be less of an issue in Java-land for other reasons)
Why don’t I need them? I can’t make every third-party package do exact version pins and it’d be miserable if I could because then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.
Even if that worked, I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.
Depends on exactly how the project is managed. Older python tooling (`pip` module) doesn't have a native mechanism to differentiate between the spec (direct dependencies) and freeze (all dependencies, including transitive).
Excuse my ignorance, but does this functionally mean we can treat this as a 'microkernel' a la minix? I always liked the 'tiny protected subsystem' in Ring 0, then a Ring 1 for Drivers (which are restartable, and dynamically loadable), then one or two rings for User processes (maybe Ring 2 for 'ls' etc and Ring 3 for typical user processes).
I am also curious: What hardware enhancements would benefit 'lightweight, kernel-enforced isolation' ? Do we need memory tags? HW Capability Lists? ?
( I believe we've concentrated far too much in making "damn fast pdp-11s" with our hardware advances, and far less on building Reliable Systems -- even if a few percent of peak possible performance is consumed by extra HW. )
Mate, wouldn’t it make sense that these rules are applied via hierarchy? If Elon respects Karparthy he almost certainly gave him a longer leash and Karparthy’s output was strong enough to not warrant intervention. It’s clear he did not want to stay long term so I’m not sure this is a strong line of thinking.
It's possible. I don't know. My tone comes off as support Elon, and I do not, at all. I've seen first-hand almost all of these tactics while I was at <Elon Company>. I'm observing that some people seem to do OK at Elon's companies, and for many years, and never seem to get the boot or be abused in other ways. Therefore, Elon is probably not quite as bad a manager as he is made out to be. This is all I am saying. Since I have firsthand knowledge, I believe my opinion has value. Those that disagree? Show me your Source of Truth. Thank you.
I don’t believe Elon is even remotely related to a people manager. He’s a stakeholder and operator which require different skill sets. He finds folks who will manage to o bring the empathy he tends to lose in his pursuit of his next project. I believe your evidence may be anecdotally valuable but let’s be clear about the dynamic of a founder/ceo.
I have always disliked the := as assignment operator convention. In these declarative languages, assignment is done frequently. There is little cognitive load to using '=' as assignment, although perhaps a bit jarring for math folk.
<- is somewhat better, but, again, for such a common operation, a single character is just more convenient. Sure, we could have editors that turn "=" into := or <- but now we're getting too fancy especially for something pedagogical.
I also don't mind the -> for C pointers; and certainly don't mind the <= >= or even == conventions (although at least today's compilers warn when they see "if (a=b) ...".
Ultimately, humans won't be writing code anymore anyway ( ;-) ?) so maybe the issue is entirely moot.
Using '=' for both assignment and comparison is awkward when parsing incomplete code. Consider e.g.:
j = 5;
The user starts writing (<|> is the cursor position):
i = <|>
j = 5;
This is a valid expression (i is a boolean). But the user probably intends to finish writing something like:
i = 0;
j = 5;
So in the intermediate state we would like to emit a single warning about an incomplete statement. But since it is valid as written, we instead end up warning about e.g. j being unbound.
> I have always disliked the := as assignment operator convention. In these declarative languages, assignment is done frequently.
> I also don't mind the -> for C pointers
Mmm. These two opinions should be contradictory if held on principle as opposed being held out of impression.
it = next(it);
if ((*it)->node->op == EQ) ...
vs.
it := next(it);
if it.node.op = EQ ...
Eh. I don't really mind either of those except for the stupid parens after the "if" in the first case.
Technically, if you don't make assignment an expression, you can even get away with using "=" for both. And "->" exists only because structs originally weren't really typechecked; you could take any pointer and just do "->struct_field" at it, and the compiler would auto-cast.
reply