RyanCavanaugh

This story is bigger than Watergate by orders of magnitude, if it's true.

There have been "Retired intelligence officer says he has evidence of aliens" stories floating in fringe media for decades, and all of them have turned out to be cranks. Bob Lazar has been working this beat since 1989; where's the evidence?

Maybe eventually one of these times it'll all be true, but skepticism -- extreme skepticism -- should absolutely be the default position here.

Context matters. Is a "web developer" someone who makes web pages, or works on a browser rendering engine?

This is still useless because there's already a single issuer of concert tickets: The ticket vendor. The vendor already has a plain-old database of the tickets which can handle transactions at a tiny fraction of the cost, and can capture the value of the transaction in fees itself. The vendor has no incentive to have blockchain miners/stakers capture that value instead.

What experiment would you run to determine if a given text input / text output interface had an "internal understanding of chess"?

I presume they're referring to https://medium.com/flow-type/clarity-on-flows-direction-and-...

(I have worked on the TypeScript team since before its initial release)

While it's true that TS would have been started with or without Angular, I think OP is largely correct in the influence that Angular's embrace of TS had in TS's long-term success.

It's difficult to see these days, but if you were watching TypeScript's adoption numbers back when Angular made its TypeScript announcement, there is a marked inflection point when that happened. I was running lots of charts and graphs at the time tracking all kinds of data, and in every graph, you could see the Angular announcement in the chart; it's where the line went from kinda slow and linear to kinda fast and exponential. It was a true discontinuity in the second derivative.

We can't run history twice and see what would have happened without Angular, but I think the quantitative impact in this timeline is undeniable.

TypeScript tries to be sound too. It wouldn't really make sense to write a type checker if that wasn't your goal. As the person who wrote the "100% soundness is a non-goal" line in the design goals document, that's there to serve the same role as "Flow sometimes has to make a tradeoff" in the Flow docs in terms of clarifying whether or not 100% soundness is a design goal. For both projects, the answer is "no".

It's unfortunate that people have, over the years, decided that just being upfront about this fact means that TypeScript has a vastly different prioritization of soundness than Flow. We don't; both checkers use soundness as the default assumption when designing behavior.

In TypeScript, type guards are considered to be exhaustive, so if you have a string | number and check it against a function that says it returns "x is number", then TypeScript will think that in the negative case, it's a string.

If isInteger was marked as a type guard, then you could write code like this:

  function f(s: string | number) {
    if (!Number.isInteger(s)) {
      console.log(s.substring(0, 0));
    }
  }

which is clearly wrong.

There's an open feature request for a new kind of "one-sided" type guards that don't cause narrowing when they return false.

Total type soundness is not a goal of Flow.

For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will:

  let m = [1, 2, 3];
  console.log(m[4].toFixed());

Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.

Maybe this is simple in implementation, but it's definitely not simple in developer experience.

You grab some code in one of your old projects for implementing a binary search. Can you copy-paste it into a new project that targets a newer language version?

The question isn't as simple as "does it have syntax errors", because we're talking about changing semantics here. Given a set of semantic changes and a piece of code, figuring out (either as a human or a computer) whether the observable characteristics of that code have changed is somewhere between vexing and impossible. It's entirely possible, for example, that your code encounters changed semantics, but not in a way that changes the actual behavior of the code.

In this world it just becomes very, very difficult to reason about extremely common operations; it'd be a constant source of frustration. There's a good reason you rarely see languages versioning their behavior in impactful ways.

Is fine-tuning of the gpt-3.5-turbo model expected to be available at some point? I have some applications that would greatly benefit from this, but only if fine tuning is available.

"Am I wrong? If people show up to say I'm wrong, that only proves I'm right!"

Nope. This is a common confusion.

The set of properties of objects and the sets of objects themselves have a complementary relationship when it comes to union / intersection and subset / superset.

Let's define a "property" as being a predicate that is true for all elements of a set. For example, a collection of red objects has the "red" property.

A subset of a set of objects can only have the same or more properties than the set you started with. If you take a bunch of marbles of varying colors, selecting a subset of those marbles can yield a set with a new property (such as them all being red), but they are guaranteed to have the "marble" property.

A superset of objects can only have the same or fewer properties than the set you started with. Adding marbles to an existing set of marbles can only make "they are all red" become false (if it was true to begin with).

Union and intersection have the same duality; the union of two sets has the intersection of its properties, and the intersection of two sets has the union of its properties.

These results come from logic, not TypeScript.

You have to give the "lawnmower engine vibrator" hypothesis some credit for its sheer hilarity. Imagine Lew sitting there getting signals loud enough for the entire table to hear, see, and feel, like the water cup in Jurassic Park

BRAAAP BRAAAP BRAAAAP

"I fold"

BRAAAP BRAAAP

"I'm all in"

BRAAAP BRAAAP BRAAAAP

"I fold"

Yeah, if I had to rank the scenarios in order of likelihood:

1. Lew made a statistically awful call and got lucky

2. (yawning chasm of implausibility)

3. A rough tie between

