One of the biggest problems I have with my personal setup is the context switch that comes from working with multiple projects. At the moment, I have probably 5-6 projects that are “active” to some degree. I obviously don’t work on each of them every day, or even every week.

Its hard to get back into a project after you haven’t worked on it for a while. What does each branch mean? How do I run the tests for this again? What was the thing I was actually trying to do next?

For most of these, I still don’t have an answer. Simply keeping a NOTES file helps, but that only goes so far.

For me, the key help would be an Emacs package that makes it easy to switch between projects I work on. It would abstract away common tasks (such as running tests, searching all files in a project, etc) and automatically save project locations on my system, making it very easy to quickly switch to what I want to work on next. Additionally, I want this system to be friendly and extensible.

Projectile is a project management system for Emacs. There are a few things that set it apart from others. Primarily, Projectile is “modern”. It has a decent test suite, is hosted on Github, and is in active development.

The code in Projectile has a quality that I like to call “shallow”, but maybe “transparent” is a better word. When you read its code, it all makes sense pretty quickly. It uses @magnars’ great dash.el list library, which makes most of its operations very clear and obvious.

A good project management system needs to be adaptable and lightweight, and Projectile does that very well. A few years ago, I tried to use some of the different Emacs project systems that were available. At the time, I basically couldn’t figure out how to use them. Every project is slightly different. Systems that are optimized for working on a C++ project probably wont work well for a Smalltalk project.

All together, this made projectile very friendly to change and contribution, and I was able to adapt it for my needs very quickly. If you have ever been frustrated about organizing projects in Emacs, I whole-heartedly encourage you to try it.

Before I learned C, years ago, I was under the impression that it was a hard language to learn. I wanted to learn more about computers, and C++ seemed easier. Everyone said it was “a better C”, and it seemed like the right way to go.

I quickly learned that my initial impression was wrong. You basically need to understand C in order to be effective at all with C++. So, I learned C, and life was good. Fortunately, I’ve never had to really use C++ again since then.

I still often get first impressions wrong. Octopress is a blogging framework for Jekyll. I have known about Octopress’ existence for a long time. The thing is, I ignored it. I thought it just wouldn’t be very useful to me.

My impression was that Octopress was designed primarily to act as a styling framework. There are lots of Jekyll blogs around that have the same Octopress style. Writing about creating an “x” plugin for Octopress was popular for a time, and these almost all seemed to be very display-related.

However, when I recently took the time to look it over again, I noticed that Octopress includes much more than a styling solution. It includes scripts that help with all sorts of things you need to do with a Jekyll website. I was amazed at how much it contains. It even has solutions to some long-time frustrations I have had with Jekyll.

The other thing that struck me was how flexibly Octopress could be used. Octopress is distributed as a git repository, not as a library. All of its code is really easy to customize to the specific needs of your application. Although the Jekyll documentation is good, Octopress’ sample configuration files are really much easier to comprehend than by referencing the Jekyll wiki. So, it was clear that Octopress would make it much easier to manage your Jekyll website, not harder.

It was clear to me that I should adopt Octopress.

Adopting Octopress

So, how do we migrate an existing Jekyll blog to Octopress?

First, follow the documentation, to set up an Octopress blog with a few of my own modifications:

 cd ~/Journal # the place where I currently store all of my 
              # journal stuff
 git clone git://github.com/imathis/octopress.git JournalOctopress

 cd JournalOctopress

 git remote rename origin imathis

 bundle install --binstubs # so I can skip the 'bundle exec'
                           # and I don't use rbenv, I use RVM

 bin/rake install # install default presentation files 

 bin/rake preview # start the server

After verifying that everything is working by visiting localhost:4000 in the browser, lets check out what Rakefile goodies we have:

bash-3.2$ bin/rake -T
rake clean                     # Clean out caches: .pygments-cache, .gist-cache, .sass-cache
rake copydot[source,dest]      # copy dot files for deployment
rake deploy                    # Default deploy task
rake gen_deploy                # Generate website and deploy
rake generate                  # Generate jekyll site
rake install[theme]            # Initial setup for Octopress: copies the default theme into the path of Jekyll's generator.
rake integrate                 # Move all stashed posts back into the posts directory, ready for site generation.
rake isolate[filename]         # Move all other posts than the one currently being worked on to a temporary stash location (stash) so regenerating the site happens much more quickly.
rake list                      # list tasks
rake new_page[filename]        # Create a new page in source/(filename)/index.markdown
rake new_post[title]           # Begin a new post in source/_posts
rake preview                   # preview the site in a web browser
rake push                      # deploy public directory to github pages
rake rsync                     # Deploy website via rsync
rake set_root_dir[dir]         # Update configurations to support publishing to root or sub directory
rake setup_github_pages[repo]  # Set up _deploy folder and deploy branch for Github Pages deployment
rake update_source[theme]      # Move source to source.old, install source theme updates, replace source/_includes/navigation.html with source.old's navigation
rake update_style[theme]       # Move sass to sass.old, install sass theme updates, replace sass/custom with sass.old/custom
rake watch                     # Watch the site and regenerate when it changes

