#52WeeksOfCode Week 29 – Clojure

Week: 29

Language: Clojure

IDE(s): NightCode

History (official):

(From the official Clojure home page)

Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language – it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure’s combination of facilities elegant, powerful, practical and fun to use.”

 

History (real):

That was the equivalent of a marketing release for Clojure. In other words, it’s targeted at the ‘suits’. If you want the sales page for the technical crowd, see the Rationale page.

I have no personal animus against Clojure. Today was the first time I had heard of it. But I have to say that my first thought was “What? You mean I can at last combine the terse, unreadable code of Lisp with the performance hit of running Java? Sign me up!”

Of course, the true story is more complex.

One of the strengths of the Java platform is the Java Virtual Machine (JVM). A Java program compiles to bytecode which runs on the JVM. The JVM gives Jave its portability between operating systems. Microsoft’s .NET language followed suit with the CLR (Common Language Runtime).

Another advantage of the JVM, however, is that Java bytecode is an open, documented standard. That means that you can use any programming language you want to write Java applications, as long as you can compile your language to produce bytecode. Examples include Jython and JRuby that let programmers write Java programs in Python and Ruby, respectively.

Clojure lets programmers write in Lisp and produce code that can easily integrate with Java and code that uses Microsoft’s .NET framework. It can also connect to JavaScript libraries like Node.js for Web applications.

This is a cool idea. Scripting languages do make for faster prototyping and development and bytecode compilation does improve performance a bit (but not as much as going all the way down to machine code).

But why Lisp for scripting? Let’s ask the creator of Clojure, Rich Hickey. From the Clojure Rationale page:

Why did I write yet another programming language? Basically because I wanted:

 

  • A Lisp
  • for Functional Programming
  • symbiotic with an established Platform
  • designed for Concurrency

 

I think the third feature is the important one. We already have multiple dialects of Lisp. Erlang is a functional programming language that supports concurrency. But neither of these can integrate so easily with existing code as Clojure.

I think that if I had a complaint, it would be that the scripting language was based on Lisp. But that’s my own personal discomfort and unfamiliarity with functional programming and not meant to diminish Hickey’s accomplishment in any way.

Discussion:

So how do I get started coding in Clojure? After a bit of research, I found that writing the code was easy enough but a real Clojure project involves keeping quite a few metaphorical plates spinning. Managing all of the files, code dependencies and project details can get hairy very quickly, particularly if you work from the command, which is the bare-bones Clojure install default.

There is an existing tool, make, which can handle code projects but it’s finicky to configure. Java has similar project management issues which are handled by a tool called ant. Fortunately some contributors to Clojure created an automation tool named leiningen. It works so well that it’s become the default tool for working with Clojure projects.

I didn’t feel like working from the command line (again) so I searched for a nice IDE for my first Clojure project. There are Clojure plug-ins for popular Java IDEs like Eclipse, NetBeans and Intellij but I wanted a program that was built specifically for Clojure.

Enter NightCode. Not only was it written for Clojure projects, but it was written in Clojure. I felt this showed admirable brand loyalty so I grabbed a copy. The interface is pretty bare-bones:

NightCode on first startup

NightCode on first startup

I only have three options: Create a new project, import an existing project or run code interactively in the little interpreter window on the lower left. This is a pretty neat feature because you can jump out of your current project, quickly test out some scrap of code to make sure it works the way you think it does and then paste it back into your main source file without leaving the IDE. Very nice:

NightCode interactive shell

NightCode interactive shell

I created a new project and after giving my project a name was presented with a list of project templates:

NightCode template selection

NightCode template selection

I like templates. They let me get on with my life.

I picked Console and selected Create Project.  In a few moments my first project was ready to code:

A simple console application project

A simple console application project

I have a few more options now. One thing I noticed were the options Run, Run with REPL, Build and Test. Since Clojure is a scripting language, it’s possible to run code without actually creating an application. Run with REPL runs your code interactively which is useful for debugging. Test checks your code for logic and syntax errors. Build, of course, creates the standalone software application. It’s still a very sparse interface, but it looks like you could do some non-trivial projects in this IDE. Not bad for free software.

