Sandwiches.

XKCD owns.


#include <stdio.h>
#include <unistd.h>


int main (int argc, const char * argv[]) {
if(getuid() != 0) {
printf("What? Make it yourself.\n");
return 1;
} else {
printf("Okay.\n");
return 0;
}
}

June 3, 2007 at 4:55 pm 4 comments

Whither High School Computer Science?

Last year, when I finally decided that I wanted to pursue a career in computing and programming, I decided to take the AP Computer Science class my high school offers (skipping Computer Science I, which uses Visual Basic 6). Though I had heard bad things about Java in the past, I figured it couldn’t be all bad – after all, in order to get kids excited about CS, they wouldn’t teach in a crappy and flabby language, would they?

Well, they did.

Now, I could launch into a rant about how CS doesn’t necessarily have anything to do with programming languages, how all that’s really important is algorithms and big-O efficiency, how aspiring CS students need math more than anything else, and so on and so forth in the vein of Knuth and Dijkstra. But I don’t believe it in the slightest. Sure, CS doesn’t necessarily have anything to do with any particular programming language, as shown by the decades of computer scientists who made stunning achievements simply through logic, mathematics and perseverance; however, CS is only interesting as an academic field because there are things which computers can do and humans can’t (and vice versa). A CS student trained without a knowledge of programming languages is nothing more than a mathematics student.

But I also believe that languages shouldn’t interfere with learning through syntactic or design flaws. Java is a major sinner in these regards. We spent several weeks going over (in excruciating detail) the difference between an int and an Integer – what, exactly, does that have to do with CS? Sure, we learned something about OOP – except for all the interesting things, such as the history of OOP, the reasons behind encapsulation, the uses of multiple inheritance (and the problems and solutions therein), and how OOP has changed from its pure Smalltalk roots to its bastardized Java form. We learned that we need to predeclare variables in a statically-typed language, but not any of the reasons why static typing may or may not be a good thing (speed, type safety, robustness, etc.).

And there’s so much we didn’t learn. We spent maybe a week on sorting and searching; never mind that the truly remarkable thing about computer-based algorithms is that they can search, sort, and process data in ways that no dead, ink-based y=mx+b equation ever could. We didn’t look at Nextstep’s use of object-orientation to power an entire operating system, quite possibly the most concrete use of OOP ever. If we wanted to focus on practical uses of Java, why didn’t we learn how to use Eclipse, the best Java IDE out there? Why did we use Java 1.4 instead of Java 1.5 or 1.6, thereby abandoning templates, primitive autoboxing and helpful classes such as Scanner?

If we truly wanted to learn about writing good code and learning the fundamentals of computer programming, we should have used Smalltalk. Using Squeak or VisualWorks or Cincom, we could learned how a truly, 100% object-oriented programming language works, the history of the GUI, how to create an intuitive GUI without endless Swing components, how to program in a robust, intuitive and simple language free of warts, and, most importantly, how to use computers to do things and solve problems that only computers can do.

Instead, we learn Java.

May 11, 2007 at 11:12 am 19 comments

Cocoa Snippet: Detonate your Cursor

- (IBAction)poofCursor:(id)sender
{
NSShowAnimationEffect(NSAnimationEffectPoof, [NSEvent mouseLocation], NSZeroSize, NULL, NULL, NULL);
[NSCursor hide];
}

In case you can’t figure it out, this code shows the *poof* animation one gets when dragging items off the Dock at the current mouse location, then hides the mouse. The overall effect resembles the mouse cursor exploding.

April 18, 2007 at 12:33 pm

Five Things that Suck About Objective-C and Cocoa

Things have been quiet here in this blog. Too quiet. As such, I’m keeping the name-five-things-you-hate-about-a-language-you-like ball rolling, having seen it rolled with zest and vigor by brian d foy, Titus, Jacob Kaplan-Moss and Vincent.

Without further ado:

