• 0 Posts
  • 369 Comments
Joined 2 years ago
cake
Cake day: July 3rd, 2023

help-circle




  • This couldn’t be further from the truth, and it’s pretty clear you don’t actually play the game. I had no idea this misconception was so common.

    Chess is ALL ABOUT creativity and figuring out how to outplay your opponent and secure a win. It’s a game of strategy and tactics, of timing and technique. The way “memorization” works is that players tend to have some number of moves in their opening(s) memorized (typically 5-10, though top players can go to greater depth), at which point they are “out of book” and into the middlegame, which is where the game is actually played using some combination of positional ideas, tactics, and calculation. Many players opt to play less theoretically viable openings (that is, variations that are not quite as good with best play), because it gets their opponent out of book faster. “Novelties” (a move in a variation not previously played by a master/grandmaster in a tournament) are played all of the time, even by grandmasters.


  • Based on the number of comments in this thread, apparently this is a common misconception. Memorization is not the primary skill of chess. Knowledge of chess principles and common ideas, strategies, and tactics and the ability to synthesize those ideas with elements of the current position are the primary skill of chess. In fact, novel problem solving is very fundamental to the game.

    Opening theory prep ultimately makes up a pretty small part of the game (though it is more pronounced at top levels of play). The primary purpose of studying openings is not to just memorize a bunch of lines (though having lines prepped is helpful), but to understand the common thematic elements that arise from said openings and common middlegame positions and ideas.


  • Do you know their rating? Tbh most people’s idea of being “pretty good at chess” is actually not very good at all (I don’t mean that as an insult, more lack of familiarity with the game).

    That’s not to say that it’s impossible for someone to think those things and be a strong chess player, but it’s probably not super common. I’ve actually ran into a couple people at a local chess club with “interesting” ideas about vaccines and uh… let’s just say they were not hard to beat (I think I mated one guy in like 12 moves). And btw, I’m not even a super strong chess player myself (~1134 USCF). But like, they probably would seem really strong to someone that just occasionally plays chess at family gatherings or whatnot. Chess is a game with a low skill floor and very high skill ceiling, so you have a huge range in ability.


  • This is not at all what chess is. This reads to me like you don’t really play chess?

    Like sure, good chess players have studied opening theory for the openings they play (and top players know at least some theory about most competitive openings), but there’s so much more to the game than simple memorization. Memorizing a bunch of lines and doing nothing else will get you nowhere with the game. Chess is about principles, concepts, ideas, strategies. It’s about tactics and positional ideas and how the two intersect. It’s about tempo and conducting the initiative. There’s a reason it’s the game with the most number of books written about it by a large margin. It’s an incredibly deep game that rewards investment and fine-tuning your own learning process (and, in fact, a great deal of unlearning bad ideas you learned earlier).

    It is decidedly not a game about memorization, even if there is some amount of it involved. At high level of play, memorization (or what we simply call “prep”) is table stakes for playing the actual game. At lower levels, many players don’t know a lot of opening theory and simply rely on some combination of positional ideas, tactics, and calculation.

    Do you know what rating your friend was at? In my experience, the super strong players I’ve met (including a Senior Master that occasionally visits our chess club who’s 2450 USCF or so) are incredibly intelligent and sharp. Anecdotally in my own chess career (only ~1134 USCF atm, though I think I’m a bit underrated due to my last tournament being in 2023), I’ve definitely noticed a difference in my own thinking since I started studying chess. Progressing in chess involves a lot of meta-cognitive thinking, and that kind of thing translates to all kinds of things in life.












  • I’d definitely prefer more sunlight in the morning. It’s 6:45am right now and the sun hasn’t even risen yet and won’t start for another half hour.

    Meanwhile, more sunlight later in the day is often gone to waste anyway, between work/commute/dinner/etc. It’s especially wasteful later in the summer… You already have sunlight super late in the day anyway.

    But honestly, I would take either as long as it stops changing.


  • Shit! Sorry, got my wires crossed, I actually meant locality of behavior. Basically, if you’re passing a monad around a bunch without sugar you can’t easily tell what’s in it after a while. Or at least I assume so, I’ve never written anything big in Haskell, just tons of little things.

    I’m not sure if I entirely follow, but in general you actually have much better locality of behavior in Haskell (and FP languages in general) than imperative/OOP languages, because so much more is explicitly passed around and immutable. Monads aren’t an exception to this. Most monadic functions are returning values rather than mutating some distant state somewhere. Statefulness (or perhaps more precisely, mutable aliasing) is the antithesis of locality of behavior, and Haskell gives you many tools to avoid it (even though you can still do it if you truly need it).

    I’m not really sure what you mean by “don’t really know what’s in it after a while”. It might be helpful to remember that lists are monads. If I’m passing around a list, there’s not really any confusion as to what it is, no? The same concept applies to any monadic value you pass around.

    Yeah, that makes tons of sense. It sounds like Transaction is doing what a string might in another language, but just way more elegantly,

    I think you might have misunderstood what I was describing. The code we write doesn’t actually change, but the behavior of the code changes due to the particular monad’s semantics. So for example, let’s say I write a query that updates some rows in a table, returning a count of the rows affected. In this Transaction code block, let’s say I execute this query and then send the returned number of rows to an external service. In code, it looks like the API call immediately follows the database call. To give some Haskell pseudocode:

    example :: Transaction ()
    example = do
      affectedRows <-  doUpdateQuery
      doApiCall affectedRows
      return ()
    

    But because of how Transaction is defined, the actual order of operations when example is run becomes this:

    1. Send BEGIN;to DB
    2. Call doUpdateQuery
    3. Send COMMIT; to DB
    4. If transaction was successfully committed, execute doApiCall affectedRows. Otherwise, do nothing

    In essence, the idea is to allow you to write code where you can colocate your side-effectful code with your database code, without worrying about accidentally holding a transaction open unnecessarily (which can be costly) or firing off an API call mistakenly. In fact, you don’t actually have to worry about managing the transaction at all, it’s all done for you.

    which fits into the data generation kind of application. I have no idea how you’d code a game or embedded real-time system in a non-ugly way, though.

    I mean, you’re not going to be using an SQL database most likely for either of those applications (I realize I assumed that was obvious when talking about transactions, but perhaps that was a mistake to assume), so it’s not really applicable.

    I also generally get the impression that you have a notion that Haskell has some special, amorphous data-processing niche and doesn’t really get used in the way other languages do, and if that’s the case, I’d certainly like to dispel that notion. As I mentioned above, we have a pretty sizeable backend codebase written in Haskell, serving up HTTP JSON APIs for a SaaS product in production. Our APIs drive all (well, most) user interaction with the app. It’s a very good choice for the typical database-driven web and mobile applications of businesses.

    Ironically, I actually probably wouldn’t use Haskell for heavy data processing tasks, namely because Python has such an immense ecosystem for it (whether or not it should is another matter, but it is what it is)… What Haskell is great at is stuff like domain modeling, application code (particularly web applications where correctness matters a lot, like fintech, healthcare, cybersecurity, etc.), compilers/parsers/DSLs, CLI tools, and so on.*