Video: 15-Minute Chat with lift-ng

This past Friday, I recorded myself practicing the short version of my presentation of lift-ng, and I thought I’d share with my blog followers. I used a Google+ live hangout to record it, and I now see that the first few moments are not recorded, which is why the video starts in the middle of a sentence. Nonetheless, the video looks/sounds quite good and it prepped me well to present it in Santiago. Enjoy!

Tagged with: , , ,
Posted in Software Development

Why a JVM on a VM?

This morning during my workout-procrastinating flip through my twitter feed, I came across Thoughts on Five Years of Emerging Languages. It is a fairly quick read which takes an interesting angle on the rather pedestrian set of language features implemented in Go as outlined in this article. It was certainly thought-provoking and has me reconsidering my disregard for Go. But that is a topic for another blog post.

Shortly after I retweeted that article, my mutual follower Gerbrand van Dieijen pointed out something that didn’t immediately jump out at me during my first reading:

That is an outstanding question. I’ve long believed in the value of hijacking the JVM despite the impedance mismatches languages like Scala and Clojure encounter. But for most of the past year all of the code I’ve shipped has been deployed in AWS on a VM. What’s the value in slapping a VM on top of that? All I need is something that runs on Linux that I can ship in Docker.

Recent developments in the Scala community certainly show the cost of running on the JVM. Typesafe’s plan for Scala 2.12 focuses on Java 8 interoperability. This of course has lead to the infamous forks of the Scala compiler. I’d wager a handsome bet this wouldn’t have happened if we weren’t paying the technical debt of our alien invasion of the Java virtual machine.

Neither Gerbrand or I are about to abandon the JVM, of course…

Although I’m beginning to understand what Brian McKenna meant by “mass delusion” of the value of the JVM, abandoning it would certainly be throwing the baby out with the bath water. One nice thing about the JVM in particular is getting to leverage all of those extant libraries. I’m not interested in a new ecosystem where everything has to be rebuilt like in Go. However, any well-established languages outside the JVM garner much more of my attention now. Haskell, anyone?

Tagged with: , , ,
Posted in Software Development

JavaScript is NOT a functional language

This humorous tweet garnered a plenty of attention early last week, and I confess I contributed to the virus with my own retweet. While I’m inclined to concur with the sentiment, I’m not completely comfortable doing so. To chose a side in the discussion implies not only that functional programming is a well-defined paradigm, but also that it is a Boolean property of languages. I’m not so sure we’ve all agreed what functional programming is, nor can we say that a language wholly is or isn’t functional.

My stance is the statement is neither true nor false, at least in the way it was meant to be interpreted. I certainly agree that JavaScript is more functional than, say, Java (especially prior to version 8), but it is also much less functional than the golden standard Haskell. Notice that I am making comparisons of the languages relative to one another, rather than partitioning the languages into opposing camps. I personally believe this is the best way to view a language’s place in functional programming as a position along continuum with imperative on one end and functional on the other.

On one end we have languages which we all agree aren’t functional, such as Small Talk or Pascal. The other end of the spectrum features the heralded functional language greats Lisp, Erlang, Haskell, ML, etc. What I find interesting is what lies in the space between those two. Some languages have properties which are certainly characteristic of the functional languages, but the language itself isn’t typically regarded as functional. Languages like Java are adopting features of functional languages making itself more functional. At what point does a language cross this mystical threshold?

Not only do I believe this should be regarded as a continuum, I believe there is a better question to ask when judging where the language lies: How much does this language help me write in a functional programming style? Let’s face it, Java will fight you to the death if you want to be functional, but the advent of lambdas and powerful libraries like Google’s Guava allow you to be quite a bit more functional than classic OOP Java.

What properties help us write in a functional style? A few that immediately come to my mind are (1) treating functions as first-class citizens, (2) declarative constructs, (3) bias towards immutable data, and (4) control over side-effects. This is by no means meant to be exhaustive, but properties like these ultimately combine to allow programs to achieve referential transparency, which is arguably the most important property of a functional program. This allows the developer(s) to reason about the program. The more a language favors these patterns as the idiomatic approaches to programming, the further towards functional programming end of the spectrum we should regard it.

