I missed the salient point about data transformations which is that of
abstractions. In OO (Java at least) almost everything was a special case,
in Clojure it is the polar opposite; almost nothing is a special case.
It is astonishing how many domains can be sufficiently modeled as a
sequence of maps [{..} {..} ...] and can be sufficiently transformed with
the 'map' function (with assoc/assoc-in).
On Sunday, 8 February 2015 17:16:40 UTC, Colin Yates wrote:
>
> +1 This separation of behaviour and state is a key part of Clojure's
> philosophy. That isn't to say that stateful components are bad as such
> (Stuart Sierra's https://github.com/stuartsierra/component is an
> obvious analog here) only that they aren't a given as they are in OO
> languages.
>
> As Jony says, when functions only depend on their parameters it makes
> many things simpler and more flexible, but can appear 'noisy'.
>
>
> http://thinkrelevance.com/blog/2009/08/12/rifle-oriented-programming-with-clojure-2
>
> is another good resource here, although I must say I haven't seen some
> of those examples in the wild :).
>
> From a similar background (Java) and having learnt some lessons, I
> wish somebody hammered me on the head with the following:
> - get real familiar with the notion of data transformations, particularly
> maps
> - internalise map, reduce, filter, apply, loop/recur and into
> - before writing any code check the API doesn't already provide it
> - repeat the above three points
> - embrace vanilla maps, they really are all you need (and also watch
> https://www.youtube.com/watch?v=ZQkIWWTygio)
> - small functions (10 lines is uncomfortable) always
> - embrace pre/post conditions, documentation (defn doc and
> marginalia) and prismatic schema
> - read as much Clojure code as you can get your hands on
> - TDD is still a helpful process/technique in Clojure ;)
>
> Longer term, watch anything from Rich Hickey.
>
> By far the biggest conceptual shift was thinking in terms of data
> being the public API and data transformation over blobs of state and
> data.
>
> Hope this helps.
>
>
> On 8 February 2015 at 14:21, Jony Hudson <[email protected]> wrote:
> > To put take a different angle on it: you might soon get to *like* that
> it's
> > usual to pass in everything as a parameter explicitly. It has the
> advantage
> > that it's easy to reason about what a function does just by looking at
> the
> > function. In the example above, when reading AccountRepository.Save you
> need
> > to check elsewhere to see how _connection is defined. Whereas with the
> > function save, so long as the parameters you feed in are sensible, then
> you
> > can be pretty sure what it will do.
> >
> > Making the functions self-contained like this is also a boon when it
> comes
> > to working at the REPL. The OO approach you have often makes it
> difficult
> > (for less trivial examples) to run a particular function in the right
> > context. But with the self-contained function it's just a case of
> getting
> > the parameters right, which is often easier to think about.
> >
> >
> > Jony
> >
> >
> > On Saturday, 7 February 2015 16:07:45 UTC, Dru Sellers wrote:
> >>
> >> Greetings,
> >>
> >> I am trying to convert my mind from OO (C#) to one more functionally
> >> friendly. I am increasingly comfortable with simple applications in
> clojure,
> >> but as I start to build more complex applications, I start to fall down
> >> about how to structure my application. I don't want to just shove OO
> ideas
> >> into the functional nature of Clojure. I'm looking for any help someone
> can
> >> provide to help shimmy my brain into the right mental patterns.
> >>
> >> Background: Long time C# developer who leans heavily on IoC / DI /
> >> Interfaces / Testing / Object Encapsulation.
> >>
> >>
> >> Specific Question: Object Encapsulation
> >> I feel like my function parameter lists are much "wider" than they
> would
> >> be in C#. This is due to the "lack" of a constructor. So if I
> previously had
> >> a C# class that looked like:
> >>
> >>
> >> public class AccountRepository : IAccountRepository
> >> {
> >> IDatabaseConnection _connection;
> >>
> >> public AccountRepository(IDatabaseConnection connection)
> >> {
> >> _connection = connection;
> >> }
> >>
> >> public void Save(Account account)
> >> {
> >> _connection.Execute("UPDATE accounts SET coupon=@coupon WHERE
> id=@id",
> >> { coupon = account.Coupon, id=account.Id});
> >> }
> >> }
> >>
> >> In the above I have encapsulated the "_connection", the other methods
> >> don't have to deal with it. In Clojure (especially if you are following
> >> Sierra's Component pattern) you end up with
> >>
> >> (defn save [db account]
> >> (update db (:coupon account) (:id account))
> >> )
> >>
> >> I end up having to pass this 'db' around all over the place. I think
> that
> >> this is just something I'll have to get used to more than anything. Am
> I
> >> missing anything?
> >>
> >> Thank you for your time.
> >>
> >> -d
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to [email protected]
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > [email protected]
> > 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 [email protected].
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
