Clojure data science public meeting

[Daniel Slutsky]

We are organizing a Clojure data science public meeting with lightning talks and chat.

Please fill in your ideas & preferences.

https://twitter.com/scicloj/status/1289949493815902216

[Daniel Slutsky]

Save the date: August 30th, 5pm UTC.

More details will be announced soon.

[Daniel Slutsky]

Clojure data science public meeting, Aug 30th -- registration & details:

https://twitter.com/scicloj/status/1291845872884625408

https://tinyurl.com/y4a2w79g

[Daniel Slutsky]

Preparing to the Clojure data science meeting on the coming Sunday:

https://twitter.com/scicloj/status/1298391171451039744

[Leandro Doctors]

Hello,

Along with a friend, we are preparing a short talk on spec.

The main idea is to show some lessons we "learned" (read: _are_
learning) exploring this awesome tool.

This talk will be aimed at a "geeky" audience unfamiliar with Clojure,
so we will surely add some quick Clojure overview.

Below is our current abstract draft[*]. Whereas there are certainly
plenty of things to talk about when it comes to spec, our original
focus is on showing how spec can help modeling our domain. What do you
think about the focus? Any other improvement suggestions? After 4+
years of clojure.spec (and plenty of talks about it)... What would you
like to see in a clojure.spec talk?

We are also interested in spec-like tools/libraries for other
general-purpose languages, so we can compare them with spec. Although
we think it is very likely there are similar tools around (after all,
formal verification has been around since the dawn of programming), we
are not aware of any other tool as widely used in a general-purpose
language as spec is within Clojure. Maybe you know of such a tool?

Your feedback will be more than welcome!

Thanks,
Leandro

[*] I am pretty sure that the English text of our abstract can be
improved. We started crafting it in Spanish...


*****************************


clojure.spec: A Swift way to Evolve our Domain Model

clojure.spec is a Clojure library that enables us to: 1) describe what
properties should our data conform to, and 2) verify the compliance of
those properties, both at compile time and run time. This quasi-formal
(and, also, verifiable!) specification step of the data model
complements the domain problem modelling step.

During our talk we will show: 1) how this specification usage not only
reduces parameter-validation error generation, but also the generation
of other types of errors within the functions’ code itself; 2) how
this mechanism can be used when writing tests; either standalone, or
combined with some “xDD” variant; and 3) some lessons we learned along
the process.

[Aaron D.]

Leandro,

Active Record Validations [1] in Ruby/Rails are widely used and very much like spec except that out of the box they are coupled to ActiveModel classes.

(A short extension decouples them completely and makes them effectively just like spec -- that is, you can express the validations in isolation and dynamically apply them to Ruby maps/OpenStructs and/or records, just as you do with spec; I wrote about how to do this [2].)

Anyway, I think they would make a very good comparison to spec, I believe, as another dynamic spec-like facility in common use.

[1] https://guides.rubyonrails.org/active_record_validations.html

[2] https://write.as/aaron-d/dynamic-validations-in-rails

[Leandro Doctors]

On Sat, 29 Aug 2020 at 12:40, Aaron D. <atd...@gmail.com> wrote:
> Active Record Validations in Ruby/Rails are widely used and very much like spec
[...]
[Speculation] makes [ARV] effectively just like spec.

Thanks for taking the time to reply, Aaron.

Your pointers are great! We will definitely mention ARV + Speculation
into account when mentioning spec-like options.

Best,
Leandro

[Daniel Slutsky]

Hi.

Here is the video from our Aug 30th meeting:

https://youtu.be/SXmJ6HdLJGA

Also, some personal impressions:

https://clojureverse.org/t/scicloj-needs-you/6467