•
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.
I've heard it said that the longer you work with JavaScript, the more you hate it. I'm not gonna lie, I really miss working on ASP.Net Core backends. Switching from that to NodeJS was a huge downgrade.
Fine but whatever you think about js, dynamic languages have certain advantages, and trying to turn it into another java or c# is a stupid endeavor. You're not "fixing" javascript by making it more like java.
The type checker is actually pretty smart and can handle a lot of weird use cases, especially in strict mode (if you mark everything as Any type, that's on you). The fact that the underlying language is very dynamic can be both good and bad. It's good because you can be flexible when you need to be, but it also won't prevent you from writing really shitty code, which lends it its reputation.
I don't know if you've ever tried writing frontends in Java, but it is terrible, especially if you want to make dynamic and accessible UIs. You don't use a power drill when you need to hammer a nail.
My comment was obviously devoid of any nuance, I am on programmer humor after all. I actually do use typescript, but I think fixing issues in application code that isn't used by other code is a waste of time. I also think there are lots of advantages of a very dynamic language, like usable REPLs and much easier debugging. We can take these advantages way further by embracing the dynamic nature of javascript, like how lisps do it for example. But instead, everyone is happy going down the route of turning it into another c# (nothing against c# but we don't need all languages to be c# and java).
•
That's what WASM is for, but it's not there yet :(
And you still have to use js for hooks and stuff
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=false and 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.
This is more a condemnation of nest.js than ts. It seems great in theory. I like the architecture and the ability to share models and interfaces between front and backend, but it's objectively makes everything more complicated. It adds layers of abstraction that should not be necessary and it's such a niche/unpopular framework for backend systems that you generally have to jump through hoops to do anything moderately complex. Not only do new devs have to learn typescript to use it, they have to learn the nest architecture to know how to do things "the right way" and you still end up in situations like this which looks perfectly valid but isn't. Typescript was never meant to be used for backend, and trying to make it do so and then complaining about it is like jogging while carrying a gun, shooting yourself in the foot, and blaming the gun.
the ability to share models and interfaces between front and backend
On the other hand, this can be considered a downside because it locks you into using JS/TS on the front and backends.
Alternatively, if you define your models and interface with an Open API spec, you can write the front and backends in whatever language you want.
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
Typically when creating API interfaces you'd be better off marking the inputs as unknown, and then using something like Zod to validate the types
Two questions immediately come to mind. 1) Would you buy the cyanide if it was on the list. 2) Where does one casually buy cyanide? I can't imagine a case where I'd need some, but it would be handy to know if I ever did.
I know you used to be able to get it for pest control, but maybe not anymore. You could also make it the old-fashioned way with molten washing soda. It can be used to make Prussian blue, for one thing.
Obviously take all necessary precautions, especially keeping NaCN away from acids.
I'd say its more like the gas tank telling you that you aren't allowed to pour in brake fluid as that could lead to runtime errors.
Also biologists: "vegetable" is purely a culinary term, and doesn't have any significance in the world of botany
A vegetable is edible plant matter.
Botanically a vegetable is anything that is not the reproductive portion of the plant derived from a flower. A root or tuber such as for yam or potato are vegetables. Edible flowers could be considered a vegetable since the ovary has not expanded to contain seed.
Intelligence is knowing Tomatoes are fruits.
Wisdom is knowing not to put them in a fruit salad.
Greek salad would like a word... the only things that aren't a fruit in Greek salad are the onions and feta.
Wisdom is knowing not to put them in a fruit salad.
A Greek salad is not a fruit salad, it is a...Greek salad.
Pragmatism is putting tomatoes with the vegetables because of taste, which is one of the most important parts of food.
Legalism is declaring in 1893 that it is a vegetable for tax purposes, because fuck you, pay taxes.
The joke is that almost everyone calls them vegetables because the botanic categorisation of parts of plants is niche jargon that is not useful in everyday life, whereas the culinary categorisation is useful, and so your shopping list correcting you is worse than unnecessary.
But that's not what TypeScript does. The joke in the meme doesn't really even make sense.
A better analogy would be you have a basket that's explicitly labeled "Fruit" and TypeScript complains if you try to put laundry detergent in it because you said it's supposed to be a basket of fruit.
This meme was clearly made by someone who doesn't use or understand TypeScript.
This meme was clearly made by someone who doesn't use or understand TypeScript.
It was made by someone who doesn't understand types, period.
Curious if it's the same wizard who was explaining that Linus doesn't understand programming because he has opinions on arm vs Intel architecture. EVERYONE programs in JavaScript anyways and my JavaScript always works on arm. Has Linus lost the plot?
As a proud Massachusettsan, tomatoes are definitely vegetables.
(Technically, tomatoes are both fruits and vegetables)
Aren’t fruits subsets of vegetables? Without looking it up I thought that vegetables were the edible part of the plant and fruits are edible reproductive parts of the plant. I could be totally off on that though.
Yea, you're totally correct. This whole confusion comes from a Supreme Court case that involved tariffs though... Basically, tomatoes are a staple good and should be taxed like a regular vegetable and not receive the elevated fruit tax.
i.e. Americans ruining english for the rest of the world (see also 7th day nutjobs), thanks guys...
It varies by language since the meaning of fruit and vegetable are language specific but that's universal for English. A fruit is an edible portion of a plant that contains seeds and a vegetable is an edible portion of a plant, so... all fruits are vegetables.
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.
We have plenty of homographs as well, “lead,” “bow,” etc but every once in a while I’m struck by just how massive the vocabulary of English is compared to… well, every other language.
•
how massive the vocabulary of English is compared to… well, every other language.
English doesn't even has definite articles.
This is giving me stress daymares about Spanish in high school.
Still, it's an interesting point you make.
But then again, with definitive articles you have a bunch of things that are not supposed to convey gender conveying gender. Like a toaster... It would suck to have to remember the gender of a toaster, or, well toasters in general.
•
It's "der Toaster" which makes it masculine. On the other hand, a girl ("das Mädchen") is neuter. The grammatical gender is somewhat arbitrary and does not follow any "real" rules.
As a German you somehow "feel" if the correct article is used, though.
Yeah, fuck that. English is bs enough.
Edit: yeah, that "feeling" is knowing it so well, you don't totally understand it, and also means it's hard to convey
It's less about magical feelings but rules that native speakers know but aren't aware of. Toaster is clearly male because nouns constructed from verb+er are always male.
Also "male gender" is kinda misleading, it's basically a mistake early linguistics made because it was so centered around Indo-European languages. The modern term is noun class, and Indo-European languages share the trait that they have three noun classes, one containing the word for "woman", the other the one for "man", and another the word for "thing". That's where the names come from: Bridges aren't female in German they simply share a noun class with women.
And girl is neuter in German because all diminutives are. "Deern" is definitely female.
Embarrassingly for someone whose native language is german, I often use the masculine when the neuter should have been used, because they feel the same to me. I never was taught any formal grammar in german, though, so that might play a role.
•
German has different words, too. Even multiple one depending on accuracy
- die Birne -> the pear
- die Glühbirne -> "glowing pear", the light bulb, coming from the shape of the bulb, common, but even Germans see that its dumb
- die Glühlampe -> "the glowing lamp", coming from the literally glowing filament that is used to produce light, the usual term
- das Leuchtmittel -> "the thing that shines", no direct translation, closest would be "lamp", to describe, well, a thing that shines, independent of what is used to produce the light, usually used in technical documentation/environment
German also has multiple other terms to describe a lot of different light bulb shapes and types. Germans can even make up completely new types of light bulbs due to the heavy use of compound words, and every other German can understand that on the fly without further explanation.
Let me just imagine some.
- das Bootshausseitenflutlicht -> a floodlight at the side of a boat house
- die Dreiecksleuchte -> a lamp or light bulb in the shape of a triangle
- das Hinterhausnachtlicht -> a night light for a part of a tenement house accessible only through a courtyard
That's really cool. For whatever it's worth I was joking. I've always admired German and almost elected to learn it in highschool, but socio-geographically(an off the cuff word combination in English), learning Spanish made more sense, as there are many Spanish speakers. But I digress; thank you for explaining such a neat feature of your language to me. I also must admit that the English word is not totally dissimilar in origin; a light-bulb glows in a lamp, but an onion is a bulb in the ground, so it isn't too different from glowpears.
That English has more words than other languages is a myth. Idk why but it keeps getting perpetuated so i guess people just believe it to be true.
Whats more is that its kinda difficult to even narrow down what a word is in a single language, and even more so to find a definition that fits all of them.
Impressively the babbel article manages to include other commons myths like implying english is some kind of mix language rather than a germanic one when it says "This is largely due to invasions of England by the Vikings and then the Normans" about why English supposedly has more words than other languages. This type of incorporation of loanwords is common in almost all big languages.
It argues based on dictionaries and effectively debunks why you can't (for comparison I'd like to add that the SAOB of the Swedish Academy lists circa 500k words).
There's nothing in this article that says English has the most words other than "So, while English is a clear contender for having the most words and German and Turkish have a large capacity for infinite combinations, all languages end up influencing others." Still, there's no justification for the "clear contender" bit other than the Oxford dictionary having more words than Larousse and Littré.
Feels to me like the article just reinforces the notion (and reality) that you can't even make comparisons like that.
Nevermind the fact that this idea is a well known myth in linguistics and arguing against it is kind of like arguing against flat earth theory.
Why not? If a shop is having a sale on fruits only then I would like to sort out all the fruits quickly.
So that the mindless automaton delivering your groceries doesn't unexpectedly give you tomatoes for your sundae, in a future expansion to dish-based orders.
I've yet to create a type error that didn't correspond to me thinking about something wrong.
I swear to god, sometimes I really don't know what Typescript really wants from me. It's like some old god: you know it needs a sacrifice but the god is not telling you exactly what he wants. So you can only try and pray.
The "return type <5 paragraphs of various word salads> is not compatible with " error messages are anything but easy to understand in my opinion.
Yeah I don't get why it spits out whole types instead of only differences between them. Like "function expects non-null 'some.param.in.object' of type 'string' in argument 'someArgument', which is missing in passed argument".
•
Botanically they are. Culinary they are not.
Some languages split the word "fruit" up in those two cases. In Dutch for example, the botanical definition of fruit translates to "vrucht" whereas the culinary definition translates to "fruit".
So, a tomato is a "vrucht" but it's not "fruit"
•
Some languages split the word "fruit" up in those two cases
I wish English did this more. There's way too many words with an overly large number of meanings.
The word "free" meaning both "freedom" and "doesn't cost money" can be confusing - some languages use "gratis" or an equivalent word for the latter definition. Sure, you can use it as a Latin loan word in English, but that's not common.
Guess it's not only Typescript that likes to argue with the developer while missing the entire point...
Malovelence is scooping the entire oily thing with your hands and shoving it into the nearest hole.
I've seen versions of this meme before but I just noticed what he's wearing. Is that a Mortal Kombat shirt?
I don't like it but God help me if I try to bring up that we shouldn't use it. I understand it I just don't like how it slows everything down for in my opinion is not much gain.
tomatoes are fruits that are often used as vegetables and are botanically classified as berries*
*according to wikipedia and my interpretation of it
Technically, according to the definition of a fruit, the cucumber is also a fruit, so yes, the tomato/cucumber salad is a fruid salad.
Intelligence is knowing that tomatoes are a fruit. Wisdom is knowing that they don't go into a fruit salad.
As someone who is relatively new to webdev stuff, I gotta ask... what is the point of typescript? Like, is it faster than JS, does it have more functions or smth? To me it just looks like JS with extra steps and a really, REALLY cursed way to declare variables.
•
As a beginner you don't see the benefits as it is indeed JS with extra steps. It's not worth it for small projects and prototypes, but once you start having larger projects where you need to refactor something, you'll see the benefits.
Also, auto-complete.
Types help you prevent errors while writing the code instead of while running. That's a massive benefit, as it literally makes a lot of errors impossible (as long as you don't work around it) - otherwise you have to write a lot of tests to get the same guarantees, and you could always miss something by doing that.
The other benefit is that it allows other developers to understand your code very, very quickly. Types describe what your data looks like - there is nothing more important in programming than that!
When you install an NPM library and your editor gives you hints about parameter types, return types etc., that's all Typescript types at work.
After maintaining a huge JS codebase for years and finally upgrading it to TS, my life is so much easier. Refactoring is faster and less error-prone. I no longer have to manually document the parameter/return types for every function. I don't have that gnawing "oh damn, what if I missed something" feeling whenever I make changes.
Yes it's a bit more work up front but it pays dividends on larger codebases.
•
It helps for when you have a variable that's for numbers and you use it as a string or something else, it shouts an error. In other words, it protects you from yourself
No, it is slower than JS but it can be compiled to JS. The point of typescript is bringing static (or generally talking, predictable) types to variables, so that treating erroneously a number as a string should be more difficult. In a large codebase, it's easy to make mistakes and debugging is not instantaneous but it needs time. Typescript helps here. You write more code but it helps you out later
I don't have much experience with TS, but in other strongly typed language it goes even further than string vs number.
For example you can have two numbers Distance and TimeInSeconds and even though they are both numbers, the type system can make sure that you won't do distance+time.
It can also let you do distance/time and return Speed type.
It will prevent many logical errors even though everything is technically a number.
I have some knowledge on C# and I've used C++ before... I really like C# (Ik it's not technically fully statically typed but it gets the point across), ASP.net just has too many hoops to jump through just to get a project started, it's kinda annoying.
Typescript gives you better suggestions, red squiggles where you would get errors or bugs if you try to run it, more information about whatever it is you’re using that’s defined somewhere else, and some other neat stuff like project-wide renaming that works every time.