Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

311–320 of 359 posts

Re: Deno will stop using TypeScript

#311
post #292

Earlier quoted context omitted.

> "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar? > I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand…

What do you think about this study that compared task completion in java and groovy from which I will paste the conclusion. > Conclusion This paper described an experiment comparing static and dy- namic type systems for programming tasks in an undocu- mented API. We gave 27 subjects five programming tasks and found that the type systems had a significant impact on the development time: for three of five tasks me meas…

Yup, that conclusion, specially number one, is pretty much a formal detailing of what I tried to say in my previous comment: Results inconclusive, depends on the task, etc.

And, of course there are exceptions in both directions for all of findings 2, 3 and 4; and those exceptions would also contribute to 1.

It's for findings like those that I wish people stopped treating type systems like religions. And paradigms, for that matter.

Re: Deno will stop using TypeScript

#312

Earlier quoted context omitted.

I do understand the value, thanks mostly to Haskell. I also know that (language- or tool-enforced) type safety and type discipline are separable concerns. I also understand when the former gets in the way, thanks to JS, TS, Rust, Lisp, and projects large and small, slow and then fast, fast and then slow, slow and then slow, and fast and then fast.

Every developer, regardless of skill level, makes mistakes and typos. The beauty of type-safety in TypeScript is that the compiler catches it instantly, in a way that is simply humanly impossible. If I misspell something, or provide the wrong argument type to a method, or have args in wrong order, etc, it's caught instantly. With JS you can have a typo that causes user malfunctions for YEARS before being found by a d…

> Any developer who's done many years of both TS and JS would never in a million years consider going back to JS.

Except, apparently, for the topic of this article.

> If I misspell something, or provide the wrong argument type to a method, or have args in wrong order, etc, it's caught instantly.

Yes, I've heard the pitch before. I've even given it more than a few times.

Of course, if both of your arguments happen to be 64-bit floats, then the type system won't help you much if you get them in the wrong order.

However, when you want to change that function to take a closure instead of a number, the type system can be invisible or it can fight you. Some of us love the structure that a type system can provide. Some of us, like the one who started this website we're on now, also appreciate the power of languages that get out of your way and let you make your own brilliant mistakes. And some of us can appreciate the beauty of different language designs and approaches, and try to rise above dogma. Which, if you've been in this line of work for 20+ years, should be you.

Re: Deno will stop using TypeScript

#313

Earlier quoted context omitted.

Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have th…

I suppose you are also going to tell us that after you’ve fitted all of those perfect functions together into that perfect program, the requirements have never changed. And I suppose when those requirements never changed you never had to rewrite lots of these perfect functions or resort to “append only” programming in order to make sure regression was impossible instead of making large changes in place. Forgive me ,…

In these discussions I basically see people try to fool other experienced craftspeople about the reality and core axioms of the craft. The idea of ascending as a developer to a point where you don't need guardrails and never have to refactor code is just not going to convinced experienced developers. It's clear bullshit.

It's like trying to convince experienced motorcyclists that you don't need a helmet because you're quite the driver. It's just defensive driving, people! That the helmet is some sort of crutch you've transcended, and maybe if everyone had a bit more skill -- like yourself -- they'd understand.

Yet it always seems to be half of the dynamically- vs statically-typed language debate.

Re: Deno will stop using TypeScript

#314
post #22

Earlier quoted context omitted.

You don't have to write as many tests when you use static typing, because your method contracts are solid. You can refactor your entire codebase with a few operations and don't have to worry about anything breaking. Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone? Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs? Where are your dynamic…

Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have th…

The line of perfect and infallible humans began with you, and will one day end with you. The rest of us need a bit of help to smooth over our human faults.

The only perfect decision I made is to accept that I make imperfect decisions, I wish I could attain the consistent perfection that you describe here.

Re: Deno will stop using TypeScript

#315

Earlier quoted context omitted.

Yikes to see people assume so little about others. Why not ask people why they use Node instead of assuming the worst about them? You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem. Btw, what's lazy is making convenient uncharitable assumpti…

