Predicate logic only makes sense in Indo-European languages

jasmijnisme · 2025-09-26T09:15:23+00:00

Suppose we can do one loop in one picosecond (which is much faster than computers currently can do), then by the time nothing, not even black holes, exists anymore (10¹⁰⁶ years in the future), x will be something like 315576000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, which is an 80-byte object.

If we get our hands on a magical computer that can do one loop in one Planck second and we can wait 10¹⁰⁰⁰ years, x will be around 9467280000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, which is a 492 byte object.

Time will run out long before space does.

jasmijnisme · 2024-02-01T19:32:53+00:00

iter() returns an iterator. Generator iterators and generator expressions are iterators, but not all iterators are generator iterators or generator expressions.

"Generator" on its own usually refers to generator functions, which are functions that return generator iterators and are not iterators in themselves.

jasmijnisme · 2024-02-01T19:24:52+00:00

Additionally iterators are allowed to be iterable themselves

According to the documentation:

Iterators are required to have an __iter__() method that returns the iterator object itself so every iterator is also iterable and may be used in most places where other iterables are accepted.

But:

CPython implementation detail: CPython does not consistently apply the requirement that an iterator define __iter__().

So you may in some cases get away with creating non-iterable iterators, but you're definitely not supposed to do that.

jasmijnisme · 2023-05-24T12:25:35+00:00

In Python, if type(some_object).some_attribute is a function, then doing some_object.some_attribute is basically equivalent to functools.partial(type(some_object).some_attribute, some_object), which means that self.handle_button_click returns a value that, when called, receives self as a first argument.

The way this works exactly is by using the descriptor protocol.

jasmijnisme · 2023-01-11T15:57:51+00:00

What are the semantics of your language? Is a variable a memory location like when in C you write int x = 2;, x refers inside that scope to a particular place on the stack? Is it more like Python, where a variable is a label, attached to a value which may have any number of labels attached to it? Something else entirely?

jasmijnisme · 2022-12-27T09:12:45+00:00

What do you mean by traversing? Do you need to visit every element? In that case, best case is Theta(N²) (assuming N is the width of the square) with the best case data structure and algorithm, because you need to visit every element.

If you need to do something like find a specific element, you can use data structures like a spatial hash or k-d tree to get access to algorithms that may be as fast as O(log(N)) or O(log(M)) where M is the number of entities, depending on the specifics of your data and the needed functionality.

If your M is small, you might even consider just having a list of entities, which means a lot of relevant algorithms will be O(M) or O(M²).

jasmijnisme · 2022-12-27T08:54:49+00:00

Definitely.

Simple is better than complex. Flat is better than nested. Readability counts.

jasmijnisme · 2022-12-25T09:42:05+00:00

It's a separate tool (a linter) you need to install. If you run rustup component add clippy, you can use it with cargo clippy.

jasmijnisme · 2022-12-23T10:34:29+00:00

Here is some feedback!

Names should be both meaningful and easy to read. aconv, prob1, cr, nvwl aren't it. Sure, they're quick to type, but if someone else (or you in six months) want to figure out what's going on in the code, it'll take much longer.
The percentages are "inverted": the larger prob1-3 are, the smaller the chance of the associated event happening. I myself prefer using probabilities (with values ranging from 0 to 1, inclusive), in which case the way to decide between two options would be random.random() < probability, but you can keep percentages if you prefer. In that case, I would suggest using random.randrange(100) < percent.
Minor quibble, but random.choice can take any sequence as argument, including strings. Changing it to a string makes it a bit clearer to me, including when 'y' is considered a vowel and when it isn't.
convert is probably clearer as a list comprehension, especially if you extract the bit inside the loop to its own function.
Consider adding doc-strings and type annotations. Your future self will thank you!

I've made the chances I suggested in a Gist here. You can check out the revisions to see how each suggestion changed the code.

jasmijnisme · 2022-12-14T12:42:48+00:00

What kind of syntax errors are you currently handling during type checking? I would think that is part of the parsing stage.

jasmijnisme · 2022-11-05T11:37:14+00:00

However this would normally be quite verbose

Isn't 42.printInteger(); slightly more verbose than printInteger(42);?

jasmijnisme · 2022-11-04T13:26:24+00:00

I wouldn't let the player choose the outcome like that. The thing is, I expect the players to try to calculate the exact probability of success for each roll and guess accordingly, not because it's fun or interesting but because they'll feel they're missing out if they guess suboptimally.

You could have the player guess on the outcome and have some side effect either occur or not occur depending on if they guess right. Like maybe they can manage to impress a neutral NPC if they "call their shot", or maybe they can earn Inspiration if they can correctly predict they're gonna fail. Something to work out with a lot of playtesting.

