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...
HN user
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...
"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.
I'll take a look. Thanks!
I'm really bewildered by all the options for emacs-git integration. Which one is your method of choice?
For those who enjoyed Wing Commander Privateer, there's WCP Gemini Gold, a remake using the open source Vega Strike engine:
http://privateer.sourceforge.net/
I've emailed the author to see if he'd like to add it to the list.
Saw your performance on the show tonight as well. Great stuff, easily best of the night. Can't wait to see what you have in store for the next round!
Fly-by-wire avionics go beyond "just" self-landing and auto-pilot (and these are no small accomplishments!). In fly-by-wire aircraft, when the flight controls are moved, it's the software that calculates how to move the control surfaces to achieve the desired result. Also, modern fighters are often designed to be inherently unstable, to achieve greater maneuverability. So even in level flight, the software must calculate and order constant tiny movements to maintain stability. These movements happen dozens to hundreds of times a second, and must take into account factors such as current speed, attitude, air flow across the aircraft, etc.
> The guy he cites who declared macros evil is obviously not a part of 'mainstream' Clojure culture
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.To add to this, Clojure also has "trampoline" for TCO in mutually recursive functions.
Kawa Scheme is another JVM language that works well on the Android.
3-part tutorial on how to write Android apps in Kawa: http://androidscheme.blogspot.com/2010/10/introduction-to-an...
That's one of the goals of the Clojure team. While the main 'branch' targets the JVM, there is also a branch targeting .NET. And there is an initiative, Clojure-in-Clojure, to de-couple the main branch from the JVM as much as possible, to facilitate re-targeting.