614 karma · joined February 25, 2009
So in order of strictness: equivalent < equal < ideq
Also, swipe doesn't seem to work on Chromium 17/Fedora. Otherwise, great work!
Or you could delegate all this to the database, which already has its own transaction protocol.
Everything is a service, if you make it so. A component is a service, offering the functionality of its interface. The 'wc' tool is a service--its interface is its command-line switches. And you're right, when everything is a service, everything is easy (I'd say easier).
Moving "QUUX formatted records from BAZ mainframe to new Oracle Windows Java 7.0 Lightweight Enterprise Server" involves these things: a source, a sink and the pipe character. Your source and sink may necessarily be in Java--meh, whatever works. But now you have a decoupled framework for doing these kinds of jobs, and you haven't invested any more time or effort than you would have with your one-off, inflexible solution. And you can now stuff anything in that pipeline. And I regularly use racket for exactly this, using protocol buffers as the pipe character. It's not rocket science, it's the Unix Way. People, embrace it and free yourself from the monolithic millstone!
That said, a LLVM backend is overkill for this and I'm sure the simple interpreter Notch has rigged up will be just fine for its purpose.
the simple shift+add version is all totally serialized
and nothing can be done before the previous operation
ends: as a result the three adds and three shifts will
inevitably take 6 cycles (the original P4 had that
double-pumped ALU, but not for shifts). That's already
slower than almost any multiply.
Edit: oops, I forgot your '(without multiplication)' qualifier. Yes, your way is likely the quickest without multiplication.This small detail has caused much discussion ever since, a good example is here: http://jpgamboa.com/archives/1424
First I write some sample code in exactly the syntax I'd like to use, in an ideal way ignoring whether it's possible or not to produce. Then I create a macro to transform that syntax into code, iterating the sample code if I encounter barriers (usually unparseable syntax). It has really helped me (a poor to mediocre scheme programmer) create good macros very quickly, improving the expressive power of my code dramatically.
Bank robbers have a 'better experience' of a bank if they're not caught too.
See also the Digital Antiquarian's fascinating (and reasonably technical) blog on the origins of Infocom: http://www.filfre.net/tag/infocom/
Presuming that, for the most part, developers migrate from Java to a different JVM language, then inevitably these languages will fragment code written for the JVM, devaluing the very foundation used to hoist the languages into usefulness in the first place. The tower of Babel will rise higher with competing idiomatic implementations of various libraries. This is not a bad thing--rather it has to be this way because introducing new language features (such as STM in Clojure's case) demands it. We're living in a gold rush on Java to mine it for its libraries. After this will come a period of settlement as each JVM language builds its own community, with civic structures that perform the same duties, but look different, in every town square.
I think the point of the article was that the author never thought this, but presupposed the answer was always 'yes'. It wasn't until looking at alternative implementations that this question popped up.
I've done the same myself. I once implemented sortable live lists (lists that may be updated with added/removed items in the background, with only part of the list shown and the rest retrieved from the server). I wondered, 'how should this work?' and cast around for other examples. At first I used the (old) Google Reader model: two lists, one is 'All items', the other is 'New items'. But then I realised that, actually, sorting doesn't add anything, and indeed might confuse people who expect predictable order in their lists. Problem solved: don't allow sorting, instead provide a canonical order.
Quoting:
Speculation regarding other contributing factors includes:
The flight engineer's apparent hesitation to challenge Van Zanten
further, possibly because Captain Van Zanten was not only senior in rank,
but also one of the most able and experienced pilots working for the airline.
As a consequence of the accident, sweeping changes were made to
international airline regulations and to aircraft... Hierarchical
relations among crew members were played down. More emphasis was
placed on team decision-making by mutual agreement.The first simply means lots of lag navigating around pages with many elements, the second really pisses a lot of people off: http://code.google.com/p/android/issues/detail?id=2118
Make it easy on yourself.
In short, with this mechanism I can't trust that doing anything, be it clicking through to an article or flagging one, might negatively classify me. I can't be sure this site isn't trying to trap me somehow.
My advice is to let all of this hand-wringing about such nebulous issues as 'quality' go. It's a fairly decent community here and that's about as good as you could expect from the Internet at large. If you're really worried about what this site has become, simply conclude the 'Arc experiment' and shut it down.