Fork me on GitHub

I had a funny conversation today on taking out to an interface things like the ApacheHttp client for Java. We have customPostRequest method that instantiates the client and calls post. We are in a side effectful method that "fires and forgets" - there is nothing to test really - I would say my protocol would not wrap the http client but the customPostRequest. I have been called out today because a person insisted to have both interfaces for "good design". I might be rusty in Java, but in Clojure we usually don't put protocols "just because" and I started questioning what is the cost of surrounding "everything" with interfaces. I could not really argue that indeed there is a cost to program to the interface "at all costs"...but it did not come out well and I don't think I had valid concrete arguments


The mocking out everything argument - adorned with the "we have dependency injection anyways" seemed to be winning - I really dislike that of Java devs sometimes - /rant off


Still in need to find a good way to quantify the cost of developing to the interface - good practice yes but where to stop 😉


The funny part was that one of the push back was "it is the same of what you are doing with immutability in Clojure" meaning that he wanted interfaces everywhere and he justified that as good practice like having immutable value objects - at the point I was kind of at a loss for words 😁


He might definitely be right 😱


Sounds like a case for the ultimate interface


Fortunately at my java shop we are not that keen on interfaces, unfortunately the reason is that the developer that is here from the start favors abstract classes and inheritance and oh boy, it makes a lot of stuff really hard.


That said, I dont think (and the few studies I have seen seemed to have the same result) it just doesnt matter if you use a static or dynamically language and all the language wars are fun for sure and also a good learning experience. But your team mattters much more as well as your environment (CI / tests / system tests / non stressfull environment / ...). I also think thats why most business people just dont care about programming languages and tools, because the difference between them is negligible.


It just doesnt matter for the outcome of the task.

Lennart Buit06:06:59

Different problems call for different solutions. Theres a place in this world for strongly typed languages as well as dynamic languages. ML style syntax has its benefits, and so do Lisp style syntaxes as well as C style syntax. For me, that means having open eyes for new technology and realising the potential problems it could solve.

Lennart Buit06:06:19

(I sometimes say at work that all choices are wrong, but some are bigger foot guns than others)


I’m really interested in this as well. But... sometimes I think that if there was a statistical difference I’d have been shown by now. So, maybe individual differences between people/teams/orgs overshadow whatever difference (OO vs FP) or (dynamic vs static) etc make.


Of course thats true on the very small scale. But lets say you have a team of experienced java engineers and need some rest backend for adding / retrieving data on a existing database, a task to be done maybe in two to three months. I personally would prefer to use clojure (as I like it really much), but it would be nonsense to teach 5 people clojure just for the sake of its advantage instead of getting the job done and earning money.

Alex Miller (Clojure team)11:06:13

Unless you’re planning on doing more work after. Taking the investment to build a high-leverage team can totally be worth it. Depends a lot on the org details


That would assume management and shareholders are concerned about the long term value of something, which is unheard of /s


I found the last sentence to be very true in the Enterprise world


@mattias504 Thats exactly my point.


Do a few million line projects in C or assembler and I'm pretty sure you'd see a statistical difference 🙂