Hacker Newsnew | past | comments | ask | show | jobs | submit | bitsai's commentslogin

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.


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.


Have you ever used anything like rails? I come from that background and clojure doesn't seem as straight forward; for better or worse. But I like the beauty of the language.


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


Is it better than plain Java? I mean, if you have the entire Java ecosystem, is it worth it to go upstream just to work in a Lisp-like language?


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.


Writing Java with Clojure is actually kinda fun, and macros let you abstract it away when the ceremony gets thick.


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.


Definitely not a trivial task--though it may be a worthy task. Incanter has moved from PColt to JBlas, and is moving toward core.matrix which will abstract the linear algebra stuff. If anything, I'd guess that Racket might be an easier ask than Clojure due to the JVM weirdness around boxing / unboxing of numbers passed to and from the underlying jblas (it's entirely possible I don't understand what I'm talking about re boxing / unboxing, though I've heard tell that the JVM makes some aspects of numerical work very challenging).


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


Oh cool, I didn't know that. I kind of blocked 1.3 out of my memory after the "let's remove clojure.contrib and break everyone's shit" mess.

It's good to know that progress toward patching all the places Java tends to leak through into Clojure is happening.

I can't say I'm a fan of the punctuation-laden syntax, but I'll pick my battles and not complain about it.

I'll switch over to this new form tonight and mention it in one of the later posts. Thanks!


This, and before 1.3 you were supposed to define a constructor function yourself. I'm pretty sure that was somewhere in the documentation. Or in the clojure.org/datatypes. Or in some mailing list post that I red. The Clojure documentation is a mess.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: