See the previous post to have any clue what I'm going on about here.

if conditional_expression:
    ...

conditional_expression・と
    ...

# program-translation
# from: en
# to: ja
# identifiers:
#   absolute_value: 絶対値 [zettaichi]
#   is_negative: 負だ [fu da]
#   is_odd: 奇数だ [kisuu da]
#   negated_number: ネゲートした数 [negaato shita kazu]
#   number: この数 [kono kazu]
#   Number: 数 [kazu]
#   self: 己 [ono]

数・種類
    【己】負だ・関数
        …

    【己】奇数だ・関数
        …

【この数:数】絶対値・関数
    この数・無・だ・と
        無を返せ
    【】負だ.この数・と
        ネゲートした数 = -この数
        ネゲートした数を返せ
    この数を返せ

# program-translation
# from: en
# to: ja-Kana-x-halfwidth
# identifiers:
#   absolute_value: ｾﾞｯﾀｲﾁ [zettaichi]
#   is_negative: ﾊﾟﾀﾞ [fu da]
#   is_odd: ｷｽｰﾀﾞ [kisuu da]
#   negated_number: ﾈｹﾞｰﾄｼﾀｶｽﾞ [negaato shita kazu]
#   number: ｺﾉｶｽﾞ [kono kazu]
#   Number: ｶｽﾞ [kazu]
#   self: ｵﾉ [ono]

ｶｽﾞ･ｼｭﾛｲ
    (ｵﾉ)ﾊﾟﾀﾞ･ｶﾝｽｰ
        ...

    (ｵﾉ)ｷｽｰﾀﾞ･ｶﾝｽｰ
        ...

(ｺﾉｶｽﾞ:ｶｽﾞ)ｾﾞｯﾀｲﾁ･ｶﾝｽｰ
    ｺﾉｶｽﾞ･ﾑ･ﾀﾞ･ﾄ
        ﾑｦｶｴｾ
    ()ﾊﾟﾀﾞ.ｺﾉｶｽﾞ･ﾄ
        ﾈｹﾞｰﾄｼﾀｶｽﾞ = -ｺﾉｶｽﾞ
        ﾈｹﾞｰﾄｼﾀｶｽﾞｦｶｴｾ
    ｺﾉｶｽﾞｦｶｴｾ

I'd like to jot down a few ideas about how to enable computer programming without English.

Why would you want to do that? I can think of a few reasons:

1. To lower the barrier of entry for people who are fluent in a written language that isn't English.

2. To explore what programming languages can be like when removed from the constraints of English (and are placed in the constraints of another natural language).

3. To simply imagine other timelines where English is not the lingua-franca of computers.

There's two parts to enabling programming in a natural language: the identifiers devised by the programmer, and the keywords and syntax of the language the program is written itself.

Let's start with the simpler case: identifiers.

# program-translation
# from: en-US
# to: en-x-piglatin

# pt: Umbernay
class Number:
    # pt: isway_egativenay(elfsay)
    def is_negative(self):
        ...

    # pt: isway_oddway(elfsay)
    def is_odd(self):
        ...

# pt: absoluteway_aluevay(umbernay):
def absolute_value(number: Number):
    if number is None:
        return None
    if number.is_negative():
        # pt: egatedway_umbernay
        negated_number = -number
        return negated_number
    return number

# program-translation
# from: en-US
# to: en-x-piglatin
# identifiers:
#   Number:
#     _: Umbernay
#     is_negative:
#       _: isway_egativenay
#       self: elfsay
#     is_odd:
#       _: isway_oddway
#       self: elfsay
#   absolute_value:
#     _: absoluteway_aluevay
#     number: umbernay
#     negated_number: egatedway_umbernay

class Number:
    def is_negative(self):
        ...

    def is_odd(self):
        ...

def absolute_value(number: Number):
    if number is None:
        return None
    if number.is_negative():
        negated_number = -number
        return negated_number
    return number

