| |
| ▲ | LoganDark 5 days ago | parent [-] | | > Much like C++ then — the machine code to which it translates lacks types! Ehh, not exactly. Most C++ compilers won't output machine code for inputs they don't understand. Though of course, you could simply translate some C++ code yourself into machine code and then say C++ is just like TypeScript in that way. "If you turn C++ into machine code, the machine code lacks types!" "If you turn TypeScript into JavaScript, the JavaScript lacks types!" The main difference is the C++ compiler won't generate machine code for you if the code you provided it doesn't compile, but the TypeScript compiler essentially treats types as a lint (unless extended by compiler plugins such as `typescript-is`, which I greatly enjoyed back in the day). Also, CHERI begs to differ. And even other than that, machine code isn't dynamically typed because it's not typed at all. Usually, everything is data (usually even the machine code itself, except on Harvard architectures), aside from any architecture-specific memory protections (and other protections), if applicable. I could probably go on about this for days. > A TS compiler will reject an ill-typed program. You of course can just strip the type syntax and get a valid (though buggy) JavaScript code. Can't Deno execute TypeScript directly? Last I checked, it didn't do typechecking itself because [the size and complexity of tsc]. For what that's worth, cling also exists, so try tricking that into executing compiler errors. I don't think it would. | | |
| ▲ | nine_k 5 days ago | parent | next [-] | | > TypeScript compiler essentially treats types as a lint Sorry, I think you've been swindled. The Typescript compiler is made by Miscrosoft and is called tsc. It very much heeds the type annotations, and very much rejects ill-typed programs. An LSP based on it does the same in an editor. Also tsc supports refinement types via flow control analysis and a bunch of other static correctness checks. Deno, bun, swc are not true compilers like tsc, they don't do much correctness checking at all. They discard al the type info, and then operate on pure JS (modules conversion, minification, etc). | | |
| ▲ | debugnik 4 days ago | parent | next [-] | | > and very much rejects ill-typed programs No it doesn't. Even on the strictest settings, Typescript is unsound in trivial ways, which I hit every time I use it in anger (e.g. undefined in unassigned variables). And Microsoft libraries seem perfectly ok with asserting their type errors away without any validation, specially for JSON values. I had a similar experience with Python until I found Pydantic. I haven't had a chance to try Elixir's new type system (is it ready yet?), but at least their strong-arrow model would ensure that runtime checks for dynamically-typed values are done eventually. | | |
| ▲ | nine_k 4 days ago | parent | next [-] | | This is sadly so; TS's type system is unsound. But so is C#'s, in ways much more egregious that in TS. Despite that, both languages are very usable in practice, and their static checks prevent a very wide range of problems common in languages without a static type system. If you need bulletproof soundness and JS as the runtime, you have Purescript %) | | |
| ▲ | debugnik 4 days ago | parent [-] | | > in ways much more egregious that in TS Which ways you say? As far as I know: both TS and C# can carry hidden nulls; both made the mistake of covariant arrays, but C# actually type checks accesses at runtime; and the other unsound case I know of in C# involves a runtime type check as well. Meanwhile, TS (and Python) allow fully unchecked casts into the wrong type. > both languages are very usable in practice Agreed, but I still consider TS too unsound in trivial cases for the claim I replied to, despite its expressive power. I think this industry is lacking severely when it comes to basic software correctness. |
| |
| ▲ | pdimitar 2 days ago | parent | prev [-] | | > I haven't had a chance to try Elixir's new type system (is it ready yet?) Sadly no, and it will likely not be fully ready for years still. It's not a funded work and only a few people are working on it (AFAICT) and the core team understandably wants gradual movement and no incompatibilities. Elixir made me rediscover love for programming and gave me productivity I never dreamed of. But after using it for 9 years, the lack of static typing really started getting on my nerves. There are only so many times you can do manual exhaustive pattern-matching on the hot paths that yell errors in production before you start feeling envious of Rust and Haskell. |
| |
| ▲ | ZephyrBlu 4 days ago | parent | prev | next [-] | | You can lie to TypeScript extremely easily in a way that you can't do in strongly typed languages. | | |
| ▲ | colejohnson66 4 days ago | parent [-] | | Even in a strongly typed language like Java or C#, nothing stops `(string)(object)42`. It all compiles and fails at runtime, like TypeScript. No matter what language you’re in, the second you use a cast, you’re asserting to the compiler that you know more than it. |
| |
| ▲ | nurettin 4 days ago | parent | prev [-] | | I think they are confused by the tslint project, which is different than tsc and is not supported by Microsoft | | |
| |
| ▲ | mabster 5 days ago | parent | prev | next [-] | | I would argue that machine code is typed, but this will be up to interpretation. I.e. you can add two 32 but floating point numbers or two 16 bit integers or store an 8 bit value. It's just doesn't require you to purposefully type pun in some circumstances (e.g. where floating point and integer registers are shared). | | |
| ▲ | jerf 4 days ago | parent [-] | | A "typed" machine code would imply that you can say "Add these two 32-bit floating points" and the CPU will say "No, I can't, those are 4 8-bit unsigned integers". I don't believe the CPU will ever say that, so it is not typed by any sensible measure. Best you can do is that there may be some registers that can only be used by floating point units and others that can only be used by ints, but even that is really just hardware limitations for performance and not any sort of type assertion; the CPU will happily bit-slam them back and forth without anything like an "exception". |
| |
| ▲ | weinzierl 5 days ago | parent | prev [-] | | "And even other than that, machine code isn't dynamically typed because it's not typed at all." Well, we have bytes, words, doublewords and quadwords on the machine level. They are usually referred to as data types in the processor manuals. | | |
| ▲ | nine_k 4 days ago | parent [-] | | I'd say that instructions are typed, but data are not. You can use an integer arithmetic, bit manipulation, floating point arithmetic, or vector SSE instruction on the very same data in the very same register, and it will just work without any complaints for most bit patterns. A CPU of course does analyze the code, but only the short segment currently in the pipeline, and not for any high-level semantics, just for data dependencies and very local jumps. |
|
|
|
