Hacker Newsnew | past | comments | ask | show | jobs | submit | ruds's commentslogin

In most of the world, "liberal" doesn't mean the left half of the political spectrum. In many places it's the centerish part and in a few places it's the rightish part. In the US, until recently, almost all mainstream politicians were liberal in this sense (even while many of the Republican liberals used "liberal" as an epithet in campaign ads).

From wikipedia:

> Liberalism is a political and moral philosophy based on the rights of the individual, liberty, consent of the governed, political equality, the right to private property, and equality before the law.[1][2] Liberals espouse various and sometimes conflicting views depending on their understanding of these principles but generally support private property, market economies, individual rights (including civil rights and human rights), liberal democracy, secularism, rule of law, economic and political freedom, freedom of speech, freedom of the press, freedom of assembly, and freedom of religion.[3] Liberalism is frequently cited as the dominant ideology of modern history


The security concerns were not addressed by not accepting new links. As the post you replied to said,

> The play was to scrape the web for old goo.gl links that went to expired domains, register the domain, and then you have a goo.gl URL that you can send wherever you want, indefinitely.


You are mistaken. Discretionary spending is spending that Congress allocates during the annual appropriation process, while mandatory spending is spending that is required by prior law. See https://fiscaldata.treasury.gov/americas-finance-guide/feder...


Antitrust suits were filed against these four companies in November, alleging that they conspired to fix prices: https://archive.is/fp44d


I don't think this sort of communication from guessers to clue giver is in the spirit of the game (at least in my play group). However, inflating later clues is a reasonable approach! It's just that I don't think you're allowed to communicate the amount of inflation. Guessers must determine whether people 5 has slack to allow additional guesses on previous clues.


You're free to add additional prohibitions on communication as a house rule I guess, but the only prohibition in the rule book I've seen is that the clue giver's speech must consist exclusively of clues (and private consultation with the other clue giver). The clue giver is free to adjust their clue in reaction to anything they hear, and guessers can speak freely.

Important: the clue giver cannot acknowledge the instruction during gameplay. That would certainly extend beyond giving a clue! The guessers must know that their clue giver can play this way prior to the game commencing.

Edit: I just consulted the rules and this is the most relevant section:

> If you are a field operative, you should focus on the table when you are making your guesses. Do not make eye contact with the spymaster while you are guessing. This will help you avoid nonverbal cues.

> When your information is strictly limited to what can be conveyed with one word and one number, you are playing in the spirit of the game.

The author's use of the pronoun "you/your" switches from field ops in that first paragraph to spymasters in that second paragraph, confusingly. With that in mind, it boils down to this: field ops cannot seek non-clue information from spymasters, and spymasters cannot convey non-clue information. The strategy I'm suggesting involves neither!


If you take this idea of communication restrictions to the limit, you could imagine the guessers identifying N sets of cards by a single word each as they discuss their guess. The clue giver listens, then uses the clue that identifies the correct set of N cards.

You really just need an algorithm to generate unique sets of 8 or 9 from the whole board, and identifies those sets by a word.


Yeah it's interesting to take these ideas to the extreme... even at the lower end I don't like it, I think zero communication outside of clues is the best way to follow the spirit of the game. But a little bit of banter and "kibitzing" is what makes it fun too.


I played in a Codenames tournament at CGE's stand at GenCon, and they forbid guessers from communicating at all. Officially, its supposed to be just the clue and number and nothing else.

Of course, I never play this way in my own games


How do guessers arrive at a consensus about what card to touch, if they are forbidden from communicating at all?


officially its a 4 player only game, at least at the tournament. I never do it this way myself though


The communication is only necessary/important if people haven't set this as a convention in the first place. I'll say that prior to ever looking at my clues: "I will give you higher numbers than what I said if you miss by more than 1. THe number I pick will always be high enough as to allow you to, with the +1 guess you get for free, make guesses on all the words I was hinting at.

There's also all kinds of not necessarily intended communicaton from the guessers in the fact that you can listen to which words they were considering and didn't pick. Nothing in the game attempt to say that you should not consider, say, whether they were going in the right or wrong direction in their guessing, but it sure can make a difference in how to approach later clues. If they were being very wrong, there might be a need to double up on words that you intended, and that your guessers missed.

In the same fashion, nothing in the game saying that I cannot listen to those guesses as a member of the other team, whether guesser or spymaster, and then change behaviors to make sure we don't hit words they considered as candidate words without very good reasons. Let them double dip on mistakes, or not make their difficult decisions easier. It's not as if the game demands that everyone that isn't currenly guessing should wear headphones to be sure they disregard what the other team says or does.


You can of course play however you want (and I certainly think this is clever), but imo this is likely against the spirit, and perhaps letter, of the rules.

The rule on giving clues is:

"If you are the spymaster, you are trying to think of a one-word clue that relates to some of the words your team is trying to guess. When you think you have a good clue, you say it. You also say one number, which tells your teammates how many codenames are related to your clue." (emphasis mine).

