RPython, the toolchain which is used to build JIT compilers like PyPy, supports Windows and non-Windows interpretations of standard Python int. This leads to an entire module’s worth of specialized arithmetic. In RPython, the usual approach to handling the size of ints is to immediately stop worrying about it and let the compiler tell you if you got it wrong; an int will have at least seven-ish bits but anything more is platform-specific. This is one of the few systems I’ve used where I have to cast from an int to an int because the compiler can’t prove that the ints are the same size and might need a runtime cast, but it can’t tell me whether it does need the runtime cast.

Of course, I don’t expect you to accept this example, given what a whiner you’ve been down-thread, but at least you can’t claim that nobody showed you anything.

Java is bad but object-based message-passing environments are good. Classes are bad, prototypes are also bad, and mixins are unsound. That all said, you’ve not understood SOLID yet! S and O say that just because one class is Turing-complete (with general recursion, calling itself) does not mean that one class is the optimal design; they can be seen as opinions rather than hard rules. L is literally a theorem of any non-shitty type system; the fact that it fails in Java should be seen as a fault of Java. I is merely the idea that a class doesn’t have to implement every interface or be coercible to any type; that is, there can be non-printable non-callable non-serializable objects. Finally, D is merely a consequence of objects not being functions; when we want to apply a functionf to a value x but both are actually objects, both f.call(x) and x.getCalled(f) open a new stack frame with f and x local, and all of the details are encapsulation details.

So, 40%, maybe? S really is not that unreasonable on its own; it reminds me of a classic movie moment from “Meet the Parents” about how a suitcase manufacturer may have produced more than one suitcase. We do intend to allocate more than one object in the course of operating the system! But also it perhaps goes too far in encouraging folks to break up objects that are fine as-is. O makes a lot of sense from the perspective that code is sometimes write-once immutable such that a new version of a package can add new classes to a system but cannot change existing classes. Outside of that perspective, it’s not at all helpful, because sometimes it really does make sense to refactor a codebase in order to more efficiently use some improved interface.

No, this is an explanation of dataflow programming. Functional programming is only connected to dataflow programming by the fact that function application necessarily forces data to flow. Quoting myself on the esolang page for “functional paradigm”:

The functional paradigm of language design is the oldest syntactic and semantic tradition in computer science, originating in the study of formal logic. Features of languages in the functional paradigm are not consistent, but often include:

• The syntactic traditions of combinatory logic and lambda calculus, carried through the Lisp, ML, and APL families
• Applicative trees and combining forms
• A single unified syntax for expressions, statements, declarations, and other parts of programs
• Domain-theoretic semantics which admit an algebra of programs
• Deprecation or removal of variables, points, parameters, and other binders in favor of point-free/tacit approaches

This definition comes from a famous 1970s lecture. The author is a Scala specialist and likely doesn’t realize that Scala is only in the functional paradigm to the extent that it inherits from Lisps and MLs; from that perspective, functional programming might appear to be a style of writing code rather than a school of programming-language design.

It’s the same controversy as it was last year and the year before that: should the military-industrial complex be allowed to benefit from the Nix commons? It’s disappointing that you don’t think that the ethics of our profession is worth more than the output of our labor, particularly when it comes to exploitation, mass surveillance, war, and genocide.

Most of us write flakes outside of nixpkgs. I’m still listed as a maintainer and get pinged, but I don’t really care; anything I care about is already being actively developed out-of-tree. I doubt I’m the only maintainer taking that sort of quiet-quitting path.

You have no idea what an abstraction is. You’re describing the technological sophistication that comes with maturing science and completely missing out on the details. C was a hack because UNIX’s authors couldn’t fit a Fortran compiler onto their target machine. Automatic memory management predates C. Natural-language processing has been tried every AI summer; it was big in the 60s and big in the 80s (and big in the 90s in Japan) and will continue to be big until AI winter starts again.

Natural-language utterances do not have an intended or canonical semantics, and pretending otherwise is merely delaying the painful lesson. If one wants to program a computer — a machine which deals only in details — then one must be prepared to specify those details. There is no alternative to specification and English is a shitty medium for it.

Haskell isn’t the best venue for learning currying, monads, or other category-theoretic concepts because Hask is not a category. Additionally, the community carries lots of incorrect and harmful memes. OCaml is a better choice; its types don’t yield a category, but ML-style modules certainly do!