Ohhh, so many choices. The most interesting ones to me are:

rake new_page[filename]        # Create a new page in source/(filename)/index.markdown
rake new_post[title]           # Begin a new post in source/_posts
...
rake preview                   # preview the site in a web browser

For me, I next started to write this very blog post:

bin/rake new_post["Octopress is Pretty Sweet"]

This let me record my observations as they were happening.

Okay. Running bin/rake preview and visiting localhost:4000 shows the new blog post. Lets start migrating the old content over. I have always hated the default Jekyll URLs, but because I was using Github to compile Jekyll, there wasn’t a good way for me to change the URLs that already existed. Migrating to Octopress (and also compiling the entire site on my own machine) makes this really easy. I also wanted to make sure the old links still directed to the current content.

A quick search revealed a Jekyll plugin that makes it trivial to set up redirects. The only thing that remained was creating the redirect information that the alias generator requires. This seems like it should be pretty easy to automate, so I added a new task to the Rakefile provided by Octopress:

task :joel_copy_old_posts do |t|

  old_posts_dir = "../joelmccracken.github.com/_posts/*"
  new_posts_dir = "source/_posts/"

  Dir[old_posts_dir].grep(/markdown/).each do |post_file|
    post_filename = File.basename(post_file)
    parts = post_filename.match(/(\d+)-(\d+)-(\d+)-(.*)\.markdown/)
    year = parts[1].to_i
    month = parts[2].to_i
    day = parts[3].to_i
    alias_name_to_add = Date.new(year, month, day).strftime("/%Y/%m/%d/#{parts[4]}.html")

    new_filename = new_posts_dir+post_filename


    old_file = File.open(post_file, "r")
    new_file = File.open(new_filename, "w")

    old_file.lines do |line|
      if line =~ /^title/
        new_file.puts line
        new_file.puts "alias: #{alias_name_to_add}"
      else
        new_file.puts line
      end
    end
  end
end

Basically, this code just takes every post, generates an alias name, adds the alias to the YAML frontmatter. So, it converts the YAML frontmatter from an old post:

---
status: published
layout: post
title: 'An Alternative to "I Am Not My Code"'
---

into this:

---
status: published
layout: post
title: 'An Alternative to "I Am Not My Code"'
alias: /2012/12/24/an-alternative-to-i-am-not-my-code.html
---

Easy, and it works well. The code could be a bit better, but since I only ever need to run it once, this level of sophistication is perfect.

The only thing left is to change the default theme. I found the venice theme and installed it:

git submodule add git://github.com/octopress-themes/venice.git .themes/venice
git add git add .themes/
git commit -m 'added venice theme'
bin/rake install[venice]

Hopefully, I will be changing the venice layout soon to something I have personalized. This, also, seems easier with Octopress. Since its themes are fairly complete, modifying them in the future looks easier than starting from scratch.

Finally, deploying. I just followed the provided instructions:

bin/rake setup_github_pages # used 'git@github.com:joelmccracken/joelmccracken.github.com'
bin/rake generate
bin/rake deploy

Overall, my experience with Octopress has been very positive. So far, I have not hit any problems. So, if you have been holding off because, like me, you didn’t think it would be very useful, I suggest giving it a try. It might surprise you how nice it is.

Code is imperfect. It has warts. It reflects the imperfections and limitations of its creators. Even though code is imperfect, we still use it and move forward, because that’s the best we can do. No matter what we do, code will never be ‘perfect’, because no meaningful definition of perfection exists. Our world is a complicated place, and the demands we place on code reflect this complication.

Sometimes, we encounter code that someone else is responsible for, and is lacking in some way. We feel the need to communicate what we think is wrong with the code. This creates possible conflict.

Nobody likes to hear that their code is bad. People in the open source community are here out of passion. They love programming and want to help others. Programming deficiencies are an unfortunate part of life. We pour our souls into our work. When someone criticizes our work, they are criticizing a source of our pride.

