ledauphin

yeah, this just feels like one of those things that's begging for a lazy (on first use) initialization. if you can't share or transfer the socket between threads in the first place, then your code will definitionally not be planning to use the object in the main thread.

I would like for somebody to pass a law providing for automatic and significant direct-to-customer penalty payments when these things "happen".

okay, I think what I ultimately missed is that this is just a new language for the existing engine. I may not be the world's most careful reader.

this is helpful. and i appreciate the intellectual/technological humility.

i think there's a decent chance we end up giving Dagger a spin this year.

i want to move away from GitHub Actions and I also want to move away from some bespoke monorepo tooling for something that's a better overall orchestrator of 'things'. Dagger scratches some of those itches, or seems to, so I've had my eye on it for a while. Knowing that they're trying to also help me define and use containerized environments - I sort of assumed I'd have to bring those myself.

I had missed the fact that Dagger is apparently trying to... replace? Docker for container definitions. That's a pretty big vision.

I really like the ambition here; it's very hard for me to translate this into belief that I could start using this now and actually replace some of my existing tooling.

At the same time, I kind of hate that they went for bash-compatible. I know everybody thinks bash is unbeatable, but at some point _surely_ we're going to move past its awful syntax and footguns (and SQL, and can I have a pony?)...

i'd read several state Ag agencies that have known this. It's why you keep watering newly planted trees even after their leaves fall, until the ground freezes. The roots will keep growing.

_thank you_. this is the comment i came here desperately hoping somebody had already made.

It's not that names are bad - it's that when you use intermediate variables, my brain has to check whether any of the variables are used more than once - i.e., is the flow here completely linear, or is there a hidden branching structure?

the chain of methods approach makes it _completely_ clear that there is no 'tree' in the code.

