Clojurists Together wants to fund you to work on your open source Clojure project from May-July 2020

[Daniel Compton]

Hi folks

Clojurists Together  is about to award
another round of funding to support open source Clojure projects. *Applications
 close on Thursday, April
9th at 11:59pm PST.*

Clojurists Together is an organisation, dedicated to funding and supporting
open source software, infrastructure, and documentation that is important
to the Clojure and ClojureScript community.

*We plan to fund four projects at $3,000 USD/month for 3 months ($9,000 USD
total).*

Previously we have supported projects
 like Neanderthal, Aleph,
Fireplace, cljdoc, Shadow CLJS, CIDER, Figwheel, clj-http and several more.

We surveyed
 our
members recently and asked them what they wanted us to focus on.

The main things our members were interested in:

   - Error messages
   - Documentation
   - Developer experience tools
   - Build tooling
   - IDE support
   - Test tooling
   - Linters
   - Profilers
   - Data analysis/processing frameworks

If you work on any of these kinds of projects, please look at applying for
funding.

Figwheel, clj-kondo, Kaocha, Reitit, Shadow CLJS, re-frame, Aleph,
Manifold, Calva, Cloverage, Chlorine, Conjure, Malli, clj-goes-fast were
all projects mentioned that our members were interested in supporting.

We encourage open source maintainers to apply
 for funding, especially
if you work on one of the projects or areas that our members highlighted.

If you work at a company that uses Clojure, talk to your engineering
manager about supporting Clojurists Together. We've been able to support
projects thanks to the generosity of our developer and company members
. The more support we have,
the more that we can do to improve things for the entire Clojure community.

Thanks, Daniel.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAK2UX_hO5PZeucAo-MDBo47Ynt_t%2Bu-qO9X6%2B%2Bv4Rw5tQLvNOQ%40mail.gmail.com.

Re: Conceptual difference between map and class

[Dieter Van Eessen]

Thanks, I'm currently reading the book you mentioned (Joy of Clojure). Just 
started on 'Types, protocols and records'...
Still doubting if I should continue learning clojure. From my point of 
view, the only major advantages of the language so far, are 'clojurescript' 
and the idea that I can evaluate stuff that I've 'printed' (data is code is 
data).
Other than that, they are messing with my head by redefining existing 
abstraction and making them 'almost equal but slightly different'.

kind regards,
Dieter

On Wednesday, April 1, 2020 at 6:44:07 AM UTC+2, James Gatannah wrote:
>
> It might be worth mentioning that, ultimately, python class instances are 
> syntactical sugar built around an internal __dict__. It gets twistier, 
> since classes are also instances of the base class object.
>
> It would be tricky (though I've seen an example...maybe in Joy of Clojure? 
> I think the author's conclusion was that it was an interesting experiment, 
> but not worth doing in practice) to implement inheritance using clojure 
> maps.
>
> For me, the conceptual difference has been that it's better to just write 
> functions that work on simple data structures, rather than tying a few 
> together into a unit that only work on a single data structure (plus its 
> derived classes). Clojure's emphasis on functional purity is another major 
> piece of this puzzle.
>
> Unit testing is one thing that becomes much easier with this approach.
>
> I deal with a ton of python code that has tests built around dozens of 
> mock objects mimicking things like database records from an ORM. And then 
> we mock out a few low-level HTTP calls in base classes so the class 
> instances we're trying to test in isolation don't break when we run the 
> tests with no web server to call. Then someone refactors the code, and all 
> the tests break because they're tied to a specific package/module structure.
>
> By contrast, if you have your business logic in one set of pure functions, 
> and you keep your side-effecting parts well isolated on the fringes of your 
> system, you don't need any of that. Just call the business logic function 
> with appropriate values and double-check the results.
>
> You absolutely can write python code that way. But your pythonic 
> colleagues will hate you for it.
>
> Hope that helps,
> James
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/9214c10a-8c9f-465a-9163-e1684d919693%40googlegroups.com.