Fork me on GitHub

I think @agile_geek is the most ancient, if we get back to oldness wars, I'm not far behind him...


Though at 2am with a baby on my lap I feel about 95 :-)


@seancorfield yeah, I am the most decrepit and ancient programmer on the planet. I remember when John McCarthy was just a post grad! Thanks for reminding me @korny!


@agile_geek: unless you were unusually late going to uni I think I have three or four years on you...


Morning 😄


@seancorfield I love the fact that in 'real' life I try to fit in with the 'kids' in work (I'm old enough to be the father of the Head of Software Engineering at my current client!) but in this channel we have a p*ssing contest to see who is oldest! toot


@jr0cket did I do something to upset you....come back... 👋


I thought @agile_geek was a state of mind, not an age. 🙂


Holy cr*p Batman! I'm a state of mind! Presumably a deranged state of mind 😉 My wife and children do wonder if I'm a figment of their fevered imagination sometimes!


@jasonbell scary thought but you're safe.


You should be able to guess my age from this : in 4 days time I will be almost exactly 1300 times as old as my baby.


13 thousand times? Really? Not sure the math on that works out? even if your baby was only 4 days old that would be 52,000 days - approx 142 years old!


You are looking good for your age then


Feel free to correct my mathematics as it's always been rubbish 😉


Hmm, sorry, 1300 times!


And through the power of slack I've fixed it, so your comment looks more confused


you can tell it’s near Christmas can’t you....


My comments always look confused....similar to their author


makes me older than you BTW


but how old is your baby @korny ?


That would make it too easy! It's a very new baby.


well, it's older than 4 days, since the earliest message in this channel from you which is still visible is on 18 dec, which means your age is >= 14 years @korny !


Does it help to mention that in 4 days it's my birthday?


oh, i see - you are treating age as discrete @korny - that helps some. the least common multiple of 365 and 1300 is 94900, which means in 4 days you will be 260 years old 😬 although taking account of leap years looked like effort so i know i'm probably a bit wrong


not all of us are Norse death gods that have been around for hundreds of years like you @mccraigmccraig


Try using weeks as a unit. And now I'm embarrassed by my crude approximations of date calculations


ah, in which case you are most likely 25, 50, 75 or 100 years old. given that people always use flattering bio pics i would guess you are 75 👴


i find that hard to believe @minimal


really want a TL;DR; of @korny's age now


@jonpither my age minus just under 2 years


(assoc @agile_geek :age (- (:age @korny) 2)))


actually that's wrong. NM


(assoc @korny :age (- (:age @agile_geek) 2))


@agile_geek: my boss (VP Eng) is half my age so I feel your "pain" there 🙂


When I was "Senior Software Architect" at Macromedia I was one of the oldest people in the company. Then Adobe bought us and suddenly I was one of the youngest people in the company. Perhaps not surprisingly I didn't stay long at Adobe.


Late to the party, but RE: the framework discussion from yesterday


I don’t think frameworks create demand, at least not initially. They cater to a segment who wants a framework


That demand is probably increased these days after the popularity of rails et al


And almost every discussions of such topics I see omits whether the target is a long-lived in-house application, or an agency-style “one-and-done” type of project


which is probably a spectrum, but will have very different needs in the framework stakes


@glenjamin Interesting distinction. At work our original legacy codebase was built without a framework (in CFML), then in 2009 a rewrite started (again in CFML) but using frameworks (MVC, IoC, ORM — argh!), and then as we rewrote some of that in Clojure we gravitated toward a framework more out of comfort than anything else, and now we are framework-free! Hooray!


Whereas some companies would have started 20 or 30 fresh projects since 2009


I think if we wanted to stand up something quickly and didn’t plan to do a lot of long-term maintenance on it, we might consider a framework to “jump start” that but otherwise I think we’re done with frameworks.


and would possibly leave them in the hands of clients who might hire someone else to pick up where they left off later


Yeah, and I think consultancies that build a lot of apps would either develop their own “framework” or use an off-the-shelf one?


@glenjamin I agree they don't create demand. I think their strength is getting to market quickly and consitency, weakness is you have to carry the framework forward and you can get painted into a corner. However, I can see strong evidence in my current client that not having a framework has led to a patchwork of different approaches all cludged together.


Even if the framework is not great they tend to add constraints around the design and sometimes that's a good thing.


We build a collection of clojure apps. Rather than a framework to help though it helps to standardise on a 'stack'


@agile_geek your issue sounds more like the Lisp curse of devs overcooking and doing their thing, rather than having the guardrails of a framework to restrict/guide them


Fair enough, Im not there!


They aren't writing their own DSL or anything


simply struggling to settle on one approach to each issue.


for example there are multiple ways of routing on the client side. Started with one way, then a different set of developers came in and took different approach but old way is still there in places, then they found issues and changed to new approach (but legacy approaches still there). I see this as language independent but a lack of maturity in idiomatic approaches to these issues in the CLojure community at large.


I don't care what the approach is as long as it works and you stay consistent. If you need to refactor to fix an issue, fine. Try out the approach, develop a way to incrementally move to the new way, bake the approach into every change in the backlog and ensure everyone understands the plan, execute.


I think that communication and discipline are the key issues.


Agreed. I see it with our code base in a lot of areas, as we gain more experience with Clojure. For example, with clojure.spec, we have about three different approaches in the code base so far, as we’ve experimented with what works best. I think we’ve reached a good place now and over time we’ll bring the two earlier approaches in line with the latest “best practice” thinking. It can be really hard when there’s so little established best practices out there, and very little in the way of guidelines for idiomatic Clojure.