On to my trivial project. The console project template is a standard “Hello World” so I use it to take both Clojure and NightCode for a spin.

Here’s the code, in case you’re curious:

Hello World in Clojure

“Hello World!” in Clojure

I’d like to test my code before running it so Test automatically inserts test code into my program, compiles and runs it:

Automatic code testing

Automatic code testing

Selecting Run gives me this:

Running my code

Running my code

Run with REPL loads the code and drops me into an interactive shell:

Running interactively with REPL

Running interactively with REPL

Now I’m ready to create my standalone application with Build:

Building a standalone application

Building a standalone application

Clojure is a unique, versatile language and NightCode gives me enough tools to handle non-trivial projects with confidence.

#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.

#Coding4Humans Book Review – Programming Pearls

I enjoy reading books about computer programming. (At this point you’re probably saying to yourself, “Of course you do, Tom. You big old nerd, you.”)

But the books I prefer to read aren’t about a particular programming language or operating system but the books about the art, history and philosophy of computer programming. Programming Pearls by Jon Bentley is a classic in this particular genre.

Bentley was a computer researcher at the original Bell Labs in Murray Hills, NJ and he used to write a column on various aspects of programming design and problem-solving for the periodical “Communications of the ACM”. This book is made up of selected essays from that column.

This book has earned a permanent spot on my bookshelf in three ways. First, it’s a fascinating glimpse into the history of computing. The year it was published (1986) was the beginning of the personal computer revolution. We were taking the power back from the mainframe computer priesthood. Having a PC was to be like Prometheus with a piece of stolen fire. We had some of the power for ourselves and were struggling to figure out what to do with it. (Hackers: Heroes of the Computer Revolution by Stephen Levy is an excellent look at the people and personalities that built this era.)

This book is also about problem-solving. As Bentley says in the introduction:

The essays in this book are about a more glamorous aspect of the profession: programming pearls whose origins lie beyond engineering, in the realm of insight and creativity.

These days we’re accustomed to being able to just throw more hardware at computing problems. Bentley reminds us that there is still value in thinking a problem through and presents some interesting ideas, examples and exercises to aid in that work.

Finally, there is my favorite essay, “The Back of the Envelope”. If I had my way, this would be required reading for all of my math students.

Let me explain.

I encourage the use of calculators and computers in my math classes to do the computational heavy-lifting. My logic is that if you understand the problem well enough to explain it to a machine, then the actual computation is just a mechanical exercise. But this doesn’t mean that you should just trust outright whatever a machine tells you. You need to know what the answer should look like by using estimation so you can judge the machine’s output. Bentley devotes an entire section to estimation and these skills also extend into other essays, such as “Perspectives on Performance” and “Algorithm Design Techniques”.

Programming Pearls includes exercises at the end of each essay to help you develop your mental muscles (don’t worry, there are hints in the back of the book) and an appendix with a catalog of algorithms. At 256 pages, it’s a pretty breezy read and the organization of topics makes it easy to just dip in wherever you like and start reading. It’s not just an excellent reference but Bentley’s writing style is friendly and intelligent without being condescending. If you’re a programmer (whether hobbyist, student or professional) you need a copy of this book.

References

Bentley, J. L. (1986). Programming pearls. Reading, MA: Addison-Wesley.

Levy, S. (1984). Hackers: Heroes of the computer revolution. Garden City, NY: Anchor Press/Doubleday.

 

#52WeeksOfCode Week 17 – CSS3

Week: 17

 

Language: CSS3

 

IDE(s): Coda, MAMP

 

Background:

When a new technology comes out, you have to ask yourself two questions:

  1. What problem is this intended to solve?
  2. How well does it solve it?

CSS (Cascading Style Sheets) were designed to solve the problem of adding styles to Web documents. Was this actually a problem? (see question 1)

