4 ms·

From what I recall, the Closure type system wasn't well suited to Javascript. I recall it as being quite Java-ish (nominal rather than structural). It's been a

From what I recall, the Closure type system wasn't well suited to Javascript. I recall it as being quite Java-ish (nominal rather than structural). It's been a loooong time since I looked at it, though, so I might be misremembering.

bananapub 3y ago
you're confusing Closure with Clojure
- ramesh31 3y ago
  >You're confusing Closure with Clojure No. Idiomatic Closure code was extremely Java-like. That was the whole point. Google built it to abstract away the nasties of early JS for their huge stable of Java programmers at the time. Dedicated JS engineers weren't really a thing yet.
krackers 3y ago
It's just JSDoc though?
- noelwelsh 3y ago
  Right, but if you can't give precise types to common coding patterns the type system isn't very useful. A lot of work in Typescript is about being able to type the kind of things people do in JS.
paulddraper 3y ago
That is correct. It was heavily Java inspired. (And the compiler itself is written in Java). But the same is true of JSDoc. There weren't any popular type systems that weren't like Java. --- Also, there are some notable departures, e.g. union types.
com2kid 3y ago
TypeScript aims to make a type system that can model anything you can do in JS. Of course JS can modify its objects, at runtime, in literally any way imaginable, so the TS type system has to be Turing complete. Anything less powerful and you aren't going to be able to model what arbitrary JS code is doing. My go to example being a function that takes in an object with a bunch of camel case parameterFields and makes them into snake case parameter_fields. Easy peasy in TypeScript, You can say, in a generic fashion, "pass an object with camelCase field names, and return the same object but the field names are snake_case". This is incredibly useful when adapting between different systems! Traditional OO systems fall flat on their face attempting such feats.
- stevage 3y ago
  Funny, I actually wrote and maintain a library which, amongst other things, does almost the same thing as your contrived example, except it's camelCase to kebab-case. It's written in Flow though, because that was what I knew at the time.
  - com2kid 3y ago
    > does almost the same thing as your contrived example Sadly, not contrived! Anyone using protocol buffers is actually familiar with this exact scenario. Not sure how the JS PB compiler handles things though, I never bothered to look under the covers. Here is a random sample I found of both the types and the conversion code. https://gist.github.com/alfrdmalr/faa012e421d9f7f60c3e6d2d32581157 https://gist.github.com/alfrdmalr/faa012e421d9f7f60c3e6d2d32...
    - stevage 3y ago
      Yeah, cool. In my case I didn't really get all the type stuff right - I was mostly using Flow to be able to generate documentation.
- simonbw 3y ago
  I thought I was pretty good at TypeScript, but I can't imagine how I would write that function. Would you mind sharing that?

bananapub 3y ago

you're confusing Closure with Clojure

ramesh31 3y ago
>You're confusing Closure with Clojure No. Idiomatic Closure code was extremely Java-like. That was the whole point. Google built it to abstract away the nasties of early JS for their huge stable of Java programmers at the time. Dedicated JS engineers weren't really a thing yet.

krackers 3y ago

It's just JSDoc though?

noelwelsh 3y ago
Right, but if you can't give precise types to common coding patterns the type system isn't very useful. A lot of work in Typescript is about being able to type the kind of things people do in JS.

paulddraper 3y ago

That is correct. It was heavily Java inspired. (And the compiler itself is written in Java). But the same is true of JSDoc. There weren't any popular type systems that weren't like Java. --- Also, there are some notable departures, e.g. union types.

com2kid 3y ago

TypeScript aims to make a type system that can model anything you can do in JS. Of course JS can modify its objects, at runtime, in literally any way imaginable, so the TS type system has to be Turing complete. Anything less powerful and you aren't going to be able to model what arbitrary JS code is doing. My go to example being a function that takes in an object with a bunch of camel case parameterFields and makes them into snake case parameter_fields. Easy peasy in TypeScript, You can say, in a generic fashion, "pass an object with camelCase field names, and return the same object but the field names are snake_case". This is incredibly useful when adapting between different systems! Traditional OO systems fall flat on their face attempting such feats.

stevage 3y ago
Funny, I actually wrote and maintain a library which, amongst other things, does almost the same thing as your contrived example, except it's camelCase to kebab-case. It's written in Flow though, because that was what I knew at the time.
- com2kid 3y ago
  > does almost the same thing as your contrived example Sadly, not contrived! Anyone using protocol buffers is actually familiar with this exact scenario. Not sure how the JS PB compiler handles things though, I never bothered to look under the covers. Here is a random sample I found of both the types and the conversion code. https://gist.github.com/alfrdmalr/faa012e421d9f7f60c3e6d2d32581157 https://gist.github.com/alfrdmalr/faa012e421d9f7f60c3e6d2d32...
  - stevage 3y ago
    Yeah, cool. In my case I didn't really get all the type stuff right - I was mostly using Flow to be able to generate documentation.
simonbw 3y ago
I thought I was pretty good at TypeScript, but I can't imagine how I would write that function. Would you mind sharing that?