Yet, all code is lacking. We need help from others to identify problems in our code. This has led some to adopt the mantra, “you are not your code”. The basic idea is that we can criticize the work of others, and that’s ok, because we are criticizing a “thing”, not the authors themselves.

First, of all, I want to say “you are not your code” has some merit. It encourages us to divorce our sense of worth from our code. Indeed, our code does have problems – all code does. If we cannot take some criticism, we can’t grow as developers and humans. This is how we learn, after all, and is especially how we learn from other people. So, we need to be able to talk honestly about code.

However, “you are not your code” fails in a few ways. First, it does not acknowledge that the developers actually do care about their code. Parents are not their children, but that doesn’t mean that parents are fine with people saying bad things about their kids. We care about our code. And, I think this is a feature, not a bug. I’ve seen code written by people who don’t care about their code, and it is unpleasant.

Saying “you are not your code” puts all of the burden on the code maintainer. It encourages the problem reporter to be careless. In reality, in any social situation, everyone has responsibility. Nobody gets to be free of responsibility for being careless with their tongue.

Besides these sort of fuzzy emotional issues, “you are not your code” encourages us to communicate in a way that doesn’t really work. For some trivial bug reports, such as misspellings, a straightforward discussion might solve the problem. However, most bug reports require much more interaction between the two parties. Software is really complicated. The maintainer and the reporter need to come to terms and establish a common understanding about the entire situation that caused the code problem. We can’t skip this step.

So, how can we do better? Like so many social issues, the key is empathy and understanding. Put yourself in the shoes of the code maintainer. What do you think they need to know? How is it that you know it? Where does the misunderstanding come from, and how can it be rectified?

As someone who wants to report a problem, answering questions like this drastically improves the quality of communications. Bug reports are better. Discussions about architecture and philosophy are more informative. Really, this lets us compose much better communications. These well thought out communications are way less offensive and much more understandable.

Of course, this is hard. It requires brain power to put ourselves in the place of the authors. It is certainly much harder than just saying whatever you want, punctuated with “you are not your code”. However, we still eventually need to come to an understanding with the other person. Regardless of how they feel about what we say, they still actually need to understand what the problem is. So, why not skip to the end, bypass the part where we make the code author feel bad, and effectively communicate what we think the author needs to know?

I love code. Regardless of what happens with my life, I will always code. If, tomorrow, I found that I was suddenly very independently wealthy, I would still code.

This passion pushes me to improve. One of the most frustrating things is to need to rearchitect something for no good reason. So, I am always looking for ways to improve my code. I read books and blogs, and try to actively apply the things that I have learned in the code that I write. Typically, I love all the advice I have gotten from various sources over the years, and my code has improved dramatically.

There is something that has always bothered me about programming advice, though. This was a topic that I touched on in the second phase of learning to program. From my recollection, all advice on how to write good code follows the same general principles. A model object might do too much, and thus need to be split apart. A controller might be doing something “more” than simply coordinating the models and the views, and needs to have that logic removed. A function might just get too large, and should then be split apart. A database might have a denormalized schema, which makes updating difficult, and thus should be normalized.

These guidelines feel really similar to one another. This is good, because it probably means they make sense. It would be suspicious if we were getting wildly different advice from different sources. However, this also suggests existence of an underlying, unifying principle. Does such a principle exist?

Personally, I am not sure. But, I do have an idea about what it might be. I have been thinking that programming is fundamentally about the “idea”, and the act of programming is just the act of codifying ideas.

Lets talk about what this means. Really abstract things are hard. For these purposes, I mean an idea is a mental state – something that can be held in your brain. These states, these basic units of information, are the stuff that our existence is made out of. Just as there is a limit to how much we can consider at a moment, there is also a limit to the size and complexity of an idea.

Regardless of the form that our code takes, we somehow force it our heads around it. Imagine examining a method that is not trivial to grasp. We would probably decomposing it, possibly by creating a story about its behavior. First it “does this”, then it “does that”. In any case, this method is now composed of multiple ideas, even though it is still one method. Our program does not match the structure of our thoughts, and this creates a hefty brain tax.

Once we realize this, we can alleviate this pressure by changing the structure of our code. We could do something as simple as splitting this method into multiple methods, or we could create a service object. Either way, we have just brought the code into line with the way we think about it.

I have started to try to develop a process for applying this principle, with the goal of trying to get a sense of whether or not it works. So far, results the are fruitful. Focusing on the ideas that need to be expressed has drastically helped me every time I have applied it.

