granitepail's comments

This is reminiscent of "The Hunger Site" which started in 1999. http://thehungersite.greatergood.com/clickToGive/ths/home

I have no idea why you're getting so much pushback. Products like those offered by Bloomberg ingest and distribute massive amounts of data in real time, as well. The comparison is completely suitable.

While their products for investment managers are mostly run off of persistent databases, the trader terminals rely on a high-volume, nebulous fan out. For many traders, a five second latency is unacceptable.

Incredibly interesting talk and a good write up. Twitter continues to impress! I was surprised to see Redis playing such a critical role, too.

You guys seem like a step in the right direction! The improved locking, in particular. Sharding is still a nasty issue w/ MongoDB.

Yeah! Exactly! Sorry if it was unclear, but what I meant was that I saw the latest wave of DBs (Rethink + Riak) as finally letting the administration & scalability side catch up to the programmer approachability side. Anyone with significant experience knows sharding MongoDB can be a massive pain. Sharding Cassandra is easier, but it certainly lacks the juicy programmer interfaces provided by more modern solutions. I'm very excited about the work you guys are doing.

I saw the article as more of a reaction to all of the technical (and often times inane) blog posts about why company x uses technology y.

The main points I took away from the article were:

- They did their homework, and - They knew that, even though it is not the most widely known technology stack, they were seeking the kind of engineer who would not only be able to pick it up, but understand their rational for choosing it

And it seems as though they've been successful! As engineers, most of us are interested in the many interesting technologies available to us, so much so that, when examining a company like Basho, many of us ask "Why Erlang?" before we ask "What are you making and why?"

Without putting words in their mouth, it is my impression that Basho sought to create an incredibly powerful and easily scalable database. They chose Erlang because it was, in their opinion, the tool for the job. As I see it, 10gen got the ball rolling towards approachable scaling/development and now Basho and the team behind RethinkDB are trying to improve by creating systems free of MongoDB's many limitations.

You're generally spot on, but I figured I'd clarify a bit of terminology since it can be so confusing in our field. Generally, TCP is referred to as a "stream" based protocol because it guarantees, amongst other things, that all packets will arrive in the order in which they were sent, as you've mentioned.

UDP _is_ great for "streaming" data, meaning data sent piecewise over a continuous connection (or, at least, emulated connection) because packet loss / reordering is an acceptable loss, since a minor blip is less destructive than pausing the video. In this type of setting, packets that arrive out of order (i.e. a packet that was sent earlier arrives after a packet sent after it has been received) are thrown out and the process keeps on chugging.

Having worked on a sizable AngularJS project for a good while, now, I can't begin to imagine where you're coming from. The strength of Angular, in my opinion, is that I write ~1/10th the code I'd write using jQuery & Underscore. Event handling, display logic, data binding, directives, resource factories – all of these and more mean I can focus on my business logic as opposed to re-binding events when I update the DOM and the dozens of other trivial bits I have to care about when using jQuery (or Backbone, really).

Obviously jQuery/Backbone setups have their place, but to claim that AngularJS makes you less effective is absurd.

it's not funny and that was not censorship. it was an expression of collective disappointment at a user's attempt to marginalize the CEO of a large and influential tech company made purely on the grounds of her being a woman.

it's an interesting move for yahoo! and i'm curious as to see how their revitalization campaign plays out.

It's also worth noting that while blunt objects such as hammers and baseball bats find uses in construction and non-violent sports, guns do not necessarily share such innocent use cases. Sport shooting is the major exemption (I'm quite a fan, myself) but at the end of the day guns are designed to put holes (some messier than others) in objects very far away. When a gun is pointed at a living organism and the trigger is pulled, its chances of survival plummet.

this should be at the top! most complete option yet, with preservation of the original documents. many thanks!

There's gob ( http://golang.org/pkg/encoding/gob/ ). Not going to claim it's on the level of node communication in Erlang, but it does make data (de)serializaiton incredibly simple. With only a few lines of code you could have a channel reading from and writing to a socket to another machine.

So you're assuming they didn't do their due diligence? That they threw $30MM at a company they knew nothing about? Has anyone in this thread gone so far as to even try the product?

This kind of response terrifies me. I'm a man, so maybe I am not in a place to correct you, but I have gotten the impression that the pressure and discomfort wrought by this kind of behavior (whether or not you have a thick enough skin to deal with it) pushes a lot of women away from tech in the first place. Even if you try and reduce the behavior to "little boys club" material, such joking is still alienating to many women.

Not only are you reducing her importance based on her former title/role at SendGrid, but you're saying her behavior warranted ("opened herself to") harassment. No two men or women are the same, but your not sympathizing with her at all confounds me.

EDIT: fixed a typo

As a group seeking to give women a safe and comfortable entry into tech, I can't imagine any scenario in which supporting PyLadies would add to the problem. It may bring more women into tech who are then the subject of such misogyny, which is a depressing thought but would hopefully continue to force the issue into the public eye.

More women in tech is a win for everyone — including employers. To be swayed from helping a cause like this because of negative social repercussions signifies, to me, a desire to hop on the bandwagon as opposed to a true desire to get women in tech and fight to ensure they are seen as equals.

