Open your mind a little; collective action has an impact but individual action may not. Paraphrasing Cloud Atlas, certainly an ocean is nothing more than a vast collection of raindrops, but each individual raindrop collectively acts as a body of water. This dissolves your false dilemma.

There are a lot of programming languages. Also, features can often be hacked onto or off of a language. It’s therefore important to be able to quickly reject a language based on undesirable features. It’s also important to recall the big picture: to maintain a large amount of instructions or transformations which have been proven correct. Anything which gets in the way of that big picture should be quickly rejected.

Self’s descendants are not well-understood in our popular culture. The two most popular (Turing-complete) languages, ECMAScript and Python, are both Self grandchildren, and Java is also a child of Self; yet, the article’s author incorrectly believes them to be ALGOL descendants because of surface syntax as well as the Java/ECMAScript focus on performance. Note also that the author doesn’t mention E (WP, esolangs), which is akin to Erlang in making message-passing explicit but descends from Self, unlike Erlang which descends from Prolog. (I will give them partial credit for noting that Smalltalk is an ancestor of Java.)

So, the exemplar should be a message-passing everything-is-an-object language designed for JIT with no Prolog influence. The earliest such language in the family tree is Self!

INTERCAL is an ALGOL descendant. A holistic timeline of esoteric languages shows that esoteric languages don’t form a family; however, there are several families not mentioned in the article, notably cellular automata and string/wire diagrams.

Yeah, writing your own squeeblerizer sucks, but there’s no better option. GNU Scrimble can be used off-the-shelf as a passthrough, so the only real tasks are implementing Squeeb’s algorithm and a sprongler; then, your entire pipeline is merely something like:

$ gscrimble --passthrough --args -- ./your_squeeb | ./your_sprongler

Edit: Whoops! Forgot to mention, GNU Scrimble also has Snorble support out-of-the-box, and Scrimble clients have content auto-negotiation, so your_squeeb can just take JSON on stdin. GNU Scrimble is really nice for this sort of thing, just…big.

And if you want to sprongle directly into a database or etc. then you can write your_sprongler to taste. Full disclosure: I have a fairly fast implementation of Squeeb’s algorithm in rpypkgs. However, I’d really recommend writing your own; it’s like twenty lines of code you can copy from Wikipedia and it’ll give you a good basis for extending it with your own desired changes later.

You can read snorblite’s code if you need to figure out a specific sprongling technique, but it’s way easier to just go look up the original SprongCode from SprongReg. Use a search engine to get around the university’s paywall. This gets you the SprongCode UUID and you don’t have to read code written by a batshit fascist.

It’s because the Booleans sometimes are flipped in display-server technology from the 1980s, particularly anything with X11 lineage, and C didn’t have Boolean values back then. More generally, sometimes it’s useful to have truthhood be encoded low or 0, as in common Forths or many lower-level electrical-engineering protocols. The practice died off as popular languages started to have native Boolean values; today, about three quarters of new developers learn Python or ECMAScript as their first language, and FFI bindings are designed to paper over such low-level details. You’ll also sometimes see newer C/C++ libraries depending on newer standards which add native Booleans.

As a fellow vim user with small hands, here are some tricks. The verb gU will uppercase letters but not underscores or hyphens, so sentences like gUiw can be used to uppercase an entire constant. The immediate action ~ which switches cases can be turned into a verb by :set tildeop, after which it can be used in a similar way to gU. If constants are all namespaced with a prefix followed by something unique like an underscore, then the prefix can be left out of new sections of code and added back in with a macro or a :%s replacement.

I was going to bring this one up. The least realistic part of Antitrust is how the antagonist is defeated, but the parts where somebody is impatiently waiting for javac to finish so that they can pack their .class files into a JAR, or typing in a list of IPv4 addresses one-by-one to see which one works, were painfully plausible.

In short: If you’d like to learn more, come visit #pypy on Libera IRC. It’s an interesting discussion topic, particularly if we want standard-library imports like math, sys, or json to work.

RPython is not capable of translating to bare metal today; it depends on libc and libffi for many features even when not producing JIT compilers. It’s also intended to operate on a layer of syscalls: rather than directly instructing hardware, it wants to make fairly plain calls, perhaps via FFI, passing ordinary low-level values. So, any OS developer would first have to figure out how to get RPython to emit code that doesn’t require runtime support, and also write out the low-level architecture-specific hardware-access routines.

That said, RPython is designed to translate interpreters, and fundamentally it thinks an interpreter is any function with a while-loop, so a typical OS would be a fairly good fit in terms of architecture. RPython knows the difference between high-level garbage-collected objects and low-level machine-compatible values; GC would be available and most code would be written in a statically-typable dialect of Python 2.7 that tastes like Java or OCaml.

