This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-07
Channels
- # aleph (19)
- # aws (1)
- # beginners (75)
- # boot (28)
- # cider (1)
- # cljs-dev (12)
- # cljsrn (20)
- # clojure (350)
- # clojure-argentina (1)
- # clojure-chicago (2)
- # clojure-dev (2)
- # clojure-russia (5)
- # clojure-spec (2)
- # clojure-uk (14)
- # clojure-ukraine (3)
- # clojurescript (68)
- # component (87)
- # core-async (25)
- # core-logic (13)
- # cursive (4)
- # data-science (72)
- # datascript (59)
- # datomic (15)
- # defnpodcast (7)
- # emacs (33)
- # hoplon (5)
- # immutant (73)
- # jobs (21)
- # klipse (6)
- # lumo (14)
- # off-topic (26)
- # om (23)
- # onyx (6)
- # parinfer (37)
- # protorepl (4)
- # re-frame (13)
- # ring (2)
- # rum (3)
- # spacemacs (2)
- # specter (22)
- # sql (47)
- # uncomplicate (10)
- # unrepl (79)
- # untangled (66)
- # vim (47)
- # yada (17)
@adamvh i write libraries for (among other things) solving differential equations and you're absolutely correct that metaprogramming is of great use there. however, compile
isn't quite that. i'm pretty sure you could generate functions on the fly just by using macros and maybe inline caching if you want to really optimize it
that said, my own approach just uses nested vectors and composes derivatives already in data form (a neglected approach since the assumption is once you output a function as data it's worthless for composition). the functional approach is what leads you to metaprogramming, or at least that's the faster way to do it as opposed to having to deal with correctly applying operators to multiple semantic levels of generated functions
so my org is looking to replace our content management system and possibly our back end infrastructure. help me convince them to use clojure?
@lilactown are you considering using Datomic as well ? The combination of both is more compelling than the sum of each one, if you know what I mean
I agree with @qqq, if you can ask for forgiveness, not permission
otherwise, it kind of depends of the organization you work in, but here are some ideas:
* the risk of adopting a new technology is insignificant compared to the risk of failing to deliver (or the difficulty / cost of hiring / staffing the many programmers you'd need with a mainstream technology)
* Clojure is a viable hiring strategy, as you need to hire fewer people, and it helps you steal very smart programmers from boring, high-paying companies
* the REPL brings productivity to a whole new level
* CMS is about manipulating data in a very generic way, Clojure's very well suited to that
* Clojure is very simple, to the point it can even be put in the hands of non-technical people (which is what a CMS is for, isn't it?)
@lilactown: focus on seamless interop. you retain as much java as you want, and you can ransition gradually. meanwhile you get a boost in productivity and programmer satisfaction. find some good examples of using clojure with existing java cms systems.
A CMS can be a very complex beast. I'd recommend introducing Clojure to your org via a much, much smaller project. Trying to bite off more than you can chew, in any language, may not help perceptions of that language.
I aver that, unless guided by an experienced mentor, almost no one with a traditional software development background will arrive at an architecture with which they’ll be happy on their first clojure project.
@lilactown tooting my own horn here, but: https://github.com/emil0r/reverie
I'm doubtful we'll use clojure for the CMS itself, but perhaps the underlying systems