# program-translation
# from: en-US
# to: en-x-piglatin
# identifiers:
#   absolute_value: absoluteway_aluevay
#   is_negative: isway_egativenay
#   is_odd: isway_oddway
#   negated_number: egatedway_umbernay
#   number: umbernay
#   Number: Umbernay
#   self: elfsay

class Number:
    def is_negative(self):
        ...

    def is_odd(self):
        ...

def absolute_value(number: Number):
    if number is None:
        return None
    if number.is_negative():
        negated_number = -number
        return negated_number
    return number

# program-translation
# from: en-US
# to: en-x-piglatin
# identifiers:
#   absolute_value: absoluteway_aluevay
#   is_negative: isway_egativenay
#   is_odd: isway_oddway
#   negated_number: egatedway_umbernay
#   number: umbernay
#   Number: Umbernay
#   self: elfsay
# scopes:
#   absolute_value:
#     number: umberney

class Number:
    def is_negative(self):
        ...

    def is_odd(self):
        ...

def absolute_value(number: Number):
    if number is None:
        return None
    if number.is_negative():
        negated_number = -number
        return negated_number
    return number

# program-translation
# from: en-US
# to: en-US-Shaw
# identifiers:
#   absolute_value: 𐑨𐑚𐑕𐑩𐑤𐑵𐑑_𐑝𐑨𐑤𐑘𐑵
#   is_negative: 𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝
#   is_odd: 𐑦𐑟_𐑷𐑛
#   negated_number: 𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻
#   number: 𐑳_𐑯𐑳𐑥𐑚𐑻
#   Number: 𐑯𐑳𐑥𐑚𐑻
#   self: 𐑕𐑧𐑤𐑓:

class 𐑯𐑳𐑥𐑚𐑻:
    def 𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝(𐑕𐑧𐑤𐑓):
        ...

    def 𐑦𐑟_𐑷𐑛(𐑕𐑧𐑤𐑓):
        ...

def 𐑨𐑚𐑕𐑩𐑤𐑵𐑑_𐑝𐑨𐑤𐑘𐑵(𐑳_𐑯𐑳𐑥𐑚𐑻: 𐑯𐑳𐑥𐑚𐑻):
    if 𐑳_𐑯𐑳𐑥𐑚𐑻 is None:
        return None
    if 𐑳_𐑯𐑳𐑥𐑚𐑻.𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝():
        𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻 = -𐑳_𐑯𐑳𐑥𐑚𐑻
        return 𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻
    return 𐑳_𐑯𐑳𐑥𐑚𐑻

# program-translation
# from: en-US
# to: en-US-Shaw
# identifiers:
#   absolute_value: 𐑨𐑚𐑕𐑩𐑤𐑵𐑑_𐑝𐑨𐑤𐑘𐑵
#   is_negative: 𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝
#   is_odd: 𐑦𐑟_𐑷𐑛
#   negated_number: 𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻
#   number: 𐑳_𐑯𐑳𐑥𐑚𐑻
#   Number: 𐑯𐑳𐑥𐑚𐑻
#   self: 𐑕𐑧𐑤𐑓:

𐑒𐑤𐑨𐑕 𐑯𐑳𐑥𐑚𐑻:
    𐑛𐑧𐑓 𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝(𐑕𐑧𐑤𐑓):
        ...

    𐑛𐑧𐑓 𐑦𐑟_𐑷𐑛(𐑕𐑧𐑤𐑓):
        ...

