> There are of course many other factors that go into it. One that may very well work in your favor is saving while living in a big city, then moving some place small later on.
That's how I've been doing the math (over, and over, and over) ever since I found this article last night - calculate savings based on my tech job in sf, and then calculate expected expenses based on what it'll be like to live basically anywhere else and maintain the same cost of living (sf is 72% more expensive than portland[0] and a whole lot more expensive than living comfortably off of $10k a year in thailand).
Christ, many of us on this site could likely get away with retiring now & moving to Thailand, if you really can assume 5-7% long(long!)-term returns on the stock market.
Clojure's a great lisp. I recommend it highly. I haven't spent much time with Scheme, but I can definitely say that I greatly prefer Clojure to Common Lisp.
That's odd, that seems a little inaccurate to me. Clojure's agents are useful for encapsulating I/O-related resources, and are integrated with the STM system. Per http://clojure.org/agents -
Agents are integrated with the STM - any dispatches made in a transaction
are held until it commits, and are discarded if it is retried or aborted.
Refs and atoms shouldn't have side effects, but agents are great for performing side effects. From page 214 of Clojure Programming:
Unlike refs and atoms, it is perfectly safe to use agents to coordinate
I/O and perform other blocking operations. This makes them a vital
piece of any complete application that use refs and Clojure’s STM
to maintain program state over time. Further, thanks to their semantics,
agents are often an ideal construct for simplifying asynchronous
processing involving I/O even if refs are not involved at all.
Further:
Agents are integrated into Clojure’s STM implementation such that
actions dispatched using send and send-off from within the scope
of a transaction will be held in reserve until that transaction
is successfully committed. This means that, even if a transaction
retries 100 times, a sent action is only dispatched once, and that
all of the actions sent during the course of a transaction’s
runtime will be queued at once after the transaction commits.
I started learning Clojure because it seemed to be the logical next step for me. In the few years that I've been programming full-time, I've noticed some patterns: in general, imperative code with lots of side effects in it is difficult to reason about and hard to test, and pure functions are easy to reason about and trivial to test. The same rule seems to hold for code that uses mutability vs code that deals only with immutable things.
Over the past couple of years, I've learned Common Lisp by working through Conrad Barski's Land of Lisp[0] and dabbled in Haskell via Learn You A Haskell[1]. I had a great time learning both, but I found that Common Lisp had a decent number of warts (e.g. four different kinds of equality) that seemed to be primarily due to backwards-compatability concerns, and I had a really hard time getting up and running when trying to write a simple webapp in Haskell. In addition, I've gotten spoiled by how batteries-included Python (which I use at my day job) is; the library scene for both of those languages seemed lacking in comparison.
What I like about Clojure is that it gives me fast immutable data structures, has a really strong emphasis on functional programming, and has access to a really huge amount of useful libraries.
So - I've mainly been learning Clojure as a nice treat for myself; the amount of jobs that exist that employ programmers to code specifically in Clojure didn't even really occur to me as something worth thinking about. It's just really a lot of fun to program in. Also, with any luck, I'll be able to transfer any lessons I learn from Clojure to my daily work in Python.
(Haskell still has a very special place in my heart [I do frequently find myself wishing I had types], I'm not trying to dis Common Lisp nor Haskell, I'm just trying to honestly answer the question of why I thought it was worth learning Clojure).
I realize this is quite off the main topic, but I thought it was interesting and worth passing on.
If you really think that "four different kinds of equality" in Common Lisp is a wart, then I recommend that you read "The Best of Intentions" (http://www.nhplace.com/kent/PS/EQUAL.html) by Kent Pitman. The article explains why that situation is quite intentional, and why it is very rational, and why it is in fact ill-advised to expect a single meaning for "equal" ... or, in fact, other "obvious" concepts like "copy" ... to be sufficient.
That article was one of the many over the years that helped me refine the way I think about programming and programming languages.
What do your superiors think about implementing new, small projects in Clojure?
When you say "has a huge amount of useful libraries" but then say that Python is "batteries included", which libraries in Clojure are particularly useful? Which ones did you wish it had?
2) I used those two phrases interchangeably - I consider both Clojure and Python as "batteries-included" languages. Case in point - before I was aware that Clojure Toolbox existed, I was able to google "clojure http request" and find several libraries that let me perform HTTP requests programmatically that I could include in my project.clj and start using right away. My memory's a little fuzzy, so apologies if this is completely wrong, but I don't recall having as easy a time doing that in e.g. Common Lisp or Haskell.
As far as which libraries in Clojure are particularly useful - Ring and Compojure are fantastic, and core.logic[0] is extremely interesting; I'll write a blog post showcasing core.logic (and using it for my first time ever) at some point. Midje is great for writing unit tests. I've only been using Clojure for a few months, so I can't point to too many others that have really been extremely useful for me, but I definitely recommend checking out the Clojure Toolbox[1] for a more thorough list of the main contenders.
To me, this is the smartest part of using Clojure in your projects. If you're a company with an enormous Java stack, it's trivial to add things like Clojure or Scala and use them as scripting languages. Or break out a library and rewrite it using one of the two, if that problem would be better solved more functionally.
Basically it makes it easy to convert projects without tearing down your infrastructure, ie, easy to convince your boss.
Fair point, mea culpa :) I'll carve out some time this weekend, figure out how to make this advice generic across platforms, and figure out how to contribute it to dev.clojure.org.
I am a mediocre-at-best Java developer, but somewhat better at writing. I'd like to learn Clojure and contribute to the community while doing so. Is the Clojure Doc project the best opportunity for someone like me?
I really suggest biting the bullet on "are we there yet" - it changed the way I think about state and identity (in that it got me to start thinking about them at all). I haven't found anything by him in written form aside from interviews, though, but I'm still really new here.
That talk's definitely a good one. I particularly like how he frames it as a discussion about the difference between value-oriented programming (good) and place-oriented programming (what you're used to, bad). Giving the two paradigms those names really helps clarify how you think about the distinctions between the two.
That's how I've been doing the math (over, and over, and over) ever since I found this article last night - calculate savings based on my tech job in sf, and then calculate expected expenses based on what it'll be like to live basically anywhere else and maintain the same cost of living (sf is 72% more expensive than portland[0] and a whole lot more expensive than living comfortably off of $10k a year in thailand).
[0] http://www.bestplaces.net/col/?salary=30000&city1=541590...