llambda

> I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time.

You may want to have a look at ClojureScript, which has come a long way in the last few years. While the tooling is still not as nice as Clojure-on-the-JVM in my opinion, it continues to get better everyday--this week support for a better REPL via NodeJS[1] was introduced, for instance. A lot of smart people are putting good effort into the compiler and ecosystem and I suspect we'll see a continued uptrend in cljs adoption. Anyway, it may be just what you want: an elegant, productive, pragmatic language with first-class support for concurrency (atoms, core.async) and well-suited to short-lived and scripting-domain problems. (Bonus you can write your frontend and backend in the same language if you want!)

[1] http://swannodette.github.io/2014/12/29/nodejs-of-my-dreams/

Whenever the topic of "simplicity" in software comes up, I feel obligated to point to the superb "Simple Made Easy" talk:

http://www.infoq.com/presentations/Simple-Made-Easy

From my personal perspective, I do not see Go achieving the kind of simplicity Rich talks so eloquently about. Instead, Go seems much more like an "easy" language.

An example of easy versus simple in the OP's article is pointing to on boarding: Sure, your on boarding of new engineers may be /easier/ because Go is an ostensibly "simple" (they actually mean small) and familiar syntax. But that does not imply any correlation with writing simple software. I would argue the difficulty of writing abstractions in Go (especially around channels) actually tends to yield the opposite!

Much like ORMs are a trap because they seem simple, so too are technologies which have such a specious quality of simplicity. It is important to establish how a given technology actually achieves simplicity in practice and I do not see how this article argues that successfully--that is not to say Go cannot achieve simplicity, but merely that this article does not seem to make a solid case, in my opinion.

SEEKING WORK - Remote or San Francisco

I build robust backend systems that serve millions of connections per day, integrate seamlessly with external platforms, and scale to meet demand. I also have some experience building front-ends and the term "full-stack" is applicable to my skill set.

I am proficient with the following technologies:

* Clojure(Script) - Ring, Datomic, Om

* Python - Flask, gevent

* MongoDB

* PostgreSQL

Some of my public work includes maintaining Flask-Login(https://github.com/maxcountryman/flask-login), development of Rauth(https://github.com/litl/rauth), and various other Python and Clojure projects including a Clojure port of Boundary's distributed, decentralized, k-ordered unique IDs.

If you'd like to get in touch, please do not hesitate to shoot me an email! I'll be happy to discuss your project with you.

Email: maxc@me.com Github: https://github.com/maxcountryman

I spoke at length with these guys last night. My takeaway is that this isn't something I personally would get involved in.

First and foremost because I have a preference for starting my own projects independently as opposed to signing on with Assembly; for a number of reasons, chief among them is arguably personal preference and perhaps a bit of an entrepreneurial streak. I also think there's a potentiality, as open source continues to grow in popularity, for corporate-funded projects to be more alluring given that they provide a steady paycheck and benefits if you work for the company. For example, I work on an open source project which was initially an internal project developed for my employer and later released to the public. Today we maintain the codebase and in a sense I am paid to do that particular bit of open source work (I don't exclusively work on that, of course). Maybe this isn't a fair comparison, but I wouldn't give up my day job, which affords some of the benefits Assembly is ostensibly offering (get paid to do open source), or exchange the free time I spend on my own projects for this kind of stake sharing in a project or product...at least not yet.

On the other hand, this might be exactly what some people are looking to do in their free time: maybe you don't want to start your own company or you want to spend time in open source but prefer to get paid for it and your employer has no intention of helping you scratch that itch. However, given that last comment in particular, I really wonder if money is the proper motivating factor for so much of what the community has come to mean? Certainly the prestige of working on a popular or important project has historically been far more valuable than monetary compensation (and can even lead to monetary compensation these days, if a savvy employer is involved and happens to notice you're a Linux kernel committer or some such).

It's an interesting idea, that I'm sure of and I'm wishing these guys the best of luck with it! While I may not be their target audience, it does seem like there could be something here. So here's to hoping it develops into something awesome.

I'm not sure what took GitHub so long to _finally_ implement a mobile view for the site, but thank you. I have been waiting for this to happen for years, quite literally.

Edit: It's worth noting I've heard plenty of counter arguments to using GitHub from my phone. But I will say, sometimes I want to check out a project and possibly browse source and lo and behold I'm not at my desktop. For this reason alone, a mobile GitHub makes sense. Glad to see it at long last.

