3 ms·
> Easy to reason about, I'd like to know what language you use as a baseline for this? I made my first "real" Javascript code back in 2005 (a vector map syste
by eitland 6y ago
> Easy to reason about,
I'd like to know what language you use as a baseline for this?
I made my first "real" Javascript code back in 2005 (a vector map system that worked in realtime) and I've been working mostly with frontend for the last 3 years so it is not lack of familiarity. In between that however I have programmed a lot of other languages, worked in a number of different teams, written new code, maintained old code and generally gotten some perspective on life.
That perspective has sent Javascript down my list of languages that are easy to reason about.
- vorpalhex 6y agoEvent 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.