Things Java Programmers can learn from Clojure
lispcast.com
Things Java Programmers can learn from Clojure
1–10 of 58 posts
Re: Things Java Programmers can learn from Clojure
#2If Java programmers would only apply the concept of immutability the world be such a better place... Every time I log from within a setter to see who's calling this and when, a little fairy falls from the sky.
Re: Things Java Programmers can learn from Clojure
#3If Java programmers would only apply the concept of immutability the world be such a better place... Every time I log from within a setter to see who's calling this and when, a little fairy falls from the sky.
I have hacked Haskell just to be able to see what goes on inside a particular method chain.
Re: Things Java Programmers can learn from Clojure
#4If Java programmers would only apply the concept of immutability the world be such a better place... Every time I log from within a setter to see who's calling this and when, a little fairy falls from the sky.
I have hacked Haskell just to be able to see what goes on inside a particular method chain.
We call this trading one hell (direct mutability) for another worse hell (Indirect mutability).
Re: Things Java Programmers can learn from Clojure
#5I would add "Create custom annotations sparingly". It makes Java interop and debugging harder. But, that is just a personal pet peeve.
Re: Things Java Programmers can learn from Clojure
#6Nice article. It does, however, trigger a thought:
> By making values mutable, this magical-changing-at-a-distance is always a possibility.
I agree, very much so. However, I could also simply promise that none of my code, nowhere, will modify that DateTime. On top of that, I'll ask all my colleagues to not mistreat it either.
Now, that's what many of us are doing now, and the entire point if the OP's first section is that that's just asking for trouble. But how is that fundamentally different from promising to never call toRubles() on a DateTime object? That's what you do with dynamic typing. Yo, here's an object. Please only call methods that it has, and I won't tell you which those are so you'll have to guess the types it may have and then browse to the API docs first (unless it has a method_missing, which you'll have too look at the API docs for as well - but what if it's duck typing and only one of the ducks quacks method_missing?)
Sure, I'm exaggerating. I like dynamic typing. I just have the idea that immutability is for nouns what static typing is for verbs. Just like Java has it half-assed, I feel a bit that Clojure has it half-assed the other way around.
In terms of Steve Yegge's conservative vs liberal discussion[0], it feels like Clojure went all liberal on one end, just to get super-conservative on the other.
[0] https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
Re: Things Java Programmers can learn from Clojure
#7Nice article. It does, however, trigger a thought: > By making values mutable, this magical-changing-at-a-distance is always a possibility. I agree, very much so. However, I could also simply promise that none of my code, nowhere, will modify that DateTime. On top of that, I'll ask all my colleagues to not mistreat it either. Now, that's what many of us are doing now, and the entire point if the OP's first section is…
Yeah, replying to myself. I'm not sure if that's considered weird but ok.
According to this logic, most mainstream languages don't make sense. Notably, Java, C#, C, C++, Clojure are all screwed up. Not sure about other lisps. Ruby, PHP, JavaScript, Python, F#, Scala and Haskell have it right though.
(yeah sure, you can do mutability in Scala and immutability in Java, but the languages and their community lean toward the other, which is what matters here, I suppose)
Given that I've been much of a C# fanboy recently, my nose bleeds.
Re: Things Java Programmers can learn from Clojure
#8I thought that classes+methods were meant to transform an object from one consistent state to another consistent state. So why is immutability suddenly a big deal? (I.e., if it's a big deal, may it be because encapsulation is lacking? IOW, is immutability a rediscovered "private" keyword, just much more cumbersome to use?)
Re: Things Java Programmers can learn from Clojure
#9Why these things in stay in books and blogs and never make their way into Java web apps:
1. Use immutable values:
Models used in client server communication need to follow Java Bean spec which is like the exact antagonistic concept to immutability. Service methods that implement business logic are stateless. As objects are not shared across threads, nobody feels the need for immutability. The most popular frameworks Spring and Hibernate dictate this architecture.
2. Do no work in the constructor
Are constructors still used? All services are wired using dependency injection. Models are either DTOs or Hibernate POJOs - both dumb and anyways don't do any work.
3. Program to small interfaces:
Interfaces are dictated by functionality they provide and not size. They can have hundreds of methods. This is how it looks: DocumentService - put every document related method in here, FinancialInstrumentService - put every instrument related method in here
4. Represent computation, not the world
Almost everybody begins OOP with this misconception - objects in real world directly map to OOP objects. Its maybe a good place to start but how many grow up from the initial simplistic rule - map nouns in requirements to classes. So, you end up with objects that don't really mean anything and don't do much. Naive use of UML diagrams also leads to this. Discovering abstractions is tricky. One needs to really live with requirements inside out before they present themselves. Who has so much time? Believe me in a quarterly release- developers get around only 3 weeks – rest is divided into BA, QA, UAT, freeze, deployment time.
PS: Please don’t get me wrong OP makes good points. It's sweet but the reality is different. May be Google does this (and they do in Guava which is just an example one after another of good stuff in Effective Java). But there's a big corporate java world out there that does things differently. They have well defined easy run of the mill patterns where these things don't fit (yet). This was just a peek into it.
Re: Things Java Programmers can learn from Clojure
#10Nice article. It does, however, trigger a thought: > By making values mutable, this magical-changing-at-a-distance is always a possibility. I agree, very much so. However, I could also simply promise that none of my code, nowhere, will modify that DateTime. On top of that, I'll ask all my colleagues to not mistreat it either. Now, that's what many of us are doing now, and the entire point if the OP's first section is…
Yeah, replying to myself. I'm not sure if that's considered weird but ok. According to this logic, most mainstream languages don't make sense. Notably, Java, C#, C, C++, Clojure are all screwed up. Not sure about other lisps. Ruby, PHP, JavaScript, Python, F#, Scala and Haskell have it right though. (yeah sure, you can do mutability in Scala and immutability in Java, but the languages and their community lean toward…
I think of it as each language making functionality trade-offs, in their design, for specific goals. Each language tweaking the recipe to make a language that best fits the programming model they advocate.