Web pages, at their heart, are just plain text. Originally if you wanted to add formatting you had to use markup tags to set the text as italic, boldface, underlined or even organized as a list or a table. This required some fiddling with individual text elements and there was no easy way to apply a style or combination of styles to text in separate areas of the page in one go. In addition, if you wanted to use the same content with different styling elements (or to present it for different browsers or platforms), you had to rather painfully re-write your markup.

Cascading Style Sheets let us define styles for different HTML elements (either in the Web page itself or in a separate CSS file) and apply them directly. Whenever the Web browser sees text with a label defined in CSS, it applies the appropriate style. Using a separate CSS file is considered better as it allows you to apply a common look-and-feel to multiple Web pages and makes it easy to re-format a Web page simply by applying a different CSS file.

So CSS does indeed seem to be a solution to a legitimate problem. But how good of a solution is it?

Pros:

  • Keeps content and design separate, making our HTML cleaner and easier to read.
  • Makes it easier to display the same page correctly on multiple devices in multiple browsers
  • Size and positioning of objects (such as images) can be pre-defined in CSS
  • Gives readers more flexibility and control in how they view Web pages

Cons:

  • Not all browsers support CSS the same way
  • Using CSS to position your Web page objects gets ugly really fast.
  • CSS is ‘markup centric’ rather than ‘design centric’, forcing many Web designers to craft their code by hand

 

Needless to say, opinions differ. (The comments are pretty heated at that link. I recommend reading all of them.)

We are trying to move from print (which has had nearly a thousand years to evolve) to the Web (which has only been around since about 1993). I don’t think we’ve figured out the new design paradigms yet, but sites like CSS Zen Garden offer some intriguing possibilities.

 

Discussion:

This week I used MAMP as my Web server as usual, but instead of TextWrangler I decided to use Coda from Panic Software. It’s not free but Panic makes very good, clean, well-behaved software and Coda is not exception. Coda is not only specifically designed to manage Web code but comes with built-in documentation for

I was looking for something interesting to do with CSS and I came across a wonderful little tutorial at CoDrops. It walks you through setting up a Web page with CSS and JQuery that renders an animated billboard that flips between two different signs. I modified the images included using GraphicConverter and ImageMagick.

The output looks like this (as an animated GIF):

Hello World billboard

hello world animated billboard

#52WeeksOfCode Week 7 – Ruby on Rails

Week: 7

 

Language: Ruby on Rails

IDE(s): TextWrangler

Background:

Wait a minute, didn’t we talk about Ruby back in Week 5?

Well, yes. But this isn’t so much about Ruby as it is about Rails. Though programming in Ruby is pretty friendly, creating a Web service traditionally is not. Rails is a software framework designed to bring the friendly nature of Ruby to Web programming.

Discussion:

Should everyone learn to code? This is a question I’ve seen pop up in the past but with projects like Code Year, Hour of Code and Code for America, it’s getting more attention these days. Given how Depending on what point in my career that you asked me this question, my answer would range from ‘yes’, ‘no’, ‘who cares’ and ‘maybe’. At this point I think it’s kind of complicated and I plan on addressing it in future.

For now, though, I’d like to talk about the resources for learning how to program.

“Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples—both good and bad—to facilitate learning.”

Excerpt From: Gerald M. Weinberg. “The Psychology of Computer Programming: Silver Anniversary eBook Edition.” iBooks. https://itun.es/us/H5erA.l

I first learned how to program back in 1977. The language was Fortran and

we wrote our code on punched cards. (And no, I didn’t have to walk to school barefoot through a blizzard, uphill both ways, in case that was your next question.) Personal computers were just being introduced at that time and they were strictly for hobbyists. The way you learned to code was either through taking a class (as I did) or through self-instruction. Either way you needed to read a lot of other people’s code.  If you were lucky enough to get unfettered access to computer time (not an easy thing back in the days of mainframes) you could just try out code and see what happened.

