because children are undergoing a critical phase in their development that has no analogy for older populations? I'm not saying isolation among the elderly is not concerning, nor widespread phone/tech addiction among adults. But I think there’s ample reason to have particular concern for the effects on children.
I suppose I'm lucky to live in the US where we have no problems with ultranationalist sentiment and racially motivated hate crimes.
I wonder if any anti-Japanese sentiment has to do with the fact that, to this day, the ruling party/LDP actively denies the numerous war crimes perpetrated against the Chinese in the second world war, including the Nanjing massacre. But I guess it must be all that propaganda. Though the Chinese may need to fine-tune their approach, since per the Newsweek article you linked "Among Japanese respondents, 92.2 percent had an unfavorable opinion of China, up from 87.3 percent in 2022. On the Chinese side, 62.9 percent viewed Japan negatively, about the same as the previous year."
But simplest: Address pairs are extremely simple, obviously. But they can implement anything.
Lists, structures, arrays, trees, arbitrarily complex multidimensional and irregular data types.
Using symbols as representational "links" they can even implement general (multi-, etc.) graphs. Which is everything.
But remove one of those addresses, and all you have left are linked series of addresses, ending with one element, or an end-of-series marker. That isn't general or very useful.
When you use lists to define a data structure, you can linearize the whole structure. I.e. (... (...) ... ( ... ) ... ... )
What you can't do is have some leaf of the structure refer back to a higher point in the structure. Which is what you need to represent a graph. I.e. any point can refer to any other point.
So instead, you linearize but use symbols to define a referencable point, and then to refer to it.
I.e. ( ... (....) (define a ( ... )) ... ( ... ( ... a .... ) ... a ... ) ... )
In this case, "define a" indicates that the next list isn't just accessible at that location, but wherever "a" appears later. And then we reference it in more then one place later.
This allows not only tree-like structures to be linearized, but graphs.
Everything is still lists, and lists-of-lists, but just as symbol or number elements can appear at more than on place, now lists in the structure can be referenced in more than once place.
All done with just pairs of addresses and symbols. Even numbers can be built out of pairs of addresses and symbols.
I.e. a binary number: (one one zero one zero zero one zero)
Of course, a friendly language is going to add lots of notation on top of address-pairs and symbols, for numbers, looping, functions, decimal number, etc. to make common code and data forms much easier to type and read than a jungle of parentheses.
--
This is very much the reason we have defined and referenced symbols in all code (or complete data languages). So that linear text can describe a graph. And the same process occurs, first the text is parsed into a tree (parsing), then at some point, symbols defining references are replaced with addresses of symbol definitions (linking).
The result is code can be a graph. We can have two functions that call each other, etc. Not just tree expressions.
I see, interesting. I never really thought about LISP as low-level. It was always just something that I implement in C however I want to. You gave me a bit of a new perspective on it.
Low level in implementation, meaning a representation that matches the native hardware data, code and storage conventions.
The advantage being hardware-level representations are the easiest to optimize for that hardware.
But also mathematically, where low level means simplest and fewest primitive abstractions that allow easy representation and manipulation of code and data. LISP's paired references and symbolic linking are very low level in that sense.
The advantage here is that with so few abstractions, code and data relationships are easy to define, analyze, transform, as well as evaluate.
And small numbers of simple abstractions are very easy to implement. As you obviously know from experience.
I have also created several little LISPs in aid of other projects.
Another language I have recreated opportunistically is FORTH. It can be viewed as a trade off between being low-level with respect to hardware, and in terms of simple abstractions. Not as flexible as LISP, but more efficient on typical hardware. Its basic abstractions consists of two dynamic lists. The first, a stream (a running list) of instructions that manipulate data on the second, a stack (a dynamic list we append and remove items from). And symbols for linking.
Yes, I know what you mean. I'm reading McCarthy's original paper now and what I'm noticing is that not all of it is low level in the second sense. For example, mathematically cond would be implemented with copairing/matching over left- and right-injections. Coproduct is the dual category to the product category that pairs belong to, so would be more natural than the higher-level cond, but much less efficient in practice.
“Financial derivatives” and “downside is limited” should never appear in the same sentence without strong conditions on what sorts of derivatives/ combos of them
I think people in the thread are mistakenly conflating the idea of buying options with writing options to sell, the latter of which can have unlimited downside
The "see also" section links to a similar changeover in Okinawa which mentions that a country having more than one traffic direction is in violation of the Geneva convention (on road traffic) https://en.m.wikipedia.org/wiki/Geneva_Convention_on_Road_Tr...
If this is a violation, the United States needs to fix its own problem. Left driving is the rule in the US Virgin Islands, and it's especially dangerous because (like Sweden before 1967) most cars there have left-hand steering and the roads are narrow.
“American territories are under American sovereignty and, consequently, may be treated as part of the United States proper in some ways and not others (i.e., territories belong to, but are not considered to be a part of, the United States). Unincorporated territories in particular are not considered to be integral parts of the United States, and the Constitution of the United States applies only partially in those territories.”
(This kind of stuff can be very convolutrd. There are parts of France that aren’t in the EU, for example. https://en.wikipedia.org/wiki/Overseas_France: “Overseas France (French: France d'outre-mer, also France ultramarine)[note 3] consists of 13 French territories outside Europe, mostly the remains of the French colonial empire that remained a part of the French state under various statuses after decolonization. Most, but not all, are part of the European Union”)
I was a Java apologist for a long time and I still think you can write fine software in it (and the JVM is an incredible piece of engineering). But the fact that the class is the _only_ unit of abstraction is just so frustrating to me now (Yegge's Execution in the Kingdom of Nouns makes this criticism in a humorous allegory[1]). Modern Java does mitigate this somewhat. Lambdas provide nice sugar over the inline class-creation you'd have to do of yore. Records make it less of a pain to define POJOs. But I think this fundamental issue is at the root of much of the language's clunkiness.
They were close but unfortunately went too far at being opinionated in solve the issues of using C at the time of Java's inception. Changing this now is Valhalla project which has unknown release date.
Luckily, C# learned from this mistake and made a decision to follow C much closely, having integers as proper primitives and supporting structs since day 1, and only improved since then in this area (JVM needs insane pointer compression and shadow tricks to pack integers to claw back performance, and in .NET "it just works" instead).
I wonder if Cassandra was written in .NET, it wouldn't have such a poor performance (though this can also be showcased by Garnet which beats competition written in C++ and C).
reply