Scheme implementations

One of the difficulties in getting started with the Scheme programming language is picking an implementation. There are a bunch. Many of them are very good. Each has strengths and weaknesses. But those strengths and weaknesses don’t always readily line up with uses. So, recommending an implementation can be tricky.

Here is a pretty good guide to picking an implementation: “an opinionated guide to scheme implementations”

I know a lot less about Scheme than (wingo). I just play with it and use it instead of Bash/Perl/Python/Ruby whenever I can at work. Still, I was a Scheme newbie once, so here’s my suggestion:

If you’re using Linux or BSD, check to see if Guile is installed. (If you’ve got Mac ports or fink installed on your Mac, you might fall into this category as well.) There are things I love about Guile, and there are things I hate about it. But it is hard to argue with it already being installed on your machine. Grab a copy of SICP or The Little Schemer or whatever and go...

If you’re on Linux or BSD and you don’t have Guile installed, check your package manager for it.

If you don’t have Guile or if you’re ready for something more than Guile, get Racket. While the people working on Scheme standards are trying to figure out how to please academics and pragmatists, Racket has built a Scheme that is good for learning/teaching the language and has much of the “batteries included” that some other languages claim you should expect.

If you want Racket but without the GUI bits, you’ll have to dig a bit for Racket Textual.

Once you’ve had a taste of Scheme with Guile and/or Racket, then you can start to delve into what makes all those other implementations unique.

strncpy

If you aren’t a C programmer, bail now.

I’ve long wondered why strncpy and strncat were so brain-dead. Recently, I came across the answer. (Which made me go, “Oh...duh!”)

These functions look brain-dead when you try to use them to prevent buffer-overflows. But they weren’t designed to prevent buffer-overflows. They’re simply for copying a substring from the source. Their size parameters are simply meant to be the number of characters to copy from the source, not anything to do with the size of the destination buffer. The expectation, as with strcpy and strcat, is that you’ll figure out if the destination buffer is big enough beforehand.

Look into the strlcpy and strlcat functions from BSD if you haven’t already. They are designed for preventing buffer overflows. It also appears that the similar strcpy_s and strcat_s are on their way into the Standard.

(And now I’m wondering if there should be a strlncpy, that would take both the size of the destination buffer and a count of characters to copy from the source.)

You can also get by with snprintf as a safer replacement for strcpy if adding strlcpy or strcpy_s is not an option. Unfortunately, it can’t stand-in for strcat as easily since passing snprintf the same buffer as the destination and a source is a no-no.

The future of the Mac

The iOS-ification Of Apple’s Ecosystem

It does indeed look like the Mac is going to start looking more and more like iOS. Honestly, that makes me uncomfortable.

A key to the success of the iPhone and iPad is that they didn’t try to shoehorn desktop/laptop software onto the palmtop/tablet. I think the same logic holds that what is good for the palmtop/tablet isn’t necessarily good for the desktop/laptop.

(If I had my druthers, the iPad would be called a laptop and MacBooks would be called mobile desktops.)

Apple does recognize this. They’ve said that their research showed touch-screens don’t work well for desktop/laptop systems. But, still, they seem to be carrying “back to the Mac” farther than I’m comfortable with.

But that’s OK.

The reason I don’t have a Linux or *BSD system in the house anymore is simply that the Macs can do pretty much everything Linux can do. Perhaps as the Mac becomes more like iOS, I’ll have a reason to bring Linux back into the house.

It may even be that someday I won’t even have a Mac. The iPad and the Linux box will split everything that I used to use my Mac for.

iMac apps vs. iPad apps

In a comment to I’ve Changed My Mind About The iPad, Joeflambe wrote:

yuck, an iPad, really?

not a real computer since there are no real apps that you use daily on your current computer.

This seems like an interesting exercise. Let’s look at the most used apps on my iMac and whether there is an iPad equivalent.

• Safari: Check

I have a Flash blocker installed on my iMac, so lack of Flash on the iPad isn’t much of a change for me.