The rule states that the number should be the number of words related to the clue. There is later provisions allowing you to use zero and infinity, but outside of these carve-outs (and imo the "allowed" language is telling here, since it implies any other number not equal to the number of words is not allowed) I don't think this is legal.


We always allow any number when we play, because part of the thinking is we cannot be sure what the spy master has in mind. Of course, the number is related to the clue but possibly also to the game history up to that point. The teammates and opponents might interpret it wrong, and that’s OK. Infinity is typically used when there is enough info in principle to finish the game and a high risk if you dont; zero is super rare. We do tend to have very aggressive bids with tenuous connections, and 4 or 5 for a clue word are used in most games. Often, they don’t all work out in a single round, but on some lucky boards or in spousal teams, they occasionally work well.


You have a valid point, to which I'll concede. The rule book gives an example (spanning pages 4-5) where a guesser uses prior clues to select a card while the count is still within the number stated by the spymaster, but I suppose an allowance for guessers to deviate in this way does not also imply that spymasters may deviate in this way. Mea culpa!

Taking this a step further, given that it's well-known that a clue is deemed invalid when it pertains to cards in certain non-definitional ways (sounds-like, number of letters, etc.), it seems extremely reasonable to call a clue followed by N invalid if it doesn't pertain to N cards in a definitional way.


Indeed, a good Codenames-playing bot should know how to do all of this, in addition to using its LLM to generate great clues.


You would like to slice (half) an onion in a way that minimizes the variance in volume of the pieces. The problem is then simplified to slicing half an onion in a way that minimizes the variance in cross-sectional area of the pieces at the widest part of the onion.


But the immunity is only presumptive for acts within the outer perimiter of the president's official responsibility. For core constitutional powers, like giving orders to the military, the immunity is absolute.


Note -- AIUI the js and wasmgc are both produced from the same Java codebase. The problem here is that the developers on the Java codebase had started making changes based on their performance when transpiled to javascript (which is only natural -- it seems that they had been targeting js output for a decade).


I don't think that was the only issue.

For example, they point out that they got 40% improvement by adding devirtualization to the compiler. Java by its nature likes to add a whole bunch of virtual method calls. Java devs primarily rely on the JIT to fix that up (and it works pretty well). Javascript relies similarly on that sort of optimization.

WASM, on the other hand, was built first to compile C/C++/Rust code which frequently avoids (or compiles away when it can) virtual method calls.

I imagine this isn't the only issue. For example, I'll guess that dealing with boxing/unboxing of things also introduces a headache that wouldn't be present in similar C/C++ code.

In short, it just so happens that a lot of the optimizations which benefit JS also benefit Java. The one example where they did a Javascript optimization was prefering Maps and Lists over PoJos.


It was all of the above.

We had a pretty awesome team of people working across the entire stack optimizing absolutely everything. The blog post only talks about the three optimizations that made the biggest difference.


Not only that, but a code reader can rely on this too. If you only use a raw for loop when you're skipping around, then the reviewer / future reader can slow down to understand what's happening here. If you use raw for loops for the for-each case, now the reader has to slow down on all your for loops. It's similar to the reasoning for "const everywhere": if you don't mark variables const, I need to figure out as a reader whether the variable is modified later, and that slows me down and increases the mental load of reading a function.


A clean history is one where there is a single commit, "big feature commit", that produces a worktree that is the same as the one produced by "fix 3" in the "unclean" history.


How is this possible, while sharing code? Doesn't this require that pushed code is perfect? What about everyone else working on the same code? Do they wait until you've reached perfection? Or, do you squash the branch once it's complete, with the assumption that there's no other development on/from that temporary branch (I envy you if so)?

(I ask these questions fully assuming I'm doing it wrong.)


> Doesn't this require that pushed code is perfect?

We aren’t talking about pushed code. We are talking about cleaning up the local commit history before pushing it into a shared branch.


And that's the one--and only--reasonable use of rebasing, to squash commits from a branch before merging into main. If engineers find themselves using rebase in any other context than squashing a merge, it's time to re-evaluate the processes/culture around workflow.


What about the context where one works with other people, while sharing code?


When working with published/shared branches with other people, the advice with git has always been that history is history and not to be changed after publishing, unless there is an emergency like a security incident.

Aside from that we need might need to clarify what the question is. With shared code & git, it’s nice to use a branch & merge workflow, and it’s nice to make incoming merges as clean / nice as you can do the resulting history is as smooth as it can be while capturing what happened at a reasonable granularity. These are today’s conventions though, and it’s really up to the team to decide how to balance shared work, and what people feel are the most important workflows and tools.


You fix your local tree before sharing it. Alternatively, you can communicate with your team and tell them they'll need to run git fetch && git rebase -i origin/main to drop your erroneously merged commits.


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

Search: