Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#181
Silverware wrote:
Mon Feb 26, 2018 8:54 pm
Weakly Typed languages tend to be a lot faster to get something working in.
While Strongly Typed languages tend to run that thing a lot faster once it's written.

Quite. I initially chose JavaScript to quickly prototype some game ideas, figuring I'd have to rewrite it in Java for speed later. (Stop laughing! :D ) But I found that, with careful design and some effort to use the language well (per browser implementation), JavaScript can be fast enough on most platforms to just write the game in it. (Packaging for distribution is a different kettle of fish; I'm just talking about the basic game here.)

I thought I was going to need a saw and a lathe; turns out the saw works pretty well.

Also, I'm sort of wishing Brendan Eich would see this conversation and drop some Official Knowledge. ;)

Hyperion wrote:
Tue Feb 27, 2018 12:28 am
Pretty sure this whole back and forth about coding standards now ranks as one of the most heated discussions in forum history, more salt and snark here than any thread on politics or religion :lol: But I suppose we can all agree that all politicians in general are just plain awful, definitely worse than java, definitely worse than flash, almost as bad as clients who want to be involved in the development but don't really know what they want.

:lol: Very well said.
Post

Re: [Adam] Thursday, February 15, 2018

#182
Silverware wrote:
Mon Feb 26, 2018 6:10 pm
The TS "compiler" is actually a transpiler, converting TS code into the equivalent JavaScript.

The JS is then run in the browser through either an interpreted method, or by compiling.

Therefore:
For TS to offer Strict Typing, it *MUST* add type checking in.
JavaScript already offers type checking, you just have to make use of it. It's not magic, it's part of the language standard.
That's not quite correct. In your statement you don't seem to differentiate between (optional) static typing (e.g. Java, Dart, TypeScript) and dynamic typing (e.g. JavaScript, Python). As a recap, a language is statically typed if a variable type is known at compile time. Of course TypeScript transpiles to JavaScript, but that does not mean the compiler/transpiler is just translating the code verbatim, or even adding in unnecessary extra conditionals.