(it also doesn’t help that our code base initially started life as a set of libraries embedded in our legacy application and has evolved into standalone apps now — so our use of Component is a patchwork and our early use of mutable state still shows through in places)


I'm fine with this as an evolution. The bit teams need to get right is communicating what the current best practice is and how to migrate towards it. That's what I mean by discipline and comms


Yes agree. Not sure a framework would help in these cases (choosing a client side routing lib or clojure spec strategy), when the lang and ecosystem is still evolving at such a pace. Interesting thoughts though, in that large teams may suffer using such an evolving tech, especially with growth of team members + deadlines etc. I suppose the advantage of a framework is to have a known approach and to be firm and stick with what it offers, but in a large team the urge may always be there to splinter off, and the result could be better or worse (worse because at least with a pluggable stack some tempered evolutionary moves may be better than big bang bet-your-house moves). So it comes back to your discipline and comms, managing the people problem. TL;DR; with bigger teams a framework wont save you.


@jonpither very true. I think I'm drawn to frameworks as they tend to come with idiomatic approaches that most developers follow (you can still get rogue groups!) and they give you some sane defaults. The bit I dislike about all frameworks I've used is that once past the simple stuff you get painted into corners or you have to know the frameworks specifics very well. Also they bloat your app with things you may not want. I was hoping arachne might be different.


Arachne will certainly help us to frame the debate. It will be great to see it in action.


Interesting the pain I'm seeing currently is not changing the routing library (same one is in use as at start) it's because it's a library and can be used in multiple ways so it's strength is also a weakness


I'd love to see an informative guide on here's how to run large teams with a lang like Clojure (fast evolving, quite new)


I come back to a maxim I've chanted for 20 years "IT projects never fail due to technical concerns, they always fail because people failed to communicate properly"


I think the answer is 'make someone responsible for each component/service/app in your architecture' and it needs to be the right person. Not necessarily the best architect/developer but someone competent who has the respect of the teams and who can listen and facilitate discussions. But ultimately it's their call. Not quite 'benevolent dictator' but certainly not 'design by committee'


These are actually the skills required of an 'architect'


if you can isolate portions so people don’t often / don’t need to work on lots of different bits


then the cost of inconsistency is reduced


absolutely, again the role of a good architect


Constantly applying single responsibility principle (in the large as well as the small) and thinking 'is this easy to change when I find out I got it wrong or the world has moved on?'


I've never been all that good at design decisions but I've always favoured easy of change over almost anything else and that way I've dug myself out of many holes in the past


The management of people - hiring (and sadly firing) - is just as critical


And you need commitment from somewhere up the management chain that if (when?) you find you’ve made a wrong choice, you can actually spend the time/money to go back and correct it consistently across the whole code base.


@seancorfield agreed. Although, I have managed this kind of change incrementally alongside every other change by 'adjusting management expectations' (and pointing out the cost of not making the change)


I think framework’s could help with consistency. Don’t get me wrong I definitely like the building up from simple pieces approach - but it’s not without its drawbacks. For example we have maybe half a dozen web apps written in clojure. The lack of a good templating approach really hurts, because each project is different; and they all do things differently… Many were luminus projects to begin with, but then as luminus itself changed the template every month or so, have all drifted substantially from each other… some apps use mount others component, others neither for example. I personally don’t find it a huge problem as I know what to expect and how to deal with it… but I was asked to onboard a developer recently who needed to start a new project and I basically had to spend a day templating the start of the app of for him — e.g. putting in component/logging/liberator/aero etc etc I totally agree with the whole communication point; but often one of the best ways to communicate is through code, by establishing good patterns that work, and pointing people at them to copy/reapply. Unfortunately not having a framework means every project is unique, so if a developer googles stuff they won’t necessarily find an answer… Then they need to speak to me or one of the more experienced clojure developers on the team, which is great - but it’s also a distraction.


Anyway, I hope Arachne will do something useful here… but I worry it might be too heavy.


That makes me wonder how far a “corporate standard lein/boot template” would go? It would help in terms of starting a brand new web app… maybe even offer a guide for how existing apps work?


seancorfield: that definitely helps - but you learn more as you go on… so the template gets updated, but the older projects don’t get rewritten (at least not fast enough) so though the onramp is quicker the problem remains


Right, and that goes back to the comments about how should a company / client manage the process of continually updating “legacy” apps to current best practices… which is a hard sell, a lot of the time...


We only added Component into the mix toward the end of 2015 (I think) and it’s been a continual process ever since, converting more and more old code to follow that blueprint.


yeah - we’re actually probably quite good at that - but it takes time - and you have to choose your battles


Remind me: where do you work @rickmoynihan ?


Regarding frameworks though, I do sometimes wonder whether frameworks are fundamentally at odds with the clojure philosophy, which is why they’ll struggle to be adopted. Basically I think a frameworks primarily become frameworks rather than just libraries when they start supplying and managing state… And in the clojure philosophy, saying things about state is basically an application concern not a library concern… i.e. it’s usually better to have an application supply an atom of state - rather than have a library def it.


Herding cats, only with data. Sounds like fun 🙂


Corralling all that random data and getting it organized for useful publications and analysis.


yeah you have a point 🙂


It’s pretty good fun… a nice mix of client work + platform


Cool story of Clojure adoption. 2008, eh? Almost prehistory!


yeah - I’ve been using it for a fair few years now 🙂