Deportation isn't prevention. It's inherently reactive. Securing a border has to be done at a border (as opposed to, for instance, at people's homes, churches, and schools).
6,499 karma · joined November 17, 2015
They definitely did.
> I don’t know German history very well
It's worth revisiting. _The Nazi Seizure of Power_ by William Sherman Allen is available in a variety of formats and may be an accessible starting point for this. It does directly contain examples of resistance and opposition to Nazis, before, during, and after their seizure of power (albeit in just one town that the book focuses on).
Rules that require the distribution of source code don't require the distribution of binaries.
> I mentioned that a native Clojure is the first step toward my dream language. Indeed, it doesn't stop there. jank will always be a Clojure dialect, but it will also optionally support more. Features like gradual typing (maybe linear typing), more explicit memory management, value-based errors, and stronger pattern matching, to name a few, improve upon Clojure. This will allow another axis of control, where some parts of the program can remain entirely dynamic and garbage collected while others are thoroughly controlled and better optimized. That’s exactly the control I want when programming.
--
Thanks for your work on jank! I hope the Alpha brings you lots of new users, useful bug reports, and some contributors. :)
Sure. I never said this desire on the part of management is generally irrational.
It's just that this (often rational) preference for "safe bets" leads to ossification and repetition. It's self-reinforcing and eventually becomes disconnected from the inherent virtues or vices involved in the thing chosen.
If you enjoy participating in this network effect as a hiring manager or tech lead or whatever, or feel it's part of your duty as an ROI-maximizer, that's fine. You're probably right.
It just seems clear that when such feedback loops are strong and risk aversion is high, it leaves little room for new languages to break into the "market" by competing on their intrinsic merits. So when that happens, it'll coincide with times and places of relatively high industry optimism and developer freedom.
> Same as using open standards
Open standards are about interoperability and user freedom, and don't really have anything to do with novelty or popularity.
> Same as using [...] well-known design patterns
A common pattern in designs of solutions for common problems that is counterproductive, or even just not very effective, is called an "anti-pattern". The honorific "design pattern" is reserved for patterns that are Actually Good™ in some way that would hold true even if no one knew them.
Consequently, "this design pattern isn't well known" just means "this solution is highly effective for addressing a common problem, but isn't very famous".
"Use well-known design patterns" is at least as much about choosing things because they're elegant, composable, flexible, performant, etc., as it is about choosing them because they're famous— hopefully much more so.
It grows, in my opinion, out of a desire for programmers to be interchangeable code extruders. The idea that a company might have to train anyone, or that a new hire might have to gradually adjust to a team's chosen languages and idioms, is antithetical to the dream of programmers as cheaply replaceable cogs in the machine.
This is a chicken-and-egg problem, and I suspect it can only really be solved when the labor market for programmers heavily favors workers. It's only then that large numbers of professional programmers significantly weigh aesthetics of language in their choices of job. It's also then that startups, which might have cultures that are more opinionated and/or less risk averse when it comes to language choice, are abundant and thriving. The rise of Python at Google worked on that same basis, didn't it?
I don't know that anyone can control the fate of a programming language like this. Maybe all you can do is make sure it's a lovely, useful language and the rest is up to fate.
Can't you just have the thing on your PATH be a wrapper that invokes the tool via its venv?
No, it doesn't. It extensively quotes its primary interview subject, who at one point makes a (fairly vague) insinuation along those lines. His words were "more like organized crime", and they're rendered in the article within quotation marks.
> Do gangs really do this, or is it just renaming the activities of homeless individuals as organized crime?
My guess would be the latter.
Freedom 0 is about the freedom to run the software "for any purpose", not "use" the software for any purpose. Training an LLM on source code isn't running the software. (Not sure about the OSD and don't feel like reviewing it.)
Anyway, you could probably have a license that explicitly requires AIs trained on a work to be licensed under a compatible free software license or something like that. Conditions like that are comparable to the AGPL or something, adding requirements but still respecting freedom 0.
But that's not an "anti-AI" license so much as one that tries to avert AI-based copyright laundering.
I'd characterize that as unusable, for sure.
Helpfully, though, uv retains compatibility with newer (but still well-established) standards in the Python community that don't share this insanity!
I think the snix¹ folks are working on something like this for the binary caches— the greater granularity of the content-addressing offers morally the same kind of optimization as delta RPMs: you can download less of what you don't need to re-download.
But I'm not aware of any current efforts to let people download the Nixpkgs tree itself more efficiently. Somehow caching Git deltas would be cool. But I'd expect that kind of optimization to come from a company that runs a Git forge, if it's generally viable, and to benefit many projects other than Nix and Nixpkgs.
--
"Rewrite" is important as "Rust".
The most pain probably just becomes from the hugeness of Nixpkgs, but I remain an advocate for the huge monorepo of build recipes.
I feel sometimes like package management is a relatively second-class topic in computer science (or at least among many working programmers). But a package manager's behavior can be the difference between a grotesque, repulsive experience and a delightful, beautiful one. And there aren't quite yet any package managers that do well everything that we collectively have learned how to do well, which makes it an interesting space imo.
Re: Nixpkgs, interestingly, pre-flakes Nix distributes all of the needed Nix expressions as tarballs, which does play nice with CDNs. It also distributes an index of the tree as a SQLite database to obviate some of the "too many files/directories" problem with enumerating files. (In the meantime, Nixpkgs has also started bucketing package directories by name prefix, too.) So maybe there was a lesson learned here that would be useful to re-learn.
On the other hand, IIRC if you use the GitHub fetcher rather than the Git one, including for fetching flakes, Nix will download tarballs from GitHub instead of doing clones. Regardless, downloading and unpacking Nixpkgs has become kinda slow. :-\
There was a time in the history of Python when people who chose Python did so primarily because they found it beautiful or pleasant to work with. These are reasonable factors in choosing a language, and they continue to be popular reasons for choosing relatively unpopular languages today.
A related essay has made the rounds on HN before. It might be worth revisiting if this question is on your mind: https://www.johndcook.com/blog/2011/10/26/python-is-a-volunt...
Is there any scientific indication that whether private thoughts are automatically verbalized actually has an impact on cognitive activity or function?
Also where do you get this idea that most people lack an internal monologue? Afaik research indicates that totally lacking verbal thinking is very rare.
It takes a long time to become mature, but it's a good strategy. NVIDIA GPUs will probably have pretty usable open-source community drivers in 5 years or so.