• stevecrox@kbin.social
    link
    fedilink
    arrow-up
    55
    ·
    1 year ago

    I am currently teaching python and JavaScript devs Typescript. Everytime they hit a problem they switch to any

    Sigh

      • TheCee@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        Indeed, and just as my old team fell for consultants, my new team also went ahead and let them add some overcomplex garbage into their codebases. And crap still keeps piling up. It’s just like it’s impossible for them to understand that from an average consultants perspective the only way to go forward is to keep adding complexity, wether they are aware of it or not.

        • OsrsNeedsF2P@lemmy.ml
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Oh, the consultants know, but they get paid, don’t complain about “risks” and “code debt”, and management only sees their delivery on time without increasing operation costs

          • TheCee@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            This. However, in our specific scenario dynamics were even slightly worse. In a first meeting said consultants apparently met some resistance but management decided to go through with it anyway. So in a later meeting, if I was the consultant, would I go and claim “Alright, I fucked up, got paid and got you gaslighted, but now we have to refactor to clean up our codebase with no immediate tangible benefit for your bosses” in front of everyone? Honestly, I don’t think so.

  • jdeath@lemm.ee
    link
    fedilink
    arrow-up
    10
    arrow-down
    2
    ·
    1 year ago

    i like when my strongly typed language can type itself, why should i have to type extra words because the compiler is stupid?

    • Wats0ns@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      17
      arrow-down
      1
      ·
      edit-2
      1 year ago

      So that next time your coworker uses the wrong type, the compiler can scream at him: “NO I WONT COMPILE THIS YOU DUMBASS, LOOK JOHN SAID ON LINE 863 THAT IT SHOULD BE A DOUBLE, NOT A FLOAT FOR FUCK SAKE”

    • tgv@programming.dev
      link
      fedilink
      arrow-up
      11
      arrow-down
      2
      ·
      1 year ago

      So what’s the type of x in

      x = 1;
      x = x + "1";
      

      number? string? string|number? any?

      The ts compiler can make a fair amount of inferences, but at some points you need to nail down the type. Is that so bad?

      • Gecko@lemmy.world
        link
        fedilink
        English
        arrow-up
        18
        arrow-down
        1
        ·
        1 year ago

        Type error unless there’s an implementation of + that specifies adding together and integer and a string.

        • jdeath@lemm.ee
          link
          fedilink
          English
          arrow-up
          11
          arrow-down
          1
          ·
          1 year ago

          💯% accurate. funny how the typescript developer thinks this is some kind of “gotcha!”… like maybe just try a language besides typescript and find out for yourself 😆

          • tgv@programming.dev
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            1
            ·
            1 year ago

            That’s such a weird take. Who cares what another language does? Your complaint was about typescript. Which lets the programmer decide what this should be. As you could have known.

            But most likely it was just trolling. On the plus side, at least now I know that the rigid minded devs came here too, and took their righteousness with them.

            • jdeath@lemm.ee
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              my complaint is that typescript is stupid, yes. so why wouldn’t i compare to what other languages do that is less stupid?

              on the plus side, at least now i know that the ad-hominem minded devs came here too, and brought their righteousness with them.

              • tgv@programming.dev
                link
                fedilink
                English
                arrow-up
                1
                arrow-down
                1
                ·
                1 year ago

                Yeah, you’re right. Lemmy is reddit, but worse, and very small. I have no doubt your contributions will keep it that way. I’m going to delete my account. This is just not worth anybody’s time and attention.

        • nyan@lemmy.cafe
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          2
          ·
          1 year ago

          Exactly. Most languages I know of that allow this at all will coerce the “1” to an integer and give x = 2. They get away with this because they define the “+” operator as taking numbers only as arguments, so if you hand them x = x + "cheese" they’ll error out.

      • sweeny@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        edit-2
        1 year ago

        I’m not sure if you’re being rhetorical or not, but “string|number” is definitely correct here. A computer could definitely figure this out, but typing is for the benefit of the coders more than the code itself. It’s basically functional documentation

        • tgv@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          That’s TypeScript’s whole point. It’s not for the computer, it’s for the programmer. It’s to avoid you assigning a string to something you elsewhere assume to contain a number. In Typescript, there’s just no solution for this, except requiring the programmer to specify the type. It can’t be inferred flawlessly.

          • sweeny@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            1 year ago

            Yeah that’s what I’m saying, I hate it when coworkers will assign everything as “any” just to avoid the scary red squigglies. Oh well I guess that’s what code reviews are for 🙃

  • vithigar@lemmy.ca
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    And if you have linter rules preventing any as a boundary type you just use Record<String, any>.

  • joel_anderson@lemmy.world
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    I mean that is the first step. ¯_(ツ)_/¯ The next step is to start defining the types more strictly than any.

    • mark@programming.dev
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      1 year ago

      Hmmm a more reasonable first step would be to just not even type anything until you’re ready. But TS makes it hard to iteratively type parts of your codebase over time. One could type using JSDoc syntax for these cases, though.

  • ZILtoid1991@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Well, you can always just add the type definitions later on.

    I did port some C code to D, by just pasting it in a D file, then fixing the differences (changing type names, rewriting precompiler macros with D metaprogramming and inline functions, etc.).

  • Pika@lemmy.world
    link
    fedilink
    arrow-up
    4
    arrow-down
    5
    ·
    1 year ago

    I’m in this post and I don’t like it.

    That being said I try to have specific types in my typescript but coming from working without typescript, there’s so much more words involved using typescript and for what I use it for I don’t really see the use case. Sure it helps you realize what part of the script needs what data types but it adds so much more complexity in the code that I’m not really sure it’s worth in the first place.

    • noli@programming.dev
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      1 year ago

      Typescript saves ridiculous amounts of time in bugfixes and is IMO a lot more readable than JS.

      I don’t know how many times TS has complained about some type mismatch in my code that made me scratch my head for 2 seconds to only then realize I was doing something stupid. With plain JS that would’ve been no issue, until I have some obscure bug 30 minutes later and have to figure out it’s source.

      Also, whatever piece of code you are working on, to do anything you have to have the types of your variables/functions in mind. If you have to keep track of all of them in your head, you will definitely mess it up at some point or have to look through a bunch of different methods/files to track down the source of some piece of data to be certain what’s contained in it.

      So yeah, TS might take slightly longer to type out, but it saves you a lot of dev time.

      • Pika@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I mean I guess that could be helpful, I’ve never really had that issue so I have yet to see the benefit of it. I just find it useless work that you’re typing out for something that the engine itself isn’t going to be able to see anyway, which means you’re going to have to have unit tests coded in regardless. And I wouldn’t say just a little more coding, typescript when implemented into my project doubled the amount of code provided, I’m trying to use it because I do understand it’s a standard, but I really don’t understand why it’s a universal standard, considering that everything it does is completely syntax sugar/coder side and it doesn’t actually interact with the underlying engine. I feel the same way about coffee script honestly.

        • jflorez@sh.itjust.works
          link
          fedilink
          arrow-up
          7
          ·
          1 year ago

          Just wait until you have to work as part of a team on a big project. The lack of types will murder the team’s productivity

        • Doc Avid Mornington@midwest.social
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          OK, so, a lot here.

          First of all, Typescript isn’t a standard, much less a universal standard - it’s a fairly patchy implementation of strong typing over JavaScript, created by a private corporation. If you’re going to write strongly typed JavaScript, it’s probably the best option, though not the only option. If you want a strongly typed, functional language, and are not wedded to JavaScript, it’s definitely not the best option.

          Strong typing is an incredibly powerful tool,and will make your life easier, once you wrap your head around it, but it isn’t the only way to go, for all projects. There are definitely some (typically small) projects that benefit from a more dynamic typing system.

          I am not really sure what you are saying about unit tests. It sounds like you are saying you think you need unit tests to assure types on the JavaScript level, even when working in typescript. That’s not the case. You can trust the compile-time type system, if you type your code. You still should have unit tests, of course, but you really don’t need unit tests that check that the types are what your typescript typing says they are. In fact, the more skilled you get at building good types, the fewer tests you’ll need. They’re always a compliment, the goal isn’t to eliminate tests at all, but you will get better safety with less testing.

          Typescript probably shouldn’t be doubling the amount of code. This sounds like you might be adding a lot of redundant type aliases, or specifying types that should be inferred. I’m not sure, I’d have to see the code.

          You also might want to look at your toolchain. Are you doing a bunch of coding, then running tsc and looking at the results? Or do you have an editor set up that can show you typescript errors and suggested completion in real time? It makes a huge difference, having a toolchain that really supports rapid, iterative, strongly typed development.

          • Pika@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            So the biggest issue is the project relies extremely heavily on a third party API service, and since the data is received over said service, typescript is unable to infer what the objects the API is sending is because it sends during runtime, to get around this I have to define everything that I expect that the library is going to have to handle that would be Recieved, since any object that the API is going to return is just going to have a type of any if it’s not defined, this on top of the fact that the API has stated that the data being sent should not be relied on for being accurate and types may change randomly(usually it does not but it has happend, it sucks but out of my control) means that I generally also have to have a function level test the data when it’s received to make sure that the value is being supplied are the correct type and are formatted in a way that the library can still understand it. Which means that it’s able to catch any inconsistency of typing before it would be processed anyway, and would either warn or throw depending on how important the function is to actual operation.

            The reason why I would call it standard is because it seems like basically anywhere you look if you are using node, you’re using typescript they go hand in hand it seems as of the last two or three years, but honestly I’ve never really understood the benefit of, I’ve always thought it was a fairly standard to have at the beginning of a function the documentation of what each perimeter should be unless it is easily verified by looking at it.

            As for my setup, it’s not very advanced it’s just Sublime Text with linter hooked to it, which does tell me on save if there’s a typescript error or if I formatted something wrong, but again even if one did happen to slip through that it would fail during the testing phase due to the fact that it would throw at the function level.

            My opinion of my experience with typescript has been that it’s great if everything is operated in house, but the second you start having to deal with stuff that comes from an external source any advantage of the check just seems not worth the extra effort to make sure typescript works right.

        • jvisick@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          TypeScript is essentially the “measure twice, cut once” approach to JavaScript.

          Yeah, anything can be anything in JS and the type declarations don’t make it into the compiled JS, but allowing anything to be anything starts to become fairly dangerous when the size of your projects starts to grow and especially when you’re working with a team.

          Rather than writing functions and just hoping they always get called with a parameter that has the properties you expect to use, TypeScript helps you make sure that you always are calling that function with the right object in the arguments. You don’t need to debug some runtime error up and down 8 frames in the call stack because this week you named a property “maxValue” but last week you used “maxVal” or you forgot to parseInt some string because you thought it would be coerced - you just need to make sure your types match and eliminate that type of debugging altogether.

          All in all, TS really just enforces a bit of sanity to the foot gun that is vanilla JS.

          • Pika@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Yeah I fully agree typescript does help in terms of knowing what type of types you should be supplying to functions, and for the most part I do use it for non-library purpose/anything that doesn’t rely on a third party, I just feel like typescript isn’t worth it when you have data that’s returned at run time that’s controlled by a third party service. You end up coding more in class definition files then you would just using normal tests