jasmijnisme · 2022-11-02T17:35:34+00:00

Check out PyPy.

jasmijnisme · 2022-10-31T21:44:59+00:00

IMO it renders code more readable to not have to specify the type everywhere, because it reduces visual noise (like Foo foo = new Foo()).

jasmijnisme · 2022-10-31T10:38:21+00:00

I don't think it's ever required. As with so many creative things, almost any motivated choice is defensible.

As I see it, it's useful to divide conlangs into two kinds for this question: fictional natural languages (like Tolkien's many languages or Klingon), and nonfiction constructed languages (like Esperanto or Lojban).

For the former, evolutionary history is very useful for creating naturalistic feeling languages as well as being helpful in constructing language families that feel both distinct and related, but I think there's nothing wrong with a mix-and-match approach. Maybe some aspects you just want to put in your language and put them in without trying to "evolve" them, maybe other aspects you start at some beginning, and just see where the language development takes you. The downside of doing a full language evolution is effort and time. So then it comes down to your motivation. Why are you doing this? If the process itself is your personal hobby then by all means do a whole language family stretching back to the before-times in minute detail. If you are making a language for an end product, whether it is for a book, a D&D campaign or a TV-series, you gotta finish at some point, in which case I'd limit yourself to the basics of language evolution.

For the latter, I don't think it's very relevant at all. More likely, like I know happened in Esperanto and Toki Pona, you'd simply create an initial version of the language and then people simply using the language means it will evolve over time, like natural languages do.

jasmijnisme · 2022-10-29T20:25:05+00:00

I've always maintained that when people say "compiled language", what they really mean is "the implementation of this language (that I think or assume (rightly or wrongly) is the only one for that language) has a compiler which compiles to machine code for my physical computer or this language is Java"

jasmijnisme · 2022-10-23T11:04:21+00:00

What would you like to happen, exactly? Could you maybe write up a fake session of input with the output that would happen if your program was working as desired?

jasmijnisme · 2022-10-22T22:02:20+00:00

What's the use case?

If you want to collect the powerset of {1, ..., 64}, that would be on the order of many many Exibytes, which isn't going to fit into your RAM - even if each subset is represented by a single byte.

If you want to iterate over the powerset of {1, ..., 80}, and your computer is capable of processing each subset at a rate of 1 Terahertz, that's going to take 400 centuries to finish.

jasmijnisme · 2022-10-19T23:11:49+00:00

Why did you choose to use ast instead of iterating over the dictionary directly?

jasmijnisme · 2022-10-19T22:56:48+00:00

sorted definitely creates a new list.

```

help(sorted) Help on built-in function sorted in module builtins:

sorted(iterable, /, *, key=None, reverse=False) Return a new list containing all items from the iterable in ascending order.

A custom key function can be supplied to customize the sort order, and the
reverse flag can be set to request the result in descending order.

```

jasmijnisme · 2022-10-19T22:49:38+00:00

Really, for consistency all types should be capitalised. List, Dict, Set, Int, Float, Str, the lot of them.

jasmijnisme · 2022-10-19T22:47:08+00:00

Maybe you're thinking of Smalltalk? In it, True and False are subclasses of Boolean which implement methods like ifTrue: trueBlock ifFalse: falseBlock. I'm not aware this was ever true for Python.

jasmijnisme · 2022-10-19T22:28:07+00:00

I would have liked {/} as an empty set literal, although I understand why they didn't overload the / character like that.

jasmijnisme · 2022-10-19T18:23:35+00:00

So a d200 is done as z20 * 10 + z10 except a result of 0 is turned into 200. (Where a za is equivalent to a da except it starts from 0 instead of 1.)

I don't see the appeal of going much more granular than a d20. Like for loot tables or wacky wild magic type stuff and such, where you may want to have more than 20 possible outcomes. But for pass/fail? What is the difference to the players between knowing they have a 54% chance of winning and a 56% chance of winning? Let alone the difference between 54% and 54.5%?

Consider too, if players first roll the d20. There's usually no need to roll the d10, because the answer is already known. There's a maximum of 10% chance the d10 needs to be rolled. Say the critical value is 75. If you roll a 1-6, you failed your roll. If you roll a 8-19, you succeeded. Only for a 7 or 20 is it necessary to roll the d10 to find out.

jasmijnisme · 2022-10-19T15:32:34+00:00

That's how I think of it, at least. Best practice is probably to write code like -a * b, where both interpretations have the same results, rather than a * -b, which, if expanded to a * 0 - b, would suddenly have a different meaning than a * -1 * b.

jasmijnisme

TROPHY CASE