Favoring expressions over statements

Two weeks ago today, I gave my CoffeeScript talk for the first time at a No Fluff Just Stuff tour event. Despite being received well both locally and at NFJS (sans one rather scathing review), I still feel like I’m not doing a good job explaining the difference between statements and expressions (on this point, I agree with the aforementioned negative review). In this blog post, I’ll sound-off my take on the difference in hopes that my followers can help me hone this into a solid and concise treatment. Bear in mind that my intended audience consists of programmers who have long been steeped in the tar pit of imperative programming. A lengthy excursion into formal lambda calculus is off the table, for instance, so I’m aiming for something colloquial. My goal is to nudge my audience’s thinking towards favoring expressions over statements, not to impress someone with big, college-education words.

What is a statement? In programming, this is an executable line of code. When you make a statement in a program, you are bidding the computer to do some action. In higher-level languages such as C, Java, JavaScript, etc., these typically translate down to several machine statements using assembly, bytecode, etc. Regardless of the compilation/translation process, these statements are intended to manipulate the state of the running program. Each statement changes a variable (hence a register and/or a value in memory), reads some input, or produces some output.

Expressions are a fundamental component of statements. Before a statement is executed, it must first determine the value which is to be involved. For instance, an assignment statement involves evaluating the expression on right-hand side of the operator before taking the action of assigning. Consider this trivial case of initializing a counter to zero: int i = 0. The 0 on the right hand side is a trivial expression which cannot be reduced further. We of course can have more interesting assignments such as int seconds = 60 * 60 * 24 or even better, double area = 3.14 * r * r. In these cases, the computer has a little work to do in order to reduce the expression down to a value, then perform the state change.

So what is an expression? It is a mathematical construct which can be reduced down to a simple value. Let’s not quibble about vocabulary here and focus on the last word: value. Expressions reduce to values. There is no notion of a program or state to manipulate. It can exist in a vacuum unlike a statement which requires this notion of program and state which can be manipulated.

Although CoffeeScript isn’t a purely expression-oriented language, it is more expression-oriented than it’s JavaScript counterpart. Let’s take a look at two if/else blocks of code which illustrate how we can replace statements with expressions. First, an if/else statement which sets min to the minimum value between a and b.

if a < b
  min = a
  min = b

Compare that to an if/else expression which sets the max.

max = if a > b then a else b

While both can be means to the same end, the latter shows us that if/else can just well be an expression, i.e. something which reduces to a value to which we assign the name max. Imperative languages know that we need this expressiveness. Ever heard of the ternary operator?

max = a > b ? a : b;

Unfortunately the ternary operator is a superfluous special case which shouldn’t be needed. Many of the existing constructs in programming languages could be expressions. Take for instance, the switch statement (as Richard Minerich points out here for C#/F#). CoffeeScript lets it be a statement.

lunch = switch day
  when "Mon","Tue","Thr" then "salad"
  when "Wed" then "wings"
  when "Fri" then "happy hour"
  else "sandwich"

If this were JavaScript, I’d have to insert the same lunch = text all in it. That is because if/else and switch statements originate from a paradigm founded in thinking in terms of a computer which must move things, execute commands, branch, etc. Expressions on the other hand are founded in mathematics. if/else/switch all translate well to mathematical functions, which are thoroughly studied and well-understood.

It turns out that expressions are generally easier to model logically and hence are more brain-friendly. This probably comes across as counter-intuitive to the masses who demand practical applications and scorn the rigors of mathematics. However, imperative programming is the result of years of dealing with the difficulties of the Von Neumann architecture by increasing abstractions. Expression-oriented programming (and hence functional programming) are the conclusion of decades of logical reasoning and deduction. Even for those who shy away from the abstract thinking involved in formal logic, it should be rather telling that these “practical” languages have a long history of striving towards abstraction, not away. The more I delve into programming with abstract expressions, the less I find myself in a mental battle to program. It flows much more naturally as it aligns with logical thought patterns.

Don’t buy it? Let’s also consider my previous statement about how expressions can exist in a vacuum. They have meaning without the context of the program. Statements on the other hand, do not. Sure, we can understand that a statement like println("Hello World!"); prints the obligatory first text to the console, but my point is that we include the notion of a program here. Expressions are simpler than statements because there are fewer components which are inherently involved. I would argue that simpler is always better. (See also, Simple Made Easy)

The more a language gives you expressions, the more you get to work with plain ol’ values, and the easier it is to reason about your code. While CoffeeScript offers mostly cute syntactic sugar, the strong gravitational pull towards more expressions is its greatest value proposition.

Leave a reply below, or send me a tweet.

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

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.


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.


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++) {

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 } {

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

Get every new post delivered to your Inbox.

Join 706 other followers