Maybe don't use any LLM to do your writing for your Master's thesis?

Increasingly, a masters degree is now a piece of paper attesting that you managed to cheat your way through uni using AI. "Congrats, you spent X years at Y location. You unlocked the right to play [role] - we recommend you keep using AI to do your new job."

I just don’t hire or entertain people who have credentials maxed

Work experience and actual outliers are better signals. Anyone can read a book and get a 100.

wrong. You can actually get great stuff done. instead of just having a lame master thesis, you can actually build meaningful stuff and write about it. You can basically have a PhD done for your master and then get a tripple PhD if you're actually pursuing a PhD...

So why should you use it for coding then?

You shouldn't. Using LLMs for coding is also considered fraud by many academic boards if that code is a core contribution of the thesis.

where do you guys live. its 2026 and this is the new world order. i'm a researcher at one of the best labs in the world and we use claude code 24/7 for our bioinformatics needs.

Will you be mailing your master's degree to Anthropic or claiming it as your own?

All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.

That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it.

For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.

This is problematic if you use tRPC for example.

You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()`

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.

Instead of using the reviver you can deserialize as a plain string, then later reassign the property as the type you want. E.g.:

  const myObject = JSON.parse(text);
  myObject.date = new Date(myObject.date);

I've been doing this for so long and never knew there was a reviver param, thanks - that is super useful.

Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.

The main advantage of json is that it’s human readable and writable. Beyond that, it has no notion of user created data types so anyone using it has to do custom unmarshalling to get a type apart from sting, number, dict and list.

Even if you don't explicitly provide a schema, you implicitly still have one. The recipient needs to know what you're sending them. Unless maybe you want to start parsing JSON payloads with an LLM.

Most JSON libraries in typed languages require this for data binding to complex types though.

Which is why many developers only use JavaScript Object Notation for JavaScript objects, and only JavaScript objects that can losslessly be written as JSON. Which this proposal explicitly does not support.

{"$temporal_type":"PlainYearMonth","$data":"........"}

> For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.

I don't know if I'm missing something, but that's exactly how I'd expect it to compose. Does the following do what you wanted your snippet to do?

  Temporal.PlainYearMonth.from(JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))))

JSON.stringify and JSON.parse should not be viewed as strict inverses of each other. `JSON.parse(JSON.stringify(x)) = x` is only true for a for a small category of values. That category is even smaller if parsing is happening in a different place than stringification because JSON doesn't specify runtime characteristics. This can lead to things like JSON parsing incorrect in JS because they're too large for JS to represent as a number.

This seems more to do with how JSON works than Temporal. There are libraries such as Devalue which will handle this for you

`devalue.parse(devalue.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})`

https://www.npmjs.com/package/devalue

This is also true of JavaScript Date instances, so I’m curious what solution you had that did work with raw JSON stringify and parse.

Would a plain data object be an instance of PlainYearMonth?

If not, that regardless of being plain data or a serialized object with functions, you'd still need to convert it to the type you want.

Then you're talking about changing JSON.parse to start parsing some schema as a type instead of object, which would break compatibility.

The JSON types are string, number, boolean, null, object and array. So how could the suggested code possibly work? Do you want JSON.parse to do arbitrary code execution like Python's pickle?

This is false, he has been on Bluesky since 2024. https://bsky.app/profile/toni.bsky.team

"17 posts" since 2024.

13 of them are reposts, and 2 of them are his own actual posts and then made 2 more posts about becoming the interim CEO of Bluesky and then "thanking" Jay.

That doesn't seem like he even uses it regularly only up until the leadership changes.

Last activity 17 days ago, 23 days ago, 3 months ago, 3 months ago, 4 months ago

Dive deeper with PDSLS

https://pdsls.dev/at://did:plc:cwf4mmm7mpzistinx3ox2zhj#coll...

Unicorns also don't exist, but we don't change the definition to include horses.

The first level argument is that old horse, burden of proof.