The OS would be the hard part. RPython admits the same compositional flexibility as standard Python, so it should be possible to hack PyPy into something that can be composed with other RPython codebases. This wouldn’t be trivial, though; PyPy in particular is tightly glued to RPython since they are developed together in a single repository, and it wasn’t intended for reuse from the RPython side.

If all of that sounds daunting, and what you would like to do instead is take an existing kernel or shell with C linkage and ELF support, and extend it arbitrarily using Python code, then PyPy can help you in that direction too. Compile a libpypy and embed PyPy against your kernel, and you can then run arbitrary Python code in a fairly nice environment which supports Python-first development. Warning: while the high-level parts of this might be nice, like Python’s built-in REPL tools, the low-level parts could be very nasty since this embedding interface is old and rotting, to say nothing of actually getting bare-metal code that doesn’t make syscalls.

A list can store zero or more elements. A NonEmpty can store one or more element. That’s all.

This overall strategy – representing the top of a list as a dedicated value – shows up elsewhere, notably in Forths, where it is called “top of stack” and often stored in a dedicated CPU register.

Extension modules are implemented in C because the interpreter is written in C. If it were written in another language, folks would write extension modules for that language instead. Also, it would be less relevant if people used portable C bindings like cffi, which are portable to PyPy and other interpreters… but they don’t.

You tried to apply far too much pressure over too large a surface area. Either make a more focused approach by not chasing Free Software and XMPP supremacy at the same time, or find ambient ways to give people options without forcing them to make choices in the direction you want. In particular, complaining about bridges usually doesn’t get the discussion to a useful place; instead, try showing people on the other side of the bridge how wonderful your experience is.

Also, I get that you might not personally like IRC, but you need to understand its place in high-reliability distributed systems before trying to replace it; the majority of them use IRC instead of XMPP for their disaster recovery precisely because its protocol jankiness makes it easier to wield in certain disaster situations.

Sounds like it’s time to start training code-writing models on leaked Microsoft source code. Don’t worry, it’s not like it’ll “emit memorized code”.

I’d love to link you to their Wikipedia pages, but both of them are redlinked. As far as I can tell, Dr. V. Ronald was an educator who moved from Canada to the USA as part of the whole Xerox PARC thing and probably was valued for mainframe experience; does anybody have a full bio? The current maintainer is Ron Sunk, who did a full run at MIT up through postdoc before going to Red Hat. The names are a coincidence; runk implements what we now call Sunk summation, after Sunk’s thesis. (As you might guess, that’s an instance of Stigler’s law, since clearly Dr. Ronald discovered Sunk summation first!)

Also, as long as we’re here, I want to empathize a little with Sunk. The GUIs that folks have placed on runk, like GNOME’s Gunk or Enlightenment’s enk, look very cool, and there’s rumors of an upcoming unified number-counting protocol that will put them all on equal ground. But @MossyFeathers@pawb.social wasn’t joking; Dr. Arnold’s code literally only reads punch cards, and there’s a façade to make it work on modern Linux and BSD transparently. It predates X11, if that’s any help. The tech debt is real.

Because frankly, Ronald (the current maintainer, not the original author) is very competent. I say this as somebody who has personally been yelled at by Ronald at a kernel summit; I didn’t deserve it, but none of his technical points were wrong. I like to think of myself as the kind of person that, given enough time and documentation, can maintain anything; I think it’d still take three of me to do Ronald’s job. (Well, “job.” I think he technically works for Red Hat or something?) Not to excuse his conduct, just to explain why he’s not been replaced yet.

By induction, that will only make your user base stupider.

They have two. If the complaint is that neither wiki is as rich as the Gentoo or Arch wiki, consider that perhaps NixOS users don’t need as much supplementary advice for configuring their systems.

It’s been two decades. What kinks do you think NixOS has yet to iron out?

You’re not crazy or harsh. This is a very real problem. I have been stuck doing business development at every company I’ve worked for. There’s always some shitty load-bearing Django app whose schema determines what the business is capable of doing, and somebody’s gotta maintain it. It’s gotten to the point where I assume that any interesting things I do will be outside of work and not for pay.

You’re thinking of CPython. PyPy can routinely compete with C and C++, particularly in allocation-heavy or pointer-heavy scenarios.

You may be pleased to know that PyPy’s Python 2.7 branch will be maintained indefinitely, since PyPy is also written in Python 2.7. Also, if you can’t leave CPython yet, ActivePython’s team is publishing CPython 2.7 security patches.