bitsai

There's a whole raft of "Rifts for Savage Worlds" products now (https://www.peginc.com/product-category/rifts/), but really I think you need only the following two to get going:

https://www.peginc.com/store/rifts-the-tomorrow-legion-playe...

https://www.peginc.com/store/rifts-game-masters-handbook/

"That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available."

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.

Mmm, I've never used Ruby or Rails professionally, so I can't really speak to that. Prior to Clojure, I mostly worked with C++, Java, C#, and Python.

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...

IMHO, absolutely. There are many wins, but the 2 biggest for us have been:

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.

I vote that it's worthwhile as well. We've been using Clojure full-time at ReadyForZero for over 3 years now (for web-dev as well as other tasks), and are very happy with our choice.

Fascinating! We use Clojure heavily, but the JVM is sometimes a bit of a headache-inducer in our environment (especially w.r.t. its eager gobbling of memory), so I'm always excited to see new potential runtimes/backends for Clojure.

If Clojure is acceptable, there is Incanter (http://incanter.org/).

Not exactly a trivial task... Incanter uses several sizable Java libraries (such as Parallel Colt) under the hood, so a port would first need to either finding suitable replacements or re-writing that code as well.

After using jaycfields' "expectations" Clojure testing library, I've become very very appreciative of libraries that expose an easy way to freeze time, for exactly the issues you described.

The article does provide some details about how the breach happened.

"Rainbows End" was indeed wonderful. Another great exploration of AR in speculative fiction (and my personal favorite) is Charles Stross' "Halting State".

As of Clojure 1.3, defrecord (and deftype) automatically define factory functions in the same namespace as the record itself. defrecord generates 2 such functions, one that takes positional arguments and one that takes a map. So once you have :use'd or :require'd the namespace, you can do stuff like the following without having to import anymore:

    (->World [:foo])
    (->World {:tiles [:foo]})

More details here:

http://dev.clojure.org/display/design/defrecord+improvements

Yes, that is a better way of making the point. Thank you.

Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like:

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.

See this comment from MostAwesomeDude in a different thread:

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

I believe jashkenas' example defines both a pre-condition and a post-condition, specifying that f accepts only odd numbers and returns only even numbers ('!' here is the operator for new contract, rather than logical negation). If f is called with anything other than an odd number, an error will be thrown right away, before the body of the function is run.

It's a bit of a mystery what Rich will be talking about tonight. The only word from him is that "I'll be talking about something new!" Not much to go on, but thought I'd share the live stream link for interested parties anyway.

I recommend Rich Hickey's presentations on Clojure:

(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...

This has also been the #1 show-stopping concern when I tried to introduce Clojure at my workplace, a small financial services company aspiring to be "enterprise"-y.

I had the pleasure of reading this paper during a computer security course. To complement the paper, the prof gave us the task of writing a 2-level polyglot quine (a program in language X that outputs a program in language Y, which outputs the original program). It was my first exposure to quines, let alone polyglot quines, so you can imagine how much I struggled. This paper will always remind me of the frustrations I experienced, and the brilliance of the moment when the "trick" finally clicked for me.