okay, now I understand what you are saying. people use const to enforce strict type or at least to not let the variable change.... but then it can't be altered... like if you want to change it or increment it from 0 to 1
okay, so they are a heavy price to alter the context to change the function of defining strong type variables with preexisting syntax notions.
time to learn typescript cause that is where javascript syntax going to adopt after reading replies here on this post.
I don't think so; You may ask a python developer and you'll know. I've quoted the docs for reference in the previous comment. If you think that writing a bunch of comments to document your code is useless and pointless thing to do, then I don't have much to say to you. Just because it increases a bit of bundle size doesn't mean it's evil.
In essence I assume you are saying that the decision made by the python language implementers to include type hints into the language is a wasteful thing.
As I said we can extend this feature in the long run to perform type checking.
During development, developers may decide to type check their code using some mechanism; lets say by using the "use types" pragma (It could be anything else really) at the cost of some performance overhead. Assuming we only care about the correctness of our code.
Then for production they may strip the pragma (or the equivalent mechanism) from their code, this just causes the JS engine to consider all the type annotations as comments so that we can have a performant and well documented code base.
okay, now I understand what you are saying. people use const to enforce strict type or at least to not let the variable change.... but then it can't be altered... like if you want to change it or increment it from 0 to 1
If you want to increment it, then you put your new value in a new variable. There's actually a number of languages out there that only support const, they don't let you reassign to the same variable. However, these sorts of languages also don't supply constructs like the for loop, they have you use reduce instead. I generally prefer a good-old-fashion for loop over reduce (My preference for immutability has its limits @rdking 
). By nature of how a for loop works, I'll need to sometimes use a let binding, but the vast majority of the code I write is able to get by with const, which also means the vast majority of the code I write already has "strict type protection".
If you look at your own code, you might be surprised to find that, you probably don't do a lot of reassigning to the same variable name. Most of your declarations can probably be replaced with const (not that you should or shouldn't, just that it's technically possible)
1 Like
Python isnāt sent over the wire to run websites.
But it's well capable of handling the wiring though which those sites function 
May it be Python or JS the point I was trying to put forward was that the developer productive is important and may well be more important than sheer performance or bundle size.
I consider readability, reliability and correctness of my code over performance any day. I believe people using these dynamic languages do think the same.
āCorrectnessā is a tricky term to get agreement on. For example, there still doesnāt exist a correct type system for JavaScript, in terms of being able to describe every semantic of the language, and no matter how iterative weād want to add syntax for a type system, the whole thing still needs to be designed first.
Thereās also all sorts of questions of semantics - most JS builtin methods type-coerce, and only throw if coercion fails; thereās many use cases where one would want no-coercion throwing. Which do we choose? when it says āstringā, what about boxed String objects? When it says āRegExpā, does that use the relatively useless āit has Symbol.matchā semantics that the language uses, or does it use the more restrictive (but what most people want) semantics of āit has a RegExpFlags internal slotā (eg, itās a real regex)? Etc.
The list of questions to debate is overwhelmingly long, and none of them matter until you can first design a complete type system for the language (TS isnāt one). Work on that, before asking for something that doesnāt exist to be added :-)
1 Like
To be absolutely frank, I think JS will never have a sound type system; As you said "correctness" is a relative measure; If the language is never going to be type safe no matter what we do then why care to make it so? Having a type system similar to TS could nearly represent things semantically then why not consider it? No one's asking for a perfect type system and there exists none; why not give the developers a good enough one. Or at the least try to research a bit into this topic.
If there's an active research in TC39 regarding this topic, please inform the community about it.
@jithujoshyjy have there been any particular issues you've had with using TypeScript, where that would be fixed if it was part of JavaScript?
I think you misunderstand the intent of my words. New syntax that resolves to comments is indeed pointless as that is a lot of work just to add new, non-functional syntax. Comments can already be added and have well documented formats for making them parseable for tooling (jsdoc or Typescript). A new syntax is not needed for that. I never said it's "evil", just not worth the effort.
As for Python, that's a completely different language used in a different context than ES. While various semantic concepts may be useful to borrow from Python, they would still need to be adapted to the context of ES and evaluated for feasibility. Put differently, type hints in Python are useful because they work with how Python is used. I can't say the same would be true if they were ported to ES. As such, if specifying a type doesn't enforce a type check, I cannot say it is worth while for engine developers to go through the pains of trying to modify the syntax.
From a different point of view, if typing were already available in the language as hints, then something like this approach would be optimal to give them the strength of enforcing type checking. But since they are not in the language, justifying their inclusion as simple comments to be acted upon later will be difficult at best.
I have no issues with TS whatsoever. If the minimal type annotations were part of JS then it would eliminate a lot of configurations and plumbing work. Also the fact that it transpiles to JS, we can't use it as is in Node or in the browser. Just making the type annotations (I'm not asking for interfaces, typed template literals or whatever) part of ES would make it a lot more approachable for beginners and experts alike. Instead of stripping off the annotations, considering them as comments would aid in documentation.
I don't like the fact that we have to have 2 separate files: one TS and other the transpiled JS in my code base. Don't you think that it's the WET-est thing to do? Think about the redundancy this would create for large projects! Given the fact that TS is specifically good for large projects.
Think about a code base just composed of JS.
I don't get it why it's not possible to impose type checking later on with some mechanism once type hints become part of the language.
I don't have an issue with this, this is how it works in any compiled language, you have your source code and your compiled (or in this case, transpiled) artifacts. Type-checking works best as a compile-time step anyways, so even if we were to add native support for it in the language, we'd still want developers to put their code through a type-check phase before publishing it.
It would be more annoying if your typescript and javascript files are intermixed in the place, instead of placing the transpiled artifacts elsewhere - I know typescript can be used such that source code and artifacts are intermixed, but I wouldn't recommend having it configured like that.
1 Like
That's the fact I was trying to put forward; TS is more similar to a compiled language and JS is by definition an interpreted one. Unlike TS, bringing types to a dynamic language this way doesn't change anything and requires no additional build steps or procedures.
so true but unfortunately that's not the case with JS. There's no compile time only the runtime; my point was to introduce a runtime type semantics by using the bare minimal TS syntax, which could be extended down the line.
That is to say, considering the type annotations as comments and later we can enforce some way for the JS VM to type check it when specified by the programmer.
Type hints aren't necessarily a usless thing. They can be used by third party tools such as type checkers, IDEs, linters, etc. Also consider the fact that they can also document the code more concisely than things like JSDocs.
I don't see a point to dismiss them entirely.
At least the language implementors should dedicate some of their efforts towards this goal since having a native type system is the most wanted feature of the community.
I guess I'm not entirely seeing why type support would be such a huge win for JavaScript. I would like to have it too, but for me it's more of a minor nice-to-have, as TypeScript is already doing a wonderful job at fulfilling my type-safety needs. If we really want to give JavaScript a powerful type system, we could just standardize TypeScript and make it so browsers can run TypeScript directly while ignoring all type annotations, unless you ask it to do type-checking at runtime (I saw someone suggest something like that somewhere), but what good does that do if it's trivial for the build-step to remove the type annotations anyways?
I guess my question is: If I'm choosing to run the type-check step before I commit my code, will this native type syntax provide me with much extra value?
I think, if we're ever going to get a type system in JavaScript, we're going to need to give it some teeth - some runtime-only features that simply can't be done during a compile-time step. For example, runtime type assertions, or, algebraic data types, or something along those lines.
2 Likes
well as you all have said, typescript is where things are going, I look forward to the new syntax and I guess when I have time I'll look into typescript itself. I hope the language adoption happens sooner for this feature than later. Javascript is a great language. One thing that confuses me about typescript... that it ideally has the type and advances sudo features... well if the purpose of typescript type is to force the users to use type then why not just enforce that? Like JsLint that enforces certain rules, couldn't one just built a transopilor that force the dev to never change the variable type.... wouldn't that be easier... idk.
Are you asking why TypeScript doesn't enforce the type safety? Because it's not possible without them bolting on a ton of runtime behavior into your code. They strive to be a compile-time only step that doesn't actually slow down your production code.
For example, I might have an array of "unknown"s, and at some point I pull something out of the array, check that it has a special property that's set to some unique sentinel, and if it does, I tell TypeScript "hey, this thing right here is an object that implements this User interface over there". I know this to be true, because I know how the code works, and TypeScript simply has to believe me. If TypeScript were to verify this assumption and ensure that this object actually implements my interface, it would have to go through each property on the object (and on nested objects) and compare it with the interface, and this could be a very slow process.
2 Likes