Month: March 2008

Switching Caps Lock with Control on Windows

Getting the control key “back into the right spot” on PC keyboards is a goal shared between Emacs and UNIX folks. The following are a collection of links on how to do so (this list is sure to grow):

Addendum: 10/01/08
The Sysinternals solution is excellent, but it throws away caps lock. This was fine for me for a while, but believe it or not, now I need it back. As such, I now employ the solution found here.

Addendum: 1/11/11
This approach does not work on Windows 7 (I just started using Win7 this week).
KeyMapper works brilliantly though.
(via emacswiki)
Addendum: 2014-12-10

Coming back to Windows I found that KeyMapper quit working for me.

AutoHotkey seems to be doing the job of swapping:

  • caps lock with left control
  • left control with caps lock
  • enter with right control
  • right shift with enter
    • Seems to be the best way to use any keyboard out there
  • scroll up and down on the wheel mouse

Alt (Meta) - Enter doesn’t seem to work.

I’ll keep at it. Here is the config. 

WheelUp::
Send {WheelDown}
Return
WheelDown::
Send {WheelUp}
Return
Capslock::Ctrl
LCtrl::CapsLock
Enter::RCtrl
RShift::Enter

On Python and Lisp

The last time I spoke to a friend of mine who knows both Scheme and Common Lisp (among many other programming languages), his current language of choice was Python. More or less, he said that it just “feels right” (I need to pick his brain more on this).
Is Lisp the future of Python? Do Lispers gravitate towards Python? I’m not sure yet, but this paper aims to shed some light on both of those questions.

When Code Really is Art

For all of the programmers who lament the fact that code is not recognized as art, there is Piet.
Joking aside, once you get up to speed on stack based programming, this looks like a fun interpreter project. I am supposing that there are some very interesting opportunities on how to literally make your code “more beautiful”!
Addendum: 09/08/08
Here is a hello world program with a thorough walk-through and explanation of how it works.
Addendum: 12/28/08
Possible projects:

  • An interpreter
  • A picture editor
  • A graphical representation of the interpreter
  • A Scheme to Piet compiler; trained to generate “pretty pictures”

Mr Ed Designer: Generating User Interfaces with PLT Scheme

PLT Scheme’s user interface library is called Mr Ed. It is used to provide DrScheme to thousands of computers running Windows, Mac OS, and UNIX. It “just works”, and does so well; it is a fine graphics toolkit. MrEd Designer aims to make Mr Ed even easier to use!
Addendum: 7/14/8:
Peter Ivanyi now maintains this application.
Addendum: 09/10/08:
MrEd Designer 2.1.2 is released; it now supports tab-panels.
Addendum: 09/20/08
In MrEd Designer 2.1.3:

  • tooltips are added for the main buttons
  • the no-border style for the tab-panels is fixed.

Caveats of Object Creation using Closures

At one time or another you have probably heard the claim made that since you can utilize closures while programming in Lisp, there is no need to utilize an object system. That claim is sort of a half-truth. While closures are the language construct that allow you to create objects, they certainly don’t provide you with all of the object oriented programming language features that you would expect. Instead, you need to implement those features yourself.
The question was posed on the PLT discussion list. Some very good points were made about the issues you must address when implementing such an object system yourself, along with a pointer detailing how the issues are addressed in PLT Scheme.

Disciplined Thought: A Programmer's Friend

This post on the PLT discussion list reminded me of me. There was a point where my interest in programming languages was more about what you could do with a language, without much of an emphasis on the why you would want to do such a thing. While you can do a lot of interesting things in different languages, there is often more value when there is reason, or vision, of why you would do those things. From my perspective, most languages have, at one time or another had some guiding vision or force behind them.
Eiffel has Bertrand Meyer saying “Everything is an object, and be static about it” and C++ has Bjarne Stroustrup saying “Keep it fast, keep it generic”, Scheme “Programming languages should be designed not by piling feature …”. Ruby has Yukihiro Matsumoto saying “It makes sense to me, if you don’t like it, see you later!”. Consequently there are a lot of really “neat” things you can do in Ruby, but it is not always obvious to me why you might want to do those things (I’m excluding the obvious ones so give me a break on those). Mats knows, and if you don’t “get it” oh well! The vision, or reason, extends all the way from the macrocosm of the entire language to the microcosm of its individual features.
Programming language features are there for a reason. While I will always find individual features interesting in terms of what you can do, one of my goals as a programmer is to always study with enough discipline to understand why such features exist.
As a programmer it is your duty to understand those features before utilizing them. Matthias’ reply to this post provides an excellent example of the conciseness and clarity that are the fruits of such discipline.

Type Conversion with Eiffel

If you are going to utilize the Object Oriented paradigm for implementing your system, you ought to do yourself a favor and learn the Eiffel programming language. Why?
Take all of the things that are not included in your statically-typed OO language of choice because they are “too hard to understand”, and visit them in Eiffel. Not only does it have all of those features, but it makes them easy both to understand and utilize.
Read about type conversion, for example. What a wonderful language feature. You can even use tuples!
You will be left scratching your head, wondering why no one else has features like this (among many others).
Eiffel is really a gem of a language!