Hacker News new | past | comments | ask | show | jobs | submit | bjourne's comments login

Fool me once, shame on you. Fool me twice... you can't fool me twice!

If you define a "move" as a piece moving from one square to another, which I think is the correct definition, then the rarest move is probably an illegal move. Like black king jumping from b4 to h8 or something. Or a piece moving to an already occupied square of the same color. In over the board chess illegal moves happen all the time in bullet chess, but not online of course.

Here is something I often do with ChatGPT: "Proof-read this text for me: <paste text>" And it obeys! The hype is well-deserved imo.

While that is true, for correctness appends should supplant updates. On HN, many users (like myself) have posted comments for over a decade. Suppose I changed my username from "bjourne" to "SpongeBob"... Should the comments I wrote in 2010 show up as having been authored by "SpongeBob" or "bjourne"? I'd strongly argue in favor of the latter since the former would constitute falsifying history. The "change" in username should be viewed as the creation of a new personae rather than a "change".

Hard disagree. You create tables for them to be queried by applications. For the Restaurants example the application clearly wasn't designed to handle Restaurant entries whose only field differs is rank. Consequently, you shouldn't allow data the application can't handle. Whenever the time comes and you think "ah, wouldn't it be great if multiple people could review the same restaurant in the same year?" you change the natural keys. You can always relax the rules. Tightening the rules is much harder because garbage data may already be present.

Keys are about the integrity of your application(s) and preventing corner cases by making them impossible.


You can use a UUID as a primary key and still enforce uniqueness on a combined index of city and name.

If they conflict and are user facing identifiers aren't you then forced to add uniqueness to the city and name, ala /chicago/chipotle_s4, potentially bleeding some business details?

I don't love uuids as public identifiers for a number of reasons but not hinting details about your data is one nice thing about them.


Hmm, I am not sure if I get you.

The cool thing about enforcing uniqueness on a secondary index is that you can just change or remove the uniqueness constraint anytime without breaking foreign key relations.


I'm not sure why you want a uniqueness index then in this case. If it's not publicly visible (effectively a secondary index / reference), then you can't use it as an identifier.

This means you need something else (a slug, as discussed herein) or just use the ID (bad practice in general) or UUID (bad for humans). If you use - in this example - city and company name - you still have to enforce uniqueness, so you have a pseudo-slug anyway.


But what's the point? You're complicating the data for no apparent gain. Only terrible RDBMSes which don't support multi-column keys require surrogate keys.

Because you can remove or change the uniqueness constraint without having to worry about foreign key relationships.

Eh, that's a feature of natural keys. If you try to fuck up your model your RDBMS will complain.

You can’t change primary keys, that’s the point, because you don’t know where they are.

For example if an old key is in a URL, and that URL is in a browser bookmark, now you need redirects, so you need to keep all the old keys around forever. Keys should be random or sequential, never contain information.

If you want to enforce uniqueness then use a unique index/constraint.


I think you are confused about the terminology because a primary key is a uniqueness constraint. They can be changed in any RDBMS worth its salt. Keys should not be random and your URL example is a case in point. The url /germany/berlin/2023/mcdonalds contains no surrogate key and is immensely more useful than the url /review?uuid=1kjksdhh3244ygdvvgdd2345.

A primary key implies a uniqueness constraint. But you can have a uniqueness constraint without a primary key.

You can change primary keys within a database but you can’t change them outside the database. A database is a map but keys are part of the territory.

The second URL with the UUID is more secure and is preferred in many situations where information leakage is a concern.

The first URL is more descriptive but more prone to breakage. It depends on the situation.


A key is any set of unique columns. The primary in primary key just hints to the RDBMS how to store the data. Both URLs encode queries on the data. The first says "give me the 2023 review(s) of McDonald's in Berlin" (i.e., it has semantics) and the second "give me the row with uuid 1kjksdhh3244ygdvvgdd2345". I don't think the second URL is more robust because, for example, if the row has to be recreated it will fail to work.

I can tell you about the software side on which I have some experience. Spiking neural networks are strictly more powerful than conventional neural networks which in turn are strictly more powerful than hand-coded rules engines. So the idea is that neuromorphic systems will some day supplant conventional neural networks in the same way they supplanted rules engines (e.g., for machine translation). However, as it stands the theoretical benefits of neuromorphic hardware has not yet been proven. Which is perhaps because hardware and software needs to mature... Like how neural nets were thought of as toys for many decades before they became practical. More brainlike doesn't necessarily translate to higher performance.

I'd say the big catch is the huge advantage conventional neural nets have. In hardware and software support.


What are the current cons of SNN?

