Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

171–180 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#171

TypeScript is an incredible language in general. The fact that Functions are Objects that can have properties/methods is supremely undervalued. Are there other languages that do this so nicely? It's the perfect blend of OO and functional. Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites. function foo() {} function bar() {} function…

In Go, you can attach methods to functions (and any type really, even "unboxed" primitives).

One of the canonical examples would be a net/http: A handler can both be a struct (or any other type really) that implements a serve method, or it can be a handler function that calls itself to satisfy the interface.

In Clojure you would achieve the thing you describe by attaching metadata on your function var. It being a Lisp, it also has macros so you can pretty much do anything.

Speaking of macros:

Clojure also implements CSP channels with macros in core/async, inspired by Go.

Channels are a very powerful construct that you might like a lot. With channels you can completely avoid the function coloring problem (callbacks, promises, async/await). Perhaps most importantly they decouple execution from communication.

So going back to your example, your commands could be producers that send their results on channels. They don't need to know what consumes w/e they make, nor do they need to hold on to it, mutate something, or call something directly.

Good analogies would be buses on motherboards, routers and switches in networks, conveyor belts, message queues in distributed systems and so on.

Re: TypeScript is surprisingly ok for compilers

#172

Earlier quoted context omitted.

That depends on how many changes it requires. If its just a matter of don't do these 3 things and your code suddenly becomes more predictable its like being slapped with a magic wand. Everybody wins. All you have to do to ensure 100% of your code compiles in a JIT is be predictable. Predictable code is, on its face, always less confusing. > The performance benefits are likely to be minimal This makes me cry, but not…

> People guessing about performance is perhaps the most frequent anti-pattern in all programming I disagree, premature optimisation is. Changing your style of programming to suit what todays JIT does but tomorrow’s may not, in anticipation of performance issues you have not yet encountered is a waste of everyone’s time. No doubt it is valuable in extremely performance sensitive code but that is the extreme minority,…

What you are advocating, the guessing about performance, is the premature optimization. Don't feel bad, most developers have no idea what that term really means. Here is the original essay where it comes from: http://web.archive.org/web/20130731202547/http://pplab.snu.a...

Premature optimization is the extra effort required to alter work necessary to circumvent guessed optimization pitfalls. In the same breath Knuth advocates always targeting known performance advantages.

Re: TypeScript is surprisingly ok for compilers

#173
post #48
post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

What language would that be?

I've programmed in Java, Python, C, C#, TypeScript, VHDL, and some other languages and they all fucking suck in some way.

If it was up to me, I would pick the best parts of the languages/ecosystems and make a Frankenstein language.

And anyway in the end, it's never the language. It's the ecosystem. Just because you can run Java on .NET doesn't mean you should -- because almost no one else does it your way and it's not worth the trouble maintaining some weird approach very few people use. You're never going to get help from library authors when it doesn't work on your weird setup.

Re: TypeScript is surprisingly ok for compilers

#174
post #38

Earlier quoted context omitted.

C# doesn't have anything resembling proper pattern matching. C#s pattern matching is akin to a marginally improved switch or if/else-if chain. C#s pattern matches aren't exhaustive, and the compiler doesn't properly check them at all.[0] There are no proper sum types in C#, so 80% of the point isn't even there. enum Season { Spring, Summer, Autumn, Winter } ... int PatternMatch(Season season) => season switch { Seaso…

>compiler can't prove the above code is exhaustive because no proper sum types Thats because c#s enum is not "closed" https://github.com/dotnet/csharplang/issues/3179

[deleted]

Re: TypeScript is surprisingly ok for compilers

#175

Earlier quoted context omitted.

> People guessing about performance is perhaps the most frequent anti-pattern in all programming I disagree, premature optimisation is. Changing your style of programming to suit what todays JIT does but tomorrow’s may not, in anticipation of performance issues you have not yet encountered is a waste of everyone’s time. No doubt it is valuable in extremely performance sensitive code but that is the extreme minority,…

