jabbawookiees

Well you could have a negotiation like so:

Recruiter: The offer is $100k.

Me: I want 120k and WFH.

Recruiter: I checked with the manager. The best we can do is either 120k but you show up every day or 90k remote.

Me: I'm already paid 110k and work remote. Sorry.

Recruiter: Oh, alright. We can't afford that. We'll continue our search with other candidates. Thanks for your time.

Both "options" presented by the recruiter are "alternatives" and they're both "negotiated agreements" (i.e. a meeting in the middle).

BATNA is short for what you get when negotiations fail and you walk away with no deal. (In this case, staying at the 110k remote job is one party's, the other party's is to keep interviewing more candidates.)

I had once had this aversion to neologisms for the sake of them too. Then I took some math classes and understood that saying "ring" is better than saying "commutative group with multiplication satisfying the following axioms...". Ultimately, it's helpful to invoke words that a group of people commonly understands, even if it seems to the uninitiated that it's saying nothing of importance.

The word "BATNA" is used a lot in discussions on negotiations. These books are full of tips on thinking about/finding out your counterpart's BATNA, coming to the negotiation table with a strong BATNA, conveying your BATNA to the other person, etc. In this context, the word/acronym conveys a very specific meaning that unspecialized English words like "option" and "alternative" don't capture.

Not sure if this is what GP meant, but one funny thing about carbon credits is that energy producers that produce no emissions but don't do carbon capture (e.g. solar farms) can earn still carbon credits which they can sell to carbon emitters (e.g. steel mills). Zero is not a negative number, so the entire world can one day be "carbon neutral" following this funny accounting and physics won't care.

Ticket is a class

do ... end is how you create no-argument functions similar to () => { ... } in JavaScript. There's some technical nuance but that's the spirit of it.

In Ruby you can call methods without needing to place parentheses.

So this roughly translates to the JavaScript code:

RSpec.describe(Ticket, () => {

  context('when...', () => {
    ...
  });

});

This specific code describes a test that uses the RSpec testing framework. In RSpec, "context" and "it" are just functions that you call to describe chunks of tests and individual tests respectively.

Some Rubyists would say that the combination of these syntax rules (do-end and optional parentheses for function calls) allow you to make "domain specific languages" (DSLs as they're known in the community) without needing to write your own parser.

I think it's pretty plain to see the impact in expressiveness if you look at the equivalent Python unittest suite. The Python equivalent would have classes that inherit unittest.TestCase and methods named like test_when_ticket_is_closed.

In Python land, classes and method declarations are repurposed because the syntax is what it is. In Ruby, you can practically make your own faux keywords by abusing do-end to accept nested blocks.

This is the first time I'm hearing this. Don't they both use ELF? Where can I read more on this?

My take: RecipeUI a Postman-like tool that offers convenient type safety and autocomplete on top of what Postman already does.

What is Postman? It's a tool that allows you to configure, save, and replay HTTP requests. It helps developers building backend server APIs, so they don't have to keep fiddling around with their frontend. In many greenfield projects, the frontend doesn't even exist yet and Postman is effectively the only way to easily test what you're working on.

The alternative to postman is writing custom Python/NodeJS/etc programs to send these requests or painfully doing it with curl and bash.

I think it's cool and I'll probably try it the next time I have to work on REST APIs.

My understanding is that this is true only if you distribute your executables which most people don't do for server-side code.

Or they could have saved themselves a CPU cycle every time they needed to index an array.

Don't get me wrong, non-zero-cost abstractions are great when they improve developer ergonomics commensurate to how much they cost. Garbage collection at the expense of GC overhead? Yes please. Classes and methods and inheritance at the expense of vtable lookups? Sure!

One-indexed arrays at the expense of either giving up the memory of the first item or always subtracting every index operation? Eh... I think I'd rather count from zero.

I have no experience with SKI calculus so I may be misinterpreting how to apply these functions. But it seems to me that the definition of F doesn't work quite right. After trying my own hand at it for several minutes and getting stuck, I looked at the Wikipedia page and found a different definition for S.

I don't know of these two systems with the same name are computationally equivalent or if the author simply made a crucial mistake in the definitions.

I made one a few days ago.

https://news.ycombinator.com/item?id=30509847

I just filled in both the url and text fields and it just worked for me.

I don't believe you're correct that intellectual property has slowed down progress.

Linux and the GNU project use copyright and they're doing well. Arguably better than the permissive BSDs for which copyright law might as well not exist. But even GNU/Linux falls far behind Windows and MacOS for regular desktop users.

Software is already the ultimate gift-able creation where you can make something for yourself and everyone else. It's cheap to make at home and it's free to distribute. Yet even here commercial products protected by IP are still far superior to things made by hobbyists just wanting to share with the world.

Medicines? Most biotechnologists I know are working at university research labs aiming to churn papers or they're working at a company that exists because of patent law. I don't know anyone researching new drugs in their spare time just to gift it to the world.

So I guess as a counterpoint, I know a hundred startup founders who made something looking to make a buck. I know zero people working on expensive technical problems purely because they care about solving it.

On the other hand, if you're a startup founder with a brilliant new idea (say, some new way to synchronize audio across multiple speakers), why would you ever leave a cushy corporate job to build it if nothing protects you from large corporations copying everything you've made?

It seems, judging by how people have been complaining that their Google Homes have been doing worse, that maybe the system is working as intended and Google ought to pay for patent licenses to the people who first took the risk to build these multispeaker systems and proved that it was a good idea.

It's possible that the solution isn't to scrap intellectual property entirely but update the numbers to reflect the more innovative and interconnected world of 2022 instead of the 1600s when it was officially conceived.

Have you heard of the storyshots addon? I pretty much ignore its output but I've found it a useful sanity check to see that everything at least renders without errors without any additional effort. I no longer make simple render tests when a story suffices.

https://github.com/storybookjs/storybook/tree/main/addons/st...