The USENET discussion board system came online in 1980 and with it you could connect with other programmers and hobbyists, trade code, ask questions and share experiences. But it still came down to reading other people’s code, looking through books and trying stuff to see what worked.

Cut to today.

Each week I do research on the language or framework I’m supposed to use and so far I’ve been very impressed by the sheer volume of openly available information available online. Not only that but that some people were doing some innovative things with online education. Here was the sequence of my training:

  • TryRuby.org – This site provides an interactive tutorial that lets you try out Ruby code in your Web browser with no additional software required. It’s a little slower than doing it ‘natively’ but it’s very well done and quite handy. There is a similar site for Haskell that I referenced last week.

  • Rails for Zombies – A very clever tutorial hosted by Code School, a site that specializes in offering online training for programming students. They have some free content (Rails for Zombies, for example) but to get access to all of the content requires a monthly subscription. This was an excellent example of the active learning style of instruction. The student watches a short instructional video and then is presented with series of programming challenges where they get to apply what they’ve learned. If they succeed, they earn ‘points’ and move on to the next level. (The overall goal is to code a version of Twitter to be used by zombies). You can download a copy of each video along with the presentation slides (in PDF form) if you wish to have them for reference. Hints are available but if you use them too much, you lose points. The combination of short, targeted lessons with an amusing back-story and the overall gamification of the lesson made this a lot of fun while still giving me a good background on Rails.

  • Getting Started with Rails – This is where it all came together. While you might think that this is where I should have started, I don’t think I would have done as well if I hadn’t covered the material in Rails for Zombies first. Once again, this site provides a decent but not excessive amount of hand-holding while it walks you through setting up a simple web application. Each step adds a bit more and since at any point you always have working code, it’s easy to figure out what happened if something goes south on you. This is hosted by the main Ruby on Rails community site and also contains screencasts, documentation, other tutorials and other links to connect up with other Rails users.

I’m not suggesting that we ditch traditional learning and move everything online. However, there are many different learning styles and I’ve found that you need to push knowledge out over multiple channels for maximum effectiveness. But a Web page is not the same as a textbook and a video lecture is not the same as an on-ground instructor.

That’s why I’ve been pleasantly surprised to see so many online instruction providers ‘giving back’ by providing resources for teachers as well as students. Code School, Khan Academy, Wolfram Alpha and others all provide materials and tools for the traditional classroom.

Epilogue:

My web application this week continues with my tradition of doing goofy things with the classic “Hello World” program. This time I built a web application that allows me to post different versions of the phrase “Hello World”, along with the language used. Here’s a screencap to show you what I mean:

It’s very silly but it was easier to build than I expected and I had fun. If you’re interested, here’s a link to the code. (You’ll have to install Ruby and Rails in order to run it.)

 

#52WeeksOfCode Week 6 – Haskell

Week: 6

Language: Haskell

IDE(s): HEAT (The Haskell Educational Advancement Tool), TextWrangler, ghc

Background:

Haskell, contrary to what you may think, isn’t actually named after the noted Leave It To Beaver character (though that would have been awesome) but after Haskell Brooks Curry, an American mathematician and logician. (There are two other programming languages named after him, Brooks and Curry. The man is something of a pop star to a certain variety of nerd.)

Discussion:

This week I’m treading in some strange waters. As I’ve said before, I’m not a professional programmer so when I write software I use what languages and tools with which I’m familiar (no point learning a new language when I have real work to do) and which seem suitable for my purpose.

As I’ve begun to dig into Haskell, however, I’m really in some foreign territory. First of all, Haskell is described as a ‘purely functional’ programming language. For the benefit of my non-nerd readers, programming languages are generally defined by how they get things done. My experience thus far has been with imperative languages, where software consists of series of commands that change a program state. As a result this is how I think about writing code and how I describe the activity to non-coders. So to me, this is a program:

let a=6
let b=5
TEST=$((a+b))
echo $TEST