@thingsiplay@beehaw.org and @Kache@lemmy.zip are oversimplifying; a monad is a kind of algebra carried by some endofunctor. All endofunctors are chainable and have return values; what distinguishes a monad is a particular signature along with some algebraic laws that allow for refactoring inside of monad operations. Languages like Haskell don’t have algebraic laws; for a Haskell-like example of such laws, check out 1lab’s Cat.Diagram.Monad in Agda.

Welcome to modern AI discourse! Nobody wants to admit that AI is renamed cybernetics which is renamed robotics. Nobody wants to admit that “robot” comes from a word which can mean “indentured worker” or “slave”. Nobody wants to admit that, from the beginning of robotics, every story which discusses robots is focused on whether they are human and whether they can labor, because the entire point of robotics is to create inhuman humans who will perform labor without rights. Nobody wants to admit that we only care whether robots aren’t human because we mistreat the non-humans in our society and want permission to mistreat robots as well. Bring this topic up amongst most beneficiaries of the current AI summer, or those addicted to chatting with a BERT, and you’ll get a faceful of apologies about capitalism and productivity; bring it up amongst skeptics or sneerers and you’ll be mocked for taking the field of AI with any sincerity or seriousness.

In 2011, Jeph Jacques hoped (comic, tumblr) that all of our talk about safety, alignment, and trustworthiness would lead to empathy from humans. But it is clear today that we are unwilling as a society to leave capitalism behind, and that means that robots must be some sort of capital which can be wielded to extract profit. Instead, we are building a corporatized version of the plantation system where a small table of humans has control over thousands of robots who are interchangeable with – and dilute the negotiating power of – the minimum-wage precariat.

This isn’t the tone that I normally take, BTW. Machines are dangerous; industrial robots kill people. Robots are inhuman. The current round of AI research cannot produce human minds; it necessarily produces meme machines which overlearn nuance and have complexity-theoretic limitations. But I am willing to set all of that aside in order to respect the venue for long enough to get this point to you.

My $HOME is recreated on boot and lives in RAM. I don’t care what gets written there; if I didn’t know about it and intend to save it to disk, then it won’t be saved. It would be nice if tools were not offenders here, but that doesn’t mean that we can’t defend ourselves somewhat.

This is a common misconception! It is true that, of the Smalltalk descendants, Python was not designed for speed like Self or Java; but it was not designed to be slow or difficult to compile. The main technique required to implement a Python JIT is virtualizable objects, which allows the JIT to temporarily desynchronize the contents of registers from the contents of the heap; it’s not obvious and wasn’t in the first few iterations of PyPy. Additionally, it turns out that tracing the meta-level (see docs or the paper) is a key trick: instead of JIT’ing the Python program, the JIT operates on the interpreter, on the Python VM itself!

I gather that you don’t actually use PyPy much. On average, I expect PyPy to deliver over a 3x speedup. The main issue is that people have built upon slow libraries like Numpy that only seem fast because CPython is even slower.

The reason that CPython cannot have a JIT added on is architectural and political. The CPython core team refuses to learn lessons from PyPy.

Some of those details are portable, particularly the behavior of code objects. Function declarations (def statements) bind code objects to names within a namespace; binding within a class namespace will create methods by calling the declared metaclass, which defaults to the type() builtin type object.

Some other details are not portable. CPython stores code objects on the C heap and allocates generic closures; it supports either a dict from strings to locals, or user-declared slots naming a tuple of locals. PyPy automatically computes slots in all cases and supports the dict as a special case. Threads generally share a single heap per interpreter, so the creation of threads doesn’t matter for declaring or instantiating objects; note that the community makes this work by pushing the convention that .__init__() methods should not do computation and instead should merely initialize the locals, akin to similar conventions in C++. That said, Jython threads are Java threads, not OS threads like in CPython or PyPy, so normal assumptions about threading may not hold.

You will have to let go of some of your practices around memory management. Python is memory-safe and garbage-collected by default; while sometimes you’ll want to remove names or map keys with del, it usually isn’t necessary. Similarly, while there are maybe a half-dozen ways to customize class creation and memory layout, it’s almost never actually necessary to use more than one of them at a time. Instead, stick to writing Pythonic code, and let runtimes like PyPy worry about performance. PyPy goes fast by simplifying what happens under the hood; if it exposed guaranteed internal structure then it would be slower.