𐑛𐑧𐑓 𐑨𐑚𐑕𐑩𐑤𐑵𐑑_𐑝𐑨𐑤𐑘𐑵(𐑳_𐑯𐑳𐑥𐑚𐑻: 𐑯𐑳𐑥𐑚𐑻):
    𐑦𐑓 𐑳_𐑯𐑳𐑥𐑚𐑻 𐑦𐑟 𐑯𐑳𐑯:
        𐑮𐑩𐑑𐑻𐑯 𐑯𐑳𐑯
    𐑦𐑓 𐑳_𐑯𐑳𐑥𐑚𐑻.𐑦𐑟_𐑯𐑧𐑜𐑩𐑛𐑦𐑝():
        𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻 = -𐑳_𐑯𐑳𐑥𐑚𐑻
        𐑮𐑩𐑑𐑻𐑯 𐑯𐑩𐑜𐑱𐑛𐑩𐑑_𐑯𐑳𐑥𐑚𐑻
    𐑮𐑩𐑑𐑻𐑯 𐑳_𐑯𐑳𐑥𐑚𐑻

Tun = (x): ...
Sachen = 4
tu Sachen

# program-translation
# from: en
# to: de
# identifiers:
#   absolute_value: Absolutwert
#   is_negative: ist_negative
#   is_odd: ist_ungerade
#   negated_number: negiert_Zahl
#   number: ein_Zahl
#   Number: Zahl
#   self: Selbst

Klass Zahl:
    def ist_negative(Selbst):
        ...

    def ist_ungerade(Selbst):
        ...

def Absolutwert(ein_Zahl: Zahl):
    wenn ein_Zahl ist Nichts:
        gib Nichts
    wenn ein_Zahl.ist_negative():
        negiert_Zahl = -ein_Zahl
        gib negiert_Zahl
    gib ein_Zahl

def is_negative(thing):
    return thing < 0

Policy proposal: Implement a registry of landlords to track rents, lease terms, and landlord income.

Land ownership is considered a matter of public record, and details about property size, building, value, tax, mortgages, and ownership history are carefully maintained by the town. Information on the rent paid and lease terms is not. Nor is there any record of who _is_ a landlord and there responsible to provide good housing to their tenants.

An registry of landlords would list all properties rented, amount paid in rent, and the lease terms. The identity of the individual renters would not be included if they lived there, but the renters of non-residental properties or corportate renters would be indentified.

Landlords would be required to keep this information up-to-date.

Such a registry would provide a very valuable source of data on the current state of rental housing.

The registry could also provide digital services to tenants and landlords, such as easy rent payments or lease signatures and recording.

Policy proposal: Implement residential property-tax deductions as simple payments to all residents.

In Massachusetts, towns are largely funded by property taxes. The town picks the tax rate (per assessed value of the property) and an amount to deduct from the tax for each property if the owner lives at that property.

For people who rent, the property tax is effectively included in the rent (otherwise the landlord would be losing money). However, they don't get the resident deduction. (Yes, if the landlord lives in the building, the build does get it. But the amount per housing unit, and per person is much lower). This makes the tax somewhat regressive.

Instead of subsidizing housing by paying property owners, simply make a payment to each resident of the town. (With a 1099 for income tax.) This means renters get the same deduction as owners. It also makes the property tax slightly progressive.

Policy proposal: Every state route/state highway (including federally funded ones) is also a bus route.

Since the roads are publicly paid for, and designed for use by motor vehicles, there should be public motor vehicles available to use them. This is most efficiently done using buses.

Making state routes reliably also bus routes allows residents to easily navigate whether driving themselves or taking a bus. It also means development that is accessible by road is more likely to be accessible by people who can't or don't drive.

A state route network is probably not a well-designed bus network. Some route redesigns would make sense. The state might choose to no longer fund the maintenance of some highways if they don't make sense as bus routes. The towns such routes run through might not like this, but ultimately if it doesn't make sense to run a bus there, then it doesn't make sense for the whole state to pay for the road itself.

The state buses would ideally be well-integrated with other public transportation. That other public transportation may adjust its services to take the state ones into account. They might be able to provide more and better service since some of their load is now taken on by state buses.

Interstates in particular lend themselves to local (stops at every exit) and express (stops at cities?) service.

This policy would allow for some efficiencies by doubling-up on signage and route design.