So I have statements that assign the value 6 to the variable ‘a’ and the value 5 to variable ‘b’. Then I assign the result of adding ‘a’ and ‘b’ together to the variable called TEST. Finally I print out the value contained in TEST.

Haskell, however, is an example of a functional language. One of the best descriptions of functional programming I’ve found compares it to a spreadsheet. Each active cell of a spreadsheet contains an expression and we don’t really care about the order in which these expressions are evaluated. We just assume that this gets done in a way that makes sense. Compare this to the chunk of code I presented earlier. The order in which those statements get executed makes a big difference in the outcome. (Before TEST has a value assigned to it, it doesn’t make sense to print it out, for example.)

Fortunately good online documentation for Haskell is readily available, including a very nice tutorial that lets you try Haskell in your Web browser (though the narrator was a bit perky for a curmudgeon like me). There is also a nice cross-platform Haskell IDE available called HEAT (The Haskell Educational Advancement Tool) which is especially designed for use by students and others learning Haskell.

There’s an old saying about having hammers and things looking like nails. (I may not be quoting that right.) Anyway, what this means more generally is that our tools, both physical and mental, influence how we think about solving problems. Software programs are as much a product of the psychology of their creator as a novel or a painting or a piece of music.

If you, like me, are used to solving problems with traditional imperative languages (C, Java, C++, bash, etc.) then your approach to a problem ends up being very ‘low level’. You break the problem down into simpler and simpler sub-tasks until you get to the level that the language can handle. But Haskell is a higher-level language so tasks that are more abstract can be handled directly. Think of it this way: If I want Java to make me a peanut butter and jelly sandwich, I have to break the task down into tiny steps, such as ‘open the cutlery drawer’, ‘pick up a knife’, ‘close the cutlery drawer’ and so on. But in Haskell I could just pass a list of ingredients [“peanut butter”, “jelly] to  MakeSandwich (with a possible option for bread type).

With that in mind, I have the perfect project in mind for my Haskell experiment. However, as I’m the World’s Slowest Coder (™), I won’t be able to finish it in time for this week’s post so for now I’ll be submitting a simpler task. (I’ll be including the Really Cool Haskell Project as bonus content for you lucky and tasteful readers who purchase the final e-book ‘52 Weeks of Code: The Psychology, Art and Philosophy of Programming’).

While we’re on the subject, one thing I notice as I dig into Haskell is there are a lot of words being written by fans enumerating all of the reasons that the rest of us should be using Haskell. Words like ‘pure’ and ‘guaranteed correctness’ and ‘compact code’ get thrown around a lot. They also describe Haskell as a ‘general purpose programming language’.

I have to disagree.

While it is true that any program you can write in a language like C# you can write in Haskell, that doesn’t mean that you should. There are certain tasks that Haskell, by its very nature, is better at than others.

For example, Haskell is better at abstraction so it’s a good fit for programs that used to be lumped under ‘artificial intelligence’ but are now referred to as machine learning or natural language processing. Haskell also has many qualities that make it work well for concurrent programming (multiple computational tasks running concurrently across several CPUs) so it’s easier to do heavy-duty data processing. But my primary take on Haskell is that it’s a very good language for mathematicians and logicians. I noticed this while I was getting up to speed on the language and looking at samples of code, thinking I’ve seen this somewhere before. Then it hit me – I’ve seen this in my math textbooks. This doesn’t take anything away from using Haskell for whatever software you wish, it’s just a better choice for certain types of problems. Haskell advocates admit that you need to change the way you think about problems in order to fully utilize the power of the language. I submit that this actually means that you need to be able to think mathematically and framing a problem in terms of formal logic.

I decided to write a program that determines if I can transform HELLO to WORLD one character at a time, with each intermediate step bringing a real world. (It’s like the old logic puzzle turning ‘cat’ to ‘dog’ with cat->cot->tot->tog->dog.) The implementation will unfortunately take longer than I have this week so let’s do something simpler. That is, let’s replace each character in HELLO with each character in WORLD, one at a time. In other words, our output should look like:

HELLO

