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

HypeScript: Simplified TypeScript type system in TypeScript's own type system

github.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#61

Post by czx4f4bd »

petethepig wrote: post #43
efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

"Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)." https://www.cs.c…

> Please note that this project is meant to be used for fun and learning purposes and not for practical use.

https://github.com/ronami/HypeScript#introduction

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#62

Post by k__ »

thrwawy74 wrote: post #53
efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

I used LiveScript for some time, but I went with the crowd eventually.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#63

Post by brundolf »

dfee wrote: post #33
noduerme wrote: post #29

This is insanely cool voodoo. But... I may be lacking in imagination here... I'm trying to think of how I'd actually use it. Maybe it'll come to me in the middle of the night 8) I do really wish TS had actual inbuilt reflective type checking along the lines of this: https://github.com/Hookyns/tst-reflect ...I can hazily see some kind of monstrosity that could come from linking these things together hah

This linked project is very cool! I wonder if this path is expressly a non-goal of the TypeScript team though…?

Yeah, giving types a runtime footprint is on the official list of non-goals for the TypeScript project: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#64

Post by Joker_vD »

p1necone wrote: post #12
theK wrote: post #10

Am I the only one that feels uncomfortable with all that usage of strings in TS’s type system? Why not use pure literals instead of string literals? This is a genuine question, I’m trying to find out what the pros and cons where in the decision making process.

In the context of type definitions, strings aren't really regular bare strings. I.e. if I write type foo = { bar: "Vodka" } I'm guaranteeing that the value of 'bar' on any object of that type must be "Vodka" - the type of bar is not string, it's literally "Vodka" because string values can be types. This seems a little obscure and pointless, but you can put these string types in a union, and enforce that a value must…

The academic term for such types is "singleton types". They allow for some quite mind-blowing possibilities as you've shown.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#65

Post by no_wizard »

LAC-Tech wrote: post #48
schwartzworld wrote: post #47

Earlier quoted context omitted.

I think OP means that if your project / job doesn't support typescript, you can write .ts files on your local machine and then compile them to .js. I think it would be very challenging though to be the only person on a project using TS though.

Yeah that would be weird. Using tsc to type check javascript - with JSDoc type annotations - works fine. You're really not missing much from "real" typescript, and you can save yourself a transpile.

until you need to type the shape of objects, and want to share that shape with other files. You can't import JSDoc types from other files. At which point, you would be forced to create `types.d.ts` file or similar. Might as well be writing typescript.

The limitations are too much for complex projects at scale. I strongly believe this is why Closure types didn't take off.

That and Google's lack of developer relations around the project

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#66

Post by anon_123g987 »

faichai wrote: post #57
thrwawy74 wrote: post #53

Earlier quoted context omitted.

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

I loved it to. I'd love to make a typed coffeescript variant, which transpiles to TypeScript rather than JavaScript. My pet name for this is `tycoscript`.

I like the idea, but I'd recommend the name "ToffeeScript".

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#67

Post by gabereiser »

agumonkey wrote: post #32
thenberlin wrote: post #22

Earlier quoted context omitted.

Man, I know this wasn't really the intention of the comment, but I just read through that thread and got a little nostalgic. Crazy that was like 13 years ago. Sheesh.

I also wonder how much of his 'tiny language' filtered through in ES6.

I wouldn’t say they are related but a lot of things he was doing back then ended up in ES6. Great minds think alike I guess.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#68

Post by mikewhy »

no_wizard wrote: post #65
LAC-Tech wrote: post #48

Earlier quoted context omitted.

Yeah that would be weird. Using tsc to type check javascript - with JSDoc type annotations - works fine. You're really not missing much from "real" typescript, and you can save yourself a transpile.

until you need to type the shape of objects, and want to share that shape with other files. You can't import JSDoc types from other files. At which point, you would be forced to create `types.d.ts` file or similar. Might as well be writing typescript. The limitations are too much for complex projects at scale. I strongly believe this is why Closure types didn't take off. That and Google's lack of developer relations…

> You can't import JSDoc types from other files

Yes, you can. Using `import('./someFile').SomeType`

Though I do agree, JSDoc works, but isn't as nice as directly writing types in a .ts file

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#69

Post by IshKebab »

efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

Is that not referring to Coffeescript? I don't see the relevance.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#70

Post by WorldMaker »

thrwawy74 wrote: post #53
efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

> Switch statements

JS has had switch statements for a long time. Do you mean switch "expressions" that can be used inline? It's not pretty but JS has long supported that too using either eval() "hacks" or IIFEs: https://stackoverflow.com/questions/32451049/is-eval-the-onl...

Do you mean pattern matching? There are two Stage 1 TC39 proposals with different approaches to it:

More hands-on/direct: https://github.com/tc39/proposal-pattern-matching

More indirect: https://github.com/tc39/proposal-do-expressions

> list comprehensions

There are several libraries with strong Iterator support today that while not syntactically gorgeous do great jobs at allowing you to write simple list operations. Off the top of my head are IxJS and iter-tools, but also classic mainstays like up to date versions of lodash and Ramda.

There's a Stage 2 proposal to bring more of them into "the standard library": https://github.com/tc39/proposal-iterator-helpers

There's also a Stage 2 proposal for an operator to make the syntax generally nicer no matter the library: https://github.com/tc39/proposal-pipeline-operator

> array slicing

Array.prototype.slice() was added back in ES2015: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Array.prototype.at() was "just added" in ES2022 for unary (single argument) "slice" (ability to use negative indexes): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

If you prefer syntax to function calls, there's a Stage 1 proposal still live for that: https://github.com/tc39/proposal-slice-notation

> better equality operators

That ship has probably sailed. Most projects at this point just have linter rules to standardize everything to the more reliable "triple equals" (===, and !==).

There are proposals for more structural equality functions in the standard library, though, for instance: https://github.com/tc39/proposal-array-equality

Post reply on HN