Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making sense of TypeScript using set theory

blog.thoughtspile.tech

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Making sense of TypeScript using set theory

#41

Post by hbrn »

sirmarksalot wrote: post #32
yitr wrote: post #29

Earlier quoted context omitted.

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself…

Here are 3 statements that were made in this thread:

- typescript is a superset of javascript

- superset of objects can only have the same or fewer properties

- Typescript contains all the rules of Javascript, and then adds some more

Do you see where the confusion is coming from?

> that also means the language specification itself is a strict superset of Javascript

This is where I disagree.

TS as a language has more properties than JS, but less rules. I.e. you can create Javascript language out of Typescript by adding more rules (constraints).

But TS as a spec has more rules than JS spec.

TS as a language is a superset of JS language. TS as a spec is a rough subset of JS spec.

Re: Making sense of TypeScript using set theory

#42

Post by jbirer »

hbrn wrote: post #41
sirmarksalot wrote: post #32

Earlier quoted context omitted.

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself…

Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more…

You are right, the statements are contradictory. It's strange to see how nobody questions marketing buzzwords from Microsoft.

Re: Making sense of TypeScript using set theory

#43

Post by eevilspock »

hbrn wrote: post #41
sirmarksalot wrote: post #32

Earlier quoted context omitted.

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself…

Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more…

You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc.

For types, just draw the Venn diagrams:

- The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset.

- the set of things that are Dogs (class or real world) is entirely within the set of things that are Animals.

- the set of things that are Javascript programs is entirely within the set of things that are Typescript programs.

Re: Making sense of TypeScript using set theory

#44

Post by mrbombastic »

theonething wrote: post #28
maxfurman wrote: post #3

The difference between `any` and `unknown` is that `any` is an escape hatch from the type system. `any` can be used anywhere and will satisfy any type constraint. `any` is how the developer says to the type system "trust me, I know what I'm doing, don't worry about this particular value." Unknown, on the other hand, is for untyped code from an imported JS library, JSON data received from the network that may or may n…

> I know what I'm doing `any` can also be an indicator of the exact opposite.

It certainly is for me :)

Re: Making sense of TypeScript using set theory

#45

Post by lhorie »

sirmarksalot wrote: post #32
yitr wrote: post #29

Earlier quoted context omitted.

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself…

> Typescript is designed to accept any valid Javascript program

That's not strictly true though. `a(d)` is valid Javascript but Typescript treats it as a different syntactic construct[0].

[0] https://www.typescriptlang.org/play?#code/C4TwDgpgBARlC8UB2B...

Re: Making sense of TypeScript using set theory

#46

Post by bazoom42 »

hbrn wrote: post #41
sirmarksalot wrote: post #32

Earlier quoted context omitted.

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself…

Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more…

> superset of objects can only have the same or fewer properties

This is potentially misleading. A superset will include more objects and therefore may include more individual properties. But type checking is about what can be safely assumed about all members of a set, so more different objects in the set will constrain the type more.

Object is a superset of Date because the set of objects includes alle Dates but also things which are not dates and have different properties. But in the context of type checking, object is more constrained because there are fewer properties which all members of the set are guaranteed to have.

Typescript is a superset of Javascript because all Javascript programs are also Typescript programs. There is no contradiction.

Re: Making sense of TypeScript using set theory

#47

Post by antihipocrat »

RyanCavanaugh wrote: post #23
jakelazaroff wrote: post #9

I might be missing something, but isn't this line backwards? > Subtype of type A is a subset of type A. Supertype is a superset. Easy. Subtype of type A is actually a superset of type A, since it contains at least all the properties of A. If you had (contrived example) a Dog class that inherited from an Animal class, Dog would be a sub type of Animal, but its additional properties (say, a bark() method) mean that it…

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…

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}.

The subset is {red}.

Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

Re: Making sense of TypeScript using set theory

#48

Post by hbrn »

eevilspock wrote: post #43
hbrn wrote: post #41

Earlier quoted context omitted.

Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more…

You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc. For types, just draw the Venn diagrams: - The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset. - the set of things that are Dogs (class or real world) is entirely within t…

> Sets defined by type vs sets defined by lists of properties, specs, rules etc.

Recursive explanations are useless: "types are just sets defined by types". That's why we are trying to define them through other means.

Also TS has structural type system, which is literally about comparing properties.

Re: Making sense of TypeScript using set theory

#49

Post by strbean »

hbrn wrote: post #48
eevilspock wrote: post #43

Earlier quoted context omitted.

You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc. For types, just draw the Venn diagrams: - The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset. - the set of things that are Dogs (class or real world) is entirely within t…

> Sets defined by type vs sets defined by lists of properties, specs, rules etc. Recursive explanations are useless: "types are just sets defined by types". That's why we are trying to define them through other means. Also TS has structural type system, which is literally about comparing properties.

(butting in)

What is recursive about the parent comment?

Re: Making sense of TypeScript using set theory

#50

Post by hbrn »

bazoom42 wrote: post #46
hbrn wrote: post #41

Earlier quoted context omitted.

Here are 3 statements that were made in this thread: - typescript is a superset of javascript - superset of objects can only have the same or fewer properties - Typescript contains all the rules of Javascript, and then adds some more Do you see where the confusion is coming from? > that also means the language specification itself is a strict superset of Javascript This is where I disagree. TS as a language has more…

> superset of objects can only have the same or fewer properties This is potentially misleading. A superset will include more objects and therefore may include more individual properties. But type checking is about what can be safely assumed about all members of a set, so more different objects in the set will constrain the type more. Object is a superset of Date because the set of objects includes alle Dates but als…

> object is more constrained because there are fewer properties which all members of the set are guaranteed to have.

In my mind it's the opposite: object is less constrained, because there are fewer requirements you need to fulfill to be considered an object. Object type is very permissive.

The more constrained type is, the fewer objects it's set will contain. The more constrained the type is, the more rules it enforces. Seems intuitive, isn't it?

Post reply on HN