aredington

One thing I really appreciated as an non-practicing observer was the frequent reminders to consider safety concerns, e.g. try a door knob before forcing it, take care with how padlocks may turn into projectiles, taking care that operating a chainsaw doesn't pose a threat to people inside a warehoused window, etc.

And you make less industrialized, more labor intensive forms of producing eggs or milk more economical than higher industrialized, lower labor forms.

Similar tool available for Firefox: https://addons.mozilla.org/en-US/firefox/addon/converter/

Just started using it, happy to be able to excise that bit of pervasive ignorance from my life.

Keep in mind that read-string, eval, and load-string are all exploit vectors. Read-string exposes you to the #= eval macro, which can execute arbitrary code at read time, as well as various vulnerabilities with object construction.

Eval executes the data it receives without any sandboxing or sanity checking, any data that has ever had any user influence should be suspect. 9 times out of 10, if you're using eval, you should be using a function reference.

Load-string is likewise vulnerable to the eval macro and constructor attack vectors.

clojure.edn offers safe versions of read and read-string that do not use the eval macro. You can get load-string equivalent behavior by wrapping the string in a StringReader and then clojure.edn/reading it until eof. If you're reading data that's had any influence from an end user, always use the clojure.edn facilities, and never eval it.

Verizon has so much bandwidth to get in and out of their network for broader internet bound and broader internet originating traffic. Netflix has to come in the off ramp that all the torrents, hacker news, and etc. traffic has to come in.

Netflix has offered to build a new offramp for Netflix traffic that goes directly into Verizon's network. Netflix is willing to shoulder ALL of the burden of this infrastructure cost, and to maintain it.

Verizon has refused the offer, and instead wants to charge Netflix a toll so that their traffic gets to use an EZ-Pass lane, instead of going through the normal slow toll booths that everyone else's traffic goes through.

Clojure: Java is too complected.

The media industry created a way to sustainably undergo the capital expenditures necessary for high quality studio recording, and the mass production and distribution of physical media communicating those studio recordings. It extracted rents in the forms of usurous recording contracts, hugely divergent pricing from their costs, and avaricious assignment and stewardship of copyrights.

Technology has reduced the cost of transmitting the information in recordings to the trivial level that serving someone a glass of water costs.

A combination of technology and prior capitalization has driven down the cost of studio recording, both lowering the necessary a prior knowledge to record well, and putting excellent mastering tools in the hands of many at low cost.

What precise value are the members of the RIAA providing today? Please demonstrate how these members provide an essential value that cannot be shouldered by individual artists (e.g. Macklemore & Ryan Lewis)

The example cited makes two decisions which are not articulated explicitly but are decisions one can make and which have benefits and costs. They are:

1) The function correctly executes on the class of things for which (.toString thing) has a sensible run time invocation.

2) The function delays examination of the correct class of its argument from compile time to run time.

1 is a benefit, in that in a dynamic system it is possible that something which, at compile time, does not have a sensible .toString invocation, can gain it at run time and then participate in the function.

2 is a cost, in that you have to delay classification to the instant in which you try to invoke .toString

This tradeoff is elemental and there will be systems you can build by embracing it that will never be possible in strongly typed languages. You'll be able to build isomorphs of them, but doing so will involve expressing significantly more ideas to get there.

One of Clojure's fundamental opinions, asserted by the language eagerly, is that vector quantities should be treated as values the way scalar quantities are in most languages. Specifically, this means that when you operate with a list and append to it, instead of modifying the value of the next (cdr) pointer in the last node, you create a new list and return the new list as the result of the append operation. These immutable collections afford certain classes of algorithm that destructively modified ones do not. Rich reviews this concept pretty well here: http://www.infoq.com/presentations/Value-Values

This story doesn't spend much time discussing this particular opinion of Clojure's or why you would choose to circumvent it by making a mutable linked list. Additionally by virtue of skipping the immutability discussion, it fails to discuss how append to the head of a list is crucially different from append to the tail when working with data structurally sharing underlying data.

Additionally it prefers to define an interface over a protocol (using definterface instead of defprotocol), and it uses camelCase naming instead of Clojure's culturally embraced hyphen-cased naming.

