There is one, it is called http or https. I agree that more direct interfaces would be nice, but there are currently methods of controlling and passing data to a PHP server from any language you can open a port in.
It takes a lot more that just http. I'd need to know the URL schema if you're restful, or the method names if you're SOAPy. Then there's the format of the data (SOAP, JSON, XML ..) and the expected data fields in the data sent and received, etc.
From the source, it looks like they're building abstracted PHP libraries, too. And it's an event/hook architecture, so you can pop this protocol out and put another one in, theoretically.
I don't know if this is a placeholder protocol while they build the software, or if this is what they plan on using and evolving.
All words are cool if you don't know what they mean. If the reader knows what it means but the writer doesn't, the effects are less predictable and desirable.
He mentioned in passing that writing a typical README requires just the right amount of planning upfront
"just the right amount of planning upfront" is exactly what Scrum should do. It's not full-circle at all, it's another approach to current good practices.
SCRUM ... all irrelevant unless the software we're building meets the needs of those that are using it.
That statement misses the entire point of Scrum. What are those short iterations for, if not to get feedback from those using the software? Why replan at the end of every sprint, if not to know how user needs have changed and been informed by the current software?
How is the readme so different from the sprint's user stories? Working from the desired end docs looks like another version of the currently fashionable "pull" methods. Not a bad one for a particular kind of project though.
You don't get more energy out than you put in, but if your goal is to make helium, that's hardly the point - just about every other industrial process also consumes energy.
but if it has some level of transaction log trail (however asynchronous)
"All transactions are settled between the card and reader alone. Readers transmit the transactions to the back office in batches but there is no need for this to be done in real time." - http://en.wikipedia.org/wiki/Oyster_card
People here are saying "I think/guess/assume that oyster cards work like... ". Without even checking with Wikipedia.
I'd like to hear about the Oyster card system's strengths and weaknesses from someone who really knows the system.
On Mon, Jul 19, 2010 at 4:34 PM, Jared <tri...@gmail.com> wrote:
> I am curious; for the people with Haskell experience why did you decide to use Clojure? I am asking this because Haskell and Clojure seem to solve similar types of problems. When would you want to use Haskell instead of Clojure and visa-versa?
[Mark Engelberg replies]
I think stateful things are too hard to do in Haskell, and they are an important part of most real-world programs. Clojure's blend of persistent data structures with a variety of reference-type objects that can contain them feels much more pragmatic to me. Also, I'm just
happier working in a dynamically-typed language.
As a side note, years ago, I wanted to write something in Haskell that worked like Clojure's memoize (which is implemented in a half-dozen or so lines of code in Clojure's core), and asked about it on the Haskell mailing list. I was pointed to a PhD dissertation on the topic of how to write memoize in Haskell. All I could think was,
"Do I really want to be using a language where memoize is a PhD-level topic?" "
