5 ms·
Event threading pulls out a huge amount of difficulty with semaphores, locks, thread safety, etc. The lack of OO means no typecasting, inheritance models, inte
by vorpalhex 6y ago
Event threading pulls out a huge amount of difficulty with semaphores, locks, thread safety, etc.
The lack of OO means no typecasting, inheritance models, interfaces, etc.
Arrays are fully dynamic, not type restricted and operate strictly by reference.
No memory mapping, manual garbage collection or even GC adjustments.
Suddenly the list of things someone has to understand to be a competent JS engineer is way smaller than a language like C or Java.
There are other languages that have a similar level of being easy to understand such as Python and Ruby, and they're good languages too but have a different set of tradeoffs.
- eitland 6y agoHave my upvote for the serious answer. Let's just say we have different opinions. Here's my attempt to create something similar from my perspective: - Being able to know to at any point what a variable can contain is very liberating. (Ok, you can define a list of Object that behaves just like a list in JS: "fully dynamic, not type restricted", but thankfully for people like me that is not common in Java anymore.) - Knowing that the compiler has my back allows me to work faster. - My preferred languages (Java, C#, TypeScript) together with version control allows me to refactor fearlessly.
- vorpalhex 6y agoIt's a tradeoff. Dynamic isn't "better" than typesafety, but it's generally easier to comprehend and reason about. Just yesterday, I was working on a C# script and encountered the following problem: + An engineer had written a script with a Dictionary of type <Transform, Material>. If you've touched Unity, you immediately caught the flaw: Transform's aren't unique enough keys and it's really easy to end up trying to add Duplicate keys, even though you really mean different objects. + So, since we don't care about uniqueness, shift from a Dictionary to a List. Except we have a problem, because we need to keep that Key->Value relation so we know what transforms get what materials. Well, we have a solution to that, it's yet-another-type called a KeyValuePair. + Well we're now nesting a generic KeyValuePair that needs type information inside of a list that is holding <KeyValuePair> objects, which also changes how we iterate through that list and add items to it. + In a language like JS, everything I just said doesn't matter at all because instead of using a Dictionary (Map in JS), we would of just said "Use a Set instead". Done.