almostdeadguy

Haha I think the irony here will fly over some heads, this is great though.

Young, inexperienced people have a hard time saying “no”. It’s even harder when working 120 hour weeks where you have less than 7 hours a day outside work (not even enough to get a full nights rest): https://www.businessinsider.com/elon-musk-doge-work-silicon-...

Sleep deprivation, stress and overwork, controlling the lives of participants, targeting at risk populations, etc. are cult programming techniques.

It was flagged this morning and I haven’t seen it on the front page until just now. https://web.archive.org/web/20250203054131/https://news.ycom...

100%, seems like a clear effort to bury anything critical or even just concerned about the actions of Musk, Altman, and the other tech billionaires in their relationship with the new administration. I saw this article also got flagged and there is nothing objectionable about it: https://www.wired.com/story/elon-musk-government-young-engin...

Almost all are trans and all are rationalists. OK.

Hope Sam Altman is getting his money's worth out of that Trump campaign contribution. Glorious days to be living under the term of a new Boris Yeltsin. Pawning and strip-mining the federal apparatus to the most loyal friends and highest bidders.

I'm sorry, what?

Like most reboots/long awaited sequels I was very skeptical of it and it absolutely blew my mind. It's one of the most beautifully shot and hallucinatory TV series I've ever seen. I think it's his best work.

Compression libraries, OpenSSL, ICU, etc. are all common dependencies for databases.