Back to JavaScript, which is the title of this post. It does very well in the first property I feel we need, which is treating functions as first class citizens. However, it fails miserably on the next three. Many languages like Java at least give us a final key word, but everything is mutable in JavaScript. That’s not to say that you cannot write a program which does not mutate the data. It just means the language is not on your side to help you accomplish that goal. Hence, it makes sense to write an outstanding book like Michael Fogus did with Functional JavaScript. Yet the reader should be aware that it will take much discipline to retain the ultimate goal of referential transparency.

Another thing to notice is how some languages need libraries to allow the developer to write in a more functional style. I already mentioned Guava for Java. The Functional JavaScript book utilizes underscore.js. This shows me that sometimes a language needs a little help to be functional, but it can be done.

Perhaps also of interest is how much a language will allow you to NOT be functional. For instance, Scala is widely regarded as a functional language. Yet you can write some very filthy imperative code thanks to var declarations and easy-to-reach side-effecting calls such as println. Compare that to Haskell which requires you to rope off the entire function with caution tape like a crime scene to allow an I/O operation to occur. Hence, we could use this to say that Haskell helps developers write more functional code than Scala.

So I guess I agree that JavaScript isn’t a functional language, but only in the spirit that I don’t think it makes a lot of sense to declare languages as such, one way or the other. Rather we should make statements like “JavaScript helps me write in a functional style more than Java, but not as much as CoffeeScript which allows me write with more declarative expressions.” Even my most recent post has me regarding my ideal language as being functional. However, I think from now on I’m going to adopt the verbiage of stating how much I believe a language helps me write functional-style programs. I suspect this mentality will be more useful for discussing programming languages. It strikes me as being a little more objective therefore less likely to spark passionate-yet-pointless arguments about language design.

Leave a reply below, or send me a tweet.

Tagged with: , , , , ,
Posted in Software Development

If I were writing a language

I’ve never honestly put thought into what I would want in my own language until recently. For years I wore blinders while working contently in the world of Java. However my shift to Scala and full-stack development over the last two years has exposed me to a little of the world outside. I doubt I’ll soon find time to dabble with language design. But if I did, here are the features, concerns, and priorities I’d pursue.

Functional

My language would be functional, of course. I don’t know that I would attempt the OO hybrid that Scala has going on. Polymorphism indeed has its problems and I don’t want to deal with those. Clojure’s ad-hoc polymorphism is very intriguing, and I just don’t feel that data needs to be hidden. Functional is where the future is, and frankly it’s how I like to code.

Static typing

Yeah, duh. If you follow me at all, you know how I feel on this topic. I’m curious if this makes the language more difficult to design and implement. It seems obvious that it would given that it’s one more responsibility of the language. On the other hand, perhaps those guarantees buys some nice properties further down the line. Regardless, I’d like my resulting language to have the fantastic properties afforded by static typing. Seeing it done well in Scala and taken to the next level in Haskell makes me believe it’s well worth the cost.

Compilation targets

If I’m gonna write a language (and I probably won’t) I would shoot the moon. There is no silver bullet in software, but I wouldn’t let that stop me from trying to write the language to rule them all. In my web-oriented mindset, this implies compilation to multiple targets so it can be used anywhere. First, I’d target the JVM. It is a very impressive piece of engineering and would open up many platforms. In particular, it would be viable as a backend language and as a mobile language on Android. The second compilation target would of course be JavaScript. I’m still not a huge proponent of JS compilation, but the idea of compiling to a limited and optimized subset of JS is attractive. Although JavaScript has it’s good parts, it is absolutely riddled with filth. Frankly, there is no getting away from it in our browser world. I would also be keen on compiling to some native, perhaps LLVM would suffice. Ultimately, I just want it to compile to something which can run on iOS. Then all of the bases would be covered.

Web-readiness