I believe people here don't belong to the situation I mentioned. You are here because you are interested and want to learn. You probably know more than 1 language. But that is not the general developer. Most developers are lazy and at the end of the day, want to go back to their wife and kids ( for example).

Yeah, and there's absolutely nothing wrong with that. It's the sign of a healthy work-life balance.

The real problem is that businesses don't want to train devs in the right tools for the jobs at hand, and are instead looking for the shortcut that will let them 'ship it'.

Re: Deno will stop using TypeScript

#316
post #288

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…

The entire comment did not mention testing so it sounds like you never have to continue working on a codebase and eventually face the challenges of refactoring something that you didn't write or remember writing. How about self-documnted code how often do you work with others?

I do work with others in non-TS codebases. I think I just been conditioned to think like that. I’m a product of my environment. I know my opinion is biased and after reading many of these comments I understand why people get a lot of value from it. I mean, I have always known that. Otherwise it wouldn’t be as popular.

It just happens to be that I have never been exposed to the circumstances that would make me re-evalute TypeScript merits.

Re: Deno will stop using TypeScript

#317
post #156

Earlier quoted context omitted.

Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.

See, that's interesting. 'Cause I do write small functions, I do avoid side effects, I do avoid mutation--and writing code in dynamically typed languages still bites me when I'm forced to do it. (It isn't really any faster to write, either.) So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Do…

Anything to justify not learning a new language.

Re: Deno will stop using TypeScript

#318
post #273

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed mor…

That document is not particularly enlightening either. > we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. But perhaps this is something beyond the simpleton comprehension of us novice programmers

> That document is not particularly enlightening either.

Here are some key words that many kibitzers here could benefit greatly from internalizing:

> > The target audience is the 5 to 10 people who work on this particular internal system.

> Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run.

Are you one of the people responsible for maintaining those 10KLOC?

> But perhaps this is something beyond the simpleton comprehension of us novice programmers

I believe Ryan Dahl would admit to having made more mistakes in large system design than most of us will ever have a chance to. Who knows, he may have picked up a thing or two along the way that most of us haven't.

This could also just be an internal product decision that really doesn't affect anyone outside the core project team, while some of us here are projecting way too much onto it.

Re: Deno will stop using TypeScript

#319
post #47

Why remove it entirely rather than split off compilation and type checking? I’m not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.

As other's have pointed out, it really sounds like the deno devs were unfamiliar with what's available with build options for typescript. An unanswered question everyone is asking, why do they handwrite the .d.ts that can be autogenerated?

Re: Deno will stop using TypeScript

#320

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…

Are unit tests a regular habit of yours? If they are, you will remember the time you came to lean on them to make your programming faster. Sure, they are lot of work upfront, but the pay off when when you modify code with units tests later is you feel safer, you write code faster and looser, and yet providing the you keep the unit test habit up the quality is the same or even better.

People who use types regularly feel the same way about typed languages. Types don't test as many things of unit tests of course, but feedback you get on what they do test is immediate - literally as you type in a IDE. The speed of that feedback is important. It's a well know in quality circles that errors discovered later cost far more to repair. In the case of types in makes you don't write a hundred lines of code under the expectation a type provides method foo(), only do find out later the foo() provided takes an argument argument you don't happen to having lying around.

While payback for types over unit tests is smaller, the effort required to use types is at least commensurately smaller, and the amount of typing required is way smaller, particularly now we have type inference. Also in my experience unit test's need to reach every line of your code forces some pretty tight constraints on how you structure it. Who hasn't had to refactor some block of code so you could test some obscure corner case catering to an unexpected error? Types don't require that - the compiler always sees everything. None of this matters much if you are going to write unit tests anyway of course, but no one does that for small projects. This is another advantage of the type system - it's always there, even for 5 five liner.

Finally, types come with an added bonus. They give the compiler more information to work with, which means the compiler can make programs run faster. Rust talks about cost free abstractions, which the extreme case: the compiler knows so much about what you are doing it generates no code at all. In rusts case it rarely has to check for if a pointer references null before accessing, and greatly reduces the number of array bounds checks, has no garbage collector, and the pattern of a function checking the number and type or argument in order to implement overloads just disappears - along with the runtime overhead of doing the checking.

Post reply on HN