this post was submitted on 20 Dec 2024
991 points (97.1% liked)
Programmer Humor
34160 readers
50 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Honestly the meme of 'JavaScript bad' is so tired and outdated it's ridiculous. It made sense 14 years ago before invention of Typescript and ES5/6+, but these days it basically just shows ignorance or the blind regurgitation of a decade old meme.
Typescript is hands down the most pleasant language to work in, followed closely by the more modern compiled ones like Go, Swift, C#, and miles ahead of widely used legacy ones like Java, and PHP etc. and the white space, untyped, nightmare that is python.
I'm like 99% sure that it's just because JavaScript / Typescript is so common that for anyone who doesn't start with it, it's the second language they learn, and at that point they're just whiny and butthurt about learning a new language.
As a TypeScript dev, TypeScript is not pleasant to work with at all. I don't love Java or C# but I'd take them any day of the week over anything JS-based. TypeScript provides the illusion of type safety without actually providing full type safety because of one random library whose functionality you depend on that returns and takes in
anyinstead of using generic types. Unlike pretty much any other statically typed language, compiled TypeScript will do nothing to ensure typing at runtime, and won't error at all if something else gets passed in until you try to use a method or field that it doesn't have. It will just fail silently unless you add type checking to your functions/methods that are already annotated as taking in your desired types. Languages like Java and C# would throw an exception immediately when you try to cast the value, and languages like Rust and Go wouldn't even compile unless you either handle the case or panic at that exact location. Pretty much the only language that handles this worse is Python (and maybe Lua? I don't really know much about Lua though).TLDR; TypeScript in theory is very different from TypeScript in practice and that difference makes it very annoying to use.
Bonus meme:
I have next to no experience with TypeScript, but want to make a case in defence of Python: Python does not pretend to have any kind of type safety, and more or less actively encourages duck typing.
Now, you can like or dislike duck typing, but for the kind of quick and dirty scripting or proof of concept prototyping that I think Python excels at, duck typing can help you get the job done much more efficiently.
In my opinion, it's much more frustrating to work with a language that pretends to be type safe while not being so.
Because of this, I regularly turn off the type checking on my python linter, because it's throwing warnings about "invalid types", due to incomplete or outdated docs, when I know for a fact that the function in question works with whatever type I'm giving it. There is really no such thing as an "invalid type" in Python, because it's a language that does not intend to be type-safe.
That's entirely fair for the usecase of a small script or plugin, or even a small website. I'd quickly get annoyed with Python if I had to use it for a larger project though.
TypeScript breaks down when you need it for a codebase that's longer than a few thousand lines of code. I use pure JavaScript in my personal website and it's not that bad. At work where the frontend I work on has 20,000 lines of TypeScript not including the HTML files, it's a massive headache.
I wholeheartedly agree: In my job, I develop mathematical models which are implemented in Fortran/C/C++, but all the models have a Python interface. In practice, we use Python as a "front end". That is: when running the models to generate plots or tables, or whatever, that is done through Python, because plotting and file handling is quick and easy in Python.
I also do quite a bit of prototyping in Python, where I quickly want to throw something together to check if the general concept works.
We had one model that was actually implemented in Python, and it took less than a year before it was re-implemented in C++, because nobody other than the original dev could really use it or maintain it. It became painfully clear how much of a burden python can be once you have a code base over a certain size.