In keeping with the previous section, my language would need to be web-ready to every extent possible. Compilation targets of the JVM, JavaScript, and LLVM are for web-readiness. The trickiest part will the the FFI, of course. I think I would prioritize great FFI with JavaScript/JSON. I know it runs against the static typing grain, but I really dig the simplicity of JavaScript objects. They’re all just a map. What I want is a way to be type safe, yet be able to utilize JavaScript objects with a native feel. I really don’t know how this would pan out. What I want to avoid is what we have in Scala, where we have case classes for our server-side data, then (assuming Lift) we have our JsonAST objects and the translations in between. What I imagine is something like all objects having a constructor which takes a JSON and instantiates the class. How do I reconcile that with static typing? No clue. Perhaps JSON-ready objects would be a special case of object. I’d have to play with it.

Also for FFI and interoperability, I would definitely make those calls safe. Scala’s interop with Java is super smooth and easy, but it leaves much to be desired by letting all of Java’s exceptions and nulls leak in. In my language, any calls to Java or JavaScript APIs would be wrapped in a monad like Lift’s Box which can be Empty (analogous to Scala’s None), Error, or Full[A] containing the result you hoped for (analogous to Scala’s Some).

Is Purescript close enough?

Perhaps so. I’ve been intrigued by Purescript lately, but have not committed any time to try it. It is strongly, statically typed and influenced by Haskell, so I know it’ll hit my first two items. It compiles to Javascript, and understand that the semantics are close to JavaScript. I’m optimistic that the FFI would be pretty good in that case. I’m not the first interested in a JVM compilation target either. I stay pretty busy in my free time as it is, and I’ve only made it worse by recently becoming a Lift committer and writing articles for NFJS Magazine. I’ve at least taken the first step and purchased PureScript by Example by Phil Freeman.

Those are a few quick things I would consider anyway. Most everything else about a language such as syntax and such isn’t that important to me. I just need these couple of things to build what I like building. What about you? What would you want in your own language? Or what languages do you think come close to what I already have in mind?

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , , , ,
Posted in Software Development

On naming

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

At work a teammate and I have a long running joke about how we disagree with identifier naming. He favors long “descriptive” names, and I like short terse names. We never get angry over this disparity in our views, and mostly find good compromises during code review. As long as I’m not working alone, I’m more than willing to lay aside my preferences for the greater good of the team. Yet these past few days, my bias towards shorter names has been triggered into some passionate responses.

The most notable was a recent podcast from Functional Geekery featuring an interview with Adi Bolboaca. In this episode, Adi is discussing his experiences leading code retreats with host Steven Proctor. I really got worked up when Adi was speaking of how he battles functional programmers and their short naming. His claim is that descriptive naming was a principle of clean code which transcends paradigms. I just really felt that he got that one wrong.

But why? Why I do I feel strongly about using shorter names? I’ve put some thought into it and I’ve identified a few factors. Firstly I was a math geek before a software geek. I’m not talking about that math minor they forced you to get with your CS degree where you’re playing the role of the computer and not the mathematician. I’m talking about the “advanced” mathematics courses where the focus is on clearly communicating abstractions. I can’t quite recall names longer than a single character in my math courses. We’d rather reach into the bag of Greek letters to retain the brevity. If a second letter is introduced, it is as a suffix to indicate something else significant. Not a character is wasted. The reader is expected to apply the short names to abstract concepts and roll with it.

Fast-forward to the present where I am now engrossed with functional programming. This paradigm is far more closely related to the discipline of mathematics than traditional imperative programming techniques and theory (if any such thing exists). Given that functional programming is much more like math lends credence to my feeling that “clean code” applied to functional programming doesn’t carry long identifier names with it. Terseness is part of the paradigm. One can even argue that long variable names are an anti-pattern. I think it’s just the unfamiliarity of our Reverse Hungarian notation that led Adi to believe the principle still applies.

However, I feel I can lay aside the relationship to mathematics and it’s use of terse naming in route to understanding the underlying reason for my preference of short names. It all goes back to my attitude towards commenting code. The computer doesn’t care what you name things. The names we use are of importance to human reader of the code. They’re glorified comments. Names which are public and hence get included as part of an API and its respective documentation are certainly important and should carry meaning. Names which are internal to the code are mere comments attached to code artifacts. As I stated previously, I agree that the only useful comment is one that answers the question Why?. The name of an identifier never answers Why?. Rather, it always answers What? and often the context of the code has already answered this question, rendering the name redundant.