3a. Lew made an extremely shrewd read and figured out the exact one hand Adelstein could have that she was ahead of and called on that basis

and

3b. Lew could cheat, and chose to do so in the one spot that gave her very little additional equity and immediately exposed the cheat at the same time

The hand is relevant on the calling side. Poker doesn't work on the principle of "I called your bluff and so I win!". If you call a bluff with a worse hand, you still lose the pot.

It's not enough to know that someone is bluffing; you actually have to have a better hand to win the pot when calling an all-in bet. Even if you were given the information "Adelstein does not have a pair" by an oracle, statistically, J4 is behind a randomly-chosen non-paired hand here.

I don't see how this is a rebuttal to the claim. 636,975 is more than 2x 304,526, so assuming the quoted paragraph is correct, sucrase is still the highest-throughput transpiler even during its warm-up phase. Probably this isn't true for the first 100 milliseconds of execution during the very first warm-up stages, but if the transpile phase is that short, it's basically irrelevant anyway.

> Seems like a trivial change, so why not do it sooner?

Re: indentation: Literally, no one thought of it, as far as anyone can tell. Linus's law appears to have its limits.

It's a PR that will be merged within the next week or so, and has been scheduled in the TS roadmap for quite a while. It's happening.

Sucrase is written in JS and boasts the highest line throughput of any competing transpiler

https://github.com/alangpierce/sucrase

            Time            Speed

Sucrase 0.57 seconds 636975 lines per second

swc 1.19 seconds 304526 lines per second

esbuild 1.45 seconds 248692 lines per second

TypeScript 8.98 seconds 40240 lines per second

Babel 9.18 seconds 39366 lines per second

RCV-IRV doesn't encourage moderate candidates because, in a polarized environment, moderate candidates are much more likely to be no one's first choice and get eliminated as a result.

This isn't hypothetical -- you can look at the results in Seattle's City Attorney race, which strangely ended up electing a Republican to a citywide office for the first time in 20 years, and where the outcome under RCV would have been the same because the moderate candidate (the reasonably well-liked incumbent) didn't secure enough first-place votes, either in FPTP or in RCV-IRV.

It's not that you can't, it's that the risks of getting caught doing it and punished for it are too high relative to the reward.

If you don't believe that deterrence is a real thing, there is a lot more human behavior that needs explanation than just the relative lack of ACH fraud.

It's the same question as why people keep so many valuables in houses where you can just break a window, walk in, and take stuff: because you go to jail if you do that.

If ACH was different and you could just, say, walk up to an ATM and punch in a routing/account number and withdraw cash, it'd be a very different situation. You can only interact with the ACH system through a regular bank, and regular banks have KYC regulations that mean the recipient of those funds has a name, address, and SSN. Doing theft via ACH means the funds end up in account clearly tied to your identity, and you go to jail.

This is how JavaScript intellisense in Visual Studio used to work, except that the program was executed "behind the scenes" using a trimmed-down VM that could execute without side effects or infinite loops. It was eventually abandoned due to poor performance, predictability, and stability.

The problem is this dilemma: If you have to wait for a "real" execution of a program, then very reasonable expectations like "I can see a local variable I just declared" doesn't work. If you try to fake-execute a program, you have problems like trying to figure out what to do with side-effecting calls, loops, and other control flow problems.

Trying to reconcile a previous type snapshot with an arbitrary set of program edits was tried by an early version of TypeScript and wholly abandoned because it's extremely difficult to get right, and any wrongness quickly propagates and corrupts the entire state. The flow team is still trying this approach and is having a very hard time with it, from what I can tell.

If regular law is the ultimate arbiter of the correct location of funds in this system, then we don't need this complex network of energy-hungry computers constantly double-checking each others' work to make a financial system. We can just use regular computers, like before.

You don't have to take bad faith arguments at face value.

When the baker says that his wedding cakes are a custom work of art tailored to each client, he's bullshitting you. He simply wants to discriminate against gay people. It really is that simple. There is no material difference between drawing flowers on a cake for a gay wedding and drawing flowers on a cake for a straight wedding, the same as there being no material difference between drawing flowers on a cake for an interracial wedding and a non-interracial wedding. When people make up false pretenses to justify their discrimination, your job as a rational human being is to identify it as such, not be a sucker.

I absolutely guarantee that if a straight couple had came in, commissioned a regular wedding cake, and then once the cake was done said "Oops we're not gonna buy it, can you sell it to our gay friends' wedding instead?", the baker would not have sold them the cake at that point, because again, it's about who he's selling it to, not what he's making.

You have a civil right to participate in normal society, such as the purchase of everyday goods and services like cakes.

This is what it looks like when that right is not enforced via mandates of business owners: https://en.wikipedia.org/wiki/The_Negro_Motorist_Green_Book

You're conflating discrimination on the basis of the product being created vs on the basis of whom the product is being sold to.

The cake being commissioned was not materially different from any of the other cakes the baker made. What was materially different was who he was selling it to.

The article says "No digit can appear in the ostrich head _more than_ three times."