So, what have we (maybe) gained? We have a framework to understand how all of this design advice fits together, as well as a metric to help us think about how to apply it. We also have a general principle to help us decide how our code should be structured. I think that’s a win, either way. Let me know your thoughts!

If you pay attention to Ruby, you almost certainly know about all of the refinements drama that happened. I’ll assume that you don’t though.

Basically, refinements is a feature that was going to be in Ruby 2.0, but has since been removed as a feature. There are a bunch of more thorough explanations of the idea behind refinements, but basically the idea is that you can monkeypatch a class, and those monkeypatches only exist within a certain scope of execution.

With refinements, you can add functionality to a class that is specific to the sender, without adding logic to the receiver that is not generally applicable.

So, here is something that lets you do this in a library. This doesn’t completely replicate native functionality, but it does let you get 90% of the way. Basically, we create classes that wrap other classes. First, the tests:

describe Refinery do
  it "ignores classes that have not been refined" do
    ref = Refinery.new
    "lol".class.must_equal ref.refine("lol").class
  end

  it "refines" do
    ref = Refinery.new do
      refine String do
        def to_ruby
          "\"#{to_s}\""
        end
      end
    end

    ref.refine("hi").to_ruby.must_equal "\"hi\""
    ref.refine("hi").length.must_equal 2

    proc do
      "hi".to_ruby
    end.must_raise NoMethodError
  end
end

And, the code:

require 'delegate'

class Refinery
  def initialize(&refine_def)
    @refinement_definition = RefinementDefinition.new
    @refinement_definition.instance_eval &refine_def if block_given?
  end

  def refine(raw_object)
    @refinement_definition.perform_refine(raw_object)
  end

  class SingleRefinementDefinition
    def initialize(type, &defn_block)
      @type = type

      @refined_class = Class.new(SimpleDelegator)

      @refined_class.class_eval(&defn_block) if block_given?
    end

    def matches?(obj)
      obj.is_a? @type
    end

    def perform_refine obj
      @refined_class.new obj
    end
  end

  class RefinementDefinition
    def initialize
      @refinements = []
    end

    def refine type, &def_blk
      @refinements << SingleRefinementDefinition.new(type, &def_blk)
    end

    def perform_refine obj
      selected_ref = @refinements.select do |ref|
        ref.matches? obj
      end
      if selected_ref.first
        selected_ref.first.perform_refine obj
      else
        obj
      end
    end
  end
end

I guess I think should put this somewhere better, but I’m not sure where, so I’m open to suggestions!

Recently, Anil Dash posted an article entitled The Web We Lost. In it, Anil discusses the walled-data-silo that is the modern web, and how less friendly and useful modern web services are.

This really speaks to my heart. Personally, I hate having to use the various web services that I do. I try to keep these websites to a minimum, but the ones I do use are simply too valuable to me to go without them. I could avoid using twitter, but the network effects are really high, and I just haven’t had the time to work out the rough edges to using my rstat.us account.

A Solution: People-Friendly Servers

I have been paying $15/month for years now for a Dreamhost VPS that I do almost nothing with, in the hopes that someday I will have the time to set up an email server the way I want, some kind of microblog, and regular blog. I don’t think this should be all that hard, though.

Imagine a system where a user visits our person-friendly server site. They sign up and provide payment information, and then our systems get to work.

A VPS is requisitioned on Amazon’s cloud. A standard system image is installed on the machine, and the user is emailed with a link to log into their new server. Once they log in, the user can choose to install different “Apps”, such as email, blogging, and file backup and syncing.

Moving Forward

Obviously, such a system would face huge technical challenges. I don’t think such challenges would stop something like this, but they might require some rethinking of the way network servers are built.

I have been spending time exploring this idea. I’m really awful about polishing and publishing scripts that I write, but this is something that is important enough to make sure it gets done.

I am trying to figure out an organizational structure to support such a system. A Co-op or a B-Corp seems like the most realistic and ideologically sounds system for something like this.

Do you have any thoughts? Do you want to help build something like this? Let me know.

The Keyboard: Keys and Keymaps

Its been a while since I posted in this series – but don’t fret! I sill am dedicated to providing a guide to Emacs Lisp, the guide that I wish I had a year ago. I also recently implied that I prefer Ruby to Lisp, but that is not important. Emacs is still the best developer environment in the world, and occupies a really important place in the future of code composition.