Perhaps the most classic example is the good ol’ loop iterator i:

for(int i=0; i<=10; i++) {
    System.out.println(i);
}

Developers worth their salt never use a verbose name like index for an iterating index such as this. The context and structure of the code already tell us that this is an index. By having the shorter name, the operative properties are more pronounced in the construct. That is, the start value 0, the stop condition <=10, and the increment expression i++ are quickly and easily identifiable. Longer names such as index, currentIndex, or indexOfTheLoop clutter this up and distract from these three vital pieces of information. Given that these three dictate what the code actually means versus what the author of the code thinks it should mean, I’m strongly inclined to prefer the more concise version.

In fact, functional languages like Scala take this even further. This construct is so common, we don’t even need as much clutter as the simple example above gives us. We compress it down further to the following.

for { i <- 1 to 10 } {
  println(i)
}

We see that the most important information in this construct is even more prominent: the start value 1 and the stop value 10. Incrementing by 1 is so common, it’s assumed unless you tell it otherwise. Don’t confuse this for more of my Scala evangelism for the Java oppressed. I’m pointing out that the functional paradigm’s embrace of terseness behooves us to reconsider what is regarded as clean code. I believe this results in those who have not adopted this paradigm erroneously believing the best practices transcend. The principles certainly transcend, with code readability being the principle in this discussion, but not necessarily the principles. I’ll go even further and argue that shorter names works well for imperative programming too, just as the for loop above suggests.

So what are my underlying principles with naming?

  • I believe that name length should be roughly proportional to scope size. The i in the above examples is a good specimen of a name with a tiny scope, and hence a tiny length is appropriate.
  • The name length should be inversely proportional to its frequency of use. A name that is repeated constantly through code needs to be short lest we introduce an epidemic of carpal tunnel. A frequently used name even if terse will be well understood. A great example of this is Lift’s S.
  • Don’t repeat the construct in the name. This is why we needn’t include “index” in the above name, neither should “accumulator” be used in a fold or reduce expression.
  • Don’t clutter the name with the context of the name. If you have a class named BankAccount, don’t use accountBalance. “Account” is already there, just let it be balance. Or if you have an actor, don’t name it’s internal state as currentState unless you are distinguishing it from other states such as previousState. Just let it be state.

Chances are good that I’m wrong that longer names are detrimental to readability. At least that was the consensus on twitter. If you take nothing else away from this post, let’s at least agree that longer isn’t always better.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development

ÜberConf Days 3 & 4: Hits and Misses

The last two days I hit some great sessions and some blah sessions. As I mentioned in my last post, my favorite part about this conference has been the people I’ve met and not the sessions as much. The third day I really saw that it can be tricky because although you can respectfully bail within the first five minutes of the presentation, I haven’t been able to decide if it is a miss until I’m in too far to make a switch.

Fortunately the day started off awesome with Matt Stine applying Uncle Bob Martin and Michael Feather‘s SOLID OOP principles to functional programming. As Matt pointed out, principles are universally true, and hence there should be no reason we cannot apply SOLID to functional programming. He did a fantastic job of demonstrating these principles with some Clojure code that I was able to mostly understand. The coolest part of this presentation was towards the end when he brought up the notorious Simple Made Easy keynote by the venerable Rich Hickey, and defined each of the SOLID principles in terms of complecting stuff that should be separate.

After such an outstanding talk, I thought I’d hang around and enjoy Matt’s next talk, Programming with Immutability. I should have read the overview/slides before this one started because it was all Java. Granted I still enjoyed the topic, I probably could have found something more relevant for me. Once he got into some details of different libraries to aid Java developers in adopting more immutability, I caught a severe case of disinterest and worked on yesterday’s blog post.

The next talk I attended was another dose of Nate Schutta titled You’re an architect… Now what?. I thought this would be a good one given my previous experience with Nate and my still-recent entry into the world of architecting. I came out of this talk quite reassured about how I’ve been approaching my opportunity.

