ViaWeb. Read that link; it's worth it -- Paul talks about how his startup's success could be directly attributed to the decision to use Common LISP.
My last employer's high-bandwidth real-time metrics analysis program. Sorry, closed-source, but we gave a talk about it at Clojure Conj.
Incidentally, we weren't the only people to decide to use Clojure for that exact same problem -- Storm was written by Twitter to solve the same problem (distributed realtime number-crunching), and does so beautifully.
ThreatGrid does large-scale real-time malware analysis. Guess what their platform is written in?
Cascalog is one of the most widely-used library on top of Hadoop. Yup, it's in Clojure, a LISP.
PuppetDB was developed by a good friend of mine over at Puppet Labs. Backend? Clojure.
Datomic is perhaps one of the most interesting datastores out there -- moving the CPU work involved in queries out to the clients, making reads exceedingly scalable (and able to do things like blocking network calls with zero impact on other clients). Guess what it's implemented in? Right.
Overtone is a "live programming" environment for music synthesis. If you have the time, Sam Aaron's talk using it to demonstrate the basics of psychoaccoustics (not to mention building the instruments he uses on-stage and using functional techniques to decompose Bach's canons and reconstruct them at will)
And so forth. Every conference has more people announcing interesting projects they've written, and I've only skimmed the very top -- ones which are exceptionally memorable. There's a lot going on, and more all the time.
Unlimited data (5GB at 4G speeds) on T-Mobile is $30/month, it's compatible with Nexus phone hardware, and I don't have to worry about getting kicked off for using too much.
I know about Republic Wireless -- and very intentionally choose not to use them.
Seriously? Now, private, for-profit companies are just asking people for cash? What kind of balls does it take to do that? And, somewhat related, what kind of idiot would give them money?
Someone who wants to live in a world where the product they're proposing to build exists, I'd expect?
Dude, we steal the server, hem and all, set it up in our lab, then we have all the time in the world to try bus based exploits.
So? Signatures happen on the HSM, which also stores the key material; only the cleartext data going in and the signatures going out are on the bus.
And if you mess up in the lab, the HSM kills its keystore and game-over. (Or, if it doesn't, the folks on the other side were insufficiently paranoid / excessively cheap and it's Their Own Damned Fault).
Sure there are stats showing how many lives have been saved from seatbelts and helmet laws, I don't have any cause to disbelieve them.
Actually, there is good reason to disbelieve that bicycle helmet laws (as distinct from motorcycle helmet laws) have a beneficial effect: Simply put, the desired effect doesn't show up on country-level statistics after these laws have been implemented.
One of the more plausible explanations for this related to its interaction with the safety-in-numbers effect: The more cyclists are on the roads, the more motorists are watching for them. Requiring helmets reduces the number of cyclists on the road on a scale reaching towards 50%, both directly from inconvenience and vanity, and less directly by making cycling seem so unsafe that it needs to be regulated... but by making cycling seem unsafe, it thus becomes actually unsafe: Every time the cyclist population doubles, the per-person accident rate drops by about 1/3rd.
So -- cut the cyclist population in half with a helmet law, and you reduce the safety-in-numbers effect enough to entirely lose what little you gained. And that's presuming that people are actually wearing appropriately sized and fitted helmets correctly -- there's no shortage of studies showing that the percentage of people doing so in areas where helmet usage is mandatory is in effect is low enough that the beneficial side of the law is of little help as well.
There are other reasons to be skeptical of bicycle helmets -- motorists are measurably more careless when driving near a cyclist with a visible helmet, and the risk compensation effect (in which a helmeted cyclist behaves more recklessly on the belief that they're safer) is clearly a factor as well. Me? I wear a helmet when I ride anywhere with traffic (it's where my mirror and headlight are mounted)... but I'm vehemently opposed to any attempts to make the practice mandatory.
[And another addendum, to be fair -- there's some new work on helmets that effectively dampen rotational inertia; if those actually make it to market, something which has been effectively suppressed in the US by manufacturers having no incentive to exceed CSPC regulations, I might want to review parts of my position -- they've been shown to be quite effective at preventing concussions, which widely available bicycle helmets don't do].
Oh -- and about seatbelts: There's no question that they make folks who are belted in safer. However, it's also well-established that they make people who aren't belted in -- such as pedestrians -- less safe: Drivers behave more recklessly when they feel secure, and seat belts and anti-lock brakes provide such security.
Nobody can seriously think that 2.5% rate is a fair price as there are thousands of FRAND patents involved in any smartphone concerning 3G, 4G, WiFi, Bluetooth etc.
Not per patent. For an entire portfolio, it seems an entirely reasonable place to start bargaining from.
And that's what happened in the Microsoft/Motorola case -- Motorola put in an opening bid, and Microsoft immediately (with no counteroffer) when running to friendly local court asking that court to decide that the negotiations (to which they'd declined to respond at all) were innately unfair.
It also sounds vulnerable to replay attacks. I can have you touch something that secretly records the signal, then play it back to the actual input device. Seems like a password you're always broadcasting from your skin...
No reasonable authentication system works that way. Typically, one uses bidirectional communications -- present a piece of data, get back a signature with a private key stored within the device. That's been done in extremely-low-power scenarios for ages -- remember the crypto iButton?
I'm a little surprised -- RabbitMQ is one of the most widespread implementations of AMQP, which is what basically everyone [founded after 2000 or so] uses when they want a distributed message queue.
What do you do? I can't imagine it involves distributed systems.
Rand's record with respect to relying heavily on public assistance is very well-documented and well-established. That you continued a thread here with name-calling and not any actual research is, well, interesting.
When that language family accounts for 90% of all professional development (with the remainder going almost exclusively to Javascript, perl, and php not functional languages) that's perfectly ok. In 12 years I've never seen a functional language used anywhere I've worked. Heard rumors of it, but never seen one put into production. Even the rumors weren't about production, but some one off dev tool some guy wrote for his own use.
Dunno 'bout you, but quite a lot of places I've been at have deployed installations of RabbitMQ or ejabberd.
I was also at MessageOne when they built a high-volume real-time metrics processing system in Clojure (which blew the socks off of the Python system it replaced in terms of scalabilitiy -- transactional memory is great for that), and have deployed production code in Clojure at other sites since then.
I'd like to just point out that all languages these days really aren't that different.
I'd like to point out that you didn't include one purely functional language in that list, or one LISP. If you stick to one family, sure, you can observe commonalities.
We (in the US) are already there. Just go read the recent news. IRS/TEA Party/medical records seizures, DoJ/reporters, etc etc. It's not "ooh, shiny!" Hollywood, but what in the real world ever is? The results (and the violation, terror, and suffering of innocents) are the same.
One side says that global warming exists and is manmade. They go too far and decide that your personal car and incandescent lights are solely to blame.
What's the most recent device you've worked with?
I had my own share of awful experiences with Android's bluetooth stack back in the HTC Magic days (in which I was building an app to pull a live feed of motor/battery/temperature/etc. statistics from my ebike), but my current Nexus 4 has been rock-solid.
So interviews are out? Or do you want a 4-week interview?
I'd think that looking at my github account would make more sense.
If it's a simpler, totally reasonable 4-day-or-less problem, why do you need 4 weeks?
Because working on a big project can require kinds of discipline that small projects don't, so hiring someone to work on big projects based only on how they perform on small ones is a good way to get mislead.
Note that I said "only". In-office code screens are essential; they just aren't sufficient.
Knives and sticks are less dangerous: it's far easier to run away
Which not everyone can do. My fiancee has spina bifida; she couldn't walk until fairly late childhood, and running isn't ever going to happen -- it was having her aunt's pearl-handled pistol in a big granny-purse that saved her from being mugged as a child. (Mugger presents knife and asks for her wallet; she reaches into purse, pulls out the gun, cocks it, says "no"; would-be mugger wets pants and runs off. Granted, a smarter mugger would have done a cut-and-run on the purse as a whole).
Mind you, her family was from the country a generation before her; they started firearms safety training early (wild animals with rabies were a real problem in their area -- even having a few cases of dogs in their kennel getting infected).
Like almost everyone else I know, she agrees that many firearms should be restricted -- large-magazine weapons and the like -- and that safety training is essential... but taking the only effective means of self-defense away from people unable to run is unreasonable.
To start if off -- we had a report of pyramid_debugtoolbar failing with a UnicodeDecodeError this morning (on Python 2, where platform.platform() returns a non-7-bit-clean bytestring rather than a Unicode string, causing code to blow up later in the templating layer; on Python 3, it works perfectly).
Or you get a phone with Qi support, and you don't need a working USB port to charge, even with a non-removable battery. More than one way to skin a cat.
In the real world, purely functional code doesn't happen.
Sorry -- I can't buy that quite as-written. Complete projects composed only of purely functional code don't happen, sure.
Purely functional code certainly does happen -- if you're doing a good job of isolating your state to small chunks of code, and building the rest of your codebase to be easy to cache, easy to memoize, easy to test, easy to parallelize and optimizer-friendly, it happens quite a lot.
But if you're writing purely functional code, you can't have any output, because that would be a 'side effect'.
The side effects in the scenario I proposed are in the printer, or the nrepl code that speaks to the socket you're connected over. Those side effects are, thus, not in the actual code under test, allowing that code to be safely run against the production system in question.
There's functional programming for purists, and there's functional programming for people who want to get things done. In the latter case -- a set I belong to -- it's all about isolation and management of side effects, not about attempting to avoid them altogether.
Slashdot Mirror
Off the top of my head...
And so forth. Every conference has more people announcing interesting projects they've written, and I've only skimmed the very top -- ones which are exceptionally memorable. There's a lot going on, and more all the time.
Unlimited data (5GB at 4G speeds) on T-Mobile is $30/month, it's compatible with Nexus phone hardware, and I don't have to worry about getting kicked off for using too much. I know about Republic Wireless -- and very intentionally choose not to use them.
Someone who wants to live in a world where the product they're proposing to build exists, I'd expect?
That gets you the opposite problem. Look at how Microsoft's home-court advantage has been favoring them in Seattle.
Dude, we steal the server, hem and all, set it up in our lab, then we have all the time in the world to try bus based exploits.
So? Signatures happen on the HSM, which also stores the key material; only the cleartext data going in and the signatures going out are on the bus.
And if you mess up in the lab, the HSM kills its keystore and game-over. (Or, if it doesn't, the folks on the other side were insufficiently paranoid / excessively cheap and it's Their Own Damned Fault).
Actually, there is good reason to disbelieve that bicycle helmet laws (as distinct from motorcycle helmet laws) have a beneficial effect: Simply put, the desired effect doesn't show up on country-level statistics after these laws have been implemented.
One of the more plausible explanations for this related to its interaction with the safety-in-numbers effect: The more cyclists are on the roads, the more motorists are watching for them. Requiring helmets reduces the number of cyclists on the road on a scale reaching towards 50%, both directly from inconvenience and vanity, and less directly by making cycling seem so unsafe that it needs to be regulated... but by making cycling seem unsafe, it thus becomes actually unsafe: Every time the cyclist population doubles, the per-person accident rate drops by about 1/3rd.
So -- cut the cyclist population in half with a helmet law, and you reduce the safety-in-numbers effect enough to entirely lose what little you gained. And that's presuming that people are actually wearing appropriately sized and fitted helmets correctly -- there's no shortage of studies showing that the percentage of people doing so in areas where helmet usage is mandatory is in effect is low enough that the beneficial side of the law is of little help as well.
There are other reasons to be skeptical of bicycle helmets -- motorists are measurably more careless when driving near a cyclist with a visible helmet, and the risk compensation effect (in which a helmeted cyclist behaves more recklessly on the belief that they're safer) is clearly a factor as well. Me? I wear a helmet when I ride anywhere with traffic (it's where my mirror and headlight are mounted)... but I'm vehemently opposed to any attempts to make the practice mandatory.
[And another addendum, to be fair -- there's some new work on helmets that effectively dampen rotational inertia; if those actually make it to market, something which has been effectively suppressed in the US by manufacturers having no incentive to exceed CSPC regulations, I might want to review parts of my position -- they've been shown to be quite effective at preventing concussions, which widely available bicycle helmets don't do].
Oh -- and about seatbelts: There's no question that they make folks who are belted in safer. However, it's also well-established that they make people who aren't belted in -- such as pedestrians -- less safe: Drivers behave more recklessly when they feel secure, and seat belts and anti-lock brakes provide such security.
you are not worried about google tracking you, but are worried about cookies? please explain?
The parent didn't indicate concern about cookies; the parent indicated concern about notice requirements for sites using cookies.
Not per patent. For an entire portfolio, it seems an entirely reasonable place to start bargaining from. And that's what happened in the Microsoft/Motorola case -- Motorola put in an opening bid, and Microsoft immediately (with no counteroffer) when running to friendly local court asking that court to decide that the negotiations (to which they'd declined to respond at all) were innately unfair.
This kind of attack is exactly why Android 4.0 introduced public-key authentication (with manual whitelisting) for USB debug access.
No reasonable authentication system works that way. Typically, one uses bidirectional communications -- present a piece of data, get back a signature with a private key stored within the device. That's been done in extremely-low-power scenarios for ages -- remember the crypto iButton?
I'm a little surprised -- RabbitMQ is one of the most widespread implementations of AMQP, which is what basically everyone [founded after 2000 or so] uses when they want a distributed message queue.
What do you do? I can't imagine it involves distributed systems.
Rand's record with respect to relying heavily on public assistance is very well-documented and well-established. That you continued a thread here with name-calling and not any actual research is, well, interesting.
True, but electric motors scale down better than gasoline ones do.
Just because gasoline is better for large vehicles doesn't make it better for everything.
Dunno 'bout you, but quite a lot of places I've been at have deployed installations of RabbitMQ or ejabberd.
I was also at MessageOne when they built a high-volume real-time metrics processing system in Clojure (which blew the socks off of the Python system it replaced in terms of scalabilitiy -- transactional memory is great for that), and have deployed production code in Clojure at other sites since then.
Obviously you don't work in embedded space -- QNX has been dominant there for decades. And then there's Mach (which underlies MacOS X)...
I'd like to point out that you didn't include one purely functional language in that list, or one LISP. If you stick to one family, sure, you can observe commonalities.
Not following the news (retractions) much? That same audit targeted liberal groups with equal opportunity -- it did focus on organizations with political-sounding names, but didn't pick bones about which side of the fence that organization was on.
Nobody says that.
What's the most recent device you've worked with? I had my own share of awful experiences with Android's bluetooth stack back in the HTC Magic days (in which I was building an app to pull a live feed of motor/battery/temperature/etc. statistics from my ebike), but my current Nexus 4 has been rock-solid.
I'd think that looking at my github account would make more sense.
Because working on a big project can require kinds of discipline that small projects don't, so hiring someone to work on big projects based only on how they perform on small ones is a good way to get mislead. Note that I said "only". In-office code screens are essential; they just aren't sufficient.
Which not everyone can do. My fiancee has spina bifida; she couldn't walk until fairly late childhood, and running isn't ever going to happen -- it was having her aunt's pearl-handled pistol in a big granny-purse that saved her from being mugged as a child. (Mugger presents knife and asks for her wallet; she reaches into purse, pulls out the gun, cocks it, says "no"; would-be mugger wets pants and runs off. Granted, a smarter mugger would have done a cut-and-run on the purse as a whole).
Mind you, her family was from the country a generation before her; they started firearms safety training early (wild animals with rabies were a real problem in their area -- even having a few cases of dogs in their kennel getting infected).
Like almost everyone else I know, she agrees that many firearms should be restricted -- large-magazine weapons and the like -- and that safety training is essential... but taking the only effective means of self-defense away from people unable to run is unreasonable.
To start if off -- we had a report of pyramid_debugtoolbar failing with a UnicodeDecodeError this morning (on Python 2, where platform.platform() returns a non-7-bit-clean bytestring rather than a Unicode string, causing code to blow up later in the templating layer; on Python 3, it works perfectly).
Or you get a phone with Qi support, and you don't need a working USB port to charge, even with a non-removable battery. More than one way to skin a cat.
Sorry -- I can't buy that quite as-written. Complete projects composed only of purely functional code don't happen, sure. Purely functional code certainly does happen -- if you're doing a good job of isolating your state to small chunks of code, and building the rest of your codebase to be easy to cache, easy to memoize, easy to test, easy to parallelize and optimizer-friendly, it happens quite a lot.
The side effects in the scenario I proposed are in the printer, or the nrepl code that speaks to the socket you're connected over. Those side effects are, thus, not in the actual code under test, allowing that code to be safely run against the production system in question.
There's functional programming for purists, and there's functional programming for people who want to get things done. In the latter case -- a set I belong to -- it's all about isolation and management of side effects, not about attempting to avoid them altogether.