For the past six years or so I’ve been programming apps for iOS and Android. I’ve never published anything in the App Store or Google Play, but it’s been interesting and fun.

I learned Java in the mid nineties when it was still new and have been programming in Java ever since, so using Java in Android apps has never been an issue. The iOS languages are another story.

First there was Objective-C. I’m good with the C part, and it was nice that Objective-C was a superset of C instead of being a kinda-maybe-sorta superset like C++. The problem was the things that they added to C to get Objective-C. I don’t like all the nested brackets or trying to remember when I can use dots or when I can’t.

Despite the brackets and other quirks of the language, my biggest complaint with Objective-C was that it had limited use. Other than iOS and Mac apps, there didn’t seem to be much use for it. Not only that, but it was easy to play around with and try things out.

Then Swift came along. Xcode playgrounds provided a way to try things out, which was a good thing. Some aspects of playgrounds aren’t intuitive to me, but they are a step in the right direction. Even so, I still felt like I didn’t have a good way to learn the language. The problem is that a lot of mobile programming is about learning to use the APIs, and I always ended up learning just enough Objective-C or Swift to get by, rather than learning the language well.

For me, the best way to learn a programming language is to choose a project that I’m interested in and then use the new programming language to implement that project. I decided it was time to do that with Swift.

The project that I chose is an adventure game. (The adventure game itself is a topic for another post, so I won’t say anything more about it here.) Although I would like to make an adventure game that’s a mobile app some time, I wanted to focus on Swift rather than the iOS APIs, so I decided to make a command-line program. I’d never tried writing that kind of Swift program before, so I started searching the Web.

One post I found was this tutorial on raywenderlich.com: Command Line Programs on macOS Tutorial I wanted to write a command-line program and it’s a good tutorial, but the first thing it says to do is to start up Xcode. I am not a fan of IDEs. Maybe that comes from being an old-school programmer. (I learned how to program when dinosaurs roamed the earth in the mid seventies.) I put up with Xcode when I’m writing iOS apps, but I did not want to use it for this project. I wanted to write my code in Emacs, not Xcode. (There’s that old-school-programmer thing again.)

I continued my search and found this: Scripting in Swift Is Pretty Awesome Yes, it does have a screen shot of making a Command Line Tool in Xcode, but then it talks about putting a shebang line (#!/usr/bin/swift) to run things from the command line. That’s what I was looking for: no IDE required and a shebang line just like I can do with Python.

The author of the post mentions Python near the beginning of the post, which caught my attention because Python is my favorite programming language and has been for a long time. There are some things in Swift that are reminiscent of Python: No semicolons at the ends of statements, and no parentheses on conditions, to name a couple of syntax things. Swift does use braces rather than using indentation the way Python does. That’s fine by me because I like Python in spite of the whole indentation thing, not because of it. Like Python and JavaScript, and unlike Objective-C (at least the early versions), writing a dictionary literal is quick and easy. That’s a big thing for me, and is the reason I use dictionaries all of the time in Python and JavaScript but only use maps in Java occasionally.

I started to wonder if maybe in a few months I would have a new favorite programming language. Could it be? Alas, no. (Actually I probably shouldn’t say “alas” because I’m not particularly interested in finding a new favorite programming language.) Swift has some nice features, but there’s a problem that I ran into when I started writing my adventure game (which at this point is still pretty short).

In a word, that problem is “Foundation”.

You see, when you use the Swift interpreter from the command line, you can’t use frameworks. I didn’t think that would be an issue, but then I started to do things that any respectable scripting language should be able to do blindfolded with one hand tied behind its back. Things like splitting up a string or trimming extra white space from the end of the string. You can do those things pretty easily in Swift, as long as you have the Foundation framework. (Yes, there is a split global function in Swift, but it’s changed, and it seems to require the use of closures, and seemed a lot messier than it should be.)

The Krakendev post tells how you can use the Foundation framework in compiled command-line programs. It’s relatively painless, especially if you use make files like I do. (Did I mention I’m an old-school programmer?) But that’s only for compiled programs. It’s not like compiling a program takes a long time (although that was the motvation for the Krakendev author looking for a scripting language) but it is an extra step and it’s a big step away from the basic idea of scripting languages.

I’m still working on my adventure game project in Swift. Overall, I like the language. It’s possible that at some point a question about how to split a string might not cause arguments on Stack Overflow with 17 different answers (and counting?) to a question, but for now I’m resigned to using Foundation for my “learn Swift” project and sticking with Python as my favorite language, scripting or otherwise.

Here are compensated links to amazon.com for the Big Nerd Ranch guides to Swift and iOS programming:
Swift Programming: The Big Nerd Ranch Guide by Matthew Mathias and John Gallagher
iOS Programming: The Big Nerd Ranch Guide by Christian Keur and Aaron Hillegass

Geology Field Trip to San Rafael Swell

On April 2nd and 3rd I went on a geology field trip with my wife and one of her geology classes.  We made road-side stops at a few places along the way, but the main destination was San Rafael Swell.  In particular, we went on an eight-mile hike through two slot canyons, Little Wildhorse Canyon and Bell Canyon.

I had never been in a slot canyon before, so it was a fun hike.  There were a couple of places where we had to wade through some cold water, and ten or twelve places where we had to scramble up or down some rocks.  A few places made interesting puzzles in terms of figuring out the best way to get up or down.




The next picture should have something in it to show the scale, and if I were one of the geology students I would be busted for not including a pen or a shoe or something for scale.  I just liked the pattern.  (In case you’re wondering, this section of rock was probably two or three feet across.)



Just as we were finishing the hike we saw a bat flying around.  I took a couple of pictures on my phone thinking there was no way it would show up, but I actually got a more-or-less recognizable picture of a bat:


My New MUD

MUD stands for Multi-User Dungeon.  I’ve heard of people say that the D stands for Dimension instead of Dungeon, but I’m going with Dungeon, in spite of the fact that my first MUD isn’t a dungeon.

One of the great things about making a text-based MUD is that it lets me do all kinds of things with world-building that would be pretty much impossible if I had to have 3d (or even 2d) graphics for everything.  I’m fascinated with the idea of generating stories and emergent stories, and MUDs are a perfect platform for working with stories in that way.

I’m using Evennia to make my MUD.  It uses Python, which is my favorite programming language.  It’s powerful, well-designed, well-documented, and has a good community.