Afaik, this technique is called threading (https://en.wikipedia.org/wiki/Threaded_code) and has been used in most bootstrap compilers for decades.

I don't think this counts as threading, though it makes use of it. Threading mostly removes the dispatch overhead, but you still have a general function per instruction, a function call, and an inability to inline constants. Copy and patch could be thought of as a generalization of threading in the sense that you still precompile code for your instructions, but instead of calling that code you poke holes in it to replace constants you only know at runtime, then make a single callable program out of those instead of jumping around for every instruction.

There is a prior, very similar approach in GNU Jitter, but it uses only the compiler and some magic rather than the linker for marking spots to replace. I read about it by mention of moonchild in a thread[0] linked by foota here.

[0]: https://news.ycombinator.com/item?id=40410420


Threading doesn't necessarily mean following the full function-call convention on every transition. A switch/case approach is one way, but it's also possible to jump intra-function without following the calling convention, i.e. a goto with a pointer-based target.

I say possible in the sense that hardware supports it. The standard C language doesn't support this, but GCC's GNU C does support it as one of its extensions.

The GNU Jitter author wrote about this, see page 48, referred to as page '17', of this PDF: https://ageinghacker.net/talks/jitter-slides--saiu--ghm2017-...

See also Gforth writing about the same technique: https://gforth.org/manual/Threading.html


That is not the point though. I know threading allows using a custom convention and just jumping. What it doesn't, IIUC, is allow specializing your code for runtime data. Copy-and-patch and Jitter do. It's essentially static vs dynamic. I'm new to this so I may very well be misunderstanding threading, but I don't think it allows for modifying the functions on runtime by itself.

There's bit of a mushy terminology problem here. Generally when we say threading we mean schemes that don't rely on generation of new native-code sequences, sure, but people who are serious about efficient threading don't necessarily view it that way.

The term context threading refers to generation of native code that behaves much like conventional threaded-code interpretation, except specialised to the particular input code. [0][1]

See also dynamic superinstructions, a term used by gforth to refer to its runtime generation of native code for input Forth code. [2]

Disclaimer: I'm no Forth expert. I should give [1] a proper read, it looks interesting.

[0] https://webkit.org/blog/214/introducing-squirrelfish-extreme...

[1] (PDF) https://csng.cs.toronto.edu/publication_files/0000/0162/demk...

[2] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html-his...


I see. I'll try to read the links over the weekend, they seem really interesting. It's sad that the terms are so overloaded though, as it makes it hard to reach preexisting approaches and leads to rediscoveries of the same idea (I see that both Jitter and C&P seem to implement this very same idea, except maybe in the way the templates are created, and both seem to believe their invention is novel).

Regarding threaded-code strategies I think the terminology is reasonable. There's a real sense in which context threading is just another kind of threaded code, although it does make it awkward to describe conventional direct or indirect threading.

The creator of Jitter has read a lot about Gforth, as evidenced in [0][1].

You're not the only one to suspect there's some reinvention going on here somewhere though. [2] I'm not familiar enough with these topics (copy-and-patch and Jitter) to weigh in.

[0] (PDF) https://ageinghacker.net/talks/jitter-slides--saiu--ghm2017-...

[1] (PDF) https://ageinghacker.net/talks/jitter-slides--saiu--bts-2022...

[2] https://news.ycombinator.com/item?id=40410420


They are both super close in the latent space. I think you could design for threading, but then copy into place and NOP out what you don't need, or wire in the right constants, etc.

That's true. But it's still a stretch to say they are the same thing. That's why I said it can be seen as generalizing the approach.


> direct control over the content shown to users

How is the Chinese government's control over TikTok content any more "direct" than the US government's control over Facebook content?


Modern war can be as simple as advocating principals that weaken another country over a long period of time.

Let that sink in. (not in a musk way)


The difference is that it's the US government that's doing the banning.


The Chinese government could order TikTok to downrank / not show content that criticizes the CCP. The US government could not order FB to downrank content that criticizes the Democrats.


Is there any evidence that the Chinese government has done that? No.

As for the US, we have documented evidence of US corporations cooperating with the US government for spying and propaganda efforts.


What's stopping the US government from doing exactly that? Btw, a court order is not very "direct". Easier to have your buddy call his buddy who happens to be the ceo of Facebook...


What was the whole "Hunter Biden laptop" debacle about if not precisely this?


Its not. Its basically the same, and that is why China has the great firewall and facebook is banned.


ByteDance is headquartered in China, a repressive country where they throw you in prison or worse if you don't obey the government. If the Communist Party told them to meddle with the algorithm to the advantage of China and harm of the USA, for example, they would have to obey, or else suffer the consequences.


> China, a repressive country where they throw you in prison or worse if you don't obey the government.

The US has 4x as many prisoners per capita than China, and Assange is still in captivity.


Can we count "students" at "vocational education and training centers?"


Update the text! I would love to read the diff.


In addition to that the hypothesis asserts that a local minimum is likely not good enough. This is different from a few years ago when most thought that the solution space was full of local minima so parameter initialization wouldn't matter that much. But that is perhaps because the threshold for acceptable performance is higher so luck is more important.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: