Skip navigation

Python limitations:

No macros
This is inevitable in a non-Lisp language.

Anonymous functions are limited to a single expression, and no statements
This is excusable; Python’s indentation-based syntax makes it hard to express inline functions unambiguously.

One can only ‘break’ out of the innermost block
Guido van Rossum claims that named blocks are rarely needed, and thus shouldn’t be added to the language. Judging from this, the Python philosophy is to keep the language simple and easy to master; a new feature should only be added if it is frequently needed and considered proper style. In practice, this often leads to having to shoehorn one’s conception of a problem into the way Python dictates it to be expressed, especially if one has a background in a more flexible language like Lisp.

Common Lisp does have extensible syntax (macros), full-fledged anonymous functions, and named blocks.

Even writing a simple CLI Yatzy game in Python, I find myself wanting to use macros, anonymous functions and named blocks. Macros allow arbitrary blocks of code to be wrapped in error-handling code, like (handle-errors (dostuff)). Anonymous functions allow the calculation functions to be defined directly in a dictionary instead of defined as named functions and then referred to by name in the dictionary, only to discard the names. Named blocks allow breaking out of a loop from an inner loop. These limitations give me the feeling that I’m fighting against the language.

There is a reason people become zealous about Lisp; it allows one to bend the language to one’s will instead of submitting to its constraints.

So why use Python? Well, there are some reasons. While Python’s infix/indentation based syntax poses some limitations in expressiveness, Python code is often terser and clearer than the equivalent Lisp code. Here are some illustrative examples:

x=y+z
(setf x (+ y z)

x[y,z]
(aref x y z)

x[0][1]
(aref 1 (aref 0 x))

if foo:
    do1()
    do2()
else:
    do3()
    do4()

(if foo
    (progn
      (do1)
      (do2))
    (progn
      (do3)
      (do4)))

Python also has a much better selection of libraries than Lisp. A language has to be popular to be good, and the Lisp community is not just small, but very fragmented across dialects (CL, Scheme, Clojure, Dylan..) and implementations (for CL: CMUCL, CLISP, SBCL, ECL..), so there is a limited selection of tested, documented, portable libraries. (Clojure seems promising in this regard, being built on the Java platform and able to use Java libraries.)

So what is the right choice? I can only conclude that it depends on the project and one’s tastes.

Emacs is at its core a Lisp interpreter. It is often called an “editor” for
convenience, but you should think of it as more of an extensible computing environment, based primarily on text buffers. It was designed from the beginning to have a much broader scope than simply editing text files. Emacs wants to be a unified environment for all things text: mail, IRC, shells, documentation, etc. This functionality is added through writing specialized Emacs Lisp programs, loaded on demand. Elisp programs you don’t want to use will thus never bother you, since they will never be loaded. Emacs can be thought of as more of a framework than an “application”.

uTorrent, on the other hand, was designed as a lightweight BitTorrent client. For years, that was all it was. It was only recently (around 2011) that it was “extended” with all kinds of features like video playback, of no relevance to the original design. Because these features are built into the binary rather than implemented as stand-alone modules/programs, users pay the price for the resulting code bloat all the time, even if they don’t use the new features.

Let’s take a look at the new features:

Video playback

This can already be done by double clicking the files in the video tab to open them in your video player.

Web content search

This can be done by switching to your web browser, finding a torrent, and clicking a link to open it in uTorrent.

“Apps” like games

Windows and web browsers already have that. In Emacs, games are meant as a creative display of Elisp hacking; in uTorrent they are a poor man’s substitute for web apps or native programs.

Ratings and comments on torrents

Torrent sites already have that.

Ruby’s syntax is often called “ugly”. Indeed it has more syntactic sugar than Python. One example is that ruby has a special syntax within strings to expand variables. Yes it’s a syntax “hack” and it’s not strictly necessary, but take a look at this.

Say you want to make a message that prints out 2 numbers. In Ruby, it can be done like this:

puts "The numbers are #{foo} and #{bar}."

In Python, you have to do it like one of these:

print("The numbers are {} and {}.".format(str(foo), str(bar)))
print("The numbers are " + str(foo) + " and " + str(bar) + ".")

Which language is more ugly in the end?

I’ve been trying out Vim again after a year of Emacs, and I find modal editing awkward now. The advantage of modal editing is that it decreases the reliance on modifier keys, but it comes at a price:

– Modality is a HCI mistake in general. You get used to being concious of the current mode after a while, but you can still wreck havoc if you eg. miss i or : and start typing. Modeless editing is much less “error-prone”.
– Moving within a line and adding characters here and there requires constantly entering and exiting insert mode, unless you want to succumb to using the arrow keys.
– If you make a mistake in insert mode, such as hitting ctrl-U to delete to beginning of line, you can’t undo it; undo can only be accessed outside insert mode, and it undoes the entire insert mode session. So if you had stayed in insert mode for a while before the accidental ctrl-U (such as when typing out a paragraph) you’re pretty much forced to retype the line you deleted.

For these reasons, I believe modeless editing makes much more sense. Emacs’ default key bindings are far from optimal though; I think that’s why modeless editing has a bad rap.

Bill Joy, author of vi:
«I wish we hadn’t used all the keys on the keyboard. I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors go, it’s pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me. I also wasn’t very good at optimizing code when I wrote vi. I think the redisplay module of the editor is almost intractable. It does a really good job for what it does, but when you’re writing programs as you’re learning… That’s why I stopped working on it.

What actually happened was that I was in the process of adding multiwindows to vi when we installed our VAX, which would have been in December of ’78. We didn’t have any backups and the tape drive broke. I continued to work even without being able to do backups. And then the source code got scrunched and I didn’t have a complete listing. I had almost rewritten all of the display code for windows, and that was when I gave up. After that, I went back to the previous version and just documented the code, finished the manual and closed it off. If that scrunch had not happened, vi would have multiple windows, and I might have put in some programmability—but I don’t know.

The fundamental problem with vi is that it doesn’t have a mouse and therefore you’ve got all these commands. In some sense, its backwards from the kind of thing you’d get from a mouse-oriented thing. I think multiple levels of undo would be wonderful, too. But fundamentally, vi is still ed inside. You can’t really fool it.

Its like one of those pinatas—things that have candy inside but has layer after layer of paper mache on top. It doesn’t really have a unified concept. I think if I were going to go back—I wouldn’t go back, but start over again.»

I am often told that Arch Linux sucks, Arch is useful because it categorizes idiots (“I like arch” proves you are an idiot), etc. So I caved in and tried OpenBSD. Well, here’s my experience, compared to Arch:

– Much slower boot.
– Worse package management. Searching is absurdly slow (no local db), no listing of deps and size to dl/install when installing something (Edit: You can show the “signature” with deps with pkg_info -S, but it’s not as nice as Arch’s listing and downloaded/installed size summary), essential packages like terminus missing…
– Chromium and flashplugin each require tedious manual configuration to run. (Edit: flashplugin actually isn’t supported at all now)
– Surf wouldn’t compile because make somehow didn’t use the variables from config.mk. (I’ve heard you have to use gmake, “make” is BSD retard-make)
– Poor VirtualBox guest support.
– Less hardware support, CPUs aside.
– No FUSE support, and hence no ntfs-3g or sshfs.
– No support for NVIDIA’s proprietary video drivers, and hence no VDPAU.

Contrary to the rampant prejudice, I almost never have any problems with Arch. Switching to OpenBSD only seems like a step back.

The FSF claims that the GPL is a matter of securing freedom for computer users, but that’s a quite distorted truth.

The GPL requires any “modified versions” to retain the terms of the GPL. This means that if you incorporate any code from a GPL-licensed program into your own program, you have to release it under the GPL. However, what if you now want to use code from a program with a different copyleft license? That would require changing the license appropriately as well, but you already need the GPL because you use code from a GPL’d program. So… you can’t. This even applies for different GPL versions. If A uses GPL2 (and doesn’t have the “or any later version” clause), and B uses GPL3, you can’t use code from both.

If you release some code into the public domain, and someone improves the code and GPL-licenses it, you can’t use the modified code unless you want to impose the GPL! According to RMS, software under the GPL is like a spider plant: If one takes a piece of it and puts it somewhere else, it grows there too.

It’s also horribly vague what constitutes a “modified version”. If a GPL program has printf(“Hello World!\n”);, is it then a GPL violation to use that in any other program? At what point is it a “modified version” of an existing work? How much code does it need to be? Does the code have to be unique? How do you verify the real origin of the code? If you copy a large block from a GPL program, but change around the function and variable names, line breaks and indentation, have you violated the GPL? If you write code that, without your knowledge, is identical to part of a GPL program, have you violated the GPL?

Copyleft and copyright are, to an extent, two sides of the same coin. We should oppose both, and release our works into the public domain; a strike against the entire backwards “intellectual property” regime.

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property.

 — Thomas Jefferson