Fork me on GitHub

I see the conversation turned to Spring yesterday...and it's not officially even Winter yet! cue: tumbleweed blows in from stage left Seriously, Spring has grown to be a bit too much of an attempt to be 'all things to all people' but anyone who denigrates it should be made to implement 5 stateful and 5 stateless session beans (or even worse Entities) using old fashioned J2EE interfaces circa 2000.....and then figure out the xml config to successfully deploy them in an app container! Hint: there was always a container specific xml that was undocumented!


Spring boot is apparently quite nice compared to old styled XML hell. I personally thought there was an anti spring bandwagon going on. It was never that bad.. arguably Hibernate deserves more negative press, not for being a bad tool - they did a great job - just that the whole idea has been surpassed


Annotations were around years before Spring boot. It's just that boot finished off the job by bootstrapping the app with no xml. Actually you could do this in most web containers already. I think JEE has stolen some of Spring's thunder recently by having leaner versions of the same stuff baked in. Agree about ORM's in general (should not single out Hibernate as it was cutting edge in the field for > 10 years! claim to fame is I fixed a bug in beta of their EJB3 implementation but there was no one else implementing it at time). Having said that, I have written many successful apps using an ORM. Like all very high level abstractions, the underlying concepts bleed thru and you need to be aware of them. I would shoot ppl for overuse of 'cascading' reads for example but when you got a performance problem because of it, it was a quick tweak to the config for fix it!


It's the age old 'implicit vs explicit' argument.


I'm feeling the same dilemma with reagent/re-frame...the subscription/dispatch model is a bit opaque to me and I keep getting tripped up by it.


hibernate, lol. object orientation in general - wtf were we smoking? one of clojure's biggest wins imo is calling a map a map


what dyu find difficult about sub/dispatch @agile_geek ?


@mccraigmccraig if I knew that I wouldn't have difficulty with it!


I know the theory and it's simple in a small app you've written yourself but when you parachute into a large code base and try and figure out what components are indirectly effected by!


that subs, handlers and views relating to the same data are often in different files i find a bit difficult - the hardest part of a re-frame app seems to be where to put stuff


i'm on the other side of that equation - i have a large app largely written by me... i should ask my collaborator how he finds it


i log every event to the console, with an interceptor, while developing, which i find very helpful @agile_geek


I think what's missing (in a lot of clj/cljs libraries) is a steer on 'conventions' to how to organise subs, handlers and views etc,


in combination with a schema for all of app-db checked after every app-db change (again, only in dev) you get a very good idea of what should be there and immediate errors when it's wrong


Yeah, schema/spec coverage on this database is a little sparse in places and conventions seem to differ. You can definitely see 'phases' of development by different people. This has been recognised and it's being addressed but as always business priorities come first


I hadn't seen that page.


another useful trick is to namespace event and sub keywords, perhaps with synthetic ns parts relating to some notion of component or area in an app


my dev process is very repl driven & complete schema checking at all boundaries works very well with it


(otoh my test coverage is a bit rubbish)


I think issues I'm seeing are the usual result of one company starting development, another taking over code base and lots of different opinionated developers!


@agile_geek totally agree, Spring was awesome when it was new. Spring boot is great for a very rapid start, but basically it’s a magic hidden set of component versions that they have “tested” to work together - somewhere there’s a config that says “ok, you get spring-core 3.1.2 and spring-security 3.2.7 and spring-jdbc 3.2.4 and … and we’ve run our acceptance tests against that combo, you should be OK”. The problem being, if you pull in a 3rd party tool that grabs a different version of a spring component, you can have versioning hell (and there’s nothing as simple as lein deps —tree to help) - we found that we had loaded two different major releases of spring-security, and so we were using an ‘untested’ combination. It did seem to work, but rather nervewracking.


I’m also in two camps about annotation and other configuration magic - lots of IOC containers do this, but you end up with a whole lot of behaviour that is opaque without a lot of background knowledge. You think Rails is bad for convention over configuration - in Spring Boot, if you want to add a health check thing, you implement an interface (or annotate a class, I can’t remember) and magically you get a new health check page entry. Trying to work out where those health checks are coming from involves (a) knowing this is how it works, and (b) searching through your code, and any 3rd party jars, to work out what implements that interface. Smart IDEs help, but it’s still rather mad imho - if you need these tools, your app is too big. </rant>


@korny 'nothing a simple as lein deps -tree'? Isn't that just syntactic sugar over mvn dependency:tree anyway? You can even filter on the jars that include your suspected culprit jar - mvn dependency:tree -Dincludes=spring-security-core


I think the problem was that it should be mvn dependency:forest


sorry, but you are right, you can find the tree - it’s navigating it that was hell. (actually, if I recall correctly, the big problem was knowing that there was a problem - everything seemed fine until we were debugging something and found that two security cals were going to two different libraries)


