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

TypeScript is surprisingly ok for compilers

matklad.github.io

Post reply on HN
Print view View original

211–220 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#211

Post by throwaway287391 »

nightpool wrote: post #187
flylikeabanana wrote: post #182

Earlier quoted context omitted.

FP in python is painful without tail call elimination and the higher-order function syntax is so clunky

JS also doesn't have TCE, but for Python even just the lambda limitations are surprisingly annoying. I can't tell you how many times i've been frustrated because it's nearly impossible to put a print statement into a python lambda

As a Python enjoyer, why do we want to shove so much into lambdas rather than just doing an inline function `def`?

Is it the fact that you have to give it a name? If so I'd say just using some generic name like `{f,fn,func(tion),callback,etc}` is fine (at least as much as an anonymous function is), and to me would usually be more readable than an inline definition of a multi-statement lambda would be.

Or maybe it's the fact that lambdas are allowed in the first place, so people are going to use them, and then when you want to debug a lambda you'll probably have to go to the trouble of changing it to a function? That is a fair complaint if so.

In any case I can see how it could be annoying if you're more used to a language full of complex inline lambdas.

Re: TypeScript is surprisingly ok for compilers

#212

Post by thrashh »

austin-cheney wrote: post #177
thrashh wrote: post #170

Earlier quoted context omitted.

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…

Not at all. You don't have to describe anything when throwing an error because that's the point of exception inheritance. Second, the whole point of exceptions is to bubble them out of the handler(!) because otherwise you would use return values (like in Go).

Since you are saying that you have to describe the problem within the error object, it sounds like you must be you are parsing error messages and stack traces to figure out what the error is. That's not how exceptions are to be used and I think that's why you are not seeing why you would bubble errors.

In other languages, you don't have to do any of that nonsense because object identity is much stronger, but JavaScript uses prototypical inheritance so you can't really tell if an error is an ImageError or an IOError. Despite this issue, exceptions were added to the JavaScript language without resolving that problem. The reason why you have to worry about frameworks eliminating error information is because that problem wasn't resolved and so frameworks roll their own error handling and there is no standard.

Re: TypeScript is surprisingly ok for compilers

#213

Post by bakkoting »

IshKebab wrote: post #10
lmm wrote: 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.

> picked up most of the ML featureset It really hasn't. In this very post he had to use a visitor to work around the fact that switch isn't an expression. JavaScript's support for iterators is also weirdly shit. It has `.map()` but that only works on arrays. You can't map an iterator!

You can now! The iterator helpers proposal is stage 3 and shipping in Chrome.

  (new Set([0, 1, 2])).values().map(x => x + 1).toArray()
You can also reduce, filter, find, etc.

Re: TypeScript is surprisingly ok for compilers

#214

Post by feoren »

andyjohnson0 wrote: post #163
grumblingdev wrote: post #116

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…

> Are there other languages that do this so nicely? It's the perfect blend of OO and functional. In .net methods, properties, member variables, classes, etc. can have attached attributes that are objects. Attributes can be interrogated at runtime using reflection. [MyAttrib(foo=42, bar="baz")] class MyClass { }

I really dislike attributes in C#. Their use is a big code smell for me. They look like C#, but they're not actually -- they're a part of the type system that has been disguised. The fact that their parameters must be compile-time constants helps perpetuate a harmful "primitive-centric" viewpoint that is antithetical to many good design principals.

Their only reason to exist is to support a use case of a 1:1 relationship between classes and functional units (or methods and functional units, or parameters and functional units, etc.), which is almost always an 80% solution that makes the other 20% extremely hard and/or impossible. I would go so far as to say that every single use of an attribute is your own code begging you for a better design. Unfortunately you're sometimes stuck with them, but that's only because you're sometimes stuck with a framework that itself is begging its creators for a better design. I wonder if Attributes were never added to the language, if developers would have just made those better choices to begin with. From my vantage point, they were a clear mistake in a language that was otherwise very well designed.