Here's a proposed policy to address several problems:

All computers sold with pre-loaded software must meet at least one of the two following conditions:

• Open: The source-code of the software and the development tools required to build and install the software is publicly available, in perpetuity, and is licensed under an open-source license.

• Replaceable: Documentation is made publicly available, in perpetuity, that is sufficient to write and install software on the computer that accomplishes all the same tasks as the pre-loaded software, and it is possible to replace the pre-loaded software without special tools.

If the pre-loaded software on the computer connects to any services on other computers, the communications protocol must be documented and the computer's owner must be able to choose what computers it connects to.

This would apply to the software in things like laptops, but also embedded software in cars, appliances, phones, and the myriad other things with computers in them. The manufacturer can choose to either "show their work" (the open approach) so that the public can see exactly what the devices will do, or keep the software secret, but facilitate its replacement.

For connections to other services, only the "replacable" option really makes sense.

This would allow hardware to continue to function even when abandoned by its manufacturer, while still giving manufacturers the option of keeping their software secret if they choose. Either one would be minimal effort, since it just requires the publishing of what the manufacturer would already have a copy of for their own use. Public organizations such as libraries could even handle the archiving and making available "in perpetuity" of the software or documentation.

For some systems, it would greatly complicate the design to make the software easily replacable after manufacturing, or replacing the software would require regulartory re-approval. These would have to go with the "Open" option. This makes sense, because these systems are effectively static tools, and exactly what they will do should be thoroughly knowable by the people using them.

Sometimes manufacturers want to keep their software secret. This tends to be much more complicated software, and thus it's less onerous to provide a mechanism to replace it. Thus, things like phones and laptops would likely go the "Replaceable" route. This is more or less status-quo, the main improvement of this policy is that hardware documentation would be available to anyone writing software for that hardware.

These requirements apply to each computer individually, of which there may be many inside a single manufactured "product". In a laptop for example, the controller in an SSD may be an embeded computer. The manufacturer could either make it easily replacable (perhaps with a usb port and documented debugging interface?), or simply release its source code. The OS and bootloader on the other hand, may remain secret, but the hardware interfaces they use would then need to be documented.

Another example might be a car. Some of the computers would simply have their source code released, particularly critical ones with safety concerns. This allows for more public scrutiny of such systems, which is a good thing. Other computers in the car, such as the one controlling the stereo or telephone, might stay secret, but be replaceable.

The "connections to other services" should apply to connections between computers _within_ a product as well. This allows owners to replace parts to repair the product.

The definition of "computer" is turing-completeness and programmability. Even if it is only programmed once, that still counts. If it can _only_ be programmed once, then only the "Open" option is available.

The trope of "robots" in stories is a way to include slavery in a story without having to deal with any of the real-life terrible things about enslaving humans.

In fact the real-life obsession among some people of making machines as human-like as they can may stem from a desire to have control over real humans. There aren't many engineering problems that call for a machine to take the form of a human, certainly not enough to justify the interest in such-shaped machines.

The Jetsons is a white American fantasy of subservient humans with none of the "downsides" (from a white perspective) of actual black people.

The "robot uprising" trope is perhaps an echo of fear of slave revolts in the U.S.

"Robots" are almost always depicted as just impractically (and impossibly) human. The main thing that separates the idea of a "robot" from a "machine" is some attempt at simulating a human, even if it's just a face.

Experiment: put a face on your dishwasher. Does it seem like a robot now?

There are definitions of "robot" that refer to some idea of a machine that senses its environment and responds, and is somehow more "independent" of humans. But this is not a very precise distinction, and is often just one of degree. A furnace with a thermostat senses its environment and responds, but most people don't think of it as a robot.

