Snowden has an agenda.
It's worse than that - I hear he has a quorum and takes minutes, too.
Why do people of a certain political stripe use that word as if it's an insult? Is Roberts Rules of Order the new Protocols of Zion, or something?
Ah, so we are ok with Karl Rove outing of Valerie Plame now?
Yeah, pretty much. At the time her CIA identity was "revealed", didn't she drive every day to the CIA Langley headquarters to work and park in a CIA parking place? And had been doing so since 1997? I'm not entirely sure, but if I were a foreign intelligence agency, that little slip might just have tipped me off that she might have been a CIA officer even before Rove announced it.
I was raising my eyebrows at the time and thought "this seems like an incredibly tiny thing to be all more-patriotic-than-thou about and will rebound badly on the Democrats when the next military-industrial complex whistleblower comes along".
And here we are.
law-abiding gun owners who never hurt anyone
Correction: You haven't hurt anyone yet. But you definitely have and want the ability to hurt someone. Having that ability is obviously really important to you. Otherwise why do you need a functioning firearm at all, and not just a plastic replica?
I am talking about normal people walking around with their tools, using them correctly, and safely. What's so wrong with that?
Because in the best case, using these "tools" in an urban environment correctly and safely for their designed and intended purpose, at least one person will die. Hammers or circular saws only tend to kill people when they're misused.
I don't mind if people in the country want to walk around with rifles in case they're, um, swarmed by rabbits or something. But in a city? There aren't many bears or injured horses here.
Sorry if this seems fussy. I keep feeling that I need to suspend my disbelief each time
I see obviously bad grammar in posts.
Hey lighten up, it's not like programming is a field where you need to be able to understand syntax and type keywords exactly, right?
Read some Kurt Gödel, Thomas S. Kuhn, and Karl Popper, please.
I started to, but when I got to the part where it tried to falsify itself, I decided to switch paradigms.
a 2-3 moratorium on chemical manufacture would devastate the industry manufacturing that chemical
(eyebrow raise) The entire agricultural pesticides industry would be devastated by a single one of their products being temporarily banned?
That's one heck of a fragile industry you've got there.
WWII was the biggest impetus for technology in the 20th century, THEN we went into space./quote>
And most of "space" was ICBMs: the launch vehicles people don't talk about in case they wake up. But Atlas launched Mercury, and the Minuteman guidance computer predated the Apollo computer. It was a happy accident that hardware not designed to kill millions could also be put on top of the same rockets, but everything after 'destroy Moscow' - including TV and weather satellites - was a spinoff.
Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).
Right. So, a back-of-the-envelope sketch on how you might do this in RP:
* Don't try to have each mob directly checking every other mob's position all the time, since that requires geometric time
* Instead create 'attack' objects which represent attacks in progress. They're only created when an actor pushes the 'attack' button. You probably already need this, since attacks probably have stats linked to them: animation cycles, cooldowns, maybe coordinates of their own if they're projectiles
* Have a container of such pending attacks
* A mob connects to the container and watches for nearby attacks, and only when it discovers that it has a connected attack does it do the damage calculations for that attack
* If the gamespace gets too big, divide it into sectors and attach the mobs and the attacks to sectors, so each mob only has a very short list of pending attacks to scan, and you could parallelise the gamespace easily
Granted there's probably lots of thorny issues here, especially to do with how lightweight all the objects need to be, but the point is that you could use the typical OO-style division of concerns in an RP framework to make it so that everything isn't watching everything else all the time; each object only connects to the event streams that interest it, and there could be a whole network of observers and re-re-republishers that minimise the notification traffic. Much like how we do it on the Internet, where packets get sent to a local switch, but only forwarded on if they're of interest elsewhere. And once you've got that, you could probably scale it right out to the MMO level much easier than imperative OO programming.
The trick is that we need good formal semantics for how all this works. It's nice that we're getting reactive libraries, but I think we need more work at the underlying mathematical layer to make sure that what we're implementing is correct. Something like Kahn process networks is probably the best approximation at this point; what we really want to get away from is the horrible mess that is imperative objects and threads.
Except that then you remove the basic principle of RP: that updates are done live. Freeze things like that and you've reduced it to the current model where you just dump values into variables and then run calculations on them to set the values of other variables which then don't change until you go and recalculate them yourself.
Not quite. As I understand it, the big idea of RP is not that everything has to be live, but that everything is capable of being live. If you have pervasive liveness given to you by an underlying framework in a safe and cheap manner, it becomes a lot simpler for the programmer to turn it off in the cases where you want to freeze a value, than to manufacture it out of nowhere in the places where you finally realise you need constant event-driven updates.
The former could take just one keyword in a reactive-declarative language; the latter (in current imperative languages) takes a whole lot of complicated, unsafe, gymnastics like spawning a new process/thread, passing a callback (which might involve security vulnerabilities since you're exposing a raw memory address), arranging your own concurrent synchronisation primitives, and so on. It's a world of pain and it really shouldn't be up to the programmer to solve this thorny problem, since they'll inevitably get it wrong, and in very nasty ways.
In the Internet age, it becomes a whole lot easier to see the entire Net - and in fact your own server/desktop - as looking less like a von Neumann computer with one 'processor' doing one thing at a time, than a network of components operating on streams of messages. So the theory is, if you had a programming language which looked more like operations on event streams, you'd have something that could work nicely with a single paradigm at all three levels: at the CPU level, it could let compilers scale your code out nicely across arbitrary numbers of cores; at the desktop level, it could provide really simple, clean descriptions of windows and UIs as time-varying functions over the state of other windows/datasources, making it a lot faster and safer to write and change UIs; and at the Internet level, where the world really does look very much non-von, it could do the same thing for entire networks of processes running on servers. Heck, maybe we could even describe our hardware network toplogies as programs? Wouldn't that be something? Especially if more and more our 'networks' aren't physical patch plugs in ports, but virtual topologies running on VM environments?
actual cascading data modification based on reverse trigger like syntax would seem to have the level of intelligent design choice on par with Intercal's comefrom statement.
Right, I don't think current DB technology, based as it is on 1970s timesharing mainframes, is up to the task. I suspect to make RP work nicely with distributed updates you would need to abstract out the idea of 'database' a bit; make it more like the Git/Mercurial model, where there's a big tree of data that anyone can hook into and receive updates, but can't affect anyone else directly.
This is the direction I think the Net will eventually have to evolve; things like Content Centric Networking are a step in this direction, if we added computation on top of that, we'd be getting very close to something much like the original 1970s 'hypertext' concept. Ted Nelson's Xanadu -- confusing, patent-ridden and badly-specified as it was -- I think had a concept of 'applitudes', applications as spreadsheet-like cells that can import data from anywhere and use it to update themselves. Imagine what you could do with a Web of live data like that.
Event-driven programming is HELL
Isn't that right there a good reason for it being implemented once, correctly, as a core OS/language feature so that the programmer doesn't have to micromanage all the interactions, and instead just say 'this is a dependency on that; event engine, you sort it out'?
For better or worse, ever since the mouse we've lived in an event-driven world. From what I can see, it's mostly worse, because our software tools haven't adapted to minimise the complexity, so we have the monstrous Byzantine complexity of signals, slots, callbacks, etc. RP - if it were done properly - seems like a good way of encapsulating a lot of this back into the system levels where it belongs.
I agree that RP has to have rock-solid formal semantics for it to be dependable; that's a job for computer scientists rather than library programmers, so I hope somone in PhD land is looking seriously at this.
Exactly. So far RP in the article sounds a lot like data-flow engines (spreadsheets, various visualization tools, DB triggers, even make builds). It has spanned decades and fields, too.
Yes. But it's been reinvented differently on an ad-hoc basis with different semantics each time. And each implementation does a slightly different subset of the same idea, and can't communicate natively with the others. Imagine if, say, there were no lambda calculus and everyone writing a programming language had to take a stab at rebuilding from scratch all the underlying mathematical axioms of computation. (Or - to put it in more modern terms - imagine if everyone were using object oriented programming, and there were no... well, there actually aren't any core axioms of OOP that current languages all agree on, and as a result we're in pretty much the same situation - try to get C++, JavaScript and
What would be really nice would be if reactive/dataflow/spreadsheet programming could be recognised for the fundamental paradigm it is, and coded as a basic language feature, so we could get on with using it rather than saying 'oh, that was invented 50 years ago so it's old hat now'. Yes, it was invented a long time ago; so was Lisp. And we're not yet using either.
What happens in this system when the price for an item changes at the same time the customer's changing the number of that item they want to order, the customer's credit limit is being updated and payments are being applied to his 26 orders each of which causes an update to his balance due?
At a first glance, I would imagine a real-world RP transaction processing system would handle that problem much the same way real-world paper based transaction processing systems have handled it for hundreds of years: by grouping field updates into documents, and then talking about updates to and within documents. For example, at the time the customer creates a 'new order' form they would get a frozen local value of the current price for the widget at the time they placed the order and further updates wouldn't propagate until they sent the order. When they pressed 'ok', the fact of a new order would be created; another system would deal with receiving and processing the order, and at that time the quoted price on the order would have to be reconciled with the current price at the time it was received. And so on.
After all, this is how we currently do things - we have things like 'quotes', 'orders', 'invoices', which are all different documents, exactly because the world is constantly in flux and we have to deal with it; why would using a new programming paradigm change any of the organisational checks and balances we already have?
but since they are running as a tor hidden service and such a tumbler is pretty easy to code/deploy (meaning any such service taken down would be pretty assuredly replaced by 10 others the next day), it is highly likely LE is actually running several of them.
Well, at least it's what I would do if I were in law enforcement. All criminals, come to free-bitcoin-money-laundering.nsa.interpol.eu. We're not coppers, honest!
E = MC ** 2 +- 3db