WELLO

WOLLO

WORLO

WORLD

 

Not as cool, I know, but it’s doable in the time I have.

Epilogue:

02/13/14 – 10:25PM – Okay, maybe not so doable in the time I have. I have to admit that rewiring my brain so I can think in Haskell is seriously kicking my butt. I’m making progress but it doesn’t look like I’ll have working code (I can hear the Haskell fan-boys yelling at me and calling me names…).

But I’m running up against my self-imposed deadline so for now I’m going to post what I’ve got sans code and come back to it later. My apologies….

#52WeeksOfCode Week 5 – Ruby

Week: 5

Language: Ruby

IDE(s): Komodo Edit

Background:

“I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.”

Yukihiro Matsumoto, the creator of Ruby, Google Tech Talk, 2008

““Anyone who has ever seen a programmer at work—any wife or husband of a programmer who has ever tried to interrupt a terminal session or a conference over a bug—knows that programming itself, if the programmer is given a chance to do it his way, is the biggest motivation in programming. ”

Excerpt From: Gerald M. Weinberg. “The Psychology of Computer Programming: Silver Anniversary eBook Edition.” iBooks. https://itun.es/us/H5erA.l

“The average person can’t see what makes code elegant or unorganized. In addition, our industry is very new. While humans have been cooking, making music, and building for thousands of years, archaeologists have yet to discover those cave paintings of Man at His Desk Typing.

So, metaphor has to become our meta-language. Not only is it how we connect the uniqueness of programming to the general public, but it’s often how we make decisions on how we approach our own software problems.”

Excerpt From: Ka Wai Cheung. “The Developer’s Code” iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=7687021FDF079E4460BC1CBEAA74BC02

There is a perception among non-technical folk that technical objects such as software, smartphones, computers and so forth are creations of pure logical mind, unsullied by subjective emotion, something something pure wind-swept mountains of something something intellect.

Ahem.

Okay, you know how when your boss says something so wrong that you feel obligated to correct them, even though this person may hold your career, your very life in their hands? How do you tell them? Rather than just straight out confront them with their wrongness, the best strategy is to simply say, “Well, that turns out not to be the case.”

Anyway, back at the pure wind-swept mountains of something something intellect….

Well, that turns out not to be the case.

Every creative person views the world as being filled with holes. When you willfully create something, you do so in order to fill one or more of those perceived holes. In short, whatever you create has to fit one of those holes and gets you one step further to completing your vision of the world according to you.

What I’m getting it is that technical innovations are as much a product of our psychology as they are of math and engineering. In fact, I would argue that many are primarily psychologically rooted in their creators, with just enough math and engineering for them to actually function out here in the real world.

Ruby is a good example. Its creator, Yukihiro Matsumoto, states:

“…there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language—how we feel while programming…Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That’s Ruby’s main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby.” [Emphasis mine.]

(Venners, B. (n.d.). Retrieved from http://www.artima.com/intv/ruby.html)

Matsumoto, a.k.a. Matz, is a professional programmer and is comfortable with any number of programming languages but he saw a Ruby-shaped hole in the world.

This week’s code sample is a very simple client and server pair. The server program (Hello_World.srv.rb) opens up a network connection and waits:

macpro15:Week 5 tsinclair$ ./Hello_World_srv.rb

When the client (Hello_World_clt.rb) starts up, it connects to the server.

The server announces the connection, sends the greeting

macpro15:Week 5 tsinclair$ ./Hello_World_srv.rb
Client has connected!
Sending greeting....

and the client prints out the greeting from the server and disconnects:

macpro15:Week 5 tsinclair$ ./Hello_World_clt.rb
You are connecting from:
127.0.0.1
Hello World!
Closing the connection. Bye!

The sample code for the server is here and the code for the client is here. They are both pretty simple but as I’ve pointed out previously, the code isn’t the point of these weekly posts. However, this is the first network programming I’ve done and it’s primarily due to the ease of writing network-aware code in Ruby that I chose to do so.