After lunch I caught Rob Spieldenner showing off some of Netflix’s cloud goods. As much as I really enjoyed hanging out with Rob and Dan Woods from Netflix, this was not the talk for me. In a nutshell, it was a workshop on AWS using stuff that Netflix built because they don’t use Elastic Beanstalk. Although Rob did a fine job with the workshop, it just brought me back to how much I don’t enjoy the AWS aspects of my job.

I had no qualms skipping the second half of the AWS action for some scaling agile action with Esther Derby. This talk was probably better than I realized, but the exhaustion of the conference was building quite strongly by this point. I wasn’t able to focus very well, although I did live tweet a handful of good nuggets. Other than my general interest in agility, my primary motivation for attending this talk is to be prepared for when my team grows or our project gets other teams working on the code base. The problems we have at our tiny size will be very different from the ones we’ll have when (not if) those things happen. The biggest point that resonates with me is her suggestion to not divide teams up by component/function. Each team should be full-stack and able to deliver working pieces of functionality without depending on another team for the rest of the vertical slice. Beyond that I mostly came away with more reinforcements for what I’m already learning at work and through other resources such as This Agile Life.

I started the next day watching Rob talk more about Netflix, but this time it was about continuous delivery. Although I like where my team is on this front, I know we could get better. One of the most interesting things I discovered is that they don’t just deploy application code like we do. Their teams build out (or “bake” as they like to call it) the application code along with a machine image which eventually gets dropped and deployed on the cloud. I also learned that there are a lot of monkeys running around their cloud. The have scripts they’ve given monkey names that randomly kill off machine instances in production, in addition to scheduled drops of availability zones and regions.

Next up was some JavaScript patterns with Raju who I’ve found is yet another fantastic No Fluff presenter. Even though we use CoffeeScript at work for all of our JavaScript, I expected much of the patterns to translate. I came home with some new tricks of my sleeve. Unfortunately as you can guess, most of what he showed was things to keep you from dying in the wild world of JavaScript, many of which are handled for us in Coffee.

And then, there was Venkat. I must say that the schedule set up to save the best for last. I hung out with most of the speakers at the conference, and every single one of them would back me up when I say that Venkat is a rock star developer, teacher, presenter, anything software. This first presentation of his that I attended was on Nashorn, the JVM JavaScript engine which ships with Java 8. Although I left the talk still not sure how I should use JS on the server, I learned that it is a well-designed/smooth tool in the JVM tool belt. The FFI interop with Java is very impressive. I also found it quite interesting that it actually has a “script mode” which gives you a handful more tricks to use in your JavaScript. I also didn’t know that it is packaged as an executable with the JVM so that you can get a REPL or pass it a JS file to execute. As a result, you can shebang the top of your JS scripts and now you have executable scripts like any other. The sickest feature I saw was how you can define a Java interface to match the functions you have in your JS, and on the fly it will provide an instantiation of that interface which is wired up to the underlying JS. As I’ve said before, I’m particularly excited to see the JVM really embracing its emerging role as a polyglot runtime environment. Overall very cool stuff, very well presented.

And then, there was Venkat on Haskell. Finally, I sat down and learned me a Haskell for great good. Over my career, I’ve learned that there is only one way that I really uptake another language. That is, I have to watch someone walk me through the first steps. Until that happens, I’m all talk. I learned C, C++, and Java at my university (yeah, notice the embarrassing lack of functional languages there? I’m still nudging them over that problem). I picked up Scala from Martin Odersky’s free online course. Dave Lee exposed me to CoffeeScript while presenting a JS library at HuntFunc. I picked up Clojure earlier in the conference, and now Haskell. The two exceptions to this is JavaScript (necessity and deceptive ease) and Groovy (as a super-set language, I didn’t need to learn much to get started). I believe the biggest thing that slows me down from starting a new language is the fear of how much time I will invest before realizing any productive gains. For some reason in my mind, I feel I’ll get over that hump more quickly if there is someone showing it to me. Anyway, I digress. On to Haskell.

