Another Home Stretch

posted on 2009-11-30 00:04:07

I'm way behind on my blogging schedule. It's been over two weeks since the last one.

It's hard to believe 2009 is almost over. It's been an overwhelming year with a fair amount of negatives (dad's death, girlfriend's dad's death) but also a lot of positives (back in school with good grades, a nice apartment, fun programming projects, an internship for 2010 and a deepening relationship with the lovely Teresa Finn).

This semester has been much harder on me compared to the last two for reasons I won't elaborate on here. My last two big papers are due by tomorrow and Dec 4th, respectively. Then I'll be pretty free until exams on the 14th and 16th. I'm almost there but the end seems wildly far away. In part because I'm having trouble focusing on doing what I need to do today. I'm preoccupied with all kinds of concerns about graduating on time, finances, finding a job, where I'll be moving and other things that just flat out don't matter right now.

Though there are personal projects I'd love to work on, I may be a vegetable most of this holiday season.

Back to paper writing...

On Minimalism

posted on 2009-11-15 00:09:07

Introduction

Today, I want to talk about something I've been meaning to get around to for a while. Specifically, I want to mention some realizations I've had about restrictions-as-strengths as it relates to programming languages. This blog post was so long in coming in part because I had conflated that issue with a desire to also discuss the source of brittleness (or non-modularity) in programs and how this all tied back to the foundations of programming and CS. Obviously, that's too much for one post. There are three questions here and each is important to me. Later, I'll blog about the other issues and hopefully write a summary to tie it all together.

Background

Programming is really hard. We've known this for a while. As Hal Abelson said, "Anything with Science in the name, isn't." Software engineering is no better off. Certainly no one would argue that we know how to build software as well as structural engineers know how to build bridges. Difficulty in software doesn't stem from a single source but as programmers we need to localize it as much as possible. One way we do this historically has been through tools: Our programming languages with their compilers, profilers and debuggers, our operating systems, and other bodies of code to reuse (libraries).

The Meat

Software has many demands placed upon it. First and foremost it needs to be functional by which I mean correct and relatively stable. Beyond that it needs to be reasonably fast and there are often other concerns from user friendliness to security. All of these concerns introduce complexity to our software, that complexity needs to be managed and I think a central question in managing that complexity is how to partition and quarantine it. I did a rather poor and embarrassing job of at least raising that question a while back. I was lucky enough to find an outstanding attempt at an answer on Daniel Lyons' blog. It was completely coincidental though, he hadn't read my article.

Daniel framed this problem as one of seeking minimalism. I see the same answer from a slightly different angle. To me, there seems to be a pattern of trying to handle complexity by restricting the actions of the programmer. For example, in Peter Seibel's Coders at Work there are numerous mentions of how different subsets of C++ are chosen by different teams of programmers to reduce the complexity of overlapping or interrelated features. People will entirely abandon templates or operator overloading. Douglas Crockford mentions making sure to never use the continue statement in his code. These are examples of programmers simplifying their own mental model to make problem solving more tractable.

Languages do this too of course, the most prominent examples from my very limited experience being Haskell forcing you to think in terms of its type system or Factor forcing you to think in terms of its stack. Adapting to the constraints may be awkward or difficult at first but they do provide real benefits. The Glasgow Haskell Compiler is capable of remarkable optimizations because it can assume that you've adhered to the restrictions of immutability and laziness. Judicious use of the type system can eliminate entire classes of possible bugs and restricting the use of mutable state simplifies parallel programming and concurrency. Through use of the stack, Factor strongly encourages thinking about the dataflow of your program. I've heard this sort of thing expressed before as a language being opinionated about how to solve a problem and there are plenty of diatribes on the failure of one paradigm (opinion) or another, especially OO since it's been dominant for so long. But let's not confuse this issue as being about particular paradigms or programming languages.

There are languages on the other end of the scale.  I tend to think of Common Lisp as the primary one. (Disclaimer: I've written far more code in CL than anything else. My coding experience in every other language is positively trivial by comparison.) Common Lisp has been described by many others as being agnostic or happy to let you express a problem any way you can think how. Then again, Common Lisp requires you to think in Abstract Syntax Trees. It's the rift between opinionated and unopinionated languages that I'm curious about. Of course, Haskell and Lisp are (generally speaking) solving different problems as lispm (Rainer Joswig) notes on hackernews.

Vladimir Sedach suggests that the rift is about metaprogramming. More specifically, he states that Lisp and Smalltalk are self-describing computational systems. Lisp is written in Lisp. Smalltalk is written in Smalltalk. It's that old metacircularity/homoiconicity chestnut. Furthermore, he mentions that Haskell can't be self-describing because it's built on two computational systems. The type system is one and the language built atop it is another. Besides as Vladimir says, "If type systems could be expressed in a metacircular way by the systems they were trying to type, they wouldn't be able to express anything about types (restrictions on computational power) of that system." Factor's FAQ even mentions that they avoided purity and static types to enable the benefits of metaprogramming and interactive development. Personally, I know what I miss most in Haskell is an environment like SLIME. Interactive development of that style has an entirely different feel to me.

These observations about types and metaprogramming were a revelation to me and clearly, it's a limitation on the expressive power of something like Haskell. The question seems to remain open however as to whether or not such restrictions are enough of a strength to offset their cost. It seems to me that it must be situational but I'm interested in a more in-depth examination of the problem. Unfortunately, I can't offer such an examination myself today. Googling around a bit I found a discussion has started on hackernews about lisp while I wrote this. In the discussion jerf writes largely about this issue.  Jerf suggests that the other end of the restricted/unrestricted scale is Java which sounds about right to me. He also suggests that the problem with maximum empowerment languages is that they don't scale to large team sizes and (correspondingly) large programs.

Of course, there are counterexamples like ITA Software but macros were thoroughly debated even among friends at ILC 09 as harmful or helpful to team programming. Vladimir Sedach again has a good grasp on their utility. In my opinion, neither Factor nor Lisp has resolved this question yet but more companies are getting involved with metaprogramming whether it be in Ruby or something else. I hope methods of containing the destabilizing facets of metaprogramming will emerge. Where Common Lisp is concerned, I think Fare's XCVB is an interesting opportunity in this direction and I'm watching it intently.

The Takeaway

Enabling single programmer productivity is important but so is enabling teams. Java as an extreme example of restriction has caused at least as many problems as it has solved. Languages with powerful metaprogramming features often need to be restrained in some fashion when used by large teams. There must be a middle ground somewhere. I say this because eventually our systems (codebases) become huge and unwieldy and we need our languages to support the difficult task of controlling that complexity and of keeping them modular and malleable. That problem of verbosity and inflexibility is precisely what metaprogramming tries to solve. I'll write about the problems in achieving modularity more in my next post.

Way Behind

posted on 2009-11-10 14:55:33

So, I'm coming up on the two week mark since my last blog post. Sorry about that. A big reason why is that I have been working on a post that might actually have some substance to it. It's still about programming and CS but it might actually have something interesting to think about. Sadly, it's not done yet. In lieu of that, I'll post some quick bits of news.

• I've still been hacking on paktahn like a fiend whenever I can.


• I've started playing Final Fantasy XII again. I love that game series. Also, it's soundtracks.


• I finally caved and got a twitter account. I'm kind of embarassed but I was following a bunch of people by checking their twitter page a few times a day. It'll save time on that, at least.


• It's rather hard to sum up all the music I'm into but my top 15 artists on Last.fm is a really good starting point. If there are any you haven't heard of, they're worth at least giving a shot.


• I cannot wait to be done with school. Optimistically I can fanagle my way into getting credit for a literature course from my Oglethorpe days. If I do that and never get a D or F in any courses, I can graduate by December 2010. That's 5-6 courses a semester, 3 semesters a year. Otherwise, it's May 2011 for me. Blerg.


• On Dad: I think I only really started missing him recently. I think in Summer I didn't even have time to process his death (or just didn't know what to think), August-September I was depressed and now I just miss him sometimes. It's not terrible but there's definitely a time or two a week where I'm all, "Man! I wish Dad was hear to {talk to, hang out with, listen to music with, play guitar with, play video games with, watch movies with, be a family with, etc, etc, etc}".

I was going to add a number of different "newsy" things here such as: the recent successes about PATRIOT act and State Secrets reform, the enjoyable experience of working with the ECL compiler developers, some thoughts on my first Factor program (which still needs some touch up work) and various other things but I'll leave that til another day because sadly, I have a test tomorrow to study for. More coming your way soon, folks.

This blog covers 2015, Books, Butler, C, Dad, Discrete Math, Displays, Education, Erlang, Essay, Gaming, Gapingvoid, HTDP, Hardware, IP Law, LISP, Lecture, Lessig, Linkpost, Linux, Lists, MPAA, Milosz, Music, Neruda, Open Source, Operating Systems, Personal, Pics, Poetry, Programming, Programming Languages, Project Euler, Quotes, Reddit, SICP, Self-Learning, Uncategorized, Webcomic, XKCD, Xmas, \"Real World\", adulthood, apple, career, careers, choices, clones, coleslaw, consumption, creation, emulation, fqa, games, goals, haltandcatchfire, heroes, injustice, ironyard, linux, lisp, lists, math, melee, metapost, milosz, music, pandemic, personal, poetry, productivity, professional, programming, ragequit, recreation, reflection, research, rip, strangeloop, vacation, work, year-in-review

View content from 2024-09, 2024-06, 2024-03, 2024-01, 2023-12, 2023-07, 2023-02, 2022-12, 2022-06, 2022-04, 2022-03, 2022-01, 2021-12, 2021-08, 2021-03, 2020-04, 2020-02, 2020-01, 2018-08, 2018-07, 2017-09, 2017-07, 2015-09, 2015-05, 2015-03, 2015-02, 2015-01, 2014-11, 2014-09, 2014-07, 2014-05, 2014-01, 2013-10, 2013-09, 2013-07, 2013-06, 2013-05, 2013-04, 2013-03, 2013-01, 2012-12, 2012-10, 2012-09, 2012-08, 2012-06, 2012-05, 2012-04, 2012-03, 2012-01, 2011-10, 2011-09, 2011-08, 2011-07, 2011-06, 2011-05, 2011-04, 2011-02, 2011-01, 2010-11, 2010-10, 2010-09, 2010-08, 2010-07, 2010-05, 2010-04, 2010-03, 2010-02, 2010-01, 2009-12, 2009-11, 2009-10, 2009-09, 2009-08, 2009-07, 2009-06, 2009-05, 2009-04, 2009-03, 2009-02, 2009-01, 2008-12, 2008-11, 2008-10, 2008-09, 2008-08, 2008-07, 2008-06, 2008-05, 2008-04, 2008-03, 2008-02, 2008-01, 2007-12, 2007-11, 2007-10, 2007-09, 2007-08, 2007-07, 2007-06, 2007-05