components talk

[William la Forge]

This is really done right! https://www.youtube.com/watch?v=13cmHf_kt-Q

[Raoul Duke]

> This is really done right! https://www.youtube.com/watch?v=13cmHf_kt-Q

The eternal battle between the forces of Data First (e.g. Rich Hickey,
PLT Racket folks) and the forces of Behaviour First (oo, interfaces).

:-)

[Raoul Duke]

Ugh, and now we see that if the language were typed, we'd know and be
able to statically enforce that the start and stop functions have to
return a value. Whatever! I love Clojure but I do not love Clojure.
;-)

[Raoul Duke]

I do not get it. It all seems really, really terrible. So (defrecord
Customers [db email]) is saying that Customers needs the *data types*
db and email, which do not in and of themselves actually specify the
functionality, right? You manually have to connect what behaviour the
Customer needs over to what functionality exists somewhere on those
datatypes?

What we really want is to be able to define the *set of behaviours*
that we want. We want Cusomters to take interfaces that define
functionality on them, not data. That would be basic stuff in
something like Java or Go etc. no??

[William la Forge]

Clojure does oo. It just shirks on typing. You can only provide type hints. What you get are casting errors. Sigh.

Clojure is STILL 10X better than Java. Just different tradeoffs. Like speed. :-(

--
You received this message because you are subscribed to the Google Groups "AgileWikiDevelopers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agilewikidevelo...@googlegroups.com.
To post to this group, send email to agilewiki...@googlegroups.com.
Visit this group at http://groups.google.com/group/agilewikidevelopers.
For more options, visit https://groups.google.com/d/optout.

[Raoul Duke]

I am less complaining about Clojure the language than Clojure the Kool
Aid as defined by Rich Hickey & Stuart Sierra. :-) Yes, I value that
they are offering different ways to tackle the problems. It is
actually great to me that they are doing this. I remain skeptical
about the old sh*t they rail against, as well as the new stuff they
are pushing ;-). Or at least I wish somebody smart could freaking
create the right Middle Ground language.

[William la Forge]

Well, some of that Kool Aid is quite good. Not all of course. If I were to do Java code now, it would be quite different. But what I am doing now in Clojure converts trivially back to Java. Just more boiler plate.

To me, the biggest plus of Clojure may well be the community. There are very few Java devs that are worth talking to, and most of them are hard to reach. And they gotta be, 'cause there's just way too many bad Java devs out there. It breaks my heart, really. I am at least hopeful about the Clojure community.

Right now my biggest complaint is clojure caches. Caches need to be fast, not persistent/immutable. Expect when the dust settles I'll be using guava caches, not core.cache. But that's the rule. When you need speed, use Java. Only then, what is the use case for a clojure cache???

I guess the same could be said for what I'm working on. Only I'm fixing things that I never thought to address in the Java version. Different perspective maybe. Advantage of being a rewrite fer sure.

My argument has been that perhaps the clojure code I am writing will be short enough that someone might take the time to read it. In actuality, I am reading more of my code more often and finding issues I did not before. Clojure is great for that. Brevity has its benefits!

--b

[Raoul Duke]

yes, hooray for Clojure existing at all :-)

[Raoul Duke]

p.s. we could still have brevity and static type checking, tho...

[William la Forge]

Fer sure! And Clojure's Java interop is for the birds! (And I do not mean nice birds.) I mean, it is great that it is even there, but when you need to use it you kinda wish it wasn't!

On Thu, Nov 5, 2015 at 2:24 PM, Raoul Duke <rao...@gmail.com> wrote:

p.s. we could still have brevity and static type checking, tho...