The fact that this meme makes sense to anyone demonstrates how dynamic typed programming languages cause brain damage.
I prefer to think of it as maybe don’t shoehorn a shitty type checker into a dynamic language. Honestly I think people who get excited about typescript should fuck off and go write java instead.
JS is the one that’s built into the browser. If JS wasn’t built into the browser, it would go onto the trashbin of bad old languages that only survived because of their platform like VBA and ActionScript and .bat batch scripting. You can’t compare JS to any other language because JS is the one you don’t get a choice on.
Tell that to the NodeJS people…
tomatoes are fruits that are often used as vegetables and are botanically classified as berries*
*according to wikipedia and my interpretation of it
I once saw a little blurb at a sandwich shop stating that tomatoes are fruit, but if you pair them on a sandwich with jalapenos, you’re getting both fruits and vegetables. I demand better scientific accuracy in restaurant marketing signs.
Now I wonder if jalapenos are fruit too (scientifically)
I like TypeScript less for its ability to categorize my grocery list and more for its ability to stop anyone from putting cyanide on it.
I hate Typescript for promising me that nobody can put cyanide on the list, but in reality it disallows ME from putting cyanide on the list, but everyone else from the outside is still allowed to do so by using the API which is plain JavaScript again
Honestly, programming is great for teaching you that you are the stupid one. This is still a feature.
The main problem with JavaScript and TypeScript is that there is such a little entrybarrier to it, that way too many people use it without understanding it. The amount of times that we had major issues in production because someone doesn’t understand TypeScript is not countable anymore and our project went live only 4 months ago.
For example, when you use nest.js and want to use a boolean value as a query parameter.
As an example:
@Get('valueOfMyBoolean') @ApiQuery( { name: 'myBoolean', type: boolean, } ) myBooleanFunction( @Query('myBoolean') myBoolean: boolean ){ if(myBoolean){ return 'myBoolean is true'; } return 'myBoolean is false'; }You see this code. You don’t see anything wrong with it. The architect looks at it in code review and doesn’t see anything wrong with it. But then you do a
GET https://something.com/valueOfMyBoolean?myBoolean=falseand you get “myBoolean is true” and if you do typeOf(myBoolean) you will see that, despite you declaring it twice, myBoolean is not a boolean but a string. But when running the unit-tests, myBoolean is a boolean.I’ve never used TS, and I’m not exactly sure what nest.js even does, but building a TypeScript project on top of a JavaScript library not designed for it seems like asking for trouble. Is that standard practice?
Yes. As of this writing there are 7,738 type definitions in a central repo maintained by users for plain JavaScript packages.
https://github.com/DefinitelyTyped/DefinitelyTyped
Many package owners write type definitions included with their package that is written in JavaScript also.
Web dev continues to be cursed, I guess.
If I really needed to use a JS library in TS, I’d have to build some sort of adapter between the two that crashes whenever the JS library (that doesn’t know anything about your types) breaks the typing rules. Anything else will inevitably lead to the above “fun” kind of bugs.
I don’t think that this would work, there are no types anymore during runtime because everything is translated into plain js on build. TypeScript only exists during development
Am I missing the joke? Tomatoes are fruits.
Well, that depends on definition. But the joke is why on earth would you want to write types on your shopping list? Like this:
- tomatos (vegetable)
- apples (fruit)
Etc.
Well, I can’t think of an English example from the top of my head, but in German the words for Pear and (light) bulb are the same. So there are some exotic use cases.
