4 ms·

Show HN: js.spec, a JavaScript implementation of clojure.spec

96 points by prayerslayer 10y ago

dwwoelfel 10y ago
Have you used js.spec or clojure.spec in production? Has it helped you catch bugs that you would have otherwise missed? How does the runtime-only limitation work out in practice? I know that flow has prevented me from checking in bugs, because I've tried to push up code with e.g. misspelled property names and the pre-push hook stopped me.
- mhluongo 10y ago
  One of the Clojure validation libs predating spec, schema, has saved us from a ton of errors, and works similarly. It also opens up reasoning about data shape- eg, auto-generating test data based on schemas. spec's support for that use case is even better. EDIT: You can see schema in action in https://github.com/cardforcoin/shale https://github.com/cardforcoin/shale. In fact, the latest build surfaced a bug via schema- https://circleci.com/gh/cardforcoin/shale/379 https://circleci.com/gh/cardforcoin/shale/379. Next version we're planning to migrate to spec.
- prayerslayer 10y ago
  > Have you used js.spec or clojure.spec in production? Not yet, but I have some use cases (mostly validation).
moxious 10y ago
I think of dynamic typing in a language as a big pro and a big con at the same time, but it's one of the things that makes a language like JavaScript or closure what it is. I love typing systems too, there are compelling advantages...and disadvantages. I guess sometimes what seems strange is attempts to bolt type systems on to fundamentally dynamic languages, like adding two extra wheels to a motorcycle, extra fairing, and then calling it a car. I don't fault anyone for wanting a car. But if you wanted a car, why not start off with a statically typed language? Why bolt this stuff on really in contravention to what the dynamic languages are trying to be? Perhaps this is JavaScript fatigue in a new guise? If everything has to be JavaScript (for whatever reason) then having no static typing ever may be hard to live with? Am I missing something or does the motorcycle with two extra wheels seem destined to be clunkier and less flexible than a proper car?
- mhluongo 10y ago
  Spec (and more generally, contracts) aren't just about "making up" for the lack of static typing. They can encode a variety of invariants that a type-system can't, and are also useful for parsing (see coercion) and generative testing. Unlike most type systems, they also aren't required across the whole code base.
  - nilved 10y ago
    It depends on how you implement the gradual typing as well. Through contracts is one way (probably the bad way, since they still apply at runtime) and static analysis with type annotations is another way. There isn't any reason a sufficient static analyzer couldn't be as powerful as an inbuilt static type system. This is effectively dragging some of the benefits of static typing to dynamic typing. I wonder why you'd pay the cost of dynamic types though, instead of going the other direction. With type inference you don't need to explicitly write types the entire codebase, and you can opt-in to dynamic types in controlled, explicit scenarios.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - tel 10y ago
    Parsing and generative testing are well-covered by static types, but I'll give you that contracts can enforcing things static types cannot. That said, static types can enforce things that contracts cannot, too. Furthermore, in my experience I find use of the things that static types can catch and contracts cannot on a nearly hourly basis while I rarely to never use things that contracts can check but static types cannot.
    - arohner 10y ago
rattray 10y ago
Seems cool. Also worth checking out: tcomb[0] which can let you use your Flow types at runtime for eg; pattern matching. [0] https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb
- prayerslayer 10y ago
  Cool, thanks for sharing. I didn't know that one.

96 points by prayerslayer 10y ago

Have you used js.spec or clojure.spec in production? Has it helped you catch bugs that you would have otherwise missed? How does the runtime-only limitation work out in practice? I know that flow has prevented me from checking in bugs, because I've tried to push up code with e.g. misspelled property names and the pre-push hook stopped me.

mhluongo 10y ago
One of the Clojure validation libs predating spec, schema, has saved us from a ton of errors, and works similarly. It also opens up reasoning about data shape- eg, auto-generating test data based on schemas. spec's support for that use case is even better. EDIT: You can see schema in action in https://github.com/cardforcoin/shale https://github.com/cardforcoin/shale. In fact, the latest build surfaced a bug via schema- https://circleci.com/gh/cardforcoin/shale/379 https://circleci.com/gh/cardforcoin/shale/379. Next version we're planning to migrate to spec.
prayerslayer 10y ago
> Have you used js.spec or clojure.spec in production? Not yet, but I have some use cases (mostly validation).

moxious 10y ago

I think of dynamic typing in a language as a big pro and a big con at the same time, but it's one of the things that makes a language like JavaScript or closure what it is. I love typing systems too, there are compelling advantages...and disadvantages. I guess sometimes what seems strange is attempts to bolt type systems on to fundamentally dynamic languages, like adding two extra wheels to a motorcycle, extra fairing, and then calling it a car. I don't fault anyone for wanting a car. But if you wanted a car, why not start off with a statically typed language? Why bolt this stuff on really in contravention to what the dynamic languages are trying to be? Perhaps this is JavaScript fatigue in a new guise? If everything has to be JavaScript (for whatever reason) then having no static typing ever may be hard to live with? Am I missing something or does the motorcycle with two extra wheels seem destined to be clunkier and less flexible than a proper car?

mhluongo 10y ago
Spec (and more generally, contracts) aren't just about "making up" for the lack of static typing. They can encode a variety of invariants that a type-system can't, and are also useful for parsing (see coercion) and generative testing. Unlike most type systems, they also aren't required across the whole code base.
- nilved 10y ago
  It depends on how you implement the gradual typing as well. Through contracts is one way (probably the bad way, since they still apply at runtime) and static analysis with type annotations is another way. There isn't any reason a sufficient static analyzer couldn't be as powerful as an inbuilt static type system. This is effectively dragging some of the benefits of static typing to dynamic typing. I wonder why you'd pay the cost of dynamic types though, instead of going the other direction. With type inference you don't need to explicitly write types the entire codebase, and you can opt-in to dynamic types in controlled, explicit scenarios.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- tel 10y ago
  Parsing and generative testing are well-covered by static types, but I'll give you that contracts can enforcing things static types cannot. That said, static types can enforce things that contracts cannot, too. Furthermore, in my experience I find use of the things that static types can catch and contracts cannot on a nearly hourly basis while I rarely to never use things that contracts can check but static types cannot.
  - arohner 10y ago

rattray 10y ago

Seems cool. Also worth checking out: tcomb[0] which can let you use your Flow types at runtime for eg; pattern matching. [0] https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb

prayerslayer 10y ago
Cool, thanks for sharing. I didn't know that one.