bkirkbri

Same here. I never understood why a paren on the left of a function name “looks like fingernail clippings” but to the right it’s “just how code works.”

Recently I’ve been reimplementing some sequencing patches using Scheme for Max and I can say it’s really a joy to use so far. Thank you Iain for making and releasing it. And documenting it!

As someone that loves what Max and Max for Live can do, but prefers a more traditional programming language when implementing complex logic, it really is exactly what I’ve been hoping for. And it’s a Lisp!

I thought it was a well executed joke myself.

I've found s-expressions to be one of my favorite things about Clojure. I understand that many people dislike them, and that many people get used to them, but I loved the syntax from the get go.

> Being born poor is obviously not a personal choice, but actions taken along the way (having a child when young), taking the risk with illegal and highly addictive drugs, committing violent crime, are conscious acts that unsurprisingly make it harder to get out of poverty. The consequences of those actions is likely particularly known in lower income areas.

I was raised with the same belief, however I have learned through broader experience that people from varying backgrounds have vastly different ways of perceiving and evaluating the information in front of them. I do not mean this to indicate, for example, that people in poverty are inferior and incapable of logically assessing the consequences of a teen pregnancy.

Rather, I would suggest that you and I were likely privy to a myriad of small, incremental and beneficial teachings and experiences that led to our view of teen pregnancy. As a result I believe it unwise to judge others, who did not have the privilege of those same teachings, based on the assumption that they knew the "unsurprising" "consequences" of their actions.

LWT's channels look more like filehandles. I think the GP was asking about channels in the CSP sense. It looks like LWT has that too in the form of streams.

If only the JVM could take advantage of this.

Exciting! I was looking for a ClojureScript monad library just last month. Can't wait to dig in to this one.

I think there is a lot of potential to help with the complexities of asynchronous failures.

We tend to take an in-between approach, baking base AMIs as needed but configuring and installing code with Ansible at boot time. We've got scripts to cut tarballs with an Ansible playbook plus support files from any tag in our repo. Then it's just a matter of specifying the tag in user-data when starting an instance. We do that through CloudFormation.

edit: grammar

This approach has been really helpful for us. We recently open-sourced our Clojure library[1] for running React on Nashorn (the Javascript engine in Java 8). Currently it consumes Hiccup-style markup, but we hope to add Enlive- and Om-style interfaces in the future.

[1] https://github.com/OtherPeoplesPixels/curmudjeon

I've been dreaming of this since Datomic came out. I recommend it to our AWS account rep every chance I get.

Looks really promising. We're using HoneySQL now, but OJ might be even lighter.

Right, but to be clear: I don't believe that only masculine men deserve authority. I think our species' slow evolution from violence as the single source of authority is possibly the most hopeful development in our history.

I have a pet theory that the reason that women (as well as non-traditionally-masculine men) are considered bossy, while other men are considered "go-getters" is due to a lack of the threat of violence. Not that a type-A guy is going to assault you if you don't capitulate to their authority. More that there is a perceived or possible threat.

In contrast to women who would be considered bossy or abrasive because they don't "back up" their claims to authority. I suppose that there is often a feeling of resentment that society/culture/custom is taking the place of that threat.

Again, all supposition and musing on my part. Probably much better articulated by someone writing on the subject 50 years ago!

Exactly. I'm always confused when someone suggests that paying off a mortgage is stupid. Sure, 5% return on mortgage money borrowed at 3% is profitable. But there are many assumptions here: how sure is that spread? Can you pay your mortgage each month if the market tanks? How large is the spread when investment is no longer hypothetical and within some risk tolerance? How much tax are you paying on gains?

To be clear: I do not mean to imply that GP is making such a bold and unconsidered claim. Just that I've been hearing them a lot lately.

Because we live in a world that is not homogeneous and are all enriched as a result. Ending up as one's own version of Howard Hughes, locked in a room with a gun and a pile of money, is unappealing to me.

Agreed. Over the past 9 years I've had to implement double, triple and end-of-the-month checking on PayPal to be sure that we have some reconciled idea of reality with respect to payments.

What's worse, their system essentially rewrites history over time. This means that rather than keeping a ledger of payment events, they change the dates and amounts depending of payment status / reversal /etc. Querying later in the week and the data is different. For the same charge.

I ended up keeping an event log of everything we ever get from them (IPN, API polling, reports) and synthesizing that into a current snapshot at query time. The code is riddled with comments saying, essentially, "this charge, then return, then recharge and failure means that the payment is OK".

We've had good luck with DynamoDB, but it could be that it just fits our use case very well. What sort of frustration were you running into? (Honestly interested to avoid trouble down the line)

I actually learned about confd via your post. Thanks for that.

In our case, HTTPS isn't an issue but there are good arguments for using a tried-and-true proxy. I see Vulcan as a quick way to test out docker containers for our architecture.

In the end I'll probably use confd to rewrite a VCL file for Varnish. It's just a matter of deciding how many containers and what level of sidekicking/ambassadoring I'm willing to put up with to "properly" organize things...

Yes, confd was on my radar and looks promising. In my case, we've already got a wad of perl duct-tape out there and adding etcd was a baby step. Using confd would have been a later step.

Vulcand will likely allow me to replace the whole shebang in one step.

What great timing! I was just about to roll my own using etcd, haproxy and a bunch of perl duct tape.

Very excited to take a good look at vulcand.

It's not crazy, it's realistic. Nothing is free and this sort of pragmatism lets/forces users to act like grown ups.

updated: grammar fix

> What's he want, more rent control?

That's one option.

> To put "the 1%" 'up against a wall'?

That kind of hyperbole is unwarranted given the very reasonable tone of the article.

> What is this article other than a whiny complaint, pandering to the envious masses?

I'd call it an astute observation by a creative, intelligent person about the city in which lives.

> If you're raised by a pack of wolves in the woods, you'll probably be rock dumb by all measures, regardless of your DNA.

Depends on how you define "dumb". I bet you'd be insanely good at hunting and eating enough prey to survive the winter.

Bill, I have the utmost respect for Braintree. But if this rumor is true, all I can say is "famous last words." PayPal have demonstrated an inability to operate competently.

And we just notified our entire customer base that they can kiss their Paypal problems goodbye because we've switched to Braintree. How does that look now?

I have my fingers crossed that this sale does not go through.

It's true that out of the box core.async is MUCH nicer to use with existing asynchronous IO APIs. My limited experience has shown that you'll want to wrap your synchronous IO operations to play well with core.async. This generally means queueing work in an operation-local (or subsystem-local) threadpool and providing an async API for interfacing with via core.async.

The next step is deciding on how to expose the asynchronicity. I chose to accept / return channels rather than callbacks, because... well... wrapping your sync code in a callback-based async API just to glue them together with go blocks and channels seemed backward to me. :)

I think this "next level up" from the foundation of core.async has potential for some really great solutions and I'm dying to see what Tim and others will come up with...

I've enjoyed working with core.async once I understood these constraints. It would be nice for code to "know" whether it's within a go block or not. That would alleviate needing do-something! and do-something!! versions of some functions.

By "know" I mean something like an in-go earmuff var.

EDITED for clarification and formatting

I believe that core.async leverages Clojure Protocols to enable you to use whatever back end implementation you like. The Quasar guys just implemented those protocols.

I think this is insightful. Benefits of ClojureScript like namespacing, functional primitives and client/server code sharing can be attained via other, easier (though not necessarily better) tools in the JS ecosystem.

Of the things that you mentioned, I'd wager that core.async will be the captivating feature for ClojureScript. David Nolen's excitement is a good gauge. If that increases adoption significantly, it's my hope that ClojureScript's other benefits keep the fire burning.

Using core.match with core.async does sound promising! Am I correct that Erlang-style selective receive would NOT be possible?

I don't see this as much of a downside though, considering the issues one can have with selective receives.