• Mail: Check
• iChat: Check (AIM)
• iCal: Check
• Address Book: Check
• iTunes: Check
• iPhoto: Check
• GarageBand: Check (StudioTrack)
• Evernote: Check

Now, to be fair, the iPad equivalents of the above do not always have all the features of their Mac counterparts. The main functionality is there. The rest...well, the iPad isn’t even a year old yet.

• Preview (as PDF reader): Check

The iPad has PDF reading built in, but no specific app for it. I do most of my PDF reading/referencing in GoodReader.

• iWork: Check

Some people will say matter-of-factly that nobody is going to want to write a term paper or create a spreadsheet on an iPad. shrug

OK, Pages for iPad doesn’t have footnotes...yet. It can’t print directly from the iPad—though Jobs himself has allegedly acknowledged that printing is in the works. (Yes, I’ve seen the photocopier pic. I LOL’d...the first time.) With my Bluetooth keyboard, I can’t see why I wouldn’t write a lengthy document with Pages for iPad. Even if I currently have to move it to my iMac for the finishing touches.

The whole keyboard + iPad topic is fodder for its own post.

I’ve created a few spreadsheets on the iPad. No less complex than those I would have created on my iMac. Although, I’m not that much of a spreadsheet user.

The iPad actually seems like a fine platform for creating presentations. We’ll see how it goes when I next need to create one.

• GuitarPro: Strike

I recently bought this Mac app. In fact, I bought it—in part—to produce content for the excellent TabToolkit iPad/iPhone app. (The fact that I can’t use it for that at the moment could be another post.) This is another app—like Keynote—that might actually work as well, if not better, on the iPad.

• DrScheme: Strike

Unfortunately, Apple’s rules don’t allow for an equivalent to DrScheme.

What if? Well, if it were a fairly straight port, it probably wouldn’t work very well without a keyboard. (Which is OK; I have one.) I can imagine a visual/touch interface for editing Scheme source code, though. (I’m imagining something like what I imagine the Viaweb editor was like.)

I think you could do a “DrEcmaScript” within Apple’s rules, though. As either an app (if it used WebKit) or a web app. I suppose a Scheme interpreter written in Javascript would be allowed, though perhaps not practical.

So...only two strikes.

It might be interesting to look through my iPad apps and see which ones don’t have Mac equivalents...or those for which I wouldn’t want a Mac equivalent.

Is the iPad going to replace my iMac? No, I don’t think so. Not anytime soon. It can, I think, come astonishingly close, however. There is a lot of overlap between the Mac, iPad, and iPhone; but there’s also enough outside those overlaps to justify each. The overlaps mean more flexibility.

The iPad may not replace my iMac, but imagine an iPhone OS desktop device. That might. Of course, being a programmer, I might still want a Linux/FreeBSD system for tinkering. (One of the nice things—for me—about Mac OS X is that I can get to the BSD personality underneath it when I want to.) For getting things done, however, I’m happy to use “app consoles”.

Mac OS a better Linux than Linux?

From “Apple's Leopard Is Better ‘Linux’ Than Linux”...

On the down side, people with malicious intent can use this extensive archive to figure out ways to hack the Mac. The fact that this hasn’t happened—like I said above, Darwin has been available for years—is a testament to the integrity of the Apple community.

No, it means that it’s really true that openness leads to better security. In fact, Apple took a lot of their open source code from OpenBSD, a system known for its security focus.

So here are my observations: Mac OS X, and Apple’s development paradigm, is the anti-Linux. And it’s Steve Jobs’ big accomplishment that Apple has built a better (I should actually say “more successful”) Linux than Linus Torvalds has ever been able to do.

This seems to imply that Mac OS X and Linux (or Jobs and Torvalds) have the same goals, which clearly has never been the case.

Edit: It would seem I’m misremembering. It seems Apple leveraged FreeBSD more than OpenBSD. See the comments.