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

Tricks I wish I knew when I learned TypeScript

cstrnt.dev

Post reply on HN
Print view View original

191–200 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#191

Post by machiaweliczny »

marginalia_nu wrote: post #140
jjice wrote: post #122

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a great way to get a great type system while staying in a systems programming and procedural environment. Hell, even python type annotations support union types. I never knew the depth of type systems until the last year when I took a type theory course and a compi…

The grass does seem tend to appear greener in the other paradigm. Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Writing anything nontrivial with duck typing made more elaborate type systems seem appealing. Needing a PhD in category theory to produce a side effect will no doubt make some other para…

TS has good option of being optional. I programmed C++ (rigid niminal), Ruby (duck), Haskell and TS is best compromise so far as it works like tested documentation which is most practical for many purposes (where program must be iterated). If you know what you want to build beforehand then sound typing might be better.

Re: Tricks I wish I knew when I learned TypeScript

#192

Post by chana_masala »

throwanem wrote: post #53
3np wrote: post #47

Earlier quoted context omitted.

I think the example type is useful for unvalidated input data e.g. from an API call. Or an update function for a DB abstraction. Internally in the backend, you’d still use the type you just posited.

Eh. A good ORM provides type definitions from model definitions, which is one way I've found ORMs more useful in TS than JS, and I'd more likely use a runtype or a decoder to both validate and type inbound data than roll my own interface for it. On review of documentation, I was actually pretty off base in grandparent comment. The real use case for Record appears to be when you need a map type whose keys are both exp…

> an object type with an index signature works fine and may be more legible.

If I understand you correctly, that's exactly what a Record is underneath

Re: Tricks I wish I knew when I learned TypeScript

#193

Post by remram »

efficax wrote: post #114
remram wrote: post #109

Earlier quoted context omitted.

Which language has both a "None" and "null"?

javascript, at least, has "undefined" and "null", an infuriating duality of falsiness. PHP also has a notion of not being set as well as being set but null.

JavaScript is what we are talking about in this thread, making the point that JavaScript is similar to JavaScript does not help ;-)

Re: Tricks I wish I knew when I learned TypeScript

#194

Post by remram »

mynameisash wrote: post #173
remram wrote: post #109

Earlier quoted context omitted.

Which language has both a "None" and "null"?

Scala, as I recall. It encourages using Options (Some/None), but since it runs on the JVM and will often interop with Java libraries, you can also have nulls. Not exactly a language design, but an unfortunate reality.

Oh no! Does it not have a type for NonNull references, like Rust does?

Re: Tricks I wish I knew when I learned TypeScript

#195

Post by errantspark »

stnmtn wrote: post #188
errantspark wrote: post #184

Earlier quoted context omitted.

This is news to me, as far as I know it'll error out when it reads TS on the REPL. How do you enable this?

Oh, in the console? Probably won't work? I'm saying that you can run chrome's debugger on source mapped TS files, which is really really nice for bug-hunting and developing locally But I mean if the biggest complaint you have is that it doesn't run in a browsers REPL console, that feels pretty minor to me. You can easily find TS REPLs all over the web Edit: if you are asking about chrome debugger, here's a link to so…

Right, but the actual benefit comes from having the REPL and the debugger in the same place. Plus the chrome REPL is fantastic, so suggesting I just use a different one is sorta like saying "you can just use your phone" when my default is a Hasselblad. When I'm writing JS/Node I can write code in the REPL in the context within which it will execute, it really cuts down on how much I have to hold in my head at one time because I can just ask the computer. It also makes exploring much much faster because my iteration times are as fast as the computer can run my code. I find it's a much more natural way of programming and about as close to SLIME as I can get while still writing in a language that has easy economic value.

Re: Tricks I wish I knew when I learned TypeScript

#196

Post by colejohnson66 »

BillyTheKing wrote: post #147
goto11 wrote: post #99

Earlier quoted context omitted.

> Other languages refer to null as their billion dollar mistake The "billon dollar mistake" as described by Tony Hoare was not nulls per se. The billion dollar mistake was having a type system where null was a member of every reference type. This does not apply to language like JavaScript without static type checking, and it doesn't apply to type systems like TypeScript where null or undefined have to be explicitly s…

exactly.. the 'only' billion dollar mistake in JS in regards to null is that typeof null === 'object' => true

