5 ms·

there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typ

there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.

mimixco 6y ago
I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.
- jackjeff 6y ago
 Just use Typescript static types where it is useful. If you access a bunch of JSON objects and you don’t need the typing, you can always declare as ‘any’ and move on. At the end of the day those type exist in JavaScript. If you access ‘first_name’ instead of ‘firstname’ it will not work. The difference is that typescript would let you know before running the code instead of getting an obscure runtime error.
- austincheney 6y ago
 Deno is having problems with TypeScript, but TypeScript is not the cause of that problem. The problem is a self inflicted issue of a name collision of their choosing.
 - jorams 6y ago
 Slow compile times are very much a problem caused by TypeScript.
 - eitland 6y ago
 My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers. I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?
 - austincheney 6y ago
 It is something to do with a class in their code named something similar to header conflicting with a same named definition in their index.d.ts file that is closely related to that class instance. If they dropped use of classes, or differentiated the names of the two things in collision the problem would appear to be solved. To turn that around and blame TypeScript as the point of failure is an extremely bad omen suggesting their code style opinions are more important than product delivery. I could live with that nonsense if this were a framework or some minor dependency, which this application is not.
 - thomasrognon 6y ago
 My compile time went from seconds to minutes when I made a recursive immutable type (which I reverted of course). Overall, I still love typescript. Edit for the curious, here's the monster type that caused such pathological build times... type ImmutablePrimitive = undefined | null | boolean | string | number | Function; export type Immutable<T> = T extends ImmutablePrimitive ? T : T extends [infer U] ? readonly [Immutable] : T extends [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends readonly [infer U] ? readonly [Immutable] : T extends readonly [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends readonly [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends readonly [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends readonly [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends Array<infer U> ? ImmutableArray : T extends ReadonlyArray<infer U> ? ImmutableArray : T extends Map<infer K, infer V> ? ImmutableMap<K, V> : T extends ReadonlyMap<infer K, infer V> ? ImmutableMap<K, V> : T extends Set<infer M> ? ImmutableSet<M> : T extends ReadonlySet<infer M> ? ImmutableSet<M> : ImmutableObject<T>; type ImmutableArray<T> = ReadonlyArray<Immutable<T>>; type ImmutableMap<K, V> = ReadonlyMap<Immutable<K>, Immutable<V>>; type ImmutableSet<T> = ReadonlySet<Immutable<T>>; type ImmutableObject<T> = { readonly [K in keyof T]: Immutable<T[K]> };
- tigershark 6y ago
 No, it’s not counterproductive to access JSON objects using a predefined schema, it saves your ass in case of typos.
snarfy 6y ago
For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests. So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.
- waheoo 6y ago
  If youre doing tdd or writing tests like this you have bigger problems. Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible. And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.
- gameswithgo 6y ago
  and you wait a minute for the tests to run every time you commit a change
  - dboreham 6y ago
    You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...
    - kybernetikos 6y ago
      You know what, that would already be better than most type systems. Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code. Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types. Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration. I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse. These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.

mimixco 6y ago

I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.

jackjeff 6y ago
Just use Typescript static types where it is useful. If you access a bunch of JSON objects and you don’t need the typing, you can always declare as ‘any’ and move on. At the end of the day those type exist in JavaScript. If you access ‘first_name’ instead of ‘firstname’ it will not work. The difference is that typescript would let you know before running the code instead of getting an obscure runtime error.
austincheney 6y ago
Deno is having problems with TypeScript, but TypeScript is not the cause of that problem. The problem is a self inflicted issue of a name collision of their choosing.
- jorams 6y ago
 Slow compile times are very much a problem caused by TypeScript.
 - eitland 6y ago
 My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers. I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?
 - austincheney 6y ago
 It is something to do with a class in their code named something similar to header conflicting with a same named definition in their index.d.ts file that is closely related to that class instance. If they dropped use of classes, or differentiated the names of the two things in collision the problem would appear to be solved. To turn that around and blame TypeScript as the point of failure is an extremely bad omen suggesting their code style opinions are more important than product delivery. I could live with that nonsense if this were a framework or some minor dependency, which this application is not.
 - thomasrognon 6y ago
 My compile time went from seconds to minutes when I made a recursive immutable type (which I reverted of course). Overall, I still love typescript. Edit for the curious, here's the monster type that caused such pathological build times... type ImmutablePrimitive = undefined | null | boolean | string | number | Function; export type Immutable<T> = T extends ImmutablePrimitive ? T : T extends [infer U] ? readonly [Immutable] : T extends [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends readonly [infer U] ? readonly [Immutable] : T extends readonly [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends readonly [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends readonly [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends readonly [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends Array<infer U> ? ImmutableArray : T extends ReadonlyArray<infer U> ? ImmutableArray : T extends Map<infer K, infer V> ? ImmutableMap<K, V> : T extends ReadonlyMap<infer K, infer V> ? ImmutableMap<K, V> : T extends Set<infer M> ? ImmutableSet<M> : T extends ReadonlySet<infer M> ? ImmutableSet<M> : ImmutableObject<T>; type ImmutableArray<T> = ReadonlyArray<Immutable<T>>; type ImmutableMap<K, V> = ReadonlyMap<Immutable<K>, Immutable<V>>; type ImmutableSet<T> = ReadonlySet<Immutable<T>>; type ImmutableObject<T> = { readonly [K in keyof T]: Immutable<T[K]> };
tigershark 6y ago
No, it’s not counterproductive to access JSON objects using a predefined schema, it saves your ass in case of typos.

snarfy 6y ago

For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests. So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.

waheoo 6y ago
If youre doing tdd or writing tests like this you have bigger problems. Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible. And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.
gameswithgo 6y ago
and you wait a minute for the tests to run every time you commit a change
- dboreham 6y ago
  You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...
  - kybernetikos 6y ago
    You know what, that would already be better than most type systems. Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code. Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types. Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration. I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse. These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.