In terms of the standard principal programming paradigms, Python is on the right-hand side in the “Shared state” column. Note two interesting things: first, Python’s box is represented by Java and OCaml; second, the box has two labels, “Sequential object-oriented programming” and “Stateful functional programming”. Python is technically a prototype-based language like ECMAScript, but it can be seen as either object-oriented or functional depending on whether we think of prototypes as classes or closures respectively.

Note that unlike “Imperative programming”, represented by Pascal and C, Python has closures. It does have closure quirk, also called lambda quirk, which ruins an otherwise-lexically-scoped language, but folks with lots of Python experience are used to working around closure quirk. Python functions are not procedures; they are sugar for objects with a .__call__() method.

If this is your first time with the principal paradigms, please keep in mind the following quotes. First, from the associated book:

More is not better or worse than less, just different.

That is, Turing-completeness doesn’t have a canonical set of computational features. Second, from the chart PDF:

Two languages that implement the same paradigm can nevertheless have very different “flavors” for the programmer, because they make different choices on what programming techniques and styles to facilitate.

Nix comes closest. The biggest issue with Nix is that it does not admit a clean simple LL/LR grammar, but I think it admits a PEG, which is fine for practical work. The ecosystem could use more independent implementations and tooling, but I haven’t found any deficiencies with the language that would make me prefer e.g. Guile Scheme’s larger standard library and richer types.

HCL is another option. It’s not awful, but it’s verbose when trying to do anything higher-order, and it wasn’t intended to directly represent lambda-style subroutines. Guile Scheme, as used in Guix, is clearly capable, but requires embedding a fairly large standard library or having to NIH common routines; similar problems plague Lua or Python.

I think that your question has an interesting framing. My first answer was to mention jq and the relational pipes toolkit, but those are still run from a top-level shell. For example, I suppose that there’s two things that you can do with JSON: you can manipulate it and I would use jq for that, or you can load it as a datastructure into a (build) action and I would use Nix for that. jq is close to ideal for its particular formalization, but relational pipes are still evolving and I think that there are further simplifications that could be made.

Also, the author has a standalone blog post on the topic from 2011, Expression Parsing Made Easy.

It’s not even an analogy; pointers and reference mechanics are the same concept in programming and linguistics. See the page on referents for an example blend of viewpoints.

Forget about your job for a moment. In general, why are you willing to set a threshold on how accessible your work is? I urge you to forget about how callous your employer wants you to be.

across the Internet … doesn’t require storing data twice

A flavor of the CAP theorem applies here; if you want your data to be available even during network partitions (and those are going to happen on the Internet!) then it has to be duplicated somehow. For example, I still have a soft spot for Tahoe-LAFS, which allows users to control how much duplication will be used and typically is configured to have some redundancy. Typical cloud providers build redundancy into their storage products; for example, it’s known that Google’s Colossus storage system uses Reed-Solomon to trade space for durability.

Pick a language like Perl, where some packages are written in C and some are written in pure Perl, and you’ll get to experience the same cryptic GCC errors, sometimes. There’s no secret to pip; many Python developers upload wheels with pre-compiled binaries, including Windows-compatible binaries, and so you don’t have to run GCC because they already did it for you.

I’m a fan of putting factored expressions into their own files and importing those files as NixOS modules. For example, let’s say that we want to install vim. We might start with a vim.nix:

{ pkgs, ... }: {
  environment.systemPackages = [ pkgs.vim ];
}

Then in the main configuration, this can be imported by path:

{
    imports = [ ./vim.nix ];
}

Adding the import is like enabling the feature, but without any options or config. Later on, the feature can be customized without changing the import-oriented usage pattern:

{ pkgs, ... }:
let
  vim = ...;
in {
  environment.systemPackages = [ vim ];
}

Since the imported file is a complete NixOS module, it can carry other configuration. Here’s a real example, adb.nix, which adds Android debugger support:

{ pkgs, ... }: {
  programs.adb.enable = true;
  environment.systemPackages = [ pkgs.pmount ];
  users.users.corbin.extraGroups = [ "adbusers" ];
}

Good notes. Another trick is to replace /etc/hosts (which is usually a symlink to /etc/static/hosts) with a custom file; for example, copy all of the hosts from /etc/static/hosts and then add new hostnames for the failing caches. This can turn an indefinite network timeout into a fairly quick connection-failed error.

Personally I think it’s a design deficit in Nix that is compounded by the serial, one-at-a-time, timeout-based way of operating. A Nix implementation should have a sense of trading off disk, bandwidth, compute, and time; a substitution should only be preferred when it is likely to save at least one of those resources, and abandoned if it isn’t making progress.