They certainly are nothing like the ability to attach methods to functions. A better example of that kind of convenience in C# is extension methods, which you can certainly define on types like Func. I love extension methods and miss them in every language that doesn't have them!

Re: TypeScript is surprisingly ok for compilers

#215

Post by karmakaze »

TOGoS wrote: post #127
karmakaze wrote: post #122

Earlier quoted context omitted.

The same is achieved with Java's use of single-method-interfaces. It doesn't matter what the method is called, it can be used in function contexts without referencing the specific method name. I'm not sure I'd like my functions to have properties (which gives them state and can alter what calling it does with the same arguments). A big benefit of FP is getting away from OO states. Perhaps the problems I work on aren'…

The properties don't have to be 'state' per se; they can also be used to store metadata about the function. e.g. you could have a function with 'domain' and 'range' on it, or an 'integrate' method.

If the result of `integrate(...)` depend on `domain` and/or `range`, what would you call that other than 'state'? Or if `integrate(...)` doesn't reference `domain`/`range` what's the use of it being there?

Or as I'm interpreting this, is sort of like documentation or information that could be used at runtime for code generation. Basically a shorthand for composing the function with its metadata. The nice thing about separation is that you know that when calling the function, there's no possible way for it to reference the metadata that is associated with it because it's composed externally.

Re: TypeScript is surprisingly ok for compilers

#216

Post by paulddraper »

grumblingdev wrote: post #116

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…

> Are there other languages that do this so nicely? It's the perfect blend of OO and functional.

Python

  compressor = lambda x: x / 2
  compressor(5)

  helpful_compressor = lambda x: x / 2
  helpful_compressor.help = "compressor"
  helpful_compressor(5)
  helpful_compressor.help
Scala

  val compressor = (x: double) => x / 2
  compressor(5)

  object helpfulCompressor {
    def apply(x: double) = x / 2
    val help = "compressor"
  }
  helpfulCompressor(5)
  helpfulCompressor.help
Ruby also has .call...but I can't remember it well enough

Re: TypeScript is surprisingly ok for compilers

#218

Post by [deleted] »

grumblingdev wrote: post #116

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…

[deleted]

Re: TypeScript is surprisingly ok for compilers

#219

Post by IshKebab »

tejinderss wrote: post #11
IshKebab wrote: post #9

Earlier quoted context omitted.

He's talking about compilers for small languages. The Typescript LSP works fine on very big projects like VSCode so I think you'd need an enormous language like C++ or Rust before you'd run into those limits. But still, I think I'd rather use Rust. I'm pretty sure the code would be nicer (e.g. no need for the explicit tag field or for the visitor hack).

The author is no stranger to rust (he’s creator of rust-analyser). The reason why he’s pitching typescript here is due to its high level nature and doesnt have to deal with memory management, low level integer types etc.

I know. I'm just expressing my opinion that he hasn't really made me want to use Typescript over Rust for this case.

I like Typescript and Deno. But I'd still rather use Rust here.

I would love it someone made a RustScript though which would be basically Rust but with arbitrary precision integers, garbage collection etc. (but still value semantics).

Re: TypeScript is surprisingly ok for compilers

#220

Post by andrewcobby »

As some how is writing a compilter in TS, I agree it's not too bad. I started with Deno like the author but ended up switching to Bun which, despite some rough edges, I'm enjoying more than Deno and it's _very_ quick! (My main niggle with Bun is the test reporting, but it's getting the job done)

For standard parser generator frontend, Ohm-js[1] is quite pleasant. I wouldn't recommend anyone reviews the offical tsc compiler, it's huuuge - instead there's mini-typescript[2] (in particular the centi-typescript branch[3]) which does a nice job illustrating how tsc is working.

[1] https://ohmjs.org/ [2] https://github.com/sandersn/mini-typescript/ [3] https://github.com/sandersn/mini-typescript/tree/centi-types...

Looking forward to GC an DOM access in WASM.

Post reply on HN