The learning to program in Emacs Lisp can be split into a number of concerns. The first concern is the language itself. How do we initialize variables, create functions, generally structure programs? So far, we have been mostly limited to these types of concerns. We have not yet touched on manipulating Emacs itself. Which, is basically the goal of all of this Emacs hacking, right? So, to get started, lets look at manipulating keybindings. One of Emacs’ most “famous” features is the magic you can do with the keyboard. I use quotes around famous because the finger stretching it requires is the primary source of criticism.

Either way, keybindings are a good place to start talking about modifying Emacs.

Setting a Global Keyboard Binding

On Mac OS X Emacs, the key Command-Q will kill Emacs. I always hated this. Disabling it was really easy, though:

(global-set-key (kbd "s-q") nil)

This code introduces a few things. First, we use the global-set-key function, which sets the key, well, globally. Other commands set keys for specific keymaps. Which we’ll get to in a minute.

Next, we have the form kbd. We could skip using kbd, but the strings we would need to use to specify a key binding would be uglier and more opaque. Using kbd lets us specify these in a much more consistent, natural way. In the above example, “s-q” is the “Command-Q” binding.

Finally, we have nil. This means that the key binding now does nothing, which disables the Command-Q quitting in our personal Emacs. Nice!

We can bind functions to keys. Lets create a binding so that Meta-h will execute a “hello world” function:

(global-set-key (kbd "M-h")
                (lambda ()
                  (interactive)
                  (message "Hello from Emacs!")))

Now, if you press Meta-h, you’ll receive a friendly greeting from Emacs.

This is the essence of keybindings. If you were to stop reading here, you would be able to get pretty far. However, there is another feature that we should discuss: that is, keymaps.

Keymaps

A keymap is simply a collection of keys to bindings. They allow us to conveniently group bindings to be collectively added, enabled, or disabled.

Not only does a keymap hold keybindings, it can also itself be bound to a key. In this way, we create a hierarchy of bindings. Lets look at a quick example:

(defvar joel-custom-keymap nil "my keymap..")

(setq joel-custom-keymap (make-sparse-keymap))
(global-set-key (kbd "C-x M-j")  joel-custom-keymap)