What you are advocating, the guessing about performance, is the premature optimization. Don't feel bad, most developers have no idea what that term really means. Here is the original essay where it comes from: http://web.archive.org/web/20130731202547/http://pplab.snu.a... Premature optimization is the extra effort required to alter work necessary to circumvent guessed optimization pitfalls. In the same breath Knuth…

> Don't feel bad, most developers have no idea

Some advice I know you’ll ignore: your tone in the comments here is deeply patronising. You know absolutely nothing about me and yet are entirely comfortable dismissing my perspective as wrong simply because yours must be correct. It’s not an interesting or rewarding way to converse, it makes me want to stop talking to you as soon as I can. Which I’ll be doing here. Have a good weekend.

Re: TypeScript is surprisingly ok for compilers

#176
post #149

TypeScript is an incredible language in general. The fact that Functions are Objects that can have properties/methods is supremely undervalued. Are there other languages that do this so nicely? It's the perfect blend of OO and functional. Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites. function foo() {} function bar() {} function…

This looks like plain JavaScript. What does TypeScript add in this scenario? Does the example above even pass typecheck?

Yep. It's javascript, not typescript. Moreover, I think the post is only trying to convey that they like dynamic typing.

Re: TypeScript is surprisingly ok for compilers

#177

Earlier quoted context omitted.

This sounds like some hyperbolic framework nonsense. First of all I/O just means access to an API. I am going to presume you mean messages from a network. In that case a message from a network either sends or fails and in the case of sending try/catch does nothing for you but provide an error object, and you don't need try/catch to capture the error. In the case of receiving a network message the message comes in or…

Disagree. Usually you don't need to just know if there is an error or not -- sometimes you need to know what that error is. For example, an I/O error versus your image-is-too-small error -- you need to respond to the user differently. I've seen plenty of web apps that treat I/O errors and user input errors as a generic "an error happened" and that is completely wrong. Proper exception bubbling means none of that code…

You made the same mistake as the grandparent by assuming I/O means something more specific than it does. At any rate there isn't a good reason to bubble error objects out of the event handler and secondly even if you did you would have everything you need to fully describe the problem within the error object including the stack trace, event type, error message, and so forth.

Its an equivalent breeze in JavaScript as well unless you are fumbling through abstraction layers (frameworks) that eliminate the information you need.

Re: TypeScript is surprisingly ok for compilers

#178
post #102

Earlier quoted context omitted.

> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript? My fantasy for the past year has been, if I could magically program anything, bringing a compiler and spec wholesale into the world out of the void, I would create a new language (call it WebScript as a placeholder) that - featured an ML style type system, ADTs, a type syntax n…

Go has exceptions: you can use `panic` to throw/catch just fine. The community will bring out the torch and pitchforks because it’s “not idiomatic” but if you’re programming solo or with other pragmatists don’t let it stop you.

Does the community care if it’s not in a public API? If it’s caught within the same library it doesn’t affect anyone else.

Re: TypeScript is surprisingly ok for compilers

#179
post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

That's some very high level view - in reality even tough those languages are in similar categories the experience would be vastly different : TypeScript - powerful type system but shit underlying stdlib and language (no pattern matching/switch expressions) Dart - worse than TS because the object model is closed - so no dynamic freedom, but the type system and expressions are weaker then the rest. Also 0 meta programm…

Your understanding of Dart sounds a little outdated. We have a fully sound static type system and the language is pretty expressive, especially with the new pattern matching stuff in 3.0:

https://medium.com/dartlang/dart-3-1-a-retrospective-on-func...

Re: TypeScript is surprisingly ok for compilers

#180

TypeScript is an incredible language in general. The fact that Functions are Objects that can have properties/methods is supremely undervalued. Are there other languages that do this so nicely? It's the perfect blend of OO and functional. Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites. function foo() {} function bar() {} function…

give me something with ts’s type system and without exceptions and try/catch. i know go’s error handing gets shit, but i really like the explicitness of it.

oh and burn npm to the ground please.

Post reply on HN