In short this describes a way to build a data structure in Clojure, but is not a particularly good as an example to be followed of how you should build data structures in Clojure. johnwalker cited a couple more idiomatic examples, e.g. data.finger-trees: https://github.com/clojure/data.finger-tree/blob/master/src/...

The way I read it he's proposing two things:

1) Refer to the analysis of Root Mean Square Error always by that name. (RMS is already often used in certain jargon instead of stddev).

2) Stop treating RMS as a default measure of variance. Treat Mean Absolute Deviation as the default measure of variance, because the figure it provides is more consistent with people's psychological interpretation.

It's not really retiring RMS, just retiring the idea that it is a good default statistical analysis.

The core point is the same: With sufficient test coverage, you can change one variable (Python 3 vs 2) and control for all others. Tests are not an end, they are a means to an end; the courage to change your software in the face of a constantly changing world.

Sounds like you're not there, but maybe you have specific domains of EVE that you feel comfortable changing at your whim. That's the success to focus on.

BTC aren't quite tulips, but the criticism is well founded that it isn't yet a good currency. A perfect currency would possess the following qualities:

Perfectly Fungible

Perfect Liquidity

Perfect Stability

Right now bitcoins are commodities. Any bitcoin is equally valuable as any other bitcoin; bitcoin's value derives from its purchasing power and from its exchange rate to other mediums of exchange. It has great liquidity and fungibility. However it has inherent stability problems as well as ambient ones:

Currently it experiences volatility by virtue of transactions not being demoninated in BTC, and of its exchange rate to other mediums of exchange. A large part of this is because it is consistently attracting large pools of people who wish to acquire it. The recent price spike appears to be a consequence of Chinese interest in acquiring bitcoin rapidly increasing. Eventually the number of people who want to possess bitcoins will grow as a function of the population on the planet, rather than as a function of new groups of people deciding it has become appealing. This will introduce some stability.

However, there's a fundamental flaw in that the pool of bitcoins is fixed, and that possessors know the finite size of the pool of bitcoins a priori. This exerts deflationary pressure on BTC, and as others have noted, discourages its spending. BTC is vastly more liquid than gold is, for example, but the stability of its value will always be an impediment to its usefulness as a currency.

This doesn't spell the doom of Bitcoin; it doesn't need to be a perfect currency, just a better currency than other currencies. It is already the most liquid commodity on the planet. It is at least as fungible as USD; attempts by coinvalidation to ruin this notwithstanding. Should the deflationary pressure of bitcoin compared to its circulation become sufficiently small, it will have inherent qualities to make it the best currency available, which can lead to it becoming more widespread.

A currency with lower transaction costs in time, and which has growth characteristics which trend toward following the value of productive output of the human race will certainly be better. USD are inherently worse.

The ring is still ambiguous. It is never characterized properly as a totem (Cobb never uses it awake, that we see). If you interpret it as a symbolic representation of his mental affiliation with Mal, then:

a) At the end of the movie he is awake, and he really meets his children. The lack of the ring is consistent with all available evidence prior to this point because he only has the ring on when he is asleep.

b) At the end of the movie he has successfully escaped Limbo twice. Cobb has mastered his own psyche; he has achieved closure on Mal's death; he has finally embraced in his own mind that the Mal in the dream is just a ghost, and can be in the dream without the ring. He can dream again without Mal invading from his subconscious.

As I read the article, the address is owned by DPR and the FBI seized the associated wallet.

Communist countries dictated by political fiat where labor resources were allocated, what industries would be engaged in, and how the capitalized wealth of the country would be reinvested.

They didn't just go around giving everyone an income that kept them from living in a gutter.

In practice, Southwest airlines has one class of passenger. Everyone rides in steerage, but you can pay a little extra to jump at the front of the line and pick your favorite steerage class seat. They're able to operate profitably on a fairly consistent basis, this author is postulating a necessity that does not exist.

Objectifying women is rarely an act that people embrace with a conscious perspective or decision. It's a way of behaving that most people engage in because the culture they occupy and learned in showed it as an acceptable behavior. They continue the behavior which reinforces their privileged position in society (again, often not consciously).