(define-key joel-custom-keymap (kbd "s") 'otto/status)
(define-key joel-custom-keymap (kbd "t") 'twit)
(define-key joel-custom-keymap (kbd "p") 'plan)

This is actual code that I use. It comes straight out of my dotemacs file. It binds the keymap joel-custom-keymap to the key sequence “C-x M-j”. When I press those, I can then press s, t, or p to run the commands otto/status, twit, or plan, respectively.

I feel like this is straightforward but awkward to explain. In any case, this is enough to get started. You’ll probably want to get familiar with what the manual entry contains so that you will know where to look in the future. Happy hacking!

I have been a Lisp supporter for half a decade now. Learning Lisp changed my life as a programmer. Since then, I’ve looked at the world with a Lisp point of view, and it has been very satisfying. There is a rather large problem, though. The more I write in Lisp along with other languages the more obvious this problem becomes. The thing is, this is a problem that is not really discussed in the Lisp community. It tends to be scoffed at and dismissed. Before we get into the details of the problem, we need to set the stage.

If you pay attention to what lispers perspective of the history of programming languages, you’ll see a progression of programming languages that started off with generations of algol-based programming languages slowly adopting lisp’s features. As of 2012, the only feature left that makes Lisp systems, well, Lisp, is having homoiconic syntax – that is, support for macros. Now, because you are reading this, I assume you are familiar with macros. It is worth quickly going over the concept, just to make sure we are on the same page.

Programming systems that have macros let the programmer do all sorts of awesome magic. Basically, whatever syntax the system “supports” can be transformed, allowing the programmer control over what that syntax does. The homoiconic property refers to the code being a data type that is native to the system.

Macros are awesome. They let the programmer extend the language, giving them first-class access to basically whatever the interpreter has. Macros are certainly worth having. Any forward-facing language should have some kind of syntax-rewriting facilities. These problems really belong in another post, and have been said elsewhere. The thing is, the Lisp community has thought about this for a long time. Best practice is to avoid using macros unless there is some a really compelling reason to use them. In practice, this often means that in any given program, you are likely to never create a macro. This point is important. The syntax of Lisp – that is, s-expressions, the odd parenthesis syntax – is designed around macro facilities that many programmers do.not.use. And, when they are used, they are used infrequently.

This would be acceptable if there was no downside to using s-expressions. However, there are downsides. And no, they have nothing to do with lots of irritating, superfluous parentheses. I promise that I will try to get to the fundamental issues I have with parentheses in another post, but for the sake of argument just accept that s-expressions tend to force your application to take a shape that is contrary to the way you think about it.

The thing is, we don’t need s-expressions for a programming system to support macros. As far as I understand it, the value of s-expressions lie in the obviousness of how they will parse. If you look at a given s-expression, it is pretty easy to understand how the interpreter will parse it. However, we have computers that make it easy to understand how an s-expression will be interpreted.

We can get any programming language to support macros. It just takes a bit of effort. For a very basic macro system implementation, we need to process the syntax of source code, change the given syntax according to rules, and then output the new code. There are nuances that make macro systems better and more user-friendly, but we can still create syntax rewriters without them.

This fact, more than any other, has turned my attentions away from Lisp. I can’t ignore the irritation that s-expressions cause. Ruby, by contrast, already naturally has a form of metaprogramming that makes many kinds of macros unnecessary.

This is a good time to mention that I have started developing a Macro system for Ruby. Some of it is inspired by what @raganwald developed, but I am trying to take it down a different route.

Do you remember those infomercials on late night television that are trying to sell viewers a way to make money? Most of them involved buying and selling real estate, but I am pretty sure I saw other types. They always featured testimonials by people who used the system to make many thousands of dollars.

To me, those always seemed a little bit sketchy. First, they seemed too polished. I understand that polish is necessary to seem (and to actually be) professional, but there is a very subtle difference between professional and con-artisty. And, if the difference is not pronounced enough, it sets off a lot of my mental alarms. Some questions immediately are raised: If you are so successful from investing in real estate, how is it worth your time to get on the television and try to sell me a course that took you all this time to put together? For that matter, isn’t the amount of valuable real estate limited? And, why aren’t you able to scale up your operations to take advantage of all this opportunity?

I want to be clear. I have no real reason to suspect these courses. The people selling them were probably genuine. Thing is, they also set off alarm bells, which the programs would never really assuage.

Nowadays, there are lots of people online who are selling courses to bootstrap web services. I have interacted with some of them, and they seem like really great people. The thing is, these types of services set off those same mental alarms. To me, at least.

What could you do to help me, as a potential customer, overcome these biases? One way would be to give some hard figures about student success and success stories. Ideally, these success stories would include links to real websites that were built after completing your course. I’d like to “see” what the course would do for me.

What if you don’t have/can’t provide any of this information? Well, I guess I wouldn’t be your ideal customer. But, you should try to get this information, because my guess is that I am not all that unique in feeling this way. You, personally, could always start smaller, possibly with a single client with the understanding that they will be willing to provide this information for future marketing purposes.

Ultimately, this kind of sales/marketing strategy has a really long history, and any kind of service that employs similar strategies has an uphill battle to fight. I think that services like these are probably extremely useful and valuable – if potential customers can see past the initial distrust of services that market themselves like this.

I really love Emacs. It provides a great outlet for my creative energy while still being really useful every day.

It also provides a safehouse from the frustrations of the computing world. Programming is now the art of stringing together other APIs. And, if the APIs that in question are really nice and easy to use, this is a wonderful experience. More often than not, though, APIs are not nice. Legacy systems mean the state of the world yesterday creeps eternally forward, and the lack of shared ideas between systems means an extreme lack of commonality.

Emacs is just as subject to these forces. Indeed, in some ways bad abstraction and accumulated cruft is more of a problem in Emacs than in other systems. Emacs is thirty years old, after all. But, each component is extremely hackable. And, since they are all unified by the restrictions and assumptions of Emacs Lisp, Emacs’ components tend to work together really well.

Emacs lets me explore all kinds of things. I use it to explore how to improve my concentration and filter distractions. I’m able to explore combining different components, and how this works for me.

Org mode makes a really good wiki. With it, I can organize knowledge whenever I need to think about things in a logical, connected sort of way. This is great for some of the topics I study personally.

Emacs lets me explore the space of possible hacks, too. Quick and dirty solutions are really easy to implement. Thus, I can explore what is possible and what is useful.

Ultimately, it gets out of my way and lets me think about things. I know that it I have some large problem with it, a solution is only a hack or two away. As I search for a good solution to a problem I am facing, I know I can scale the solution up to the problem, regardless of basically how hard the problem is, or how strong the constraints end up being.

Emacs is really a pleasure to use. I hope that you embrace it, and it brings you as much joy as it has brought me.