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

161–170 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#161

Post by wiseowise »

hibbelig wrote: post #111
AgentME wrote: post #94

Earlier quoted context omitted.

Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to…

Your parent suggested to make changes to TS so that TS is no longer compatible with JS (in the sense you described). Once that happens, compiling to WASM instead of transpiling to JS is a very valid design choice.

The whole purpose of TS is better JS.

Re: TypeScript is surprisingly ok for compilers

#162

Post by c-hendricks »

dataangel wrote: post #159
c-hendricks wrote: post #144

Earlier quoted context omitted.

In Python, can typings define a property added to a function? Example, I have some Redux helpers that are functions, but those functions also define a `.actionType` property. TypeScript handles that. edit: accidentally wrote "object" instead of "function"

I believe you could have a Protocol that requires the property and that the object is Callable.

Ah, that's not really that different than in TypeScript then. There you have to define a callable interface, and can add whatever properties you want

    interface SomethingCallableWithAnExtraProperty {
      // This means you can call it like a function.
      (args: Whatever): SomethingReturned

      // And since it's an interface, you can still do interface-y things
      anotherProperty: string
    }

Re: TypeScript is surprisingly ok for compilers

#163

Post by andyjohnson0 »

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
    {
    }

Re: TypeScript is surprisingly ok for compilers

#164

Post by afavour »

austin-cheney wrote: post #153
afavour wrote: post #119

Earlier quoted context omitted.

> Also, try/catch will never compile in the JIT Changing the way you program to fit what a JS compiler does or doesn't do is a fool's errand, IMO. The performance benefits are likely to be minimal, confusion for anyone else who has to touch the codebase is high.

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, especially in the JavaScript world.

If I were involved in a project where performance concerns were high enough to require everyone know what the JIT is and is not doing my proposal would be to use a language other than JavaScript. If thinking this makes me a “small child” in your mind I’m fine with that.

Re: TypeScript is surprisingly ok for compilers

#165

Post by pjmlp »

troupo wrote: post #51
pjmlp wrote: post #49

Earlier quoted context omitted.

C# and Swift have pattern matching.

It's more limited than what you'd ideally want: pattern matching in function definitions. This makes walking ASTs a breeze. Edit: And inline pattern matching for values returned from expressions and function calls (similar to destructuring, but more powerful).

I would say what C#11 does is already quite good, likewise for Swift.

Perfection is the enemy from good.

Those I can use at work, ML derived languages not, even F# is an uphill battle in most shops.

Re: TypeScript is surprisingly ok for compilers

#166

Post by marcosdumay »

airstrike wrote: post #120
andsoitis wrote: post #113

Earlier quoted context omitted.

> 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. JavaScript and TypeScript are not "proper" languages? Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more p…

JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today

> I don't think anybody credibly claims it to be a language we would want to use

Ouch, you posted this on the internet.

Somebody, somewhere is certainly going to claim this. Some of the people with that claim are even going to have a rationale behind it.

And to be fair, the tooling is going to push a lot of opinion. Because as bad as the JS/TS tooling is, its UI component has been evolving steadily while every other tool stagnated. And by now it has quite probably surpassed the 90's RAD paradigm (I mean, I can't make up my mind).

IMO, the language is one of the main things holding those tools back, but most people just won't agree.

Re: TypeScript is surprisingly ok for compilers

#167

Post by thrashh »

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…

TypeScript is really nice but you're really describing a JavaScript feature to be honest.

Here's some other languages that support objects as functions (although not necessarily functions as objects): https://en.wikipedia.org/wiki/Function_object

Re: TypeScript is surprisingly ok for compilers

#168

Post by thefaux »

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…

This blend of functional and oo programming was pioneered by scala.

Re: TypeScript is surprisingly ok for compilers

#169

Post by CharlieDigital »

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…

    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.
Yes. C#. The equivalent are `Func` and `Action` types representing functions with a return and without a return. In fact, the JavaScript lambda expression looks awfully familiar to C#.

One of the snippets below is C# and the other is TypeScript:

    var echo = (string message) => Console.Write($"You said: {message}");
    
    var echo = (message: string) => console.log(`You said: ${message}`);
The same signature in C# and TypeScript:

    var Apply = (Func fn, string input) => fn(input);
    var result = Apply(input => ..., "some_string");
    
    var apply = (fn: (input: string) => string, input: string) => fn(input)
    var result = apply(input => ..., input);
The C# can version can also be written like:

    var Apply = (Func fn, string input) => fn(input);
    var lowercase = (string input) => input.ToLowerInvariant();
    var result = Apply(lowercase, "HELLO, WORLD");
For the curious, I have a small repo that shows just how similar JavaScript, TypeScript, and C# are: https://github.com/CharlieDigital/js-ts-csharp

Screen grab of the same logic in JS/TS/C# showing the congruency: https://github.com/CharlieDigital/js-ts-csharp/blob/main/js-...

Re: TypeScript is surprisingly ok for compilers

#170

Post by thrashh »

austin-cheney wrote: post #155
raxxorraxor wrote: post #115

Earlier quoted context omitted.

For everything with the slightest bit of I/O it is quite practical if you have even the most trivial assumptions about its form. Sure, you can check for everything. It often is more effective, but not prettier or easier to read and of course you also will miss cases.

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 that encounters the errors needs to necessarily know how to handle the error and your app always responds correctly.

That said, I don't use exceptions as much in JS because exception handling in JS is still very nascent. There's no base library of exceptions and telling different exceptions apart is not built-in to the language. In a language with more mature exception handling, it's a breeze.

Post reply on HN