#52WeeksOfCode Week 23 – IRC Chat

Week: 23

Language: IRC Chat

IDE(s): Messages + Jabber + BitBee + Chatzilla

History (official):

(From the homepage of #irchelp)

“/I-R-C/ n. [Internet Relay Chat] – IRC provides a way of communicating in real time with people from all over the world. It consists of various separate networks (or “nets”) of IRC servers, machines that allow users to connect to IRC. IRC is very similar to text messaging, but designed around communicating with large groups of users instead of one on one.”

History (real):

Kids, way back in 1988 (ask your parents), the Internet was still mostly called the Arpanet and was not available to average people. Even if you did have access, you had to use your phone to connect to it.

Not your cell phone but a regular old-timey phone. You know, that thing plugged into the wall at your grandparent’s house that they use to  talk with you at Christmas?

Anyway, the Internet For The Rest Of Us(™) consisted of Bulletin Board Systems (BBSs). These were PCs sitting in someone’s basement connected to a phone line. Still dial-up,sure, but you could share files, play games, chat with other users and have lively discussions.

Though BBSs had a chat program, Jarkko Orkarinen, a student at University of Oulu in Finland, decided that he wanted Internet users to be able to connect with BBS users. So while he was upgrading the chat program on his university BBS, he developed IRC (Internet Relay Chat).

IRC is still around, despite having lost a lot of its user base. Its arcane command syntax makes it intimidating for non-technical users, but its flexibility and open standards make it a useful platform for automated messaging. For example, two normally incompatible software programs that have no communication mechanisms in common can easily be set up to exchange data via IRC.

Discussion:

IRC is actually a communications protocol. In other words, a set of language rules. Any programs that speak IRC can talk to each other, regardless of operating system or platform. IRC sends and receives messages in plain text which makes it pretty easy to write code for both servers and clients. That being said, it’s not exactly the Queen’s English:

/join #52weeks

is the command to join a chat room (channel) named 52weeks. On the other hand, pretty much any program that can send or receive text can speak to an IRC server.

I’d like to bring IRC kicking and screaming into the 21st century for my own amusement. In other words, I want to use the default chat application on my MacBook (Messages) to talk to someone on IRC.

The challenge is that Messages doesn’t know how to talk to IRC and vice-versa. However, there is an open messaging protocol called XMPP (eXtensible Messaging and Presence Protocol). Originally named Jabber, the idea was to create a sort of lingua franca for instant messaging.

The first step is to install a Jabber server. The easiest way to do this is with Openfire. It’s easy to setup, open source and cross-platform. I got the server running, setup an account for myself, pointed Messages to the server and I was up and chatting.

Connecting to Jabber from Messages

Connecting to Jabber from Messages

Okay, there was nobody to talk to but the point is, I was at least able to talk to myself.

Now to set up a gateway to connect my Jabber server to my IRC server. I’ve already set up an IRC server using ngircd (installed from MacPorts). I can verify the server is working by connecting to it with Chatzilla, a Mozilla Firefox addon that lets me easily connect to an IRC server using the URL irc://<server_name> in the location bar.

It’s important to use the same username on the IRC end as on Jabber. A gateway’s good but it can’t read your mind.

Now for the protocol gateway to connect Jabber with IRC. I chose BitBee, a Linux/UNIX  IRC server that knows how to connect to other instant messaging services. I installed BiBee using MacPorts, stopped the ngircd server (I didn’t need it anymore) and started BitBee.

Chatzilla connection to BitBee

Chatzilla connection to BitBee

The key to managing BitBee is the &bitlbee channel. This is where you add the accounts for your other chat services. I set up a Jabber account called tsinclair_irc with the password ‘password’ and added the account to BitBee:

account add jabber tsinclair_irc@macpro15.local password

Now to test the connection. First I sent a message from Jabber to IRC:

Connecting to IRC from Messages through Jabber

Connecting to IRC from Messages through Jabber

Now to see if the message came through on Chatzilla:

Message to Jabber from IRC

Message to Jabber from IRC

I sent “Hello yourself!” back:

Message from Jabber to IRC

Message from Jabber to IRC

Let’s look at the setup from 100,000 feet:

Overview of my messaging setup

Overview of my messaging setup

All along the way, I went for the easy option where available though parts of it were harder than they needed to be.

 

Advertisements

#52WeeksOfCode Week 32 – Assembly Language

Week: 32

Language: Assembly

IDE(s): SciTe + NASM

History (official):

(There is no one version of Assembly language since it is aimed at specific hardware. However, I did find this in the Forward for The Art of Assembly Language by Randall Hyde which I thought was amusing):

Egads. What kind of book begins this way? What kind of author would begin the book with a forward like this one? Well, the truth is, I considered putting this stuff into the first chapter since most people never bother reading the forward. A discussion of what’s right and what’s wrong with assembly language is very important and sticking it into a chapter might encourage someone to read it. However, I quickly found that university students can skip Chapter One as easily as they can skip a forward, so this stuff wound up in a forward after all.

So why would anyone learn this stuff, anyway? Well, there are several reasons which come to mind:

 

  • Your major requires a course in assembly language; i.e., you’re here against your will.
  • A programmer where you work quit. Most of the source code left behind was written in assembly language and you were elected to maintain it.
  • Your boss has the audacity to insist that you write your code in assembly against your strongest wishes.
  • Your programs run just a little too slow, or are a little too large and you think assembly language might help you get your project under control.
  • You want to understand how computers actually work.
  • You’re interested in learning how to write efficient code.
  • You want to try something new.

 

 

Well, whatever the reason you’re here, welcome aboard. Let’s take a look at the subject you’re about to study.

History (real):

I feel the need to lend some perspective before I dig into Assembly language, otherwise known as Assembler.

This is a picture of the first personal computer ever sold, the MITS Altair (from OldComputers.Net):

MITS Altair image, courtesy of OldComputers.net

The First Personal Computer

 

The Altair was introduced in January of 1975. It had 256 bytes of RAM (up to a maximum of 64K), a 2.0 MHz Intel 8080 CPU and was available for $395 as a kit. You got a box of parts. You had to make your own circuit boards. If you wanted it pre-assembled, that was an extra $255.

I want to draw your attention to the front panel of this computer. Yes, I mean all of the blinky lights and flippy switches. If you wanted to program this personal computer, you had to flip the switches on the front panel, entering your commands one word at a time in machine language (a series of 1’s and 0’s).

Now because there was no floppy drive, no hard drive, no secondary storage of any kind, if someone happened to trip over the power cord while you were flipping switches, you had to start over from the very beginning.

I mention this to tell you that no matter how arcane and hard to write, maintain, debug, read and understand Assembler is, things could be (and have been) much, much worse.

Discussion:

While Assembler was a step up from machine language, it wasn’t what you would call a giant leap. You still have to shuffles 1’s and 0’s around and have a deep understanding of the underlying hardware of your computer, but at least it took slightly less time to write code.

But if we now have all of these high-level languages, why bother writing code in Assembler?

  • Speed – Assembler programs are extremely efficient and very fast.
  • Size – The efficiency of Assembler also means that programs take up very little space.
  • Power – Since you’re working very close to the hardware, you can do things with Assembler that you can’t do with higher level languages

It’s not as if you have to choose between one or the other. If you have a section of code that needs to run quickly and efficiently you can write it in Assembler and hook it into your higher-level code.

For this exercise I decided to use NASM (The Netwide Assembler), a free, cross-platform assembler for Intel-compatible processors. There doesn’t seem to be a good IDE for Assembler (rumors exist of an Assembler plugin for Eclipse) so I’m going to use a text editor. Though NASM is available for Mac OS X, documentation on how to use it is limited or out-of-date. Linux, on the other hand, is well-documented so I’ll be using Debian 7 for my development platform and SciTe as my text editor. It’s free, cross-platform and does syntax highlighting for a number of common programming languages.

I looked for a “Hello World!” program in Assembler and thanks to a very nice tutorial from Ray Toal at Loyola Marymount University, this is what I found:

Hello World in Assembler

Hello World in Assembler (Using the SciTe text editor)

Compiling and running just involved a bit of typing.

Compiling and running code

Compiling and running our code

Before we look through the source, let’s see what’s happening at the command line.

nasm -felf64 hello.asm

The source code file is called hello.asm. This command tells NASM what format (-f) the output should take. In this case it’s 64-bit ELF (Executable Linkable Format, the standard binary format for Linux executables, object code and software libraries). NASM takes the source code (hello.asm) and compiles it into the object code file hello.o. Object code is machine code, a set of binary instructions.

However, as far as the computer is concerned it’s just a pile of 1’s and 0’s.

ld hello.o && ./a.out

There are actually two commands here.

ld hello.o

The first runs the linker (ld) to link the object code with the ABI (Application Binary Interface) for the target platform. It’s like putting a ‘Start’ button on our code so our processor knows how to run it. The default output is an executable called a.out. The line

./a.out

runs the program to print “Hello World!”. The ‘&&’ between the two commands simply means ‘if the first command succeeds run the second command, otherwise just stop’.

Now let’s go through the source code line-by-line:

# ----------------------------------------------------------------------------------------
# Writes "Hello, World" to the console using only system calls. Runs on 64-bit Linux only.
# To assemble and run:
#
#     gcc -c hello.s && ld hello.o && ./a.out
#
# or
#
#     gcc -nostdlib hello.s && ./a.out
# ----------------------------------------------------------------------------------------

 

Anything that starts with a pound sign (hashtag for you youngsters) is a comment and is ignored by nasm. This is pretty standard Linux syntax and you may see the semicolon (;) used for a similar purpose on other platforms.

       .global _start

The global keyword marks symbols that need to show up in the output (hello.o). As you might suspect, NASM is showing the linker where the executable starts.

       .text

This is just a name for a section of code. Remember, the output is just a string of 1’s and 0’s which could mean anything, depending on where you start reading and how many bits you read at a time. This keyword .text tells us that that the following section is runnable code, not data.

_start:

As stated above, here’s where our actual code starts, in case it wasn’t obvious.

       mov     $1, %rax
       mov     $1, %rdi
       mov     $message, %rsi
       mov     $13, %rdx

A machine language instruction consists of two parts, the opcode (what the code should do) and the operand (the data on which the opcode should act). In these four lines, .mov is the opcode for loading data into a register (a small fast chunk of memory used for temporary storage). These four instructions copy data into the registers rax, rdi, rsi and rdx.

The first (rax) holds the location of the system call we’re going to use, which is write ($1).

The second (rdi) is the memory location where we’re going to write our message which is standard output ($1).

The third (rsi) is the string we’re going to write to output. ($message is just a label for the string data, which we’ll find elsewhere in our code. Hang on.)

The fourth (rdx) is how much of our message to print, 13 bytes (or characters).

We’re loading a sequence of commands. Write 13 bytes of our message to standard output. It’s like setting up a series of dominoes, just waiting for that lone finger to start the string of activity.

And here comes the finger:

            syscall

Since our system already knows how to print strings, why reinvent the wheel? This opcode tells our processor to read the four sections of memory we’ve set up and act accordingly. We still have to tell the processor we’re done so let’s set the dominoes up again.

       mov     $60, %rax
       xor     %rdi, %rdi

The first loads the exit command ($60) into our register rax. The second is the exit code for our program to spit out, in this case 0. Ready for the finger again?

       syscall

Finally we come to our data section.

message:

       .ascii  "Hello, world\n"

This is labelled with message: so we can refer to it elsewhere in our code, as we saw above. In this case, it contains the string that we want the system to print to standard output. It’s labelled as plain old alphanumeric text, because we have to specify how we want the processor to interpret those 1’s and 0’s.

On the plus side, Assembler is a very powerful way to write fast code that takes up very little memory space. On the minus side, you have to keep track of where your data is at all times and what takes a single line of code in a high-level language takes thirteen in Assembler.

Not that there’s anything wrong with that.

Hyde, Randall. The art of assembly language. No Starch Press, 2003.

 

#Book Review – Code Reading

The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or formally used as a method for learning how to design and program.

 

Aspiring writers are always told to read as much as they can if they want to become better writers. As Dave Thomas points out in his foreword to Diomidis Spinellis’ Code Reading, aspiring programmers almost never get this advice. By code, of course, I mean the program source code, the fundamental recipe for any piece of software.

Imagine that you’re taking a writing course. You get assignment after assignment – persuasive essays, memos, poetry, research papers or prose. Now imagine that you have to do every one of these assignments from scratch, without any examples. You have to work everything out yourself.

This is the traditional method of teaching programming. I know because I used to teach programming classes.

Code Reading is both refreshing and an eye-opener. Not only does Spinellis present a solid case for the habit of reading program source code, he also fills his book with code examples, complete with commentary. Though the examples are mainly from Java and C, the lessons learned can be applied to any programming language.

Just to be clear, the code presented is not from the toy examples found in programming textbooks. This is material from real, working software projects. The book covers major programming topics and even includes analysis of a complete, working program. Spinellis gives tips and techniques for the novice code reader to aid them in developing their skills.

From my own experience, reading code can be very educational, even entertaining. Every programmer tries to put their own personal stamp on their work and part of the fun is seeing the human mind behind the algorithms.

For example, I was teaching game software development and wanted to get my students some practice in reading code. We downloaded the source code for BZFlag, a tank game based on the video game BattleZone combined with Capture the Flag. It’s a fun, cross-platform game that you can play solo or over the Internet with teams.

There was one particular feature in which I was interested. During play, you can set your tank to AutoPilot mode and let it play for you. This makes a nice change from having to pause your game whenever you have to get up and take care of business.

We grovelled through the source code files for a bit and I finally found the sections having to do with AutoPilot. As I read them, I spotted some code that looked very intriguing but was never actually called by any other part of the program. It looked like someone was trying to build a heuristic system for the AutoPilot mode. In short, it was meant to have the program build a solution starting with the goal and working its way backwards. It was very clever and had a lot of potential. I could add see why it hadn’t been  implemented due to the inherent complexity of the method.

The fact that the code was just left there, unfinished, was fascinating. When I saw that code, I put myself in the mind of that programmer. I’ve also had coding ideas that got stuck in blind alleys. But here was someone like me, trying to solve a problem in an interesting way and failing that, leaving a note for the explorers to come after in hopes that they would ultimately succeed where he did not.

This book shouldn’t just be on any programmer’s reference shelf, it should also be the basis of at least one undergraduate programming class.


Spinellis, Diomidis. Code reading: the open source perspective. Addison-Wesley Professional, 2003.

#52WeeksOfCode Week 28 – Vala

Week: 28

Language: Vala

IDE(s): TextWrangler

History (official):

(From the Vala project home page)

“Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C..”

History (real):

Oh, there’s so much to unpack here.

new programming language” – okay, I’m with you so far.

modern programming language features” – I think I need some details on this one, bub.

GNOME developers” – Wait, I know this one! GNOME is a free, open source, cross-platform desktop environment. It’s mainly found on Linux systems, but you can also install it on Windows, Mac OS X and other UNIX variants.

The GNOME Project was started because the major desktop at the time, KDE (K Desktop Environment) used some proprietary code which made it problematic for certain open source projects. GNOME, on the other hand, is built on completely free code and all of the source code is readily available for download and hacking.

without imposing any additional runtime requirements”- A runtime system consists of any additional files required to run a program. Every piece of software has some kind of runtime requirements. In the case of Vala, this statement simply means that you don’t need to install anything extra to run applications written in Vala. (We’ll get to the reason why in a bit.)

without using a different ABI” – ABI is short for Application Binary Interface. An ABI, on a high level, is a set of rules for communication between different software modules. One use of an ABI is to allow programs to talk to the host operating system. The ABI specifies things like how to pass information from one program segment to another. Normally, a developer doesn’t have to worry about the ABI (it’s taken care of by his development system) except in certain cases when he’s writing code in different programming languages and he needs all of his programs to talk to each other. The ABI referred to in the official statement above is the GNOME ABI. (Like the runtime thing above, we’ll get to the why in a bit. Spoiler alert: it’s the same reason for both.)

To sum up, Vala is a good language for writing GNOME applications because you don’t need to install anything extra except a Vala compiler. Sounds good!

Just a minute. GNOME developers were writing software before Vala came along. Why do we need another programming language?

For the answer, we’ll have to send our imaginations back to the early ‘70s. The Summer of Love was still in recent memory, the conflict in Vietnam was winding down and the voting age was lowered from twenty-one to eighteen. (“Old enough to fight, old enough to vote”)

Almost unnoticed during all of this excitement, Bell Labs researcher Dennis Ritchie was creating a new general purpose programming language that he called C. This by itself wasn’t that exciting but C was used to write the first release of AT&T Unix.

I can sense I’m not exactly blowing your skirt up with this, but hear me out.

Prior to that time, computer operating systems (the software that runs the hardware) were written directly to the hardware using assembly language. An assembly language was very low-level code that produced software that would only run on a specific type of hardware. That meant that if you wanted to run Awesome OS (™) on a different type of computer, you had to completely rewrite the operating system. Needless to say, this slowed down innovation in the computer industry significantly.

Here’s my point.

C was the first high-level (ie. human-readable) programming language that could be used to write operating systems. The beauty of high-level languages is that as long as you have the original code, getting programs to run on different computer hardware is pretty easy.

Dennis RItchie, in short, was the father of the portable operating system.

The consequences of this were huge. Computers can’t run without an operating system and the difficulty of creating an operating system for new computer hardware was a serious limitation to computer hardware innovation. Ritchie’s work revolutionized the computer industry.

What does this have to do with Vala? True to its UNIX roots, GNOME was written in C. Now C is a solid reliable programming language (as evidenced by the fact that it’s still in use over four decades later). However, C doesn’t have the features of more modern languages and so for general purpose programming it imposes more and more limitations on the developer as the state of the art advances. They have to work harder just to stay in place.

Vala is based on a pretty clever idea. It has all of the snazzy bells and whistles you expect from a modern programming language so it’s easy for developers used to newer languages like C# to pick up.

But the Vala compiler converts Vala code to C code which is then compiled into just another GNOME application. That’s why you don’t need to install any extra software or libraries to run programs written with Vala.

Discussion:

Once you have the Vala compiler installed, all you really need to start writing code is a text editor. I installed Vala using MacPorts and I’m going to use TextWrangler to write my code.

A basic Hello World program in Vala looks like this (courtesy of the GNOME Vala tutorial):

int main () {
   print ("Hello World\n");
   return 0;
}

 

Compare this to the same program (courtesy of the Content Creation Wiki) written in C ( and Vala reveals its roots:

#include <stdio.h>
#include <stdlib.h>

 int main(void)
 {
  printf("Hello, world\n");
  return EXIT_SUCCESS;
 }

Now I just compile my code and run the program:

valac hello01.vala
./hello01
Hello World

Pretty straightforward, but not very modern. Let’s jazz it up a bit using some modern paradigms (courtesy of Dream.In.Code):

using GLib; // not required
public class HelloObject : GLib.Object {
   public static int main(string[] args) {
       stdout.printf("Hello World!\n");
       return 0;
   }
}

It still works:

valac hello02.vala
./hello02
Hello World!

The Vala Project has created a programming language that both embraces modern development techniques and honors its roots.

#52WeeksOfCode Week 24 – Game Programming

Week: 24

Language: Game Programming

IDE(s): Twinery 2.0 Beta

History (official):

This is the only entry in this sequence which is completely open. Since I can use any language or platform I want, there’s nobody to pick on.

History (real):

When I was a program chair for our game software engineering program, I was given a lot of textbooks from optimistic publisher reps. One that stood out from the others was “Beginning C++ Game Programming”. (Dawson, Michael. Beginning C++ Game Programming (Game Development Series). Premier Press, 2004.)

We ended up not using the book because it didn’t target a particular platform like Windows or game programming framework like Unreal. But when I took a closer look at it, I realized it wasn’t actually about game programming.

It was about learning to code by programming games.  The book took you through basic programming concepts, such as control structures, loops, data structures and even object-oriented programming. These are all of the things that would be covered by a beginning to intermediate programming text. What made it different was that every piece of code was either a game or gaming-related (like a character generator for an RPG). It almost made me want to learn C++ over again because the book made it look like so much fun.

While technology and education methodologies have progressed substantially since I was a lad, programming textbooks still have really boring assignments. The success of gamification in learning as illustrated by Khan Academy, Code Academy  and Google’s Oppia project suggests that it’s time to bring that into the classroom at the college level.

Discussion:

The goal this week is to write a game. I can pick any language, framework or platform I want. I am, in fact, spoiled for choice.

When I was a lad and computers were the size of draft horses and ran on steam power, computer games were text-only. They were a lot like those “Choose Your Own Adventure” books and some of them, most notably from Infocom Games, were very sophisticated.

Though text adventures are not as popular as they once were, they’re still around, supported by an enthusiastic community of developers and storytellers. As a result, there are a number of software programs that make it easier for you to develop a text adventure and users post their files for others in the community to try.

At one time I wanted to try my hand at this and I used Inform, which was a powerful tool that included a scripting language and let you build very complex worlds. Unfortunately learning to program in Inform was definitely more work for me than my casual interest in creating a game so I did a quick project and never picked it up again.

We have more choices these days, however. A newcomer to the field is Twine, a tool that is more in the spirit of the Choose Your Own Adventure books and so not as sophisticated as Inform. Consequently, it’s much easier to build a game. There are two versions of Twine. One is a downloadable package for Windows or Mac OS X. The new version (which is still in beta) lets you do all of your development in a Web browser and then download your game as an HTML file. That looked like fun, so I started it up in a browser window.

Twine game editor

Twine Web-based game editor

The interface is a bit sparse so it took a bit of experimentation to get started. You are presented with a blank canvas. To begin you add a Passage, which is what I would have called a room. When you do, you’re presented with the Passage editor.

Passage edit window

Editing a Passage

You give the Passage a name. You can also add Tags, which contain information that is not visible to players but might be anything from a simple annotation to a link to run a custom script before the story starts. Tags are totally optional.

Unless you want the shortest story ever, you need to link to other Passages.  The easy way to do this is by adding the name of the Passage, surrounded by double square brackets, as you can see above. If the Passage you name doesn’t exist, it will be created and linked to the current Passage. You can put as many links as you want to other Passages. You can also create the new Passage directly in the editor and link to it later.

Continue creating and editing Passages until you reach an end point for your game. At any time you can play-test your game in the editor.

Starting the game

Starting up my game

Note that all of your data is saved locally in your Web browser so if you quit without saving then you’ve lost all of that work. Fortunately you can archive your work in progress by periodically clicking on the Home icon in your editor and going to your main work page.

Twine Web Main Page

Twine Web Editor home page

There you can also start a new story, import story files and work on other stories. Once you’ve completed your game, you can download it as an HTML file and either post it as a Web page or open it locally in a browser.

It was very quick and easy. Though I could have jazzed it up with stylesheets and javascripts, that’s totally optional. The thing is, I had so much fun putting using this that I can see myself coming back to it.

I may not have the Great American Novel inside me but there are plenty of short stories.

#52WeeksOfCode Week 22 – PHP

Week: 22

Language: PHP

IDE(s): TextWrangler plus MAMP

History (Official):

(From the homepage for the PHP Group)

“PHP is a popular general-purpose scripting language that is especially suited to web development.

Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.”

 

History (Real):

PHP is a very popular programming language and runs on over 200 million Web sites, including some very large ones like Facebook. Not bad considering PHP was not originally conceived as a programming language.

According to creator Rasmus Lerdorf in a 2012 interview with the IEEE house magazine Computer, PHP was originally just a collection of utilities he hacked together to make his web page development easier. He found he was writing the same code over and over again for his clients so like any good coder he took it upon himself to automate the process.

All well and good.

But other programmers saw what he was doing and asked for copies of Lerdorf’s toolkit. Hackers being who they are, when they found bugs they fixed them and passed the changes back. Eventually he handed off responsibility for pieces of his code to others and PHP grew in scope. Each programmer added functionality to scratch their own particular itch and contributed their code back to the community. Lerdorf mostly stayed out of any code architecture decisions, preferring to leave that to the community.

Those of you who are familiar with the open source development process may see the fundamental flaw here.

For the rest of you, let me explain. When you set out to create a programming language (or any non-trivial software project), you create a specification. This is a document that sets out the conventions that everyone has to follow in order to participate. For example, you make a list of keywords, words that have special meaning in the language. This lets others know that these words can’t be used for anything else.

With a specification document, you can have many developers working on the project and have some assurance that they won’t be stepping on each others toes.

A specification document can and does get updated but it’s usually in a way that adds features or project scope without significantly changing the basic rules.

Next, even an open source project staffed by volunteers needs someone who is the final word on changes. This could be an individual (like Linus Torvalds with Linux) or a group (like the team that manages Debian).

Without these, the software project has no real structure. Features get added and taken away without much of an explanation and some functionality may be either missing or duplicated by multiple redundant methods.

The fact that PHP is so widely used and seemingly robust is more of a testament to the heroic efforts of the community of PHP developers who are applying spit and baling wire to make this code work.

But there are always consequences.

Just for fun, I searched for ‘php sucks’ and got almost 10,000 hits. After glancing through the links, here are some of the most common complaints:

  • The code libraries are a disorganized mess
  • Unnecessary duplication of functionality
  • No coherent design
  • Messy and complex
  • Incorrect or incomplete documentation
  • Data input needlessly complex or error-prone
  • Poor code readability

These are some of the milder complaints. There are more, but you need to be a programmer to fully appreciate the horror.

I don’t blame Lerdorf. By his own admission, PHP was never meant to be a programming language. It was just a bunch of neat, useful hacks that a talented, enthusiastic community of programmers adopted as their own. In a sense, the story of PHP is a pure expression of the Hacker Ethic.

NOTE: This is not a PHP hit piece. As I’ve said, I’m not a professional programmer, just an interested bystander. I have no dog in this fight. I just have an incurable compulsion to lend perspective.

Discussion:

First off, we need to install PHP. This is pretty easy. You can either use one of the pre-built installers or just build it from scratch.  Mac OS X comes with free programming tools as an optional install so I already have PHP on my system.

In theory you can use PHP like any other scripting language, but since it’s designed for Web development you really need to set up a Web server that understands how to run PHP code. Fortunately some very smart people set up a software stack called LAMP (Linux-Apache-MySQL-PHP) as a free, turnkey solution for Web development. LAMP started out on Linux but variants are also available for other platforms, such as MAMP for Mac OS X or XAMMP for Windows.  What they all have in common is easy installation and setup.  I’ll be coding on my MacBook so I’ll be using MAMP.

Now I just need a text editor so TextWrangler it is. I could use something fancier like Aptana, NetBeans or Coda but I don’t plan on coding up anything terribly complex.

Since I’m not looking to do anything fancy, I created a simple form. The user is asked to input a number between 1 and 10 and press Submit.

Enter a number

Pick a number…

Then the number gets passed to another page, where a simple loop prints “Hello World!” based on the number entered by the user.

Hello World five times

This fellow is very friendly!

I felt this was an appropriate spin on the standard “Hello World!” program as PHP was originally designed to manage HTML forms.

#52WeeksOfCode Week 20 – Qt

Week: 20

Language: Qt

IDE(s): Qt Creator

 

History (official):

(From the Qt Project ‘About Us’ page)

“Qt (“cute”) is a leading cross-platform application and UI development framework for leading desktop, embedded and mobile operating systems. Qt uses standard C++ and is widely used for developing software applications with a GUI and also for developing non-GUI applications with features such as file handling, database access, XML parsing, thread management and network support.

Qt’s powerful full-framework capabilities allows for the creation of highly-performing native applications as well as for hybrid development where the developer can choose which tools provide the best user experience.

Qt is created by developers for developers where making developers’ lives easier is top priority. We strive to provide an incomparable developer experience with the tools necessary to create amazing user experiences. Qt is platform agnostic and believes in making sure that all developers are privy of being able to target multiple platforms with one framework by simply reusing code. We believe in providing freedom to the developer. Code less. Create more. Deploy everywhere.”

History (real):

Qt allows C++ developers to create modern-looking GUI applications without having to learn more current languages such as C#.

(NOTE: I have no problem with C++. It was my first object-oriented language and I’ll always have a soft spot for it in my nerdy heart.)

The code is quite portable between different operating systems, making rapid, cross-platform deployment straightforward.

BUT…there’s a price.

In programming, as in life, you get nothing for free. The cost of portability is that you can’t rely on any particular operating system to do things for you. For example, Windows may have a perfectly fine software routine for rendering a menu, but you can’t use it. If you do, then you’ll have to rewrite your code every time you want to run your application on a different operating system that uses different code for menu-rendering. In a related issue, you have to include the code libraries that your applications uses because you can’t assume that your target computer (even if it runs the same operating system) has them.

Because of this, Qt has to reinvent the wheel for almost everything it does.

Another consequence of this independence is that the owners of the operating systems you’re targeting are always ahead of you with shiny new graphics features and new hardware. As a result, your applications are always going to look kind of shabby compared to the ones that are native to the platform. (Java has a similar problem.)

That being said, I like the idea of Qt. Cross-platform, particularly for a rich development framework, is a good thing.

It turns out that the reality fell a bit short.

 

Discussion:

Though Qt works with different IDEs (including a plain old text editor), I decided to use the native development environment Qt Creator. It’s free and since it pulls the install files from the Internet, the installer is a quick download. Since Qt is by definition a stranger wherever it goes, I decided to use Mac OS X as my development platform.

I fired up Qt Creator. It seemed straightforward enough, with plenty of documentation and tutorials.

QT Creator GUI

QT Creator GUI

I decided to go with a simple graphical application project. I typed in the project name, chose a folder for it and clicked on Save.

My project was nowhere to be found. It wasn’t in Qt Creator. It wasn’t in the folder I had created. Not only that, but the menu selection to create a new project was now grayed out.

(“I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced.”)

Not a promising start.

I quit Qt Creator and re-started it. This time after naming the project, I just accepted the defaults. Now my project showed up. Now I just need to build and run it.

Hello World in Qt Creator

Hello World in Qt Creator

After a bit of searching in the documentation, it seems that I need to set up a Build and Run Kit.

After a bit more searching, it looks like I have to drop down to a command line and type in a bunch of code to create the kit by hand. You know, just like the Founding Fathers because FREEDOM.

I’m not going to do it.

I’m not stupid. I have all of the developer tools installed. I don’t have a problem typing commands in a terminal. I understand the reasons that this is happening is that Mac OS X deploys applications as self-contained packages and since Qt has its own code libraries, I have to hand-carry the bits into a package, as it were.

This is 2014. You offer me a graphical code editor that produces graphical applications on a modern operating system. If you can’t let me develop, build and run from the GUI out of the box with your own IDE, then I’m done with you.

I realize that at this point thousands of Qt developers are probably lining up outside my door to punch me in the throat, BUT…

If I was a professional Mac developer, with experience using XCode, Xamarin, Eclipse and even Visual Studio (which I have), what POSSIBLE reason could you give me to try Qt after this experience?

This is fixable, fellows. Get on it.