The intent and perspective of the author do not make the problem go away any more than a hunter realizing he accidentally shot someone in the wilderness that he mistook for a deer makes the victim's bullet wound close.

Part of the concern is that the youth and gender are highlighted prominently for these engineers, and ONLY the young woman engineers are listed as perks. I absolutely value the contribution women engineers bring to my work environments, they are valuable additions to our team, but some of them aren't young.

Again, IF the engineering team was described separately, OR if other engineers were included as 'perks', e.g. "We have a senior Rails contributor on staff whom you can learn with", OR if the perk wasn't specifically calling out their youth and gender (we have a multinational team of many races and genders), then this would be a non-story.

When you include the women as a perk in an effort to tempt engineering talent, it's easy to interpret the mindset of the author of using women as objects. Even if the author ISN'T authoring the list that way, they are not being cognizant of the pervasive problem of viewing women as objects and acting to prevent it.

Everything else on the list is proffered as transactional compensations of talented engineers renting their labor to the CEO. Highlighting the youth of these engineers while including them on a list of perks implies specific things about how they are valued.

If he had separately described the work environment, and had included these engineers in that description, and had not focused SOLELY on the young female engineers, then this wouldn't be a story.

Say it's the exact same mechanism as evacuation slides.

Patents in the U.S. since 1995 have had a term of 20 years, prior to 1995 it was a term of 17 years.

The slides were initially patented in 1956. In 1956 the U.S. patent term was 17 years; those patents expired in 1973.

But, let's suppose some advances were made and the specific valving mechanism was patented later. It would have had to have been invented and patented some time after 1995 to still be covered by a patent.

If it were patented any earlier, its term will have expired and the idea is now in the public domain, which means anyone can use the idea without paying anything.

He got whacked because he was being dismissive of people's objection to a business decision.

He compared the business decision to engineering limitations (vacuums need AC out of plugs, mobile phones need cell towers in range), and was snide about people objecting to the business decision to have a console that only works when it is connected to the internet.

He wasn't having open an honest dialog, and he wasn't conducting that dialog politely.

I think most folks on HN know of some marginalized political philosophies such as anarchism or libertarianism. These political philosophies aren't popular, but there are polite and intellectually rigorous ways of discussing them, and there are immature and inconsiderate ways of discussing them.

You can discuss marginalized or unpopular things without being an asshole. But Orth was discussing them while being an asshole, and was doing it as a representative of Microsoft.

There's a growth in both supply and demand, let's call them ds and dd. ds is relatively constant, though every 4 years it halves. dd is stochastic and gets influenced by how many ways there are to use bitcoins as a store of wealth, speculative opinions on its future conversion to dollars, and how many actors will accept bitcoins as a transfer of wealth.

Most of the pressure on dd has directed it to grow, so demand is going up, and it goes up faster over time. ds is a designed feature of the currency, and is designed to shrink quasi-deterministically.

The supply of bitcoins is not growing in proportion to the growth of demand for bitcoins, thus the price goes up. So it's probably most fair to say that the demand is growing significantly faster than the suppply. However, the most recent halving day has significantly altered the differential between ds and dd.

The recent spike in price is due to a recent drop in supply. The amount of BTC awarded from successfully mining was recently cut in half from 50 to 25BTC, and the difficulty rate has been rising as better mining hardware has been getting out into (a few) people's hands.

It's harder to get your hands on BTC now than it used to be.