I hate to be the bearer of bad news, but I think there may be even simpler solutions to this problem:

    (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s"))))

The above is a Clojure one-liner example that I believe satisfies the original problem. So while LINQ may have simplified from the C-language family solutions he had seen, it's clearly possible to take it one step further with the expressivity of modern languages like Clojure...

Edit: remember to sort! (Forgot my coffee this morning...)

Edit again: and aphyr's solution is even more concise and idiomatic, where `s` is the first paragraph of the blog post:

    => (->> (string/split s #"\s+") frequencies (sort-by val) reverse (take 10))
    (["I" 7] ["to" 6] ["the" 5] ["a" 5] ["of" 4] ["candidates" 3] ["is" 3] ["question" 3] ["in" 3] ["their" 2])

> Just use django bro

I would be fascinated to read your rationale for just using Django. Specifically I'm curious what use-cases you see as Django having an advantage in? (Specific examples make for a much more interesting dialogue.) In relation to this, do you think there are contrasting use-cases where Flask might excel as a more suitable option? Personally, I do not favor Flask or Django or <insert web application suite here> exclusively; instead I evaluate a use-case and then determine which tool best fits my needs. However, it would be amazing if you could somehow show that "just use django" is axiomatic to web development in Python...

It's a (fairly simple) macro that defines a function which while doing so associates a quoted function definition (the same as the function being defined) with the metadata of the defined function's var: it might require a double reading (based on my inferior description) because it's got some meta-ness going on.

But the salient point here is there's really nothing magical about what's happening there.

> it's full of magic. You can feel it, but you can't really understand it without digging through the source code.

Are you trolling? If not, care to provide concrete examples?

I've written a number of small applications in Clojure and I find that it /lacks/ magic, even in comparison to something like Python (which is generally highly un-magical). For instance, Clojure's namespaces prevent circular dependencies; while a simple example, this is idiomatic to the larger philosophy of Clojure and indicative of a general dislike of magic that permeates the language as a whole, in my experience.

> I'm always hesitant to relate anything I hear from talking to Uber drivers because I'm worried that Uber might be smart enough to track online comments back to drivers.

Yes, I hope I haven't done that here... I intentionally eliminated as many details as I could.

Instacart continues to disappoint me: I had a detailed conversation with one of their drivers: the driver relayed to me a number of disappointing and distressing aspects of their employment, including an opaque policy regarding tip dispersal, differences in compensation between new and old employees, e.g. commission for new employees, and other shady discrepancies.

Now compound this with a general degradation in quality of service: Recently I've had a driver attempt to deliver the wrong groceries to me, in fact the driver almost left before I could tell them that these were not the groceries I had ordered...prior to that I've had several incorrect or missing items that I was billed for. I wonder if this push towards changes in their driver employment terms has led to a overall lowered quality in the service? This is just speculation of course, a number of factors probably contribute to this. But the bottom line is my experience as a customer has continued to deteriorate.

I had reached out to Intacart directly over email to try to understand how the drivers were compensated so I could determine how much to tip the drivers. I also inquired about the exact mark up over the base cost of an item: I feel like I'm being charged at minimum three times over the base cost: 1) mark up 2) delivery fee 3) driver tip. Contrast this with Uber, who roll everything into a single fee that I never have to think twice about. At any rate, I never received any response from Instacart and I'm still not sure how to appropriately compensate the drivers. It's really disappointing that Instacart has both declined in quality and made it more difficult for me as a customer to understand them as a regular expense.

I would probably be better off just walking to the grocery store or taking a cab: at least then I know exactly what I'm paying for and can anticipate the rough cost.

We have plans to implement Python 3 support. It's not the highest priority but we want it to happen. I'll probably slate it for v0.6.0. By the way, community participation is more than welcome...there was a pull request that provided support for 3 but unfortunately it wasn't updated to bring it inline with the breaking changes 0.5.0 had to introduce. So, if you have any inclination to hack on a patch that provided Python 3 support I'd be very grateful and could probably even work alongside its development.

Not yet.

> All the same: OAuthLib and its libraries cover the exact use-case you've laid out

Nope. They very much do not: your expectation is that your users will roll their own clients or use Requests' shim, which seems a little rough around the edges and doesn't provide for the necessary use cases, e.g. OAuth 2.0 and Ofly. I'm sorry, but this is not providing for the use cases I've laid out by any stretch of the imagination.

Rauth is batteries included, ready to get you up and running in minutes, not hours or days. You won't need to write your own client or patch an existing client to make it work with an unsupported protocol like OAuth 2.0.

> I don't see OAuth1 getting simpler than that

Then you haven't used rauth. The whole auth dance is taken into consideration and various helpers make it a breeze, literally a two or three step process. Further, once you have tokens, it becomes as simple as:

    session.get('me')

Now, that's what I call simple.

I think in your attempts to compare your lib to rauth you're missing the broader thrust of rauth: rauth is a client library. It makes using OAuth (1.0/a, 2.0, even the OAuth-ish Ofly) as easy as we can make it. This is far removed from the goal of some generalized, spec-centric, even idealized, implementation of OAuth as a spec. Rauth isn't trying to do that, it's trying to make it easier for you to connect to Facebook or Twitter or whatever provider you happen to need. I wouldn't really know, but I've been told, it seems to shine in this regard. :)

First, I believe rauth existed prior to your library: rauth is over a year old now. (Or maybe existed at around the same time; regardless as you'll see below, contributing to your project wouldn't have made sense for us.)

Second, you're trying to solve a different problem than rauth solves: we needed a library that provided for the practical, de facto implementation of OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs. This is exactly what rauth does. It loosely wraps Requests, which means you get to basically use Requests that also happens to handle real-world OAuth providers as a consumer. I don't think it's really fair to call this "silly": it's clearly filled a hole in the ecosystem for some people.

If you want to consume an OAuth provider, rauth tries to give you a simple interface to do so with. It's almost as easy as using Requests. You might even say, it's OAuth for Humans. (Sorry, Kenneth. :)

Edit: to be clear, rauth is about pragmatic simplicity, about a clean API that's pleasant to work with. It's a client for OAuth modeled around the fact and philosophy of Requests. Vis-à-vis everything else I've seen, this is in pretty stark contrast to existing libraries.

Maybe you should try it?

> Google made a big mistake cancelling Google Reader that will have severe ripple effects to its empire.

Oh come on: enough already. Obviously there was a /vocal/ user base which is very loudly now upset that the product is being sunset. Guess what, Google didn't see it as a large enough set of people to make it worth monetizing. Such is life. Move on. It's certainly not the end of Google if that's what this article is trying to imply. It isn't even the beginning of some horrible backlash either. It is however getting old.

> I have a more serious problem with your offices. A lot of folks just like you build these great offices, lure people like me in, and then wind up getting jobs as architects working for someone else.

And the even more serious problem here, by implication, is that this is actually considered a valid business model: I start a small company, we build a decent product, end up with a few loyal customers and bam acquihired. It's a common enough thing to be a valid goal. You may call your startup a success, for example, if you happen to fortunate enough to have this happen to you and your business.

What a peculiar notion of success we've been developing!

> Mr. Musk not only apologized, he said the charging stations should be 60 miles closer together and offered me a second test drive when additional stations were built.

How interesting is that! Mr. Musk himself, noting his own perceived deficiency in Tesla's charging station network. Whether or not this is an admission of guilt, it certainly is quite interesting he would immediately offer a follow up test drive after additional stations had been built. Fast forward to Musk's blog post and it seems he's completely changed his attitude: now the fault is entirely with the journalists; now Tesla is the victim of an ill-intentioned agenda on the part of the New York Times...

I normally don't find these sorts of tutorials useful. But after reading these simple instructions I thought I'd give it a shot. Here's my feeble attempt:

http://f.cl.ly/items/003y1m2a0b2n0F1p2G3Q/lambda.png

Try on a little human emotion and sensitivity for size: this isn't your site to police. Even pg has pointed out the precision of the wording which you seemingly ignored.

No, it's not your fault. And this is just a mechanism of deflection.

Step back from your solipsistic convictions for five minutes and realize that your rationalizations here only serve the purpose of avoiding forgiveness. You have decided that not only are you not a victim but in fact you and you alone are responsible for everything and therefore you don't ever need to forgive anyone. Moreover you have now implicitly made the rest of the world victims. Hm...

I'm only surprised to not see any of Kenneth Reitz' work on this list, e.g. Requests. In fact in that vein is rauth, an OAuth client lib built on top of Requests (https://github.com/litl/rauth). Full disclosure: I'm the author of rauth. :)

Interestingly enough, Washington State's similar initiative, Initiative 502, passed as well tonight. It would seem momentum is growing around legalization. How the federal government via the DEA and DOJ ultimately handle these two victories for legalization proponents may be telling in regard to how close a national concensus is.

What I've read[1][2] in regard to this incident is that it is most likely a calibration issue: i.e. the touch screen is improperly calibrated and as a result is not selecting the proper region of the screen. Now this is concerning because it likely means other machines could be or are miscalibrated. However the important takeaway here is that this is not some malicious attempt to rig the vote. If that were the case the likely method would be completely invisible from the UI; why would an attacker bother to actually show a user they were being manipulated? Of course, they wouldn't.

[1] Joseph Hall comments here, also provides a link to further commentary by him: http://gawker.com/5958114/an-expert-weighs-in-on-that-viral-...

[2] http://www.theawl.com/2012/11/the-truth-about-voting-machine...

> I'm not sure letting this calibre of "journalism" and the people who lap it up slide is the solution.

So flag it and move on: if you must comment, you can do so sans ad hominem and still communicate your point.

I don't understand why a complaint about quality should itself be a paragon of lowered quality?

Do you think you could reframe that comment without the needless personal attacks on the writers and readers of the article in question?

It truly is disappointing to read comments like this. The content [of your comment] isn't abjectly worthless, it's just wrapped in unnecessary hatefulness that honestly does nothing to further a high quality of discussion. Can't we do better here?

I bought the game via the PayPal link but so far haven't received my copy. Not sure if this is related to the load on your site. In the meantime I'll play around with the demo. But I did want to mention that I hadn't received it yet as there are likely to be other people in a similar situation. Maybe it's worth putting a note on the blog post?

> A single person taking the role of director/editor/screenwriter is pretty much unheard of in the industry.

Wrong.

Let's take a very recent example (and note well, this is not at all uncommon outside of Hollywood, for instance Teshigahara's famous collaborations with author Kobo Abe) Paul Thomas Anderson, directed, wrote, and produced/edited (both the 65mm and digital transfer, in tandem) The Master. It is not at all uncommon for a director to at least collaborate with a screenwriter if not write the screenplay themselves. And most directors would like (although this is sometimes prohibited by the studios, e.g. in the case of Orson Welles) to have creative power if not direct control over the production and editing process.

However, even at this level of involvement we are a far cry from the claim that a single person is responsible for the film as a creative work.

For instance, you're missing a critical piece of the equation: acting. You could easily make the argument the job of an actor is as important as any role a director might have and ultimately it is the centerpiece of so much film as well as the final artist presentation. Even the most controlling directors have limited ability to hold de facto control over this aspect of the film.

Considering all the multitude of complexities of the process, the myth of this superhuman director here is a lot less interesting than the actual process of filmmaking, if you ask me.

First off it seems like there is a strange, specious simile the OP is trying to draw between a director doing some camerawork (note: Kubrick in that particular interview cited is only speaking of /handheld/ camerawork specifically because it's difficult to communicate the framing and such) themselves and an individual being able to do everything (within the scope of some discipline) themselves. Let's clear something up right now: directors who do some or all of their own camerawork are NOT tantamount to directors making a film by themselves. There is so much more that goes into making a film besides the raw camerawork. Even your average Joe will know this by proxy as big events like the Academy Awards highlight the complexity of big Hollywood productions and the many roles that individuals have mastered. Directors, e.g. Lars von Trier, will sometimes oscillate between doing all camerawork themselves and none of it. (In Trier's case he even experimented with allowing a computer program to compose shots in a completely automated way!) However none of this backs up the apparent assumption that this is equivalent to making the film wholly yourself.

That said I think this is a pretty weak and misleading analogy! We can give the OP a break here and say, "Sure I know what you're getting at." However, if you really want to get a strong point across, use a better analogy.

Finally, let me dwell on one passage in the posting that I find troubling:

> Lately it has started to feel like our society respects “vision” more than the actual craft of execution.

What is going through the OP's mind here? Execution is definitely the only thing that has ever mattered.