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

201–210 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#201

Post by stnmtn »

errantspark wrote: post #195
stnmtn wrote: post #188

Earlier quoted context omitted.

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 tim…

Not sure if this solves 100% of your problems, but this seems like it could help a bit https://chrome.google.com/webstore/detail/typescript-console...

Also for me, the benefits of a statically typed language on a large team heavily outweighs not having TS in a chrome REPL. It's not even close. Maybe your use case is different, but for me it seems like you're missing the forest for the trees.

Re: Tricks I wish I knew when I learned TypeScript

#202

Post by stnmtn »

nathias wrote: post #185
stnmtn wrote: post #168

Earlier quoted context omitted.

No one using TS claims JS is broken. People want a good type system in javascript, and with that obviously comes a new layer of complexity The tradeoff is clearly worth it for certain use cases, and clearly not worth it for others. It seems you are discounting and ignoring cases when it is worth it.

I don't think there are no use cases, but I think they are rarer than people think, and that for the most of development TS will be picked because it's someone preference not because of its actual benefits.

Do you really think that use cases for statically typed languages are rare?

Re: Tricks I wish I knew when I learned TypeScript

#203

Post by tshaddox »

marginalia_nu wrote: post #189
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…

> 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! That seems a rather arbitrary limitation. When Java says Foo, it would translate to what you would consider Maybe . How you represent types, and what that representat…

"Maybe" doesn't have the same problem as Java nulls though, because with an optional type the type system would force you to always handle the possibility of the value not being present. With Java nulls you just get a runtime error if you try to do certain things with something that turns out to be null.

Incidentally, Java does have Optional, and codebases which use it consistently are vastly better to work with. https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

Re: Tricks I wish I knew when I learned TypeScript

#204

Post by [deleted] »

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.

[deleted]

Re: Tricks I wish I knew when I learned TypeScript

#205

Post by ipaddr »

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.

Monad: In functional programming, a monad is an abstraction that allows structuring programs generically. Supporting languages may use monads to abstract away boilerplate code needed by the program logic.

Promise: A Promise is an object representing the eventual completion or failure of an asynchronous operation. Essentially, a promise is a returned object to which you attach callbacks, instead of passing callbacks into a function.

Re: Tricks I wish I knew when I learned TypeScript

#206

Post by lalaithion »

knuthsat wrote: post #157
nicoburns wrote: post #146

Earlier quoted context omitted.

> Needing a PhD in category theory to produce a side effect will no doubt make some other paradigm seem appealing in the future. I think it’s only really Haskell (and perhaps languages like Idris) that’s super strict on side effects. In Rust it’s a simple mut annotation, and perhaps a mutex (and you’ll want that in C too of course) if you’re working across threads.

Does rust have Mut annotations on functions? I mean, when you look at a problem that monads solve with types is that every function has an “annotation “ of what it uses (IO or mutable state). Similar how async in JS allows await, a state annotation would allow put get or IO annotation any of the IO capabilities. Of course monads are much more but Mut does not look like it pollutes everything with Mut, including funct…

No, it does not.

Re: Tricks I wish I knew when I learned TypeScript

#207

Post by dboreham »

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…

The wheel of typing.

Re: Tricks I wish I knew when I learned TypeScript

#208

Post by knubie »

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.

If you understand promises you pretty much understand monads already since promises are more or less a type of monad.

Monads represent computation contexts. In the case of promises, the computation is preformed in the context of a value that will be available some time in the future (or not at all in some cases).

   my_promise.then(compute_result)
Another context could be a list, where the computation is performed on each value in the list

    my_list.then(increment)
Or the context could be that the value is maybe null

    maybe_string.then(uppercase)
How the computation is actually performed depends entirely on the monad. Usually .then is called .bind or .flat_map because it will automatically unwrap nested monads.

Re: Tricks I wish I knew when I learned TypeScript

#209

Post by spoiler »

irrational wrote: post #134
awestroke wrote: post #130

Earlier quoted context omitted.

Try fixing the problems

That is exactly what is taking 99.99+% of the development time. Fixing the problems with typescript. My JS code has no issues.

Your original question of "does typescript get better?" can be rephrased as "does any tool become easier to wield with greater/better understanding?" and the answer is "yes".

Without a [concrete] example of what type of issues you faced, I doubt anyone can give you actionable advice, though.

> My JS code has no issues.

Either the types were wrong, or the code was wrong, either way there is an issue. Since you said you're inexperienced with typescript, it's possible the types were erong.

There are certain JavaScript patterns where TypeScript can be a bit inexpressive/unergonomic (especially with a lot of "metaprogramming" or "runtime polymorphism"[1] involved).

[1]: Most of the cases in our company the difficulty of expressing some types of "runtime polymorphism" was what I call thoughtless polymorphism (ie, it usually hides runtime errors that you're unaware of, especially if there's a proliferation of `anys`s in the code)

Re: Tricks I wish I knew when I learned TypeScript

#210

Post by spoiler »

recursive wrote: post #186
spicybright wrote: post #129

Earlier quoted context omitted.

Of course, I'm not going to muck around with brittle webpages that can't take a webpage just to fix one blog post, though.

I totally agree about ligatures. My user style sheet works pretty flawlessly for everything. * { font-variant-ligatures: none !important; } I cannot comprehend how ligatures ever got popular in programming, particularly in blogs supposedly trying to teach new languages or concepts.

For me personally, I found that they help reduce the noise in the code.

I also noticed that it makes it a bit easier to "read" the code (not just visually, but "semantically" if that makes sense). As in, I think I have to spend less time "parsing" ≤ than =However, I am mildly dyslexic, so that might play a role in it.

Post reply on HN