Looking at the dependencies list (https://gist.github.com/tisonkun/06550d2dcd9cf6551887ee6305e...) I see plenty of reasonable things like:

* Base64/checksum/compression encoding libraries

* Encryption/hash libraries

* Platform-specific bindings (likely conditional dependencies)

* Bit hacking/casting/zero-copy libraries like bytemuck, zerocopy, zero-vec, etc.

* "Small"/stack allocated data structure libraries (smallvec, tinystr, etc.)

* Unicode libraries

There are certainly things that would add bloat too, but I think it's silly to pretend like everything here is something a database engine would need custom implementations of.

Just tried this using similar prompting to the original and it required several rounds of telling it about compiler errors before generating something that looked suspiciously like a _very_ basic version of "nom", without any of the state/position tracking or the nice error model in megaparsec. I suspect anyone talking about instances where doing something like this "just works" is a grifter/aspiring AI influencer.

It's fine to have preferences or cognitive inertia towards working a certain way. It's silly to pretend that doing things this way conveys some kind of universalist advantage or to conjure up a bunch of imaginary/highly niche scenarios (I'm remote coding over 28.8k at the bottom of the ocean and have no access to a browser anywhere!) that necessitate working this way for argumentative purposes.

2 is the factor, not the initial delay.

It drives me crazy personally, I think Arcs abandoned this for good reason. Root has a major rules sprawl issue IMO. Many rules are spread throughout the cards, the "Learning to Play" guide, the "Law of Root", the player mats, etc. I don't actually think you can really learn the game unless you have the board and player mats right in front of you. Wehrle's predilection for thematic names with clearer/plainer synonyms I think makes this hard as well.

People who praise the game by saying "the board teaches you how to play" are technically correct, but I think this glosses over how difficult it is to internalize turn structure before sitting down to play the game.

That being said, it's not the worst game I've ever had to learn. That dubious distinction probably belongs to Wehrle's John Company (scowling at you "Events In India" rules).

Et tu evildojo666?

My point was not to question that people would write tests, the point I'm making is that it's tempting to generate both code and tests once you start using an LLM to generate large swaths of code, and then the assurance that tests give you goes out the window.

I'm not convinced that using AI as more than auto-complete is really a viable solution, because you can't shortcut an understanding of the problem domain to be assured of the correctness of code (and at that point the AI has mostly saved you some typing). The theory-crafting process of building software is probably the most important aspect of it. It not only provides assurance of the correctness of what you're building, it provides feedback into product development (restrictions, pushback that suggests alternate ways of doing things, etc.).

With some patience and practice, I think reasoning about borrows becomes second nature. And what it buys you with lexing/parsing is the ability to do zero-copy parsing.

> Unit, integration, e2e, types and linters would catch most of the things you mention.

Who’s writing those?

Different game, but Carrom is supposed to be great as well. I haven't played it but many of the folks I follow on BGG prefer it to Crokinole.

Confused why this is displayed as being 9 hours old when I remember seeing it on the front page a couple days ago. Search also seems to confirm this: https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=fal...

It's not even clear what "longest running continuous government" means or how it would be defined.

Treating performance and reliability (which is inescapably impacted upon by performance characteristics) as externalities is a great way to create perverse incentives for your engineering team.

Also this reads like a cry for help:

> Therefore, to keep our Kubernetes clusters optimized, it would necessitate mandating all teams to perpetually engage in complex manual optimization processes indefinitely, or until Mercari goes out of business.

I truly don't understand why this isn't more widely discussed (I've seen several "GH Actions Gotchas" articles where this isn't mentioned). Many of the community actions also seem to be designed to run as short jobs to paper around missing features (for ex: https://github.com/dorny/paths-filter ), that end up eating up an enormous amount of your minutes budget.

> Replace Monoid by Appendable, Monad by Composable, Functor by Runnable, etc. and most programming languages are "category theory".

I'm not sure an "Appendable" Int or IO type, or a "Runnable" / "Composable" List type is any less confusing to Joe Programmer. These descriptions do not articulate the same things implied by the Monoid, Functor, and Monad laws. Some of these aren't even correct (i.e. not all Functors are "Runnable", Monadic types do not necessarily compose directly, just via Kleisli composition).

> This says little about whether knowing the field of category theory will be useful to programming. Indeed, I think there's a good argument to say Haskell programming is much harmed by it.

> If its authors hadnt used their knowledge of category theory, but rather named the abstractions in more ordinary terms, the language would be more useful to more people.

I think this is really the least of Haskell's problems. Mystifying/poorly written monad tutorials and conflation with IO (or confusion about how IO works in the haskell runtime) is more responsible for confusing new programmers than the concept itself. I have no background in mathematics above undergrad calc 2 and I was able to understand them just fine.

This is a bit too navel-gazing delve into what was more succinctly said in a quote often attributed to Reiner Knizia: “When playing a game, the goal is to win, but it is the goal that is important, not the winning.”

I’d also recommend the author delve into the existing catalog of negotiation games, since the linked post in the top of this article seems to indicate that they aren’t be aware some of the brilliant games in the genre:

* Cosmic Encounter - Players play one of several wildly unbalanced alien races with a special power and are forced into a series of confrontations where they must either battle or negotiate. One of the few games I’ve played where 1 to N players can win (and I’ve seen cooperative wins before). The game revolves almost entirely around negotiation (with your matched opponent, with other players at the table as potential allies, etc)

* John Company - A wild simulation of running the British East India Trading company. Players hold different positions within the company providing different privileges and effectively must negotiate to better their position. Players can also work to undermine the company at the expense of those more invested in it, or can hedge against the company’s failure.

* Quo Vadis? - Players are Roman politicians who must move their senators through a series of committees, to the inner sanctum, where the player with the most prestige wins. Moving through committees occurs through votes, and prestige can be obtained through voting (as an incentive provided by the game) for others or by negotiating more prestige.

Who is upvoting this and why?

> If you are looking to learn the language, I recommend Learn You A Haskell.

I definitely don't recommend this. While cute, Learn You A Haskell is lacking a lot of pragmatic advice about how to write software in haskell. It's good for getting you up to the FAM trio of type classes but leaves out a lot of practical advice around things like navigating base (what to use and ditch from it), the available community libraries, topics like monad transformers, and pragmatic advice around things like error handling, testing, and isolating effects from tests that come up very quickly in real world Haskell development.

Haskell Programming From First Principles is a much better book IMO: https://haskellbook.com/

I haven't written Haskell in a while, but there may be even better books today as well.

Old-school euros (sometimes called "Old-school German games" or OGs[1]) are sadly a dying category of game amongst the new crop of narrative-driven games or highly complex and thematic solitaire Euros. Truly a shame, since these games along w/ train games [2] and some economic games (Splotter games [3], auction games like Neu Heimat/The Estates [4], etc.) are some of the most intriguing and interactive games you can play. They are also games that are truly about playing your opponents (choosing actions that encourage them to better your position, learning to play the game well at different player counts or w/ players of different skill levels, etc.).

A recent evolution of the term "Euro" has given it the connotation of describing games that are largely solitaire, but historically it was used to denote games that lacked an element of chance (little to no use of shuffled cards, dice, or other sources of randomness), that were often not thematic or based on a licensed property, but that were often _highly_ interactive. Knizia in particular has designed some of the best interactive multiplayer games of all time.

As much as I appreciate the resurgence of interest in board games, I don't love that the designs seeing the most press are narrative games that don't advance the medium or really lend themselves well to the format of tabletop games, but rather seem to be an attempt to bolt on the strengths of video games in a clumsy way.

[1] https://boardgamegeek.com/guild/3948

[2] https://boardgamegeek.com/boardgamefamily/19/series-18xx https://boardgamegeek.com/boardgamepublisher/65/winsome-game...

[3] https://boardgamegeek.com/boardgamepublisher/140/splotter-sp...

[4] https://boardgamegeek.com/boardgame/249381/estates

This conversation almost always strikes me as a pointless exercise. We can't even agree on what it means to be "simple" or precisely define what it means to have "less features" in a programming language (or perhaps we can by saying complexity is anything more than what is provided by machine language, but we get no closer to an understanding of how much of this is necessary or when this is desirable). A programming language is an abstraction over machines and inevitably all languages introduce features to unburden the programmer from extraneous detail, toil, or precarity involved in orchestrating the operation of that machine. The author is correct that many "simple" languages like Brainfuck are actually very complex to use, but this strikes at the inherent feebleness of the premise that we can clearly define what we mean by a "simple" language (or at least any clarity on when the complexity tax is worthwhile or not worthwhile). Many programming language features are conditioned on a trade-off that having to think about X less in exchange for requiring knowledge of Y is a net benefit to the programmer. If we take the idea that simplicity means "less features" at face value, we throw out the notion of any high level language having the potential to be simple.

The oft-cited Rich Hickey talk [0] I think gets _somewhat_ closer to vindicating the concept of simplicity being something we can talk about more objectively, but I'm still not convinced the concept is worth redeeming. Instead I would propose that languages should have a clear purpose and context in mind. Designing a language with clarity about the intended scale and pace of change in software that will be built in the language, the domain/category of software it is well adapted to build (i.e. embedded, web, OS, compilers, mathematics, mobile, servers, games, and so forth), and the nature of the teams and the public community it intends to support supersedes and encompasses whatever we want to call "simplicity" or "ease". What is easy, simple, helpful, etc. is incidental to how purposefully built a language is to a set of use cases.

[0]: https://www.youtube.com/watch?v=LKtk3HCgTa8

Why would we assume they are (I'm not sure that the "someone somewhere" part of that is material either) going to use a mining rig already to assess the merits of mining rigs for heating? That's tautological.

The problem with the "inheritance isn't part of OO" take is that every single one of the languages we call object-oriented that gained mass adoption have inheritance, including Alan Kay's own smalltalk. There have been entire books written about object-oriented design describing ways to use (or not use) inheritance in program design. So whether or not it was intended to be important by the author of the term is immaterial, it for all intents and purposes is a crucial part of object oriented languages.

Inheritance is not the only problem w/ OO either, many things are straight up awkward to express when you must couple data and code together. Many 2+-argument function w/ disparate parameter types create confusion about which class "owns" the definition of the function.

You also don't need to marry data and code to get the benefits of encapsulation. Many functional languages in the ML family have developed clever solutions to encapsulate the definition of a datatype while exposing it to module-local functions. There's no need for the datatype to carry a method around with it to support this.