This definition is causing issues:
13|> let
14|> ( first, second, third ) = numbersToPair 1 2
15|>
16|> in
17|> ( first, second, third )
This `numbersToPair` call produces:
( Int, Int )
But then trying to destructure it as:
( a, b, c )
Will work, and third will get undefined. I guess JavaScript is gone on a path where Tuple is something that will never see the light anytime soon. And I'm really sad to see that.
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
I don't think it is fair comparison. JS has no compiler so such construct you have put here has no place to be verified, and because of weak typing JS even don't throw here runtime error.
But its true that in JS there is nothing like tuple at the language level, its just an Array with fixed length, nothing more. So it is effected by all array methods like push or pop which never should be in tuple type.
We can though compare Elm with TypeScript, and here if you will type it correctly the error also will be there. Consider:
I didn't know that we could use that Tuple-like syntax in TypeScript. thanks for showing. There are places where it can be very useful.
But since TypeScript will eventually transpile to JavaScript (and since we can't force users of our libraries to use TypeScript) there will always be a flaw in that system, where in Elm you have to use Elm.
Hence why I compared Elm and JavaScript because TypeScript is in the end a superset, not a language (unfortunately).
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
TypeScript is a language. It has no run-time representation, types are removed, but you cannot say its not an language only because it a superset of another language. You can also have run-time data decoders and validators via Elm by using TS abstraction, at the end of the day both languages land into JS.
Yes you are correct. I was wrong for saying that this is not a language.
My point was to say that you can have interfaces, tuples, and everything you want, this won't prevent me from using your library, compile it to javascript and use the wrong types because in the runtime, it is JavaScript.
When with Elm, even when you are using ports you get type safety because even if Elm does compile to javascript, you are in the sandbox of the Elm runtime, which keeps you safe in terms of type checking. And if you dig in the documentation, you'll see that all side effects are handled by the Elm runtime so that you never have to leave the runtime for anything (except again using ports).
Well you can also link an assembly program to a C++ library and call a function of the library (by its mangled name) with all the wrong calling convention and argument types and have the library code crash on the call. Yet C++ is a language...
C++ compiles to assembly (or machine code directly, which can be viewed as the same thing in different representation), just like TypeScript compiles to JavaScript (or a subset of it to Web Assembly - see the link at the end of my comment). My point is that in any language it's possible to escape from the "world" it builds by having something that lives outside of that world making it do unwanted things, circumventing any "in-world" protections this way. Just like I can defeat TypeScript's type safety by interacting with it from JavaScript, I can defeat C++'s type safety by interacting with it from assembly (or actually any other language that allows me to interact with a library - again analogous how I could use, say, CoffeeScript to "attack" TypeScript the same way I can use JavaScript for that).
In both cases I just think it's not right to call the higher-level language less of a language than the lower-level one it compiles to just because there are ways outside of the language's defined borders to make some features of it work not as expected, because then basically every language is actually not a language except maybe for the microcode implementation of opcodes inside the processor, and even then I could mess with it on a hardware level.
And for the above point it doesn't matter that the syntax of TypeScript is mostly (not entirely, by the way!) a superset of JavaScript. It is still its own language which just happens to borrow 99% of JavaScript's grammar, from that perspective. Crystal has also an extremely high similarity with Ruby and is still a different language entirely, which is clearer to see there since Crystal does in fact not compile to Ruby (or take C# and C++, or Visual Basic and QBasic, etc.), but the concept that similarity doesn't devalue either of the similar entities should apply in both cases.
You can also look at it the other way: I guess you would agree more that Elm is a separate language. Yet it also compiles to JavaScript and you can also trip it over by forcing it to do unintended things from the JavaScript side. The difference is that the syntax doesn't resemble JavaScript... but that doesn't affect any technical features of the language at the end of the day, so it should not be relevant! And for that reason I believe calling TypeScript a superset of JavaScript is helpful to start working with it but it just describes syntax similarity, which influences no other part of the language itself. (By the way, there is a project called AssemblyScript - which, using your point of view, could be viewed as a subset of TypeScript - that compiles to Web Assembly instead of JavaScript, albeit not all types are supported. Check out github.com/AssemblyScript/assembly...)
You will never figure out why it starts falling apart after entering PWN3D into the field just looking at the Elm file.
But if you see the rogue script inside the HTML file which reaches into Elm's "protected" world and breaks assumptions (in this case the assumption that reading the property of an HTML element never throws an error), you can see why it behaves like that.
(And in the same way I can of course pass unexpected things from JavaScript into the TypeScript world that break assumptions there, as you said. The only protection against this sort of thing would be to rigorously check every detail at runtime and that would kill performance obviously.)
As I was suspecting, it takes a script written in JavaScript. So you example will work in the case of a malicious attacker having the ability to inject scripts. But I hope we don't do that to our own applications!
I think that we can agree that in the context of an application, one won't use the JavaScript DOM API and the Elm DOM API at the same time or it would be pointless to use Elm.
But I'm really grateful for your example because this kind of attack might be harmful if an attacker has access to a flaw that allows him to inject scripts as I said. I wonder if using the MutationObserver API in some way can prevent the outside from mutating some HTMLElements (but it would probably mean blocking the Elm runtime from mutating it too).
MutationObserver won't help here, especially since my attack is against the JavaScript object representing that DOM element and not even the DOM element itself.
But one point I'm getting confused about right now is this: The reason I even chimed in in the first place was this statement of yours:
My point was to say that you can have interfaces, tuples, and everything you want, this won't prevent me from using your library, compile it to javascript and use the wrong types because in the runtime, it is JavaScript.
...which I read as "things outside of your bubble can interfere with your code at runtime in unexpected ways, rendering your compile-time protections useless", which in my opinion is true for pretty much every language, hence the example with Elm now.
If we are talking about staying inside the bubble anyway, then for me that point is moot, because in your own TypeScript code you also won't add scripts that hurt yourself...
And if you are just talking about the defined interfaces between the languages, then it's true that JSON data in ports won't be able to trip up Elm that easily but that's just because Elm does (expensive) runtime validation there for you. TypeScript leaves this task up to you. (But there are tools out there to help with that, such as the validator io-ts github.com/gcanti/io-ts/ which does runtime validation with given constraints and automatically also creates the correct TS types from it based on your constraints.) Just like in my C++ example: C++ also won't do runtime type checking (in fact it cannot because unlike JavaScript as "base language", machine code doesn't have types, just raw bytes in memory whose meaning is up to you to know).
And if that is actually the point here, then again I don't see how "doesn't do runtime type checking" makes TypeScript any less of a language than Elm. :-)
(Oh and, "in Elm you have to use Elm" isn't true either, because there are (hacky) ways to synchronously invoke your Elm function from JS without implicit type marshalling, and then you can pass arbitrary data to it including data with traps like properties that throw and so on. And since you are talking about other people using your code, you can't force them not to do that either, if they think they need it. See lazamar.github.io/calling-elm-func... for example. Just like only providing a .ts file won't prevent people from compiling it to .js and circumventing your types, providing only an .elm file won't prevent people from compiling it to .js and messing with it either. Or, as mentioned, providing only a .cpp file in C++ won't prevent people from compiling to an .a file and statically linking to it from a language that doesn't care about the original function signatures your C++ functions had.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Too bad JavaScript does not have a real Tuple system compared to Elm.
This code will produce
While this code in JavaScript
Will work, and
thirdwill getundefined. I guess JavaScript is gone on a path whereTupleis something that will never see the light anytime soon. And I'm really sad to see that.I don't think it is fair comparison. JS has no compiler so such construct you have put here has no place to be verified, and because of weak typing JS even don't throw here runtime error.
But its true that in JS there is nothing like tuple at the language level, its just an Array with fixed length, nothing more. So it is effected by all array methods like push or pop which never should be in tuple type.
We can though compare Elm with TypeScript, and here if you will type it correctly the error also will be there. Consider:
The Playground
TypeScript correctly shows an error here 👌.
BTW. I am also fan of Elm. So thanks for the comment!
I didn't know that we could use that Tuple-like syntax in TypeScript. thanks for showing. There are places where it can be very useful.
But since TypeScript will eventually transpile to JavaScript (and since we can't force users of our libraries to use TypeScript) there will always be a flaw in that system, where in Elm you have to use Elm.
Hence why I compared Elm and JavaScript because TypeScript is in the end a superset, not a language (unfortunately).
TypeScript is a language. It has no run-time representation, types are removed, but you cannot say its not an language only because it a superset of another language. You can also have run-time data decoders and validators via Elm by using TS abstraction, at the end of the day both languages land into JS.
Yes you are correct. I was wrong for saying that this is not a language.
My point was to say that you can have interfaces, tuples, and everything you want, this won't prevent me from using your library, compile it to javascript and use the wrong types because in the runtime, it is JavaScript.
When with Elm, even when you are using ports you get type safety because even if Elm does compile to javascript, you are in the sandbox of the Elm runtime, which keeps you safe in terms of type checking. And if you dig in the documentation, you'll see that all side effects are handled by the Elm runtime so that you never have to leave the runtime for anything (except again using ports).
Well you can also link an assembly program to a C++ library and call a function of the library (by its mangled name) with all the wrong calling convention and argument types and have the library code crash on the call. Yet C++ is a language...
Are you comparing C++ to TypeScript? I'm not sure I get the point.
As far as I can remember, C++ is not a superset of Assembly. Please, elaborate your point.
C++ compiles to assembly (or machine code directly, which can be viewed as the same thing in different representation), just like TypeScript compiles to JavaScript (or a subset of it to Web Assembly - see the link at the end of my comment). My point is that in any language it's possible to escape from the "world" it builds by having something that lives outside of that world making it do unwanted things, circumventing any "in-world" protections this way. Just like I can defeat TypeScript's type safety by interacting with it from JavaScript, I can defeat C++'s type safety by interacting with it from assembly (or actually any other language that allows me to interact with a library - again analogous how I could use, say, CoffeeScript to "attack" TypeScript the same way I can use JavaScript for that).
In both cases I just think it's not right to call the higher-level language less of a language than the lower-level one it compiles to just because there are ways outside of the language's defined borders to make some features of it work not as expected, because then basically every language is actually not a language except maybe for the microcode implementation of opcodes inside the processor, and even then I could mess with it on a hardware level.
And for the above point it doesn't matter that the syntax of TypeScript is mostly (not entirely, by the way!) a superset of JavaScript. It is still its own language which just happens to borrow 99% of JavaScript's grammar, from that perspective. Crystal has also an extremely high similarity with Ruby and is still a different language entirely, which is clearer to see there since Crystal does in fact not compile to Ruby (or take C# and C++, or Visual Basic and QBasic, etc.), but the concept that similarity doesn't devalue either of the similar entities should apply in both cases.
You can also look at it the other way: I guess you would agree more that Elm is a separate language. Yet it also compiles to JavaScript and you can also trip it over by forcing it to do unintended things from the JavaScript side. The difference is that the syntax doesn't resemble JavaScript... but that doesn't affect any technical features of the language at the end of the day, so it should not be relevant! And for that reason I believe calling TypeScript a superset of JavaScript is helpful to start working with it but it just describes syntax similarity, which influences no other part of the language itself. (By the way, there is a project called AssemblyScript - which, using your point of view, could be viewed as a subset of TypeScript - that compiles to Web Assembly instead of JavaScript, albeit not all types are supported. Check out github.com/AssemblyScript/assembly...)
Do you have any examples of unintended things you could do on the javascript side using Elm?
You mean the opposite, right? Like, breaking Elm using JavaScript? Since this is what we were talking about.
Here is an example: gist.github.com/CherryDT/7ced888d7...
You will never figure out why it starts falling apart after entering
PWN3Dinto the field just looking at the Elm file.But if you see the rogue script inside the HTML file which reaches into Elm's "protected" world and breaks assumptions (in this case the assumption that reading the property of an HTML element never throws an error), you can see why it behaves like that.
(And in the same way I can of course pass unexpected things from JavaScript into the TypeScript world that break assumptions there, as you said. The only protection against this sort of thing would be to rigorously check every detail at runtime and that would kill performance obviously.)
Interesting, thanks for your repro.
As I was suspecting, it takes a script written in JavaScript. So you example will work in the case of a malicious attacker having the ability to inject scripts. But I hope we don't do that to our own applications!
I think that we can agree that in the context of an application, one won't use the JavaScript DOM API and the Elm DOM API at the same time or it would be pointless to use Elm.
But I'm really grateful for your example because this kind of attack might be harmful if an attacker has access to a flaw that allows him to inject scripts as I said. I wonder if using the MutationObserver API in some way can prevent the outside from mutating some HTMLElements (but it would probably mean blocking the Elm runtime from mutating it too).
MutationObserver won't help here, especially since my attack is against the JavaScript object representing that DOM element and not even the DOM element itself.
But one point I'm getting confused about right now is this: The reason I even chimed in in the first place was this statement of yours:
...which I read as "things outside of your bubble can interfere with your code at runtime in unexpected ways, rendering your compile-time protections useless", which in my opinion is true for pretty much every language, hence the example with Elm now.
If we are talking about staying inside the bubble anyway, then for me that point is moot, because in your own TypeScript code you also won't add scripts that hurt yourself...
And if you are just talking about the defined interfaces between the languages, then it's true that JSON data in ports won't be able to trip up Elm that easily but that's just because Elm does (expensive) runtime validation there for you. TypeScript leaves this task up to you. (But there are tools out there to help with that, such as the validator io-ts github.com/gcanti/io-ts/ which does runtime validation with given constraints and automatically also creates the correct TS types from it based on your constraints.) Just like in my C++ example: C++ also won't do runtime type checking (in fact it cannot because unlike JavaScript as "base language", machine code doesn't have types, just raw bytes in memory whose meaning is up to you to know).
And if that is actually the point here, then again I don't see how "doesn't do runtime type checking" makes TypeScript any less of a language than Elm. :-)
(Oh and, "in Elm you have to use Elm" isn't true either, because there are (hacky) ways to synchronously invoke your Elm function from JS without implicit type marshalling, and then you can pass arbitrary data to it including data with traps like properties that throw and so on. And since you are talking about other people using your code, you can't force them not to do that either, if they think they need it. See lazamar.github.io/calling-elm-func... for example. Just like only providing a .ts file won't prevent people from compiling it to .js and circumventing your types, providing only an .elm file won't prevent people from compiling it to .js and messing with it either. Or, as mentioned, providing only a .cpp file in C++ won't prevent people from compiling to an .a file and statically linking to it from a language that doesn't care about the original function signatures your C++ functions had.)