https://www.peginc.com/store/rifts-the-tomorrow-legion-playe...
935 karma · joined May 14, 2010
https://www.peginc.com/store/rifts-the-tomorrow-legion-playe...
Came here to say exactly this. At my current workplace, one of the very first steps in any project that involves both FE and BE work is for FE and BE engineers to get together and design the API. Once that's done, work can proceed on both sides in a largely asynchronous and independent manner. And one of the first things to be implemented on the BE is API endpoints with multiple mocks that can be requested by the FE, so the FE can start integrating with the endpoints as early as possible.
At its core, Clojure is basically just data and functions. Once the switch flipped in my mind, I found that to be simpler and more straight forward than any of the languages I worked with before.
When the majority of your code is side-effect-free, pure functions (and Clojure makes it very easy to structure your code this way), it becomes very easy to reason about. And very easy to test, with minimal ceremony!
P.S. When I was learning Clojure, I kinda devoured all the resources I could find. A couple interesting looks at the language from the perspective of Rubyists:
http://briancarper.net/blog/536/clojure-from-a-ruby-perspect...
http://confreaks.tv/videos/rubyconf2009-clojure-for-ruby-pro...
1. Clojure's tools for making abstractions are orders of magnitude better than Java's, so our codebase is significantly smaller and simpler than what it'd look like in Java.
2. Clojure lends itself very well to a REPL-oriented kind of iterative development that speeds up writing and testing code tremendously, compared to the typical Java workflow.
(->World [:foo])
(->World {:tiles [:foo]})
More details here:http://dev.clojure.org/display/design/defrecord+improvements
length
vector-length
string-length
hash-count
set-count
...
Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.", which is one of the many reasons why I enjoy the language so much.
http://news.ycombinator.com/item?id=3051142
Perhaps it would be interesting to see how it was done in Twisted: http://http://twistedmatrix.com/documents/current/api/twiste...
We'd like to think that the C# guys were looking our way when they came up with async/await, but there's no proof. :3
(Part 1): http://blip.tv/clojure/clojure-for-java-programmers-1-of-2-9...
(Part 2): http://blip.tv/clojure/clojure-for-java-programmers-2-of-2-9...
http://privateer.sourceforge.net/
I've emailed the author to see if he'd like to add it to the list.
I think Yegge was referring to Christophe Grand's talk on DSL's and macros. Grand has written several notable Clojure libraries, so I do consider him part of 'mainstream' Clojure culture. But he didn't say "macros are dangerous and you should never use them". Quoting Phil Hagelberg's response in the linked discussion:
The talk I saw was about how functions are generally more
composable than macros, so they should be the first tool
you reach for. I think it was more directed at folks who
come to lisp and are drunk with the power of macros.
(Assuming it was this talk: http://clojure.blip.tv/file/4522250/)
Towards the end of the talk, Grand discusses how macros can be useful for optimizing or adding syntactic sugar to DSL's.3-part tutorial on how to write Android apps in Kawa: http://androidscheme.blogspot.com/2010/10/introduction-to-an...