@korny I'd agree about opaque behaviour but as per my conversation with @mccraigmccraig I don't think that issue is constrained to any particular language/framework/library, although better in some than others. As with all these issues it's normally a 'people' problem (developer communication and discipline). Sometimes it's better to have a 'benevolent' dictator impose 'faulty' structure than a lot of 'smart' people solving problems in isolation. At least frameworks introduce some structure - like it or loathe it.


true - at least if I get asked to help with a horrible legacy system based around spring-boot, I’ll know roughly what fits where, or I’ll be able to google it


one of the things I like about microservices, is that you can still make a sprawling mass of chaos using them, in fact it’ll probably be an even worse sprawling mass, as you’ll have strange timing problems and probably terrible error handling. But at least there will be some sort of modularity, and a clear-ish separation between components, and seams where you can turf parts of the system that are unfixable and replace them bit by bit.


I really dislike the way the annotations plug make stuff appear in the application


I much prefer having a file that explicitly includes / mounts my routes


app.use(”/path”, resourceClass) vs app.use(resourceClass);& @Path(”/path”)ResourceClass

Rachel Westmacott10:11:07

I’m personally very happy with my position on the anti-Spring bandwagon. And it is exactly the magic that I detest. Sure, I didn’t have to deal with what came before Spring, but that doesn’t make Spring okay. Developer communication and discipline was never enough to stop Spring being a PITA. It’s one thing to have a third party library let you down, it’s quite another to find that the stack traces and the debugging tools have all been broken because someone thought that AOP (glorified COME FROM statements a la INTERCAL) were a sensible solution. Meanwhile the pythonistas were meditating on “Explicit is better than Implicit”… To be clear, I’m not saying I could have made a better Java framework, but for as long as I’ve known Spring I would never choose to use it.

Rachel Westmacott10:11:22

(I promise not to talk about Spring again.)


Hi, thought I would say hello. It feels like I'm barging into someones conversation!! Currently I'm experimenting with clojure in docker on aws.


Hi @petem - just a lot of old farts ranting about Spring 🙂 I definitely have grown to prefer explicit to implicit - any time you add magic like annotations, you are shoving complexity under the carpet, rather than making it actually go away - and as a result, testing it properly is going to be harder


One of the things I’ve loved about clojure and FP in general is that instead of where the thing might hold all sorts of complexity, you use (foo thing …) and the complexity is more explicit.


cough controlled effects cough


controlled effects can still be opaque


hi @petem, why not aws lambdas written in clj(s) then?


I am definitely an old fart!! Sometimes I think that open source projects don't know when to stop. Spring has a commercial concern behind it so I suppose that the team cant really afford to just halt development. It started life as a lightweight IOC framework (like pico) but just kept growing. Its one of the factors that ruined java development for me. Dont get me started about Spring stack traces.....


Hi @benedek I'm learning about docker and docker swarms at the moment. There is a mountain of technology that passed me by while I was busy writing java!! I just looked up AWS lambdas, they look interesting but I must not get sidetracked.


I learned to code on a HP-41C calculator my dad brought home from work… First real coding was on my Sister’s uni account - BASIC on a DEC-20 First own computer was a ZX-80 ...


Ditto on point 3. I learned to code in Basic on a PDP-8 using a teleprinter and an acoustic coupler although I did help my dad feed punchcards into a reader at his work one Sat morning when I was about 10.


I think we might have had this battle before, and you might have won 🙂 both of us old enough for early-onset dementia?


I’m also winning the “oldest first-time dad” competition at NCT classes and pretty well anything else parenting related 🙂 One of the guys in our NCT class pointed out that his own dad is only 2 years older than me.


The father of the Head of Development at my current client is same age as me! Feeling my age when 80% of the developers weren't born when I started programming as a profession and all but about 2 weren't born when I started programming.


Is now a good time to mention my microtan-65? 🙂


6502 - my first ASM :)


haha mine was x86


Z-80! I had lots of fun poking assembler into my ZX-81’s memory.


186 was my second, got paid for that too


z-80 then 6502 then 68000


another panel q for u @agile_geek - is clojure an old fart's lang?


it's an interesting question and the age profile of early adopting Clojurists was quite high


@kevin42 thanks for the link.


My opinion? Most old farts in IT are either locked in to technology that they were experts on 10-15 years ago, and dragged along by the trailing edge of the adoption curve; or are early adopters who jump on new ideas because they’ve had to embrace new ideas for their whole career. There’s also a bias towards good old ideas (like lisp) being revived in a new way!


hopefully i fall into your second camp @korny


All clojure users are :-)

Rachel Westmacott13:11:43

I learnt on a calculator. I wish it had had lisp.

Rachel Westmacott14:11:15

I think the strangest BASIC I tried was YaBasic on PS2. It was dog-slow and if you tried to factor out subroutines it got w…a….y slower, but the gradient-shaded polygons were blazingly fast.


well... I got a reply back from my MP... and as a proper politician he managed not to say a lot.


(defn brexit [] brexit)




i would rather go for (defn brexit [] ::brexit) or (defn brexit [wtf] wtf)


but brexit means brexit