Haskell is every bit of bad ass I expected. I was pretty comfortable with many of the concepts because of my work in Scala. As much as I love type inference in Scala, I didn’t realize how much I was missing. Haskell will look at the body of the function and infer output AND input types. I’ve been doing Java and Scala so long, that it hadn’t even occurred to me that such a thing could happen. I really love the ideas behind having an IO monad and all that good stuff, and it was cool seeing it in action. One thing I didn’t expect to see is how the inputs to a function can be pattern matched right there at declaration time, reminding me of what I’ve seen in Erlang. I also had forgotten how every function in Haskell takes at most one argument. More arguments just means that you’re really returning another function with the next argument. Unfortunately, I’m in the same place with Haskell as Clojure… I don’t know what I should aim for next. I need to dream up something I can build with each one.

So that was the rest of the sessions I attended. As I’ve said many times, the best part is the stuff I’m not bothering to write up: Hanging out with other developers. Although I enjoyed a lot of talks at this conference, I would gladly return only to hang out. I’ve made some great connections that I’m excited about and I look forward to what some of us might be cooking up in the near future. Stay tuned.

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , ,
Posted in Software Development

ÜberConf Day 2: Second expojure to Clojure

Day 2 for me at ÜberConf was the first day for many, as it marks the beginning of the meat of the conference. I didn’t love the first two sessions, but they lived up to my 3 of 5 stoke rating. While Kirk Knoernschild did a fine job presenting the modular architectures material, it wasn’t anything new to me. The refactorings he demonstrated to obtain a modular architecture to the code base just seemed obvious to me. I’m a fan of OSGi, although I don’t use it on any current projects. Hence I left that one quite underwhelmed.

For the second talk, I really took a liking to Nate Schutta. The topic of leading technical change described many behaviors I already exercise to stay abreast with the developments in our craft, such as reading blogs in down time, turning off the TV, etc. I thought the talk would be more about how to influence change in our organizations (although that piece was there a little bit). Despite all of that, I just thoroughly enjoyed Nate’s presentation style and the great points he made throughout. A great example of the sorts of things he said came out in an earlier talk I didn’t attend when he almost quoted Jason Tice from This Agile Life by stating “We’re not FTEs. We’re not ‘resources’. We are people. Treat people like people.” Needless to say, I shared that podcast episode with him.

(EDIT: In the original post, I completely forgot this talk)
The third talk I joined covered the Java type system. I don’t feel like getting much into it, but I came away realizing how much of a train wreck it is. Not trying to be arrogant here, but it really is a pain, especially with mutability ruining everything. Great talk, but the material was a little depressing if I think about having to go back to Java.

On to the second half of the day, the more compelling half of the day… As I’ve mentioned before on this blog, Clojure was the first functional language on the JVM I looked at. In that post I also expressed a renewed interest in Clojure, and now a little over a year later I finally took initiative and dove in. And when I say “dove in”, I mean I got violently barraged with Clojure. Neal Ford does not mess around when leading a Clojure workshop. He and Stuart Holloway made a conscious decision to make their intro to Clojure try to cover EVERYTHING and see what sticks with the audience. Firstly, I LOVED this approach. I always hated the snail pace of school… Like yeah, I got it the first time. Granted I didn’t understand half of what he showed, but the half I did understand is far greater than the quarter of the material I would have comprehended if given at a slower pace. So kudos for that.

I would have sunk in this workshop two years ago. I don’t know how any Java developers swam in those two sessions. If it wasn’t from the comfort level I’ve already built up for immutability, persistent data structures, code compactness, etc; there is no way I would have comprehended anything beyond "Hello, World!". I know, because I tried it before. I got to the REPL, entered (+ 1 2 3) enjoyed the echo of 6 and didn’t know what to do next. I think I’m actually ready to play in Clojure more now. I feel really torn tho because I am enjoying Scala so much at the current time, both at work and in free time.