Taking away benefits to see which candidates are the "hungriest" seems lazy - and unethical - to me. It's not easy to source good candidates, but it seems completely backwards to find the best, most driven candidates possible through a method that, in the end, deprives them of something you could easily deliver.

I've worked with companies who have a 1-month "escape hatch" on-boarding plan, wherein either the employer or employee can terminate the agreement no-harm-no-foul if expectations are not aligned. This is obviously more of a social agreement, as most companies use at-will employment contracts. This way, you can still treat your employees right.

the phrase i see uttered time and time again throughout his posts (i've read three, now) is "then i realized that <library/component> sucks" followed by a self-indulgent pursuit to make a better <library/component> that ends in failure.

i am the type of programmer who loves to reinvent the wheel (albeit, mostly as a means of exploration) but i never approached it like this. this seems to be very self-destructive behavior rooted in the cop out of the yet-unvalidated claim, "i can make something better."

it seems as though many of his judgements are made before gaining an intimacy with the subject he wishes to work on. i would suggest an investment in actually refining his skill set. he may be able to see the need, but doesn't seem to understand how things got to where they are — an important step in moving forward.

i wanted to sympathize with his plight, but it seemed as though a lot of his suffering was caused by an unchecked ego. i think he'd be happy undertaking and completing some VERY simple projects — perfecting them before moving forward.

I'm always a bit shocked at how incestuous this community can be. Many articles that pop up are simply responses to other articles, rarely containing enough content to justify being anything other than a comment. In this case, I saw the content of this article condensed into a single, well written, concise comments on the article about that guy making $8k off of some Mac OS X app. Worse, that was an article I found a bit obnoxious in and of itself (it felt hard to justify that as anything other than boasting when I'm fairly certain everyone understands a well promoted sale can do some good.)

Closing off that rant and moving on to an actual comment, I don't know that I agree with the 'advice' here. If you have to hide the fact that your idea is making money out of fear of copy-cats stealing up your business, then it was certainly not a sustainable model to begin with. It's a good way to make a quick buck and, in that context, this is likely good advice, I just wouldn't count on some project that depended on it to last any meaningful amount of time.

For those of you who don't know, weavejester is the creator and maintainer of a few of the more prominent (and, in my opinion, production ready) clojure libraries (thanks!), mostly centered around web serving. His code is concise and chunked into many small functions, abstracting out as much functionality as is possible -- this is the lisp way.

If you've written much clojure (or any other lisp, really) you likely realize that writing massive functions is not a part of the lisp paradigm, and for good reason -- not only are large functions tough to read, but the notion of everything being a function makes it natural to build what are essentially nested function calls into more abstract functional representations.

I understand why Chris has mentioned support for other languages (raising money + support), but anyone who approaches this project should really keep in mind the fact that it is being built with Clojure in mind. I'm sure that, should it be funded and seen to completion, Light Table will provide a rich experience for other languages, but what is most exciting about this project is its potential to truly cater to the needs of a functional programmer. As he correctly states in his introduction, functions are the most often used "block" in functional programming, and editors/IDE's should reflect that and I am hoping Light Table manages to do this.

Regarding the criticism of live code evaluation, I see it as a bit absurd. It should be obvious that the main goal of such an interaction with one's code is not to test functions on live inputs. I see this being most useful in scenarios where the programmer wishes to, say, process strings read in through a socket. Live code evaluation could be immensely useful in a situation in which someone writes their parsing functions and then calls the higher level function on that test input and sees the string progress through their parsing functions, making it much easier to debug. This is just one example.

This response is a bit scattered, as I wrote it piece-wise while cleaning up. Sold as-is.

I don't think our ideas are mutually exclusive — what you're describing is the notion of abstraction as it is applied to writing code. FP gives programmers incredible power with regards to reusing code (macros, first class functions, etc) at the expense of taking a little longer (in some cases) to wrap one's head around.

I was merely commenting that I think part of the reason people have been drawn to FP lately is that the industry as a whole has matured to a point in which more people recognize the need for and have developed the skills necessary to embrace such abstractions.

This article serves to fracture the community in a manner disturbingly similar to that in which the 'smug functional programmers' he complains about do. I can't help but sigh.

I think the recent rise in popularity of functional programming is a sign that more people are beginning to approach computing from a 'computer science' perspective as opposed to a 'programming' one. That is, to say, that the industry has matured to a point in which a significant portion of industry programmers are getting excited about some of the more abstract concepts brought to us through functional programming.

Few people will argue that the concepts underlying FP don't take some time to internalize, but the number and quality of FP learning resources is increasing at an incredible rate. This, alone, makes me skeptical of the author's points — people are going out of their way to create accessible learning resources so that they might share something they find to be useful/interesting. In any movement of any kind, there will always be evangelists. Some (read: most) of these evangelists will be overly aggressive and preachy, but they are rarely (read: never) representative of the larger body.

In the past two years I've become quite a fan of Clojure, and I have found the community to be tight-knit, welcoming and eager to share.