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

221–230 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#221

Post by dboreham »

underdeserver wrote: post #162
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 know dozens of people who tried understanding Promises and all of them succeeded. I know dozens of people who tried to understand monads (including myself) and maybe 3 of them succeeded (I do not consider myself one of them).

Monad imho is deliberately badly explained to preserve the mystique and the smugness of the cognoscenti. I found this book invaluable for translating the field into something that makes sense: https://alvinalexander.com/scala/functional-programming-simp...

Re: Tricks I wish I knew when I learned TypeScript

#222

Post by tus89 »

> Well, arrays and objects are quite special in JavaScript. If you pass them to a function it will pass the reference to the array or object which means it will mutate the original array

Unlike every other language that passes arrays by value. Ye gad.

Re: Tricks I wish I knew when I learned TypeScript

#223

Post by kaba0 »

remram wrote: post #194
mynameisash wrote: post #173

Earlier quoted context omitted.

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?

Since Scala 3, it can have total static analysis where nulls become a separate type that has to be explicitly declared in type signatures.

So, yes.

Re: Tricks I wish I knew when I learned TypeScript

#224

Post by IggleSniggle »

hardwaresofton wrote: post #93
EnderShadow8 wrote: post #2

Note: don't use typeof x === 'object' to check whether something is a valid object, because it will return true for arrays as well. Arrays are objects, so this is expected behaviour.

Array.isArray[0] is your friend [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Did anybody else have their brain do a weird backflip seeing `Array.isArray[0]`??

  Object.getOwnPropertyDescriptors(Array.isArray)
  /* 
  {
    '0': {
      value: 'https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray',
      writable: true,
      enumerable: true,
      configurable: true
    },
    length: { value: 1, writable: false, enumerable: false, configurable: true },
    name: {
      value: 'isArray',
      writable: false,
      enumerable: false,
      configurable: true
    }
  }
  */

Re: Tricks I wish I knew when I learned TypeScript

#225

Post by dllthomas »

jorisd wrote: post #141
alpha_squared wrote: post #137

Earlier quoted context omitted.

Until it's the root cause of code not working as expected, by another developer far removed from initial implementation. Non-obvious code is harder to maintain. Code is written for people, not machines; that means the harder it is for people to maintain, the less useful it actually is.

Valid point. On the other hand, these kinds of advanced types can prevent lots of bugs and maintenance work, and may therefore be worth the day of debugging when it breaks after two or three years of usage. I've used types like this in a pretty advanced TypeScript UI project consuming lots of services to enforce compile time errors. We were using generated TS clients for all of the APIs we consumed, and the compiler…

Complicated types (like any complicated code) need their own tests demonstrating that they do what the author thinks (and fails to think about, as it's changed).

Re: Tricks I wish I knew when I learned TypeScript

#226

Post by nosefrog »

marton78 wrote: post #63

Kinda off topic from someone whos mother tongue is not English: what happened in the past years that people apparently forgot how the irrealis works in English? Shouldn't this be "Things I wish I had known when I learned TS" as opposed to "Things I wish I knew RIGHT NOW"?

As a native English speaker, I never learned formally about irrealis, so it's not possible for me to have forgotten them :P "Things I wish I had known" and "Things I wish I knew" both sound right to me.

Re: Tricks I wish I knew when I learned TypeScript

#227

Post by throwanem »

chana_masala wrote: post #192
throwanem wrote: post #53

Earlier quoted context omitted.

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

More or less. There are extra steps involved with a Record, but they work the same iirc.

Re: Tricks I wish I knew when I learned TypeScript

#228

Post by afiori »

kazinator wrote: post #187
marginalia_nu wrote: post #140

Earlier quoted context omitted.

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…

C is not "barely typed". It has quite a lot of type checking. An expression like "obj.memb" in C requires obj to be declared to have a type which has a member "memb". C catches it if you call a function with the wrong number of parameters, or wrongly typed parameters, such as passing a "struct foo *" pointer where a "struct bar *" argument is required. C has "holes" in the static safety net in areas like memory safet…

In the field of formal type systems two common approaches to defining types, in practice they are quite similar but in my opinion they differ a lot in framing.

One side can be represented by Haskell, Hindley–Milner type systems, or even Coq; here every value has its own "best" type that is intrinsecally associated with it, that is values and types are defined and constructed together.

On the other side you have sort of a formal definition of duck-typing; you have values and properties that are satified by some set of values, here you have your values (all numbers, all strings, all memory addresses) and expres in usual logic terms any property you want (e.g. this memory address must be either Null or point to a string of even length).

All this to say that C has a nice type system from the first point of view (function pointer allow you to have higher order functions!) but a very weak one from the second point of view in that it is very hard to decide if an operation will have a valid result just by the types of the values you feed into it (let's not talk about UB for now).

In my opinion in later decades there is a movement to care more about type systems that follow the second approach. In my opinion it is one of the reason for the success of Typescript; its objective wasn't to have a nice type system full of good properites, but to model how javascript was being written.

Re: Tricks I wish I knew when I learned TypeScript

#229

Post by chana_masala »

exdsq wrote: post #117

Still working on this, but might give someone a laugh :) Problem 1 from Project Euler in TypeScripts Types https://github.com/iiTzEddyGG/typing-euler/blob/master/src/p...

I am highly interested in type programming lately, exactly the kind of thing you're doing here. Do you have any other resources that inspired you? Here are some of my favorites:

https://gist.github.com/hediet/63f4844acf5ac330804801084f87a...

https://github.com/codemix/ts-sql

https://github.com/jamiebuilds/json-parser-in-typescript-ver...

https://gist.github.com/acutmore/9d2ce837f019608f26ff54e0b1c...

Re: Tricks I wish I knew when I learned TypeScript

#230

Post by dboreham »

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.

Not an explanation, but they key thing to know is that monad is not a thing, but a pattern. It's a pattern for composing things. Like the FP equivalent of the Unix shell pipe character. Like the Unix shell provides composability for processes that happen to read from stdin and write to stdout, most FP languages provide a framework for composing monads (of whatever kind) neatly e.g. Scala and Haskell "for comprehensions".
Post reply on HN