Hi all,
I'm using Clojure to build a set of services.
Development with Clojure is fun but most of the time, I lose time with
fixing regressions due to changing small parts of the codes. Do you have
any best practices to avoid regressions occurring due to changes in the
code? I use :pre and :p
Hi Timur,
I find almost all of my pain is from changing shapes of the data that flows
through the system. As you say “I pass the results in a map and each function
updates the map” so even if you unit test each fn that doesn’t actually help
because the tests provide the (now incorrect) data. St
Timur writes:
> Hi all,
>
> I'm using Clojure to build a set of services.
>
> Development with Clojure is fun but most of the time, I lose time with
> fixing regressions due to changing small parts of the codes. Do you
> have any best practices to avoid regressions occurring due to changes
> in t
Hello all, just wanted to mention a few easy places that someone could help
out if they're interested.
There are two excellent guides that Andy Fingerhut has written in the past
on comparators and hash/equality stuff. Andy has given the ok to contribute
those guides onto the new clojure.org sit
Does anyone want to suggest or promote a naming convention for atoms, refs,
and agents, i.e. some of things that you can dereference with @ i.e. deref?
(Also, what about futures, delays, and promises? I think of these as
playing a different sort of role, even though deref works with them, too.)
&, $, and ! might be good to use as special naming characters for
atoms/refs/agents, either as an initial char, a final char, or both, but
I'm wondering whether anyone already has a naming convention that they use.
--
You received this message because you are subscribed to the Google
Groups "Cl
Why should they have any sort of naming scheme? Dynamic vars are unusual
because their values can change. Atoms and refs remain the same, and even
though inside their values mutate, they don't affect the outer var.
- James
On 5 December 2015 at 21:39, Mars0i wrote:
> Does anyone want to suggest
I took it to mean "How many people are *using* your Clojure app?"
On Friday, December 4, 2015 at 3:33:10 PM UTC-5, puzzler wrote:
>
> I took it to mean "How many people are working on your Clojure project?"
>
> On Fri, Dec 4, 2015 at 8:44 AM, James Reeves > wrote:
>
>> What does this question mea
Also, if you have so many atoms in your program that it becomes hard to
remember where they are, that would be another source of concern ;-)
On Sat, Dec 5, 2015 at 4:44 PM, James Reeves wrote:
> Why should they have any sort of naming scheme? Dynamic vars are unusual
> because their values can c
On Saturday, December 5, 2015 at 5:45:22 PM UTC-6, James Reeves wrote:
>
> Why should they have any sort of naming scheme? Dynamic vars are unusual
> because their values can change. Atoms and refs remain the same, and even
> though inside their values mutate, they don't affect the outer var.
>
On Saturday, December 5, 2015 at 8:04:34 PM UTC-6, tbc++ wrote:
>
> Also, if you have so many atoms in your program that it becomes hard to
> remember where they are, that would be another source of concern ;-)
>
Yeah I'm worried that I'll come back to the code a year later and not
remembe
As in the past, many survey questions are not appropriately designed for
getting info about uses of Clojure in academic research. I don't think
there's very much use of of Clojure for this purpose, but the survey won't
be able to track it.
(Examples:
7. Where do you deploy Clojure, ClojureSc
12 matches
Mail list logo
