Morning 😴

I got round to finishing chapter 2 of Living Clojure last night 🎉 🙂

morning

I was reading through the section on map and thinking to myself that Clojure is really an amazing language and then two sentences later read, "It is OK to pause for a moment and savor how cool this really is."

Lazy sequences, recursion, map, reduce and filter... Awesome stuff

Next is state and concurrency. Really excited

It's like looking at enterprise licences for an Adobe ColdFusion Server licence

Hehe Open BlueDragon was open source and free to use, the last time I looked at CFML was in 2008.

Yeah, the current defacto is Lucee

Ah well, got Yada now.

😄

I just covered atoms in Living Clojure. Hoping to transition away from ColdFusion in the next year

@jasonbell have you been using Clojure since 2008 then?

@yogidevbear no, only in the last 18 months but it’s been full time so it’s all I do now. Went from Java with some Scala for the Spark things and now full on Clojure.

Nice. Sounds like you've had a lot of useful exposure recently

To be honest I’ve pretty much ditched everything else.

Once I managed to flip from OOP to functional, then the light went on, the world is a much nicer place 🙂

Clojure is amazing untill you go to analyze compiler internals

and you see there ugly old dragons

Morning

@jasonbell we are using Datomic in current client and although it's interesting and I can see use cases for it I think a normal relational database whould have worked for the use cases we are using it for. Feels a bit like 'shiny toy' syndrome to me.

@agile_geek handy to know, it looked interesting for what I was looking to do. But yes, shiny I agree with.

@mariusz_jachimowicz yeah, but it's a hosted language so it's really just Java under the covers and not ideomatic Java at that as it's got to run fast so there are lots of ugly optimisations in there. I am literally at this moment watching https://vimeo.com/100518965 by @reborg which is talking about all of that.

@jasonbell don't get me wrong I think it solves a lot of problems I've had in the past in systems dating back as far as the late 80's but strangely enough given what my current client is doing right now its probably overkill. Although it was chosen by a third party and probably with future use cases in mind that we have not yet exploited.

There’s always a good fit for something, somewhere.

I have actually implemented some of the concepts of Datomic myself at least 3-4 times and I've seen it done by others. In all cases our naive implementations caused more problems than they solved (usually performance and having to maintain your own complex DSL beast - an anti pattern I worry about in our community!)

@agile_geek Sure, but Clojure could be refactored. So you could show this code for student and say this is how you should develop or this is how you can simple made easy or this is code based on don't force me to think idea,....

@agile_geek Well it seemed like a possible solution for storing twitter auth tokens in a nice structure.

@jasonbell hmmm, it works well with Clojure because it's datom structure and the Clojure data structures work well together but for that use case any key-value store would work as well and you wouldn't need the transactor functionality per se.

true

If we want to get hype then refactoring should be first class development citizen - get easy to reason about the code even without reading code line by line

@mariusz_jachimowicz I’m happy to accept that Clojure is a JVM language and concentrate on the things I need to do and not concern myself with the things I don’t need to do.

@mariusz_jachimowicz hmm, refactoring it as a teaching exercise might be useful but to be honest if I was teaching (and I do sometimes) Java - which is what you would be doing - unless I was teaching how to write compilers I would not use the core as an example. It's full of the all the 'evil' stuff you wouldn't do in a biz app like lots of statics, massive classes and methods etc.

and don't get me wrong - I love Cloujure and ClojureScript and I admire whole this work

without refactoring it is hard to continue development by new comers

Is the state of core’s code, or core’s approach to contributions a larger barrier?

@glenjamin I don't see this a barrier at all to using the language. I know next to nothing about the core but I've been using Clojure for almost 4 years. I think it's a barrier to contributing to the core but should Rich optimise contributions over utility? Not a good idea IMHO

I don't think current core is optimised for utility at all, it just is what it is

Is clojure good enough that a lack of core progress isn't a problem? Only time will tell

Maybe a bad choice of words? I feel there is a lot in the design of the core that is there to support performance in terms of speed and memory though?

There are some hacks in there for those things, but also aiui lots of junk

I think adoption of the language in business domains is more likely to influence Clojure's progress?

That's true...and a statement that holds for any evolving system that maintains backward compatability.

CLJS has a much better use of protocols for built-in types for example

We all learn from our mistakes...even Rich!

@glenjamin to properly answer your question above... I think the core team's approach to contributions is slightly more of a barrier but that's anecdotal and as I've never come close to contributing it would be better to ask someone who has?

I don't think a language's success has much (anything?) to do with how easy or hard it is to contribute patches to the compiler. The number of people who work on compilers -- and even the core libraries -- in any language is absolutely minuscule compared to the number of users (and I say this as a compiler writer myself -- for both C and C++ back in the day).