The Pittsburgh Java User Group has not been meeting regularly for some time now. The last meeting was almost two months ago. I attended this one with the impression that it might well be my last attendance of the group, and even more, that it might be the end of the group altogether.
Programming meetups aren’t just about presentations and coding. Abby and I joined others in meeting up for dinner for a joint Pittsburgh Ruby and Pittsburgh Python social and enjoyed relaxing and socializing outdoors in Bakery Square. Although it perpetually looked like it was going to rain, it turned out we weren’t really rained on.
Carol, Andre, and Abby:
It was fitting that there was a joint social for two language communities, because we live in a polyglot world.
Despite my original intention not to engage into any tech-related conversation, I couldn’t help remarking on my current polyglot responsibilities at work at CMU on the METAL project!
Read On →
Originally, I was not going to present anything, since I did not feel that I had anything exciting to quickly share (I have not been doing much Ruby programming lately at all other than debugging my Octopress-generated blog), and don’t like talking just to talk.
But at the very last minute, just half an hour before the meeting, I noticed some developments in the world of RSpec announced on Twitter by Jim Weirich, and I got excited enough that I decided to talk about his rspec-given, which was just released at version 3.0.0.
I’d met Richard earlier, a month ago at Pittsburgh TechFest. He does not claim to be an expert at functional programming, but is enthusiastic about concepts and techniques that he can and does apply to improving software quality in many dimensions. Since I have been a functional programming enthusiast and practitioner for twenty years, I had these goals in attending his presentations:
evaluate what Richard and others have done with, and think is important about, functional programming
offer a few corrections, elaborations, suggestions as appropriate for the situation
gather information on how I may be able to effectively explain functional programming to those who are new to it
Jun 30, 2013 · 1 minute read · Comments pragmatismJavaScala
I wrote a post on my personal blog about my being a “pragmatist”. I mention it here because few words are as controversial, I think, in the programming community, as “pragmatic”. I wanted to be on record as identifying myself as “pragmatic” despite the negative connotations, because the entire mindset of this new programming blog is pragmatic. For example, I will soon write about the realities of programming language choice, including why I used Java, despite its deficiencies, for a decade, and why it is not going away, and why I currently am an advocate of Scala, one of the most ambitiously pragmatic languages to have come along in my lifetime.
I mentioned in my initial post for this blog that I have had some problems with the software I use to generate my personal blog, Octopress, and was thinking of migrating to a different platform that might in some ways be more robust to such problems. I ended up not doing so, and I still stand by that decision, but I just yet again ran into a problem with Octopress.
Here I report on how I figured out the problem and begin a conversation about the nature of error handling and API design.