If you want names (and that's a fine thing to want!) then _either_ comments or defining separate _functions_, e.g `function messageRecipient`, `function friends`, `function visibleToScroll`) is the way to go. Although with many languages that don't have a built-in pipe operator, it becomes harder to express the nice linear flow in a top-to-bottom arrangement if you take the function route. A good reason for languages to keep converging toward syntax for pipes!

For my money, you only define those functions if you want to reuse them later - additional indirection is not usually helpful - so comments would be my choice if there were no other uses of these selectors.

I'm equal parts amused and bewildered that this author with so many interesting thoughts has managed not to see what pretty much every other serious reader of Lord of the Rings has pointed out over decades - the entire story is about a weak and almost completely unknown set of people who were "chosen" only by the most inexplicable series of events anyone could imagine - who through no inherent power of their own manage to save the world by nothing more or less than the choice to be kind to a pitiful (though clearly treacherous) creature... and who then go right back home where they belong, dismissing any notion of chosenness beyond the ordinary sort where everyone is chosen to do what is good for their neighbors.

the Hobbits pursued not greatness or destiny, but took the only path toward life available to them and then returned to let the rest of the world get on with living.

this is the way.

also works great in combination with `set -g base-index 1` so that switching between the first 9 windows can be done naturally, with `-1, `-2, etc.

I generally agree with you, but I'd be interested to hear your take on what the purpose of CI _actually is_.

It seems to me that a big part of the problem here (which I have also seen/experienced) is that there's no one specific thing that something like GitHub Actions is uniquely suited for. Instead, people want "a bunch of stuff to happen" when somebody pushes a commit, and they imagine that the best way to trigger all of that is to have an incredibly complex - and also bespoke - system on the other end that does all of it.

It's like we learned the importance of modularity in the the realm of software design, but never applied what we learned to the tools that we work with.

I read this whole article and I can't figure out what they're actually claiming, other than some version of "we should try to imagine that things might be different than we imagine."

can somebody (or ChatGPT) take a stab at making this make more sense?

do you use React capabilities exclusively for state management? I have found that they inevitably fall apart when things get sufficiently complex, which has me reaching for one of the many MANY 'other' state management libraries.... which then sometimes has me reaching for other related things, which then....

this seems implausible to me based on how heat generally transfers...

i agree it's not cunning or a plan, but that doesn't exclude the possibility that this is an evolutionary/societal adaptation that _really works_.

Two things can be true at the same time: that this type of banter has undesirable consequences as well as desirable ones. This type of nuance is generally the sort of thing that's worth trying to understand before you try to 'fix' it.

it's at the very least an evil plot to stop users (and extension authors) from _making their own decisions_ about the efficiency trade-off.

which is really just absurd when you think about it. I don't care about another hour of battery life, but even if I did, I'd be perfectly happy if Chrome just told me "hey these extensions aren't very battery-efficient!" and I got to make my own decision about that.

when you say "our in-memory engine", are you talking about dataframe or the lazyframe?

i've been using iterm for... years and had never noticed this setting. Which is a killer feature for my use of emacs.

thanks!

thank you!

We have a framework at <job> to do memoization as well as distributed compute - in fact the memoization was mostly a happy side effect of the need to transfer serialized function arguments to other machines.

Your addition of code/runtime dependencies intrigues me. I will probably take a look at your code to try to understand this better.

I somehow doubt there's enough overlap for us to open source our work and try to merge with yours, but it's really cool to see other people working on similar concepts. I predict we'll see a lot more frameworks like these that lean on mathematical principles like functional purity in the future.

can I still use my keyboard shortcuts for switching between sessions and windows within the session?

I am much happier with that muscle memory than whatever the iterm shortcuts would be.

is it accurate? the rain and wind sensors with no moving parts seem like they'd be a significant compromise over transitional moving anemometers, etc.

Hi - this sounds really interesting. If the author sees this - would you consider putting some non-technical features in the list? "cross-platform" and "zero dependencies" are great, but those aren't really helping me decide whether I might benefit from giving this a spin.

From skimming the rest of the readme, I kind of think this is meant for "visually navigating tables in a database, as read-only operations." But I may very well be wrong. A summary of the actual use cases would be very helpful!

I'm interested to read more about the "personal property liability" thing in the US. I have never heard anyone explain why your example would expose you to liability. There are other things I can imagine, like unfenced swimming pools or open sinkholes that you knew about, but tree roots and general features of the land? Maybe there's a long history of case law about this.

a friend of mine organized 40+ player games of CTF at night on campus back in the day. The nighttime element was really key to how much fun it was.

I don't think we had many, if any, disputes about whether anyone had been tagged, even without the belt flags.

I love the "ball flag" idea.

do you have a reference for how to use static typing for polars columns? I haven't seen this in their docs...

this is a hilarious take. It's certainly more serious for their customers, but is it more serious for the responsible parties (the board of directors)? It seems clearly not.

I don't think the main problem backend developers have with frontend work is the language. As you say, Typescript is a really good language - in many ways better than Python. I don't think it's even the tooling, although becoming basically competent with two very large tooling stacks is not a trivial matter either.

I think there's a fundamental verbosity to the way most SPAs do data management - I've seen it said elsewhere that when you build a SPA, you basically end up having to reinvent the database, by which it is meant that an inordinate amount of your code is dedicated to extracting data from the backend via an API and then keeping track of that state using mountains of front end code.

At some point, you have to decide - is this really two separate applications (a backend and a frontend), or is it actually just one? If you don't have a need for multiple different clients, and you already have a backend written in Python (or some other backend language, e.g. Elixir, Kotlin), then maybe you can get away with writing a whole lot less code if you can find a framework that fills in that whole in-between layer for you and lets you stick with the language you already have.

an interactive shell really _doesn't_ need to be interoperable between users in the first place, but even a scripting shell doesn't need this either.

This is what the shebang in your scripts is for. If you need to write a script that is going to get shared, you have (at least) two perfectly good options:

  - use bash (or some lowest common denominator)
  - use a fancier (better?) shell, like fish/xonsh/nushell/oil and just require that everyone have that shell installed (they don't have to use it as a daily driver). 

xonsh is not really any different from other shells - it can be installed as an isolated environment with its own runtime (in this case Python)

A third and usually better option is to use a dedicated scripting language - this is of course an opinion, but many people have recognized that anything longer than ~50 lines and that will need to be iterated upon in the future is a bad fit for a shell-like language.

it really isn't. but to be fair, it got a lot worse many years after the acquisition (2008), so it's hard to be certain whose fault it was.