Communication happens over HTTP at the wire level, and we use the Server Sent Events standard (http://en.wikipedia.org/wiki/Server-sent_events), and particularly browsers' EventSource implementations as the foundation on the client side.

Pedestal Services have a balled up implementation that transmits the data from the server side.

full disclosure: I'm a Relevance employee and have been working on this a great deal.

Pedestal provides a few distinguishing values in this space overall:

- Same language on the client and on the server. You can get this with something running on the native OS in both locations, or with javascript and node, or with clojurescript and clojure. ClojureScript and Clojure can sit on top of the browser platform like javascript. We're opinionated and would rather solve problems with Clojure than with Javascript.

- A server-initiated communication mechanism that can send data to those clients without parking a thread or process in order to maintain all the information for managing the communication. Our Server Sent Events mechanism lets clients initiate HTTP connections to the server and hold the connection open. On the server side, we can park those connections without eating a thread to do it, and pick up the connections to send new data down to clients as appropriate.

- A pretty powerful set of libraries for developing client applications in ClojureScript. The libraries let you isolate the scope of change to HTML document trees so that changes to underlying data reflect small changes up to the presentation layer. This foundation has created lots of interesting abilities, like being able to record a set of interactions and replay them with a new presentation layer, or being able to replay specific sets of data being sent from the server to clients.

There's a lot more that we've built up, based on our experiences trying to solve problems for people in Clojure, but I think these are three things we do that deserve giving us some of your time for evaluation.

I think there's a nice case of posterior-prior art.

"so easily" is poorly defined, but when you are talking about collection data subject to concurrent modification you have a few options for correctness:

1. Read lock on the data for the time a thread is using it. This ensures that it is not destructively modified while iterating over it. This is a terrible option if you're using any kind of blocking operation during the lifespan of the read lock. The thread who obtains the lock runs quickly without any kind of penalty. After it obtains the lock, which might have taken an extremely long time. Especially if some OTHER thread was blocking with a read lock held.

2. Read lock long enough to copy the data. Work with your copy in isolation. You have to incur the cost of the linear copy, this might or might not be less than the cost of performing the work you actually want to do, but if it's close, your run time just went up 2x.

- Brief caveat: Any explicit locking scheme subjects you to risks from deadlocking. This is where complex multithreaded applications develop explicit locking orders from, and what can make large codebases difficult to work in.

3. Don't read lock, hope for the best. This can work better if you have a means to detect concurrent modification and restart. You might even get the correct behavior for 99% of cases.

4. Work with immutable data structures that cannot be destructively modified out from under you. Immutable data is computationally cheaper to read in the face of parallelism than every other option. It is more expensive to write to. What do your read and write loads look like?

- Also please keep in mind that while Clojure provides immutable persistent data structures out of the box and its reader generates them for all the canonical serializations, it does not take away Java's destructively modifiable types

Clojure's immutable data structures allow you to scale out across many cores without needing as rigorous locking semantics as a destructively modified version of the same work would need; copy on write presents no contention until you want the new value to be the canonical value.

Would I trade a 1000% performance hit on write ops in exchange for the ability to scale out over 10000% as many cores simply? Every day of the week.

Single threaded execution is a computational dead end. If you want to go faster, you have to parallelize, be it on a single system or on a cloud service. Clojure's persistent data structures ease this. That the persistent data structures also have canonical serializations ALSO ease this.

You should be angry that they have managed to persuade you that theirs was the only way out. The odds that properly modularizing their source tree such that they didn't provoke the limitations of the VM they were running on was impossible are vanishingly small, and the odds that they correctly hacked the VM are also vanishingly small.

Facebook's Android Engineers chose the ego stroking solution which involved clever hacks. This only reinforces my being happy to have uninstalled the FB android app 2 years ago.

Sexism isn't a problem that exists in conferences, it is a problem that is pervasive in the industry surrounding software. In that industry, women are a minority of workers, and they enjoy fewer privileges than their male peers.

When a person presents at a conference with material intended to be humorous, but where the humor excludes women, it is adding to the problem that women do not enjoy an equal position with men. It reinforces that this is an industry where men are privileged, and sets an example for others of privileging men.

I can't imagine someone publicly defending racist jokes included in a conference in this day and age. Even if it's "just a joke", it excludes members of the audience based on circumstances of their birth. The same applies equally well to sexist jokes which exclude members of the audience based on circumstances of their birth, yet people are willing to publicly defend the choice to be sexist.

From the creator's own mouth, it's a satire language, but all satire has a good point. Vigil's is many programmers' susceptibility to The Broken Window problem. It's creation raises a good point about the usefulness of contracts in the absence of mechanisms for enforcing those contracts.