Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure

Show HN: Ghostwheel – easy spec, side effect detection and tracing for Clojure(github.com)

64 points by gnl 7 years ago | 19 comments

gnl 7 years ago |

Fellow Clojurians, I present to you, Ghostwheel.

It makes the writing, reading, refactoring, testing, instrumentation and stubbing of function specs easy; introduces a concise syntax for inline fspec definitions; helps keep track of side effects; and makes general debugging almost fun, with full evaluation tracing of function I/O, local bindings and all threading macros.

It's Alpha software and the Clojure port, while essentially functional, still needs some love to achieve full feature parity with ClojureScript – most prominently missing at the moment is the tracing functionality.

To steal a quote from Nathan Marz' Specter in a blatant attempt at a so far likely undeserved comparison to its indispensability, I like to think of Ghostwheel as clojure.spec's missing piece. It has become quite essential to me and I hope that you will find it useful too.

Feedback, PRs, and issue reports are welcome and much appreciated.

Do your thing, HN.

merlincorey 7 years ago | |

I quite enjoyed the quote in the README, and, of course, the name.

Looks like a great project!

gnl 7 years ago | | |

That is certainly a fitting username. Thank you!

divs1210 7 years ago | |

This looks great! Is there a way to make it work with existing specced code? I already have a large codebase with lots of fdefs. Can Ghostweel work with them without modification?

Thanks!

gnl 7 years ago | | |

At the moment you can set the gspec to nil, but that would simply disable s/fdef generation and all of the spec-related magic. I'm planning to introduce a configuration option with the next release to force Ghostwheel to trust that there's an external s/fdef for that function and still do all the spec stuff.

There may be some limitations on this compared to using inline gspecs – I have to play around with it a bit, but I think it should work fine. Until then, you can still use Ghostwheel for tracing and side effect detection though.

gnl 7 years ago | | |

The short answer is "more or less", the longer answer is the second one in the FAQ:

https://github.com/gnl/ghostwheel#faq

kimi 7 years ago | |

I am not sure about the Quick Fix thing in Cursive. Care to elaborate?

gnl 7 years ago | | |

When you place the cursor on >fdef or >defn – which Cursive doesn't know what to do with out of the box – a light bulb appears right next to it. This is IntelliJ's quickfix feature for errors it can easily correct. You click it, select 'Resolve as...' and then 'defn'. I think the default shortcut ist Alt+Enter.

EDIT: I'll update the docs to make this clearer.

yogthos 7 years ago | | |

I wrote a post on the topic here https://yogthos.net/posts/2017-10-03-MovingForwardByLettingG...

Basically, the macro system makes it possible to extend the language in userspace via libraries. This allows the core language to stay small and focused, while different ideas can be tried out as usage patterns change.

The way Clojure is used today is very different from the way it was used a decade ago. However, the language itself has stay remarkably focused over time.

cutler 7 years ago |

Is it just me or is Clojure(script) becoming more and more syntax-heavy with each passing year?

yen223 7 years ago | |

A subtle advantage of having a macro system is that you only pay the price of having unconventional syntax if you opt into it. You can keep the core language small and push weird syntax into macros, which can be imported like libraries.

The core language of Clojure is pretty small and simple compared with most other languages.

gnl 7 years ago | | |

While that is true of the basic building blocks of the language, clojure.spec for example does have an overly verbose syntax (I would define it that way, even though it doesn't introduce new basic syntax elements) for function specs and that was one of the main motivations for writing Ghostwheel.

I wouldn't see this as some sort of development in Clojure though and I don't really know if that's what cutler meant anyway. Maybe he'll elaborate.

grzm 7 years ago | |

Would you care to elaborate? Is there something specific you see in this project that caught your eye? One thing I noticed is the use of ligatures, which is becoming increasingly common as editors embrace Unicode more fully, but that's an editor/presentation feature, not something specific to the language. For example:

  ->  →
  =>  ⇒
  >=  ≥

I've seen an increasing number of people trying out Fira Code, which includes a nice set of such ligatures:

https://github.com/tonsky/FiraCode

gnl 7 years ago | | |

The font in the screenshots with the ligatures is in fact Fira Code and the font in the REPL screenshots without ligatures is Ubuntu Mono.

I guess those could be considered additional syntax, but they're also completely optional and interchangeable with the corresponding, more Clojure-like keywords.

lilactown 7 years ago | |

I'm not sure what you mean. Clojure(Script) hasn't added any new syntax to the core language in a long, long time.

pka 7 years ago |

This looks promising, can you expand on how this differs from clojure.spec and core.typed?

gnl 7 years ago | |

This is basically generative testing using clojure.spec in a nice package with a cherry on top and a few extras.

core.typed still seems to be quite experimental and not yet production-ready, but it certainly looks very promising and I'm keeping an eye on it. It currently also doesn't work on ClojureScript, which has been the primary platform for Ghostwheel so far.

badsavage 7 years ago |

Cool, will try it out!