Five Things that Suck About Objective-C/Cocoa:

  1. Syntax for NSString literals. For the uninitiated, in Objective-C code enclosing "insomnia" in simple double-quotes creates a C-style char[] string; if you wish to use the far more powerful and versatile Objective-C NSString class, you must add an @ (making @"insomnia"). Backwards-compatibility with C is a good and useful thing, but why require more keystrokes to do the most commonly-used thing? I myself last weekend puzzled over a wonderfully non-specific “invalid reciever” error for a long time before realizing that I forgot an @ when sending strings to an arrayWithObjects: method. Aside from that, why use the @-sign as a prefix for NSStrings when it’s used in a plethora of other places, such as @interface, @implementation, @end and @selector? Though 90% of my @-key-presses in Textmate are prefixes to NSStrings, I can’t have a keypress of @ automatically expand to @”” – there are too many other things to do with the poor little @-sign. The oft-neglected | (pipe or vertical bar, I’ve heard both) character is far less disruptive to the flow of typing.
  2. reallyLongAndCamelCasedMethodNamesGetAnnoying. I refer specifically to the lovely NSWorkspace method openURLs: withAppBundleIdentifier: options: additionalEventParamDescriptor: launchIdentifiers:
    And ObjC method names can be concise yet informative – take for example NSString’s compare: options: range: locale:. I must admit, this complaint is not entirely valid, especially considering Textmate/XCode’s fancy code completion.
  3. No operator overloading. Come on, guys – why reject this crucial part of Smalltalk heritage? I, for one, am sick of writing objectAtIndex and objectForKey: as compared to Python’s []. Though Smalltalk allows one to define new operators, I’d be perfectly happy to settle for a few overloadable operators (string concatenation is desperately needed).
  4. Mysterious helper methods. I didn’t know of the existence of NSHomeDirectory(), NSTemporaryDirectory(), or NSClassFromString() until very recently. True, this is my fault, but I think that F-Script’s idea of storing all of these methods in a singleton System object is excellent, and much more in line with Objective-C’s Smalltalk heritage. (Actually, I have a half-finished ObjC class that makes NSBeep() and all those other miscellaneous C functions into class methods; if there’s any interest, I’ll finish and release it. I suppose that makes this complaint invalid. Oh well.)
  5. File management is a mess. Essential code is scattered throughout NSWorkspace (in all its brain-dead glory), NSFileManager, NSFileHandle, NSPipe, NSDirectoryEnumerator, and NSData – few things are as infuriating as hunting down the correct class that does exactly what I want. (Actually, no. Finding a better solution after thirty minutes of hacking around some perceived inadequacy is worse.

So there you have it. To be honest, it took me quite a while to write this, mainly because Objective-C is such a great language and Cocoa is such a great set of libraries. I suppose that the imperfections in a consistently useful and friendly toolkits stand out, and in retrospect I sort of feel guilty for my picky attitude. After all, it could be much, much worse.

April 5, 2007 at 11:59 pm 3 comments

This Is Worrying


Last login: Sun Mar 18 22:39:27 on ttyp1
Welcome to Darwin!
ok-computer:~ p_trick$ python
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> True, False
(True, False)
>>> __builtins__.True, __builtins__.False  = __builtins__.False, __builtins__.True
>>> True, False # oh dear
(False, True)
>>> if False: print "Oops."
...
Oops.

Is there a reason for this?

March 19, 2007 at 2:49 am 2 comments

Old School

In a raucous debate with my dad about my post regarding the merits of C, he made the following analogy:

“Condemning C because of its poor string support is like condemning a Ford Focus because of its poor ability to cruise at 35,000 feet.”

Touché, Dad. Touché.

March 18, 2007 at 3:53 pm

An Apology to SQLAlchemy

Dear SQLAlchemy:

Before I started working with you, I became familiar with the Django and SQLObject ORM’s. They use the intuitive technique of assigning attributes to a model, like so:

class Person(SQLObject):
fname = StringCol()
mi = StringCol(length=1, default=None)
lname = StringCol()

This is an intuitive and pleasing paradigm, and I was perfectly content until I heard some clever people say nice things about you. I enjoy working in new environments, so I took a look at you. Much to my suprise, I hated you. Quite strongly, in fact. It felt like taking a giant step backwards going from the above SQLObject code to the following:

person_table = Table(
Column('fname', String(255)),
Column('mi', String(1)),
Column('lname', String(255)))

class Person(object): pass

assign_mapper(Person, person_table)

I recoiled. Why did it take so much more typing in SQLAlchemy to make a far less pythonic solution than that of SQLObject? I then ignored you until I realized that my SQLObject code was littered with list comprehensions instead of good, Right-Thing SQL; I gave you another shot, but I ran you through some more tests.

I realized that you could map multiple tables onto one object and one tables onto multiple objects, and quickly realized that this strange breed of polymorphism/inheritance, alien though it was, totally kicked the crap out of Django’s ORM. (Which, incidentally, still doesn’t support model inheritance.) Declaring tables and objects as one thing, though convenient, leads to sloppy and inefficient code. You made me realize that, and I thank you.

And then the neat ideas started flowing every which way – composite primary keys (why didn’t I think of that?), manual save-and-reload (crucial when just mucking about with data), backreferences (I am Ozymandias, king of kings! Look upon my massive amount of automatically updating references, and despair!), properties (less code to write = good), ActiveMapper (mmm…conciseness), and the way assign_mapper still allows me to treat tables inside objects as attributes.

I owe you an apology, SQLAlchemy. I wronged you.

Sincerely,

Patrick

January 29, 2007 at 7:23 pm 1 comment

Older Posts Newer Posts


About Me



I'm Patrick Thomson. This was a blog about computer programming and computer science that I wrote in high school and college. I have since disavowed many of the views expressed on this site, but I'm keeping it around out of fondness.

If you like this, you might want to check out my Twitter or Tumblr, both of which are occasionally about code.

Blog Stats

  • 556,426 hits

Follow

Get every new post delivered to your Inbox.