So I thoroughly enjoyed this workshop, and I think I made a good decision forgoing my original plan to attend two JavaScript sessions. It also prepped me to be more comfortable with Matt Stine‘s use of Clojure in his Functional SOLID session. (EDIT: I’m a little ahead of myself here, as this talk occurred day 3) I’m starting to feel a LOT of pressure to spend more time in Clojure. I’ve noticed the Clojurians often point out the complexity of Scala’s syntax. Given how elegantly simple Clojure’s syntax is, I see where they’re coming from. Everything is just a list. '(1 2 3) is a list, (+ 1 2 3) is a list. A record is just a map, and it receives the benefits of all of the map functions. Scala on the other hand is frankly more like Java; there are these special things and those special things, etc. More so than ever before, I understand why Scala is often regarded as “just a better Java”. As I listen to some of these guys talk about the differences, there is a part of me that can’t stop thinking about some of the good points made.

And on that point, even if I were swept off my feet by Clojure, I still believe I made the best choice to set my team on our current course with Scala, Lift, Akka, etc. The tooling available for web application development is much more mature; Lift being the most outstanding web framework I’ve yet to experience. More importantly, I believe my team needs a gradual adoption of functional programming. There is no way I could have shut our shop down for a month while we learned a new language in hopes that we would catch up later. We needed to maintain productivity using our Neanderthal OOP skill set while we foster our still-budding functional programming skill set.

Yet a danger lies there. After the workshop, Neal and I had a great conversation about the merits of each Scala and Clojure. He described the situation as if we are standing in the OO/Java world looking at the distant functional programming world. Scala paves a wide parking lot across that chasm, allowing us to leisurely take our time reaching the functional programming world. Unfortunately, you can easily become complacent in the journey and set up camp somewhere short of functional programming. Clojure on the other hand is a narrow bridge straight to the FP world with no middle ground.

That last statement is arguably my greatest attraction to Clojure, with its elegant simplicity standing right behind it in second. Having been increasingly immersed in Scala over the past two years, I am now sold on functional programming. Now that it is clicking, I am done with the imperative paradigm. I crave referential transparency, which is arguably the greatest advantage of functional programming. I want immutability, and I want to tightly constrain side effects. I would love to spend more time in a more purely-functional language to see if I can finally defeat the last remaining footholds of imperative and object-oriented thinking.

I’m still a wee bit hung up on the dynamic typing. It won’t stop me from playing with Clojure, as I’d argue it is the most compelling functional programming language on the JVM (here, I don’t say Scala as it is a multi-paradigm language). I just think it is too valuable, throwing out the baby with the bathwater sort of thing. While I was talking to Neal, he said he felt that while static typing is valuable, it isn’t worth the cost. Matt shared a similar sentiment, lamenting that he quickly tired of fighting the compiler to run code that he knew would work. I’d like to see an example of this. In my experience, it didn’t compile because it was wrong. He even joked later on that in Haskell, if you can get it to compile then it works. Given how much Scala attempts to borrow from Haskell, this can hold true for it in many cases too. All of that aside, I see where static typing may not be appropriate for Clojure. It seems a bit dynamic in the way it likes to treat records as a map, and nearly everything else as a list.

So what’s next? I need to spend more time with the exercises Neal sent us home with. From there I need to find something to work on in order for me to stay motivated. As much as I love code, I only do well when there is a goal involved, particularly something to be built. I did receive a tweet inviting me to help with an OSS MongoDB driver wrapper. While that is moderately interesting, I’d love some other suggestions.

As if this wasn’t a long enough day, I wrapped it up by attending a make-up AngularJS workshop from Raju Gandhi. Even though we already use Angular at work, I was optimistic that I would learn some things that I’ve missed along the way. The main thing I came away with is a better understanding of how directives and such work. The best part of this one was meeting Raju and picking his brain on some of our developments with lift-ng.

I closed the day out by hanging out at the bar where I was fortunate to find many of the speakers and No Fluff Just Stuff organizers hanging out. I spent a lot of time talking to their lead developer (drawing a blank on his name at the moment). I’m certainly experiencing what others have told me about conferences: The sessions and keynotes are great, but the people you meet are the greatest part of the experience.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development
Follow

Get every new post delivered to your Inbox.

Join 623 other followers