The robot trope may be a re-casting of the older trope of animals that act like just differently-shaped humans. It's _possible_ there's some of the same motivation there: if you're used to working with domesticated animals, you might think an animal that was more human would be like a human you could boss around. But I think the reverse is more likely: putting human attributes on animals is a way to describe their _uncontrollableness_. A smaller example of the pattern of putting human thoughts in various things to explain their unpredictability or complexity (e.g. gods controlling weather, yokai, etc.), and make it seem less scary.

Many RDF datasets are meant to be interpreted as simply "statements in the graph are true". In order to record more nuanced interpretations, we'll make meta-statements: statements about statements and graphs.

We'll use a predicate that assigns a probability to a statement or graph. When its subject is a statement, it means that statement is true with that probability. When its subject is a graph, it means all statements in that graph are true with at least that probability.

Assume we have a dataset with a variety of statements, some of which we think are true, some are false, and some are true only with some probability. We can't just start inferring new statements from this dataset, since we have no idea what they would mean.

First create a graph of "assumed true" statements. Let's call it G₁. Add to it a statement "G₁ probability 1". We can add to our "true" graph probabilities for other statements not present in that graph itself. Within this graph we can safely let loose a inference process to find more true statements.

Next comes the fun part. We want to allow inferences about statements with a known, non-1 probability. To do that, let's say we have a statement outside G₁, S_a, and there's a statement in G₁ "S_a probability .9". We'll create a new supergraph of G₁ consisting of G₁ plus S_a. Let's call that G_a. We can add to G₁ a statement "G_a probability .9". Then, we can safely let an inference process run in that new supergraph.

Let's say we have another statement, called S_~a, known to be the inverse of S_a, either because a human manually added a statement to G₁ creating that relationship between them, or an automated process was able to infer that. We can infer it's probability is .1, and carry out the same supergraph process, this time producing a graph with probability .1.

Let's say we have another statement, S_b, also with probability .9. We could perform the supergraph process with it on G₁ to produce yet another graph with probability .9. We could also perform the supergraph process on G_a, producing a graph that represents everything in G₁ being true, plus S_a, plus S_b. We'll call that graph G_ab. We can then add to G₁ a statement "G_ab probability .81". This assumes the probability of the two statements is independent.

To represent dependant probabilities, instead of making statements about probability in G₁, we can make them in the subgraphs that suppose those statements are true. E.g. if S_a being true implies S_b has a probability of .99, then we add a statement to G_a saying as much. The supergraph construction then proceeds the same, but the resulting graph has a probability of 0.891.

Let's try a more formal approach.

We'll define three predicates:

n hasProbability p

n is a statement or graph, p is a number between 0 and 1 (inclusive).

n hasProbabilityAtLeast p

n is a graph or statement, p is a number between 0 and 1 (inclusive).

s isOppositeOf t

s and t are statements.

You can make several inferences that are obvious. In addition:

• if n isOppositeOf m and n hasProbability p then m hasProbability 1 − p

Let's think about a largest possible graph, the graph that contains all possible statements. Let's call it G_🌌. Assigning meaning to G_🌌 is pretty much impossible; it contains every possible contradiction! You could apply a certain kind of inference engine to it that just constructs subgraphs that contain no contradictions, but it would have a infinite about of work to do. So instead, we'll carve out subgraphs that we can assign some meaning to. We can also nicely represent subjectivity while we're at it.

Let's say I want to mark some statement (S_a) as true. I create a new graph of statements I think are true, and add the statement to it. Let's call it G_morgan:1. I can also add to G_morgan:1 the statement "G_morgan:1 hasProbability 1". I can let an inference engine loose in this graph and have it add everything it can derive from statements already in the graph to it.

Now let's say I want to say another statement (S_b) in G_🌌 (but not G_morgan:1) has probability 0.8. I add a statement to G_morgan:1: "S_b hasProbability 0.8". This can trigger the automatic creation of a new graph G_morgan:b, which contains S_b, and is also a supergraph of G_morgan:1. We can then infer in G_morgan:1 "G_morgan:b hasProbabilityAtLeast 0.8".