It’s not undefined, therefore it’s an object. And because every type can be null, it makes sense that it’s just “object”, not “string” or whatever.

Re: Tricks I wish I knew when I learned TypeScript

#197

Post by shepherdjerred »

marginalia_nu wrote: post #140
jjice wrote: post #122

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a great way to get a great type system while staying in a systems programming and procedural environment. Hell, even python type annotations support union types. I never knew the depth of type systems until the last year when I took a type theory course and a compi…

The grass does seem tend to appear greener in the other paradigm. Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Writing anything nontrivial with duck typing made more elaborate type systems seem appealing. Needing a PhD in category theory to produce a side effect will no doubt make some other para…

You don't need a PhD, you just need the first few chapters of [Category Theory for Programmers](https://github.com/hmemcpy/milewski-ctfp-pdf) :)

Re: Tricks I wish I knew when I learned TypeScript

#198

Post by kaba0 »

throwanem wrote: post #158
ebingdom wrote: post #144

Earlier quoted context omitted.

> Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo…

I'd love to see an explanation of monads that accurately captures their capabilities in terms no more complex than those required to do the same for promises.

To understand Monads, we have to first understand Functors, Monoids and the Applicative type classes (type classes are more or less the same as interfaces in Java, C++ and the like).

A Functor is something that implements a `map` function. You can think of a Functor as anything that can encapsulate/surround something else. The map function applies a function to the encapsulated element without modifying the outer structure. For example, a List is a Functor, that has this map function implemented in most languages. It indeed surrounds a given type (zero or more item of that type to be more correct), and it indeed applies the same function over each element of the map. Several languages have a “Result/Maybe/Optional” type, that can either contain one instance of a type, or Nothing. Some languages allow you to modify the inner element, when it exists, that is, it is also a Functor that encapsulates an element and has a map function to change that.

Let’s dissect this Monoid word next (which is not a Monad!). Before the definition, let’s look at an example: summing numbers. Let’s say we have a list of numbers, and we want to calculate the sum of it. We can start from the beginning and go through the list one by one, or sum the first half and the second half first, and then add them together. These are possible because the add operation is a Monoid over the numbers. What that means as an interface (type class) is, that it implements an `empty` function, a so called neutral element (0 for addition), and a `concat` one (which is + itself).

These names make us think of Lists, and indeed, Lists are Monoids as well, not only Functors. They have an empty method returning [], and they have a concat function that concats two lists together. Do note that concating an empty list to a list doesn’t change it.

Is a Return type a Monoid? We could make the case for empty being Nothing, where concating Nothing changes nothing, but what about concating two Results both containing an integer? Should we sum them or give the product, or write them next to each other?

It turns out that (in Haskell at least) you can do specify something like, this is only a Monoid if the embedded type it has is a Monoid. So for example that way a concat(Just [1,2], Just [3,4]) will return the concatenated list inside a result type.

Re: Tricks I wish I knew when I learned TypeScript

#199

Post by shadowgovt »

nathias wrote: post #183
shadowgovt wrote: post #170

Earlier quoted context omitted.

This is a good response to drill down on, because the poster's assessment of the purpose is accurate. Yes, much of both TypeScript and React are there to minimize performance costs and improve software reliability in tens-of-thousands-of-lines-of-code projects: TypeScript is using static type safety to replace the need for dynamic typechecking (decreasing the expected runtime error rate and the runtime cost of dynami…

Yes, the right tool for the job, but because TS covers a set of tools its rare that this is exactly the tool you need. I'm sure there are cases but mostly I think people just use it because of the hype/preference and I really hate to make prototypes with TS.

Yeah, prototypes are probably the wrong use case for React or TypeScript because they can crash without causing someone $X million in revenue (by definition; if it can cost someone $X million in revenue, it's no longer a prototype and the team maintaining it probably wants stronger guarantees than what native JavaScript provides for proper use of APIs and data handling if they ever want to sleep at night).

Re: Tricks I wish I knew when I learned TypeScript

#200

Post by [deleted] »

remram wrote: post #193
efficax wrote: post #114

Earlier quoted context omitted.

javascript, at least, has "undefined" and "null", an infuriating duality of falsiness. PHP also has a notion of not being set as well as being set but null.

JavaScript is what we are talking about in this thread, making the point that JavaScript is similar to JavaScript does not help ;-)

[deleted]
Post reply on HN