In terms of typing, TypeScript (very much like Google's Dart language), can be used both statically and dynamically typed. TypeScript in fact performs static type checks at compile time when types are available, i.e. when they have been declared or when they can be inferred. The generated JavaScript hence contains no dynamic type checks, as in this case variable types are guaranteed to be known, and checked for correctness, at compile time. Still, TypeScript allows you to make use of optional typing (the Any type), and can be used fully weakly typed, but then you're back to square one.

Of course the type check technically has to be "added" somewhere (hint: at compile time). As others have pointed out, the whole point of static typing is to not allow silly run time type errors to creep up, and to not force the programmer to manually type check every single argument. I recommend looking into the actual TypeScript language specification, specifically Section 3: Types.

Money quote:
TypeScript's type analysis occurs entirely at compile-time and adds no run-time overhead to program execution.
Post

Re: [Adam] Thursday, February 15, 2018

#183
Silverware wrote:
Mon Feb 26, 2018 6:10 pm
For TS to offer Strict Typing, it *MUST* add type checking in.
That's not true. Again, if you read what I wrote there is no concept of types or typechecking in runtime in machine code executed on your CPU. But the code executed is still typesafe. Because it was typechecked at compile-time. Same abstract concept applies to typescript.
Silverware wrote:
Mon Feb 26, 2018 8:54 pm
While Strongly Typed languages tend to run that thing a lot faster once it's written.
That is not necessarily true and in fact having runtime type information might allow you to JIT-compile into faster code (which is what android does nowadays for example AFTER compiling into native code). Because that's not the main point behind statically typing things. The main point is error-checking.
Flatfingers wrote:
Tue Feb 27, 2018 1:32 am
Quite. I initially chose JavaScript to quickly prototype some game ideas, figuring I'd have to rewrite it in Java for speed later
The difference in speed is most likely quite minimal, V8 is very powerful.

mysticx explained it very well, so maybe you guys could listen to him if you don't want to listen to me...
Post

Re: [Adam] Thursday, February 15, 2018

#184
Well... if that's the case.
All you have done is checked at transpile time to see if the code expects the value to come in as something other than the specific format, but lost the flexibility of the weakly typed variable, without gaining anything extra.

That seems like a... poor trade.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: [Adam] Thursday, February 15, 2018

#185
That's funny. Open any big opensource javascript or python project and see where that "flexibility" is used. Hint: almost nowhere. Reassigning variables to values of different types is a poor practice in most cases. Not just that, but reassigning variables in general should be a corner case, most of them should be immutable either way, the const keyword should be used as a default variable qualifier in javascript. In rust you have to do additional work to even define a mutable variable ('let mut' instead of just 'let'). Immutable variables make your code cleaner and more readable, easier to follow.

const input_as_string = ...;
// ... More code
const input_as_int = parseInt(input_as_string);

is much cleaner and readable than

let input = ...;
// ... More code
input = parseInt(input);
Post

Re: [Adam] Thursday, February 15, 2018

#186
DoctorGester wrote:
Tue Feb 27, 2018 2:42 pm
const input_as_string = ...;
// ... More code
const input_as_int = parseInt(input_as_string);

is much cleaner and readable than

let input = ...;
// ... More code
input = parseInt(input);
i dont think that its more readable.
i've been programming for over ten years now, and i couldnt give a single hoot about if you add _as_string there.


especially when i dont have to care what type it is in the first place (like in silver's js examples)
Post

Re: [Adam] Thursday, February 15, 2018

#188
DoctorGester wrote:
Tue Feb 27, 2018 3:00 pm
Well I'm not entirely convinced you are using the best practices then.

Check out what other people have to say about this issue: https://softwareengineering.stackexchan ... nst-in-es6

...Well according to that and the explanations, the only place I should use const is on my Goat global object...
Since everything else is just temporary variable assignment, let is fine.

And since I use temporary variables for basically everything, and place any long term data into the global object... well any usage of const in my code is pointless.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: [Adam] Thursday, February 15, 2018

#189
Not seeing where you got that from.

The rule of thumb: use const literally everywhere you can. Use let where you can't use const, for example for (let index of array) { ... }.

For example in this https://github.com/DoctorGester/greevil ... atchery.ts code I use:
const: 84 times
let: 40 times (28 of them in for loops)

So we end with only 12 variables which are actually mutated.

This code:
https://github.com/facebook/react/blob/ ... eactDOM.js

const: 66
let: 28
Post

Re: [Adam] Thursday, February 15, 2018

#190
No, you obviously missed what I was saying.

I have no use for Const, because constant values (for non objects) are stored in an object.
All other values (ones that need to be altered) are stored in let's or the object.

I know const only provides constant values for numbers and strings, for arrays and objects it instead provides constant references.

So the only place for const in my own code is the global object, which stores pretty much everything.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: [Adam] Thursday, February 15, 2018

#192
Dynamic typing is a pain because Python throws errors at me when it's expecting a float but somehow gets an int and I can't tell which it's receiving because they all look the same in the code; it also doesn't tell me where this happens because it usually happens in a completely different part of code and it's a nightmare to debug.

Static typing lets me sort this problem out immediately. I don't buy that dynamic typing helps for prototyping at all; I prototype stuff in C# much more easily.

The benefit of dynamic typing is surely that of variable reallocation and less awkward handing of functions (if you want a function that can take either an int or a float, for example).


Also adding "_as_int" etc. is awful for both readability and practicality and should not be done; your compiler can tell you this in a statically typed language, and it might not even be true in a dynamically typed language. So just no.
Games I like, in order of how much I like them. (Now permanent and updated regularly!)
Post

Re: [Adam] Thursday, February 15, 2018

#193
DigitalDuck wrote:
Tue Feb 27, 2018 4:41 pm
might not even be true in a dynamically typed language
It WILL be true if you define it as const input_as_int = parseInt(input). That's the point. It can never change. Obviously you should not do that for all variables, so that might have been a bad example. But descriptive (or as some say 'overly descriptive') variable and function names are good. For example, consider 'function find_ability_cast_target_based_on_cluster_history'. In a lot of code I've seen this would be called something like 'find_target'. The latter doesn't tell you much. The target for what, find how or based on what? Same applies for variable names. So I would say having "input_as_object" and "input_as_string" is better than "input" and "input2" and much better than having just a singular "input" which can be anything. Obviously if you only have one input variable you don't append the type to the name.

Online Now

Users browsing this forum: No registered users and 6 guests

cron