I was down with severe cold and cough pretty much all of this week, and so have managed to accumulate a lot more goodie links this time. (Yay? Yay!)
This post talks about how “print” debugging is a sign of bygone age, and how we can do better with advanced languages and tools. According to author, “code as data” has a potential to be the biggest enabler of better debugging. And many other things. Look at the last paragraph of the post. It has pointers to so many gems of examples of the sort of things “code as data” can enable. In my opinion, the last paragraph weighs more than the rest of the post! Don’t get me wrong. The post is great. It’s just that the pointers in last paragraph are so, so exciting!
By the way, wondering what those s-expressions are doing in the strings? You may find your answers here.
I mentioned this in passing in my last post in the series. I went through it, but have no immediate willingness to cook up a Lighttable plugin, so didn’t retain much in that reading. Based on a second hand account from Aleks though, the tutorial is good, but will leave you wanting for more. That’s a good kind of thirst to have. Luckily for you, we can probably expect a wave of Lighttable plugin tutorials being published in near future.
Just had a cursory look. That too only at the lecture notes. Follow at your own peril. (Two kinds of perils here I am talking about: 1. I am no expert on the subject, and don’t guarantee the quality of content. 2. The rabbit hole may take you so deep down that you might forgo everything else in your life.)
Compiler optimizations don’t have to suck. Let the good folks at EPFL explain to you how! Lightweight modular staging is a novel approach to the problem of optimizations. This paper was first shown to me by Mushtaq, and I was recently reminded of it thanks to some tweet. (Sorry Mr/Ms Tweeter! I have lost your reference.)
A collection of nifty macros. Optimized for-loops, nice-ified beans, JavaFX DSL, concise extension methods, and more.
And this one.
Somehow pretty-printing doesn’t seem to be all that popular in the static typing community. This surprises me. It’s good to see some libraries coming up to address this need.
Fun read. Illustrates with lovely examples how types and algebras can drive your design. Joy, correctness, and a sense of accomplishment are things that you’ll receive in the end.
An “extractor” is Scala’s attempt at generalizing pattern matching to non-data-constructors. As of version 2.10, any object that defines one (or more) of the following can be used for extraction:
(Where do those
B’s come from you ask? Well, it doesn’t matter. No, really. Scala doesn’t care about that and gives you a full liberty with regards to where you can get them from. You could use type parameters from any enclosing scope, type parameters on methods themselves, or even concrete types.)
2.11’s name based extractors is an attempt to generalize these signatures further. Heiko’s article will help you understand how.
The generalized form uses the kind of typing which is not quite typing - Desugar things as per rules and then see if the final form compiles. The for-comprehensions work the same way, and I am ambivalent about that.
Anyway, this improvement is largely aimed towards performance. You can downright ignore it if you don’t care about that.
Paul Philips, a valued member of the community, recently decided to walk out of Typesafe. And probably out of the whole Scala landscape. He said he made this decision because he “lost faith”. This talk will give you more insight into that. It also has some fair criticism of Scala collections library. A must watch if you do Scala.
This threw me in utter shock. Your decades old language is getting maps now?!
A twitter acquaintance told me Erlangers have been using association lists for the purpose. There also exists a map module, and that’s used to. If that’s the case, I think it’s more fair to say that what Erlang got now is just a literal syntax for maps, with some nifty pattern matching support. That would be less of a shock. Also, the Clojure influences are evident. (To my eyes, at least.)
A very interesting discussion. The theme is use of inheritance in collections (or pretty much anywhere else), the perils of it, and the potential improvements. Also lurking in there somewhere are some best practices to follow when using inheritance.
Some seem so pissed that they’re calling for its death, while some think it isn’t really a culprit on its own. My position? I find subtyping simple to conceptualize and build software around. I haven’t run into any major problems with it. I’ll throw my tantrums if/when I do.
In their own words (slightly paraphrased), “OData is about providing a uniform way to expose, structure, query and manipulate data using REST practices and JSON or ATOM syntax to describe the payload. It also provides a uniform way to represent metadata about the data, allowing computers to know more about the type system, relationships and structure of the data.”
What surprised me was that the protocol was first defined by Microsoft, the devil behind many common proprietary formats. Talk about irony. (Or hypocrisy?)
The site is down half of the time. What a shame for something centered around HTTP and REST.
This got a bit monotonous, right? Here’re a couple links to lower the tech quotient and add a different flavor to the post.
A philosophy comic. Delves into a complex muddle of will power, obedience, and pleasure. The reading will end in one of these: epiphany, annoyance, or mindfuck. (That’s how they roll, these philosophy majors.)
Colors and symbolisms have fascinated me since childhood. This paper was an interesting read to me.
That’s all. Yeah, that was a lot for one week!
In other news, I finally got a hard copy of SICP as a gift. (Thank you, Mahesh and Bhushan!) I am going to have to take great pains to not tsundoku this book (like many others). Wishing on a star the days would be longer and I would show more commitment.
This blog post was originally posted at my Blogspot blog at this URL.