HN user

Mikhail_Edoshin

900 karma
Posts0
Comments776
View on HN
No posts found.

The real understanding builds on not knowing. Once I realise I don't know something I cease thinking and start watching the thing. Then somehow I understand.

We do have a mechanism similar to LLMs but it provides existing knowledge; it's a search mechanism, basically. New knowledge happens when we turn that mechanism off.

We used both terms, the WW term meant the overall event and the other one was for the Soviet part that started June 22, 1941 and ended in 1945, first in Germany, the main victory, the in Far East in the war with Japan. The term itself is taken from to the war of 1812 with Napoleon; that one was The Patriotic War. The Finnish war has its own name. The Poland operation is not counted as a part of the war.

There are private efforts in Russia, but mostly they digitize Soviet-time books written in Russian or maybe in other languages spoken in Russia. (As far as I know, that is; I am, of course, not aware of the whole field.) Mir published in Russian too, but here it mostly printed translated works, a lot of scientifical and technical literature, a foreign sci-fi series and such. It was like a two-way enterprise, connecting USSR to the world.

Officially all this does not seem to be supported in any way, I'm afraid.

I frequented a forum with a two-pane UI with a tree in one page and the text in another. It encouraged long posts; was used for political and historical discussions. And what was amazing was that it had a seamless NNTP backend, you could easily participate using an news client, which was nearly every email client those days.

Exactly.

C. S. Lewis participated in many arguments about Christianity. He was a professor and had a very good memory (the biography says "total recall") so he was a formidable opponent. Yet he himself wrote in private writings that he never felt himself farther from Christianity than after having won in another such dispute. It was around fifty, I think, when he decided to stop doing that and started to write the first book about Narnia.

Sincere communication is only possible when the ego defenses are down; when ego is vulnerable. Ego is scared of that, so this rarely happens. But this is the only true communication; all the rest are status games. (If you haven't read "Impro" by Keith Johnstone, pick it when you have a chance.)

Thanks, will add that to my reading list.

Inheritance is both good and not so good. The problem it solves is in a way unique and the very fact that it solves it is indeed quite a feat. But the solution is rather crude.

In a comment nearby I put out a theory that an object is essentially a managed computation, a computation that is driven by external events. What inheritance does is that it allows us to meld two or more such computations together in a relatively seamless way.

Again, a simple but maybe not a minimal model could be that. We have a set of collections: linked list, queue, AVL tree, etc. Most of them do not have a built-in way to count the number of objects they contain. Some do; e.g. an array, but many do not. But, of course, it is not that hard to add it to any collection. Assuming we have 'Init', 'AddElem' and 'RemElem' all we have to do is to add a counter that is set to 0 at 'Init', increment on 'AddElem' and decrement on 'RemElem'. Then we could read the current value with 'NumElems'. At the same time if we do not need a counter, then we should not add it to avoid extra work. So it looks like it would be nice to somehow extract the idea of a counter into a separate computation and then add it to a collection as necessary.

Inheritance allows us to do that in a uniform and general way and this is surely a remarkable achievement. But its solution is not simple. E.g. I have no idea what is the best way to inherit here and am afraid we'll end up with a separate variation for each collection. Yet the concept of what we are after is basically that:

    aaaa = new LinkedList;
    bbbb = new LinkedList + Counter;
Of course it may require special definitions at the class level, but otherwise the result should be that simple, because these are all the distinctions that are important in this context.

Yes, this is exactly what I'm saying. Objects, closures, co-routines and eventually state machines, which was the first concept, I think, all revolve around the same core thing.

We keep returning to it because this is the natural way to do computation using a machine, but we also try to escape because it is rather hard for a human. We like the functional form more: it looks sequential and goes nicely from start to end. With objects we quickly lose our way in a soup of small parts.

Behavior is a good clue. The current model, even with data, lacks behavior. It has a method, which is like a message we send to it. But it does not seem to give it enough behavior, even though we don't make any assumptions about its complexity.

Or maybe it could give it behavior if it were like that:

    class Aaaa
      [some data]
      method handle(message, ...)
        [some code]
This construction implies there are multiple messages. "Multiple" is the key difference. The part that was missing in the original sketch is a second method:
    class Aaaa
      [some data]
      method bbbb()
        [some code]
      method cccc()
        [some code]
Now this is an object. For example, it can be a random number generator: we initialize it and then read next numbers. Or it could be a timer: we initialize it and then read the value. We do not need a fully object-oriented environment for that; there is a plenty of such things in C and other non-OOP systems.

Such a thing surely has some behavior and this is exactly what we use. We are not interested in the internal data much. In fact the internal data of an object play exactly the same role as a function stack frame: it is a private slice of memory a computation keeps for itself because this is how it works. As in knitting the size of the manipulator is tiny compared to the final result and to do anything substantial we need a place to keep stuff around until we are done. And we need to be sure data stay were we've put them, hence encapsulation.

So an object is very much like a function, it is a computation that uses some memory to do its job. It is different in that in an object the computation runs step-by-step guided by external events. A function is like an object that gets the whole sequence of events at once, runs from start to finish and in the end discards the working memory so we tend to forget it exists. An object runs from message to message and keeps the working memory, which we see as "object data". This is why objects arise naturally in areas like user interface where events are truly external. But an object is actually a primary form of computation: if you can process a single event, you can use it to process a sequence; but if you can only process the whole sequence, you cannot just switch to processing single events. There are many similarities with closures, coroutines and such; I'd say they are different ways to express the same principle.

(This also means that objects are naturally mutable. Immutable objects are an aberration that arose because we've got here in a very roundabout way.)

Data will indeed be necessary. But data in OOP are interesting: they are not supposed to be directly visible. They are like the method body: there is one, but it is not important what it is. So if we add data, it will be that:

    class Aaaa
      (some data)
      method bbbb():
        (some code)
Do you think this is an object now?

There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words.

People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point to an object. Usually we try to talk about them using definitions, that is some sequences of words that are supposed to describe a thing. Such discussions are notoriously unproductive. The reason is that words are not really good as pointers: we have much more things than we have words and we have to reuse the same words to point to different things in different contexts. Yet in a phrase words look same so we tend to conflate these different things. As a result we get lost and go around in circles.

So instead of definitions Ilyenkov talks about a notion. Notion is something that reliably points to a thing that is hard to point at. It does not have to be an abstract thing: for example, we cannot point to radio. We can point to a household radio apparat but it has way too many parts completely unrelated to radio as a principle. So instead we build a minimal radio that has like three or four parts yet is capable of emitting or receiving radio waves.

We can do the same with abstract things too using the same approach. Let's build a minimal working model of a thing. "Working" so that the model indeed has the quality we are after; and "minimal" so that if we lose a single part, the quality is gone. Since the thing is abstract the model will also be abstract, that is it will be a sequence of words too, very much like a definition, but not quite.

(The same principle is widely used in parables: they describe some situation and thus try to guide your attention to certain qualities of it, hoping to trigger understanding. Sometimes it is hard to even name the thing they are pointing at, yet their pointing power is palpable. I myself often think about the parable about seven blind people and an elephant. You see I'm not naming the thing it points at: I don't have a good name for it.)

So let's go back to object oriented programming. What would be a minimal working thing that we can reliably call an object?

Here is what cannot be there. First, there must be no inheritance. If inheritance were required, then the first thing we build wouldn't be an object as it would have nothing to inherit from. Only the second thing would be an object and only because it inherited from the first. But this does not seem right. Second, there must be no polymorphism on the same grounds.

But at the same time if we do this:

    class Aaaa
        method bbbb():
            ...
then it is too minimal. It is hard to say how it is different from a function. It is not an object at all. Yet; there is a missing part that would turn this into a true object, but what the part is could be somewhat surprising.

If they ever start actually hurling massive objects to the orbit then these will be weapons. The data center functionality will be imitated remotely, if necessary.

See "Starlink is a way to give internet to whales" and "Pokémon is a fun little game" maybe "to train delivery robots as a surprise by-product nobody foresaw" and other such stories.

The same thing can be noticed in dreams. I once heard advice to try to re-read what you see in a dream. So I was dreaming and in a dream I read a phrase about something and there was a name of a city there. I managed to remember that advice and re-read the phrase. It felt exactly same, but the city name was different.

(LLMs carry other numerous similarities to dreams or to certain psychiatric disorders. So there is indeed a mechanism in our brains that is similar to how they work. But it is not the only thing there and on its own it won't "evolve" into consciousness. Even if we believe consciousness evolved somehow, it would be hard to imagine it started as a delirious state and then somehow ceased to be delirious.)

I remember some very old Windows shell app, Dashboard, by Starfish software, I think. It run under Windows 3.1, possibly replacing Program Manager, and it had a neat virtual desktop feature with tiny pictograms of several desktops for you to switch and drag mini-windows between them. Combined with other capabilities it was a true gem. (But somehow in Windows 95 the updated version started to feel less useful and I eventually abandoned it. Maybe it was the effect of moving between systems and a typical reinstall-to-clean-up routine that was common those days.)

Some symbols may not be readily available, e. g. <> or {} or [] and you'll have to either switch to English or install and learn a modified layout. But this is mostly a Windows issue, I think; the Russian keyboard layout on Windows is barebones compared to that of Mac. As a result there are other custom-made layouts in circulation, e.g. a typographically enhanced one.