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

Static TypeScript: A Static Compiler for the TypeScript Language

microsoft.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#51

Post by spraak »

agentultra wrote: post #28
siempreb wrote: post #17

Earlier quoted context omitted.

> Make a language that is only the TypeScript extensions to JS, and drop all the JS parts. So? Is there a reason left then to use Typescript instead of C or C++? I cannot think of one. Especially for education you better use a real language that will stay for more than 10 years at least. Microsoft is doing a great job taking over the Javascript community, and now this.., would love to see their hidden agenda. IMAO Ty…

Definitely painful. After trying to get a team to adopt and gradually type a large codebase for the last 2.5 years I can say that gradual typing is a dream. In practice you write more code than you end up typing as you go and the project is never 100% complete. If something gets typed as `any` all bets are off and there are no benefits. So people don't end up running the type checker during development anyway. Which…

> If something gets typed as `any` all bets are off and there are no benefits.

Then why allow `any`? Using TS without the compiler and linter configs tuned to your benefit is like trying to use a plane only as a car. No discipline required if you let yourself fly with settings that set you up for long term success later.

Also, Flow is not on the same level as TS. It's a dead project and was never fully baked.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#52

Post by pjmlp »

otabdeveloper4 wrote: post #30
austincheney wrote: post #22

Earlier quoted context omitted.

I am not sure where you are going with that. C++ is largely popular and enduring for the same reasons as Java: institutionalization (taught in school).

That's simply not true. I'm not aware of any place where C++ is taught. (And in fact C++ programmers are very hard to find.) C is very common and anybody with even a bit of format education has been exposed to C. Then you get people who know a bit of C and throw in a couple 'class' and a couple 'cout', and call it 'C++' for some reason. Which is wrong, obviously.

Plenty of options to learn C++ at several European universities.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#53

Post by Dork1234 »

baybal2 wrote: post #32

> As a result, the use of scripting languages (such as JavaScript and Python) for microcontrollers is on the rise. I can not think of what they smoke claiming running a scripting language on an MCU. Microsoft seem to set its sights on breaking the MCU development after nothing has left to break on the desktop.

Python was first created in 1991 where a top of a line computer ran at 50mhz and had 50 MIPS. A current generation MCU - ATSAMG51 easily runs at 120mhz, and devices are quickly moving up to the 500mhz range (https://groboards.com/giant-board/). There clearly is enough processor power to Python. StaticTypescript isn't even running scripted, it is compiled to native and has performance close to C/C++ developed code.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#54

Post by agentultra »

spraak wrote: post #51
agentultra wrote: post #28

Earlier quoted context omitted.

Definitely painful. After trying to get a team to adopt and gradually type a large codebase for the last 2.5 years I can say that gradual typing is a dream. In practice you write more code than you end up typing as you go and the project is never 100% complete. If something gets typed as `any` all bets are off and there are no benefits. So people don't end up running the type checker during development anyway. Which…

> If something gets typed as `any` all bets are off and there are no benefits. Then why allow `any`? Using TS without the compiler and linter configs tuned to your benefit is like trying to use a plane only as a car. No discipline required if you let yourself fly with settings that set you up for long term success later. Also, Flow is not on the same level as TS. It's a dead project and was never fully baked.

Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive?

That was the whole sell of "gradual typing," was it not? That you could turn it on, type everything as `any` then add better types as you go with the goal of eventually having a fully typed code base.

Except in our experience you'll always be playing catch up and never get to the promised land.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#55

Post by zbentley »

Allower wrote: post #34
otabdeveloper4 wrote: post #31

Earlier quoted context omitted.

> A ... programmer needs to understand ... underlying operating system and its internals Oh the humanity! I weep for mankind and for the industry if this is where we have fallen. Quick question: are you a Javascript programmer?

Well I mean that is the point of abstraction.. if we always had to have our heads at the lowest level we would not be productive what-so-ever.

"understanding the basics of the operating system internals and how your code interacts with them" is far, far from the lowest level.

It is also an essential understanding for writing quality, performant code in any context--web development included, even frontend.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#56

Post by spraak »

agentultra wrote: post #54
spraak wrote: post #51

Earlier quoted context omitted.

> If something gets typed as `any` all bets are off and there are no benefits. Then why allow `any`? Using TS without the compiler and linter configs tuned to your benefit is like trying to use a plane only as a car. No discipline required if you let yourself fly with settings that set you up for long term success later. Also, Flow is not on the same level as TS. It's a dead project and was never fully baked.

Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive? That was the whole sell of "gradual typing," was it not? That you could turn it on, type everything as `any` then add better types as you go with the goal of eventually having a fully typed code base. Except in our experience you'll always be playing catch up and never get to the promised land.

Don't do gradual typing, is what I'm saying. Start a project with the compiler and linter tuned strict and you'll do well. But if you have to go gradually and you have a goal of typing an untyped codebase, then just introduce a rule at a time from a list of rules you'd like in the end. Each rule should be a single commit or single PR (or Epic, or whatever granularity required)

> Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive?

Your project either doesn't benefit from static types or you're not seeing the benefits. I agree it's annoying to convert a JS project to TS, but TS in the end has been a huge boon to our overall velocity (long term) considering bugs, refactoring, and service to service edges.

Re: Static TypeScript: A Static Compiler for the TypeScript Language

#57

Post by agentultra »

spraak wrote: post #56
agentultra wrote: post #54

Earlier quoted context omitted.

Because sitting around and typing tens of thousands, maybe hundreds of thousands of lines of code is not super productive? That was the whole sell of "gradual typing," was it not? That you could turn it on, type everything as `any` then add better types as you go with the goal of eventually having a fully typed code base. Except in our experience you'll always be playing catch up and never get to the promised land.

Don't do gradual typing, is what I'm saying. Start a project with the compiler and linter tuned strict and you'll do well. But if you have to go gradually and you have a goal of typing an untyped codebase, then just introduce a rule at a time from a list of rules you'd like in the end. Each rule should be a single commit or single PR (or Epic, or whatever granularity required) > Because sitting around and typing tens…

> But if you have to go gradually and you have a goal of typing an untyped codebase, then just introduce a rule at a time from a list of rules you'd like in the end.

This was the plan. In a similar fashion to bringing a legacy code base under test we would commit to bringing this code base under type coverage. We started by adding explicit type signatures at the start and refining the types as we worked on the modules. What we ended up with is an archipelago of typed modules.

This has the consequence of forcing the developer to be aware of the coverage of the module they're working with. On our team I don't think there were enough people who had experience with strongly typed languages on board -- we're a JS shop. This meant we had to teach our teams how to think and design with types as we went along... and as deadlines approach and teams work towards their goals sometimes... that escape hatch is too tempting.

So your archipelago spends most of its time shifting. Some old, crufty modules never end up getting typed. New modules are well typed. And there are too many of the former to enable strict checking without overloading the developers.

It's not simply a technical problem but a social one too.

> Your project either doesn't benefit from static types or you're not seeing the benefits.

I believe types benefit the programmer and help us reason about programs. We've been seeing benefits there. It has helped some of the more junior developers learn how to write better code.

One boost has been that I started teaching a weekly class in Haskell that some of our developers opt into and that has had a positive effect. A more strict language has helped demonstrate how to structure programs and think in types. Which has helped them, they say, write better Javascript (even though I'd never recommend learning Haskell to "become a better programmer," you'll walk away frustrated).

Post reply on HN