HN user

pigs

156 karma
Posts6
Comments32
View on HN

Yes, significantly upping the ulimit would have probably been sufficient for all practical purposes, although we might run out of JVM heap space if we are up long enough. Plus, it really bothered me that I didn't know what was going on.

There were only two threads stuck, so monitoring the threads wouldn't have set off any alarms. One was a Clojure agent thread, which basically allowed all the clients marked for retirement to queue up.

I used both Yourkit and Java Mission Control for monitoring the JVM. They both have some functionality of deadlock detection, but it did not flag these two threads. Yourkit identified these threads as waiting, not blocked, but I'm not sure how it makes that distinction.

Damn, this is sad. I'll echo the other comments here that he was a nice guy. I was an undergrad at Duke circa 1999-2000 and knew him through the Duke LUG. I was a noob, and he always showed a fair amount of patience with my questions on the mailing list. Later on the LUG started meeting for beers on Friday afternoons and he was just as friendly in real life. He was one of those guys that seemed like a computing god for me so early in my career.

Very well stated. A few months ago I wrote a post on my company's blog pushing Clojure, and the ideas just seemed to flow. Now I'm getting around to writing a specific post on ClojureScript, and even though I love writing cljs code, I'm having a hard time making a convincing argument to others. There are however a few things that still stand out about ClojureScript I think, but I don't think they are mature enough to qualify as a killer app, but mostly just something to pique the interest of a certain class of programmers.

One is the port of core.logic. AFAIK there is not a comparable Javascript logic library, although the ClojureScript port does not have all the features of the Clojure base.

Another novel feature is integration with nrepl via the piggieback library[1]. This allows you to evaluate ClojureScript code directly in your running web app if your editor has nrepl connectivity. Again, I don't know of a way to do this with current Javascript tools. But here again, the solution still feels like it lacks maturity.

I don't understand enough of core.async to really comment, but the excitement around it seems to point to another rather exclusive bit of ClojureScript functionality.

[1] https://github.com/cemerick/piggieback

OSX For Hackers 14 years ago

I know OSX does a lot of things right, but focus follows mouse and copy-on-select/paste-on-middle-click are two things that I can't live without.

I've been using Clojurescript with a Noir backend to build an internal tool for work, and I thought I'd share my experience so far. Some background: I'm a Java guy by trade, this is my first FP language, and I'm not that well-versed in Javascript. In general, I've found the whole experience to be rather fun. A bit of a learning curve for sure, but once I ramped up I felt really productive. I don't feel like I get stuck as much as other times when I've tackled a new framework/language. And the nature of the language lends itself to just start writing functions rather than get caught up trying to abstract everything. I feel like my code flows better, is easier to refactor, debug, etc. Clojurescript may still be considered new/beta/cutting-edge, but I never found it to be buggy or frustrating to use. A few minor things I got hung up on:

goog.dom.query - This isn't included by default, I'm guessing because it's a third-party wrapper around dojo.query. I had to follow a few threads on Google Groups to figure out how to include it. Another option is to use Chris Granger's jayq. But there's no way to do CSS-type selector queries by default (that I know of).

Converting between Javascript objects and Clojure data structures - I had to scratch my head a bit the first few times I ran into this, but there are lots of code snippets on Stack Overflow and various other places around the web. I was able to quickly develop a few reusable idioms to handle this.

Lazy sequences and side-effects - people with more experience in FP might not have gotten stuck on this, but this was another head scratcher for me. Basically any type of DOM manipulation is a side-effect, so if you're app relies on that, you'll need to occasionally force evaluation of a lazy seq.

The browser-connected REPL takes a few manual steps, but it's well documented, and extremely useful. It's just not as easy as running "lein repl". The default compiler is not integrated with lein either, and is not automated, but lein cljsbuild is available as Kevin mentions. I ended up using Chris Granger's cljs-watch.

In any case, if you can't find it through Google, it takes all of about 15 secs to get your question answered on #clojure IRC.

My current setup includes VimClojure and a browser-connected REPL in my terminal. I'm using Noir on the backend, and the included Google Closure libraries on the front-end. I tried to minimize the number of additional dependencies (perhaps irrationally), so I opted out of using the remotes from fetch (formerly pinot), and just used goog.net.XhrIo calls to the noir backend to acheive a similar effect. I did find the crate library to be perfect for dynamically creating DOM objects. You can write something like [:form [<form body...>]] instead of "<form> <form body...></form>", and it's nicely highlighted with Clojure syntax. For debugging, I just use Chrome's debugger. It's compiled JS, but it's easy to figure out where you're at. All of your functions are at the bottom of the script. You're not going to have a lot of state to track in the actual Javascript either, so most bugs are easily sniffed out, at least in my somewhat simple app. Sorry for the long post.

I've spent the past few days trying to implement a little utility app in Clojure/Clojurescript for work, and here's some of my initial impressions. I've been going back and forth between the approach explained in this article and the Clojurescript One workflow. Disclaimer: I'm a bit of a Clojure noob and primarily a backend guy, although I have some experience with jQuery.

- In Noir I was able to make the jump from "getting started" to "building my own app" fairly quickly.

- After getting a somewhat-viable backend, I hit a pretty steep learning curve trying to figure out how to hook in some Clojurescript.

- I started looking at Clojurescript One, however, I've found it to be a bit of a firehose. I'm intrigued by their development ideas, but I ultimately just want to pick and choose a few things that I can integrate into my existing Noir backend. The Clojurescript repl is pretty sweet though.

- I think I might just use the Domina library in isolation, and use the cljsbuild approach in this article. I will try to revisit Clojurescript One later as I gain a little more experience.

The crux of the argument (and most of the book for that matter) is that you want to avoid mutability whenever possible. Adding setters for every field by default means mutability is the default mode for your application. Adding getters for every field by default means you lose any advantages of encapsulation. At one time, Java Beans were a heavily marketed pattern by Sun. Joshua Bloch came along and said "hey, this is a bad pattern" (and maybe others, but he's the one I always think of).

"In Java, it's considered best to just go ahead and add the getters and setters first"

I don't think this is true. I'll concede that it may be a requirement for certain things like an ORM API, but in the general case, it's bad practice. The mere act of adding a getter violates immutability.

"I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future."

Is this a controversial stance? It seems like common sense, unless I'm misunderstanding something.

EDIT: To clarify: I assume he's saying "don't add accessors by default for all private members unless you need to, because you can always go back and add it if you really need it", which is common sense for any project, external or internal. I'm pretty sure he's not saying "don't add accessors, just use public members", which is controversial, IMO, even for internal projects.

In my experience at a big business, technical skills alone are not sufficient for "be treated with respect, get paid well". It takes a certain amount of shameless self-promotion and other skills normally associated with politicians. The nice thing is that you can do your boring 9-5 in two hours without anyone noticing, and spend the rest of your time preparing for a better job.

Perhaps I wasn't clear, but I was referring specifically to the aesthetics of the typeface. Good code in monospace is no less beautiful than good code in font X.