The Little Book Of Ruby Programming

My new book on Ruby programming is published today, available from Amazon (US), Amazon (UK) and worldwide (ISBN: 978-1913132071).

I originally wrote The Little Book Of Ruby way back in 2006. My software development company was creating some Ruby development tools at the time and we really needed a quick way to learn the basic features of the Ruby programming language. Hence The Little Book. This latest edition has been considerably updated, expanded and reformatted and there is also a downloadable source code archive of all the programs in the book. It is the first time I’ve released The Little Book Of Ruby in paperback and Kindle eBook format. If you are new to Ruby and want a really quick way to start programming, I hope this may be of use.

Smalltalk – The Most Important Language You’ve Never Used

In my last two posts I mentioned two programming languages with big ideas (Modula-2 and Prolog) which, however, never ranked among the dominant mainstream languages. Now I want to look at one of the most influential languages ever created – Smalltalk.

It would be hard to overstate the influence of Smalltalk. Without Smalltalk there would have been no Mac and no Windows. In all probability you would not now have a mouse attached to your computer, networking might have come around eventually but not as quickly as it did - and object orientation might never have made it to the mainstream.

This is Smalltalk/V - a Windows based Smalltalk from the 1980s.

Then again, it could be argued that object orientation never did make it to the mainstream. Well, not the sort of beautiful, simple, elegant object orientation at the heart of Smalltalk, anyway. C++ was the first object oriented language to take OOP into the mainstream – and most OOP languages that followed appear to have built on the foundations laid by C++ rather than by Smalltalk. As Alan Kay - the ‘founding father’ of Smalltalk once said: “I invented the term 'object-oriented', and I can tell you I did not have C++ in mind".

Most of the current generation of OOP languages take some bits of Smalltalk (such as classes and methods), miss out other bits (such as data-hiding, a class-browsing IDE, image-saving, the ‘message passing’ paradigm etc.) and add on a few things of their own – such as C++’s multiple inheritance. The end result is that those languages are less simple, consistent and coherent than Smalltalk. One of the proud boasts of the developers’ of Pharo (one of the best modern Smalltalk implementations) is that the entire language syntax can be written on a postcard. Try doing that with C++!

Dolphin Smalltalk - a modern Windows-based implementation

Object Orientation in Smalltalk was an attempt to simplify programming: to make code highly modular (the programmer sent ‘messages’ to objects and it was up to the object to ‘decide’ which methods, if any, it used to respond to those messages) and more easily maintainable. In fact, most modern OOP languages have become more complex and harder to maintain.

When I read programming forums on the Internet these days, the main feature which is praised by enthusiastic programmers is the speed with which they can write programs. In fact, the more programming I do (I’ve been at it since the early ’80s), the more I become convinced that the most important thing is not the speed with which I can write programs but the speed with which I can debug them. The simpler the code, the easier it is to debug.

Debugging is  the partner to maintaining. A great many programmers now think it’s neat to contribute a ‘hack’ to some programming project then move on to something else – leaving some other sucker to try to maintain and fix the increasingly incomprehensible code at some future date. For many programmers, debugging and maintaining are not even activities which register in their minds. Quick and clever coding is all they care about. Long-term reliability isn’t. Well, frankly, you wouldn’t want the control systems of a nuclear power station written by quick-and-clever programmers!

Simplicity and maintainability were ideals that shaped Smalltalk and Modula-2. That’s why Smalltalk worked with inheritance (re-using existing features) and encapsulation. It’s why Modula-2 implemented data-hiding inside hermetically sealed modules.

But maybe the three languages that I’ve highlighted (Smalltalk, Modula-2 and Prolog) were simply too different from the languages that eventually came to dominate the world of programming. Smalltalk was perhaps too insular – there was no separation between the programing language and its environment – and its insistence on simplicity made it hard to change the language to add on significant new features. Prolog programs were too uncontrollable, with their wide-ranging searches for solutions to complex problems. Modula-2 was too restrictively ‘modular’ with its authoritarian insistence on the precise separation of one unit of code from another unit of code.

As a consequence, we now have more mundane languages such as Ruby, Python, Java, C++ and C#, which all mix-and-match ideas from earlier languages but seem to lack any single ‘great idea’ of their own. Perhaps that is what the world really wants – workaday languages that may not be perfect but at least get the job done.

Even so, I refuse to believe that they represent the face of the programming future. One day, surely, someone will have a brilliant idea (and no, I can’t even guess what that might be!) that will dramatically change the way we program. Until then, I can only wonder how different our experience of programming might have been if only Prolog, Smalltalk and Modula-2 had become the big trinity of languages instead of C, C++ and Java.

Prolog – The Logical Choice for Programming

In my last blog post I mentioned a few old programming languages that had big ideas. One of the most ambitious of these was Prolog. Since very few programmers these days have any experience of Prolog, let me explain why it was such a remarkable language.

Prolog was designed to do ‘logic programming’. When I first used Prolog, back in the 1980s, I was initially overwhelmed by its expressive power. When using other (‘procedural’) programming languages, you had to find solutions to all your programming problems at the development stage and then hard-code those solutions into your program. With Prolog, on the other hand, you could ask your program questions at runtime and let it look for one or more possible solutions. Heady stuff. This (I thought) must surely be the way that all programs will be written one day.

You can try out Prolog online using Swish 

Prolog programs are constructed from a series of facts and rules. For example, you could assert that Smalltalk and Ruby are OOP languages by declaring the following ‘facts’:

oop(smalltalk). 
oop(ruby). 

To find a list of all known OOP languages you would just enter this query:

oop(L).

In Prolog, when an identifier begins with capital letter, this indicates an ‘unbound’ variable which Prolog will try to match with known data. In this case, Prolog replies:

L = smalltalk
L = ruby

Now you can go on to define some rules. For example, let’s says that you want to write the rule that Reba only likes Languages that are OOP as long as Dolly does not like those languages. This is the Prolog rule:

likes(reba,Language) :- 
   oop(Language), 
   not(likes(dolly,Language)).

Let’s assume that the program also contains this rule:

likes(dolly, ruby).

You can now enter this query:

likes(reba, L).

The only language returned will be:

L = smalltalk

This is just the tip of the iceberg with Prolog. The language gets really interesting once you start defining enormously complex sets of rules, each of which depends on other rules. The essential idea is that each rule should define some logical proposition. When you write a rule, you can concentrate on a tiny fragment of what might eventually become an amazingly complex set of interdependent propositions. The programmer (in principle) doesn’t have to worry about the ultimate complexity. Instead, as long as each tiny individual rule works, you can rely on the fact that the vast logical network of which they will ultimately form a part will also work. Making sense of that complexity is Prolog’s problem, not the programmer’s.

In principle, Prolog seemed to offer the potential to do ‘real’ AI (programming) of great sophistication. Some people even believed that Prolog would provide the natural path to creating a truly ‘thinking machine’.

Well, years went by and Prolog failed to live up to its promise. Part of the problem was that, while it was great at finding numerous solutions to a problem, it wasn’t so good at finding just one. A nasty little thing called the ‘cut’ (the ! character) was used to stop Prolog searching when once a solution had been found. But the cut, in effect, breaks the logic and scars the beauty (and simplicity) of Prolog. Another problem was that Prolog interpreters were fairly slow. Prolog compilers were created to get around this limitation and Visual Prolog even introduced strict typing (which is not a part of standard Prolog). But in order to gain efficiency, the compiler sacrificed the metaprogramming (self-modifying) capabilities which many people consider fundamental to the language.

Visual Prolog has a good editor, a built-in debugger, design tools and compiler - but purists would say that it isn't 'real' Prolog.

In brief, it’s probably fair to say that Prolog’s greatest enthusiasts were simply unrealistic about what the language might achieve. For the time being, Prolog seems to be an interesting diversion in programming history which has not (so far) delivered upon its early promise.

Still, it was, and is, an amazingly ambitious language that did lots of really interesting things. Unlike most of today’s ‘new and better’ programming language, it didn’t just recycle old ideas in slightly new ways. However, there was another programming language that was just as ambitious as Prolog but ultimately far more influential: Smalltalk. That will be the subject of my next post.

Try out Prolog

There are several implementations of Prolog available, both free and commercial. One of the most complete free editions is SWI-Prolog: https://www.swi-prolog.org/ In order to use this with an editor/IDE you should also install the SWI-Prolog Editor: http://arbeitsplattform.bildung.hessen.de/fach/informatik/swiprolog/indexe.html Alternatively, you can write and run short SWI-Prolog programs online here: https://swish.swi-prolog.org/ Visual Prolog has (by far!) the best IDE – complete with editor, debugger, visual designer and compiler. It is available in commercial and free editions. However, this is a non-standard version of Prolog: https://www.visual-prolog.com

Why Are There No Big New Ideas in Programming?

Modern mainstream programming languages are all much of a muchness these days. Take some object orientation, add in some ‘dynamic typing’, maybe add on a fast compiler to give you the programming benefits of a ‘scripting language’ with the efficiency benefits of C… I keep reading the same sorts of claims made for all kinds of ‘new’ languages. Far from seeming at all new, they strike me as lots of old stuff mixed up together in different ways.

Where are all the truly new ideas now?

In all the languages I’ve use in the last forty years or so, only three have struck me as having a ‘big vision’ – languages that have a profound belief in the value of their design; and that belief shapes the language itself from start to finish. None of those languages, however, is now widely used. They are: Modula-2, Prolog and Smalltalk.

The be-all and end-all of Modula-2 was its modularity. You put code inside well-defined units called ‘modules’ and once in there, that code cannot be accessed from outside the module unless it is very precisely imported and exported. If you think this sounds like the modules, units and mixins of most other languages, think again. Java, C#, Ruby, Object Pascal and many other languages are far less strict in their modularity. In fact, it has been my experience that most programmers have so little experience of modular programming that they often have great difficulty even trying to understand the concept and the benefits of strict modularity. That’s one reason why – even though Modula-2 itself may have failed to take the world by storm – I think it would be useful to most programmers, whatever languages they usually use, to have at least some experience of programming Modula-2 or its successor, Oberon.

But even more ‘visionary’ than Modula-2 are Prolog and Smalltalk.  If you have never programmed in Prolog (and I suppose it must be highly likely that you haven’t) I’ll explain why it was such an exciting and ambitious language in my next post. 

Writing a Retro Text Adventure in Delphi

It’s no secret that I am a keen adventure gamer. I love playing them. I love programming them. The traditional type of text adventure (sometimes called ‘Interactive Fiction’) is a bit like a book in which the game-player is a character. You walk around the world entering human language commands to “Look at” objects, “Take” and “Drop” them, move around the world to North, South, East and West (and maybe Up and Down too). Unlike modern graphics games, an adventure game can realistically be coded from start to finish by a single programmer with no need to use complicated ‘game frameworks’ to help out.

While my Delphi adventure game has a graphical user interface it is, in essence, a text adventure just like the 70s and 80s originals

I wrote an adventure game called The Golden Wombat Of Destiny back in the ‘80s. Over the years  that game has gained cult status. It’s even been turned into a bizarre musical film on YouTube. You can play it online here: https://archive.org/details/TheGoldenWombatOfDestiny

Programming a game is not a trivial task. If you are using an object oriented language, you need to create class hierarchies in order to create treasures, rooms, a map and a moveable player.  You need good list-management to let the player take objects from rooms and add them to the player’s inventory. And you need to have robust File/IO routines to let you save and reload the entire ‘game state’.

If you really want to understand all the techniques of adventure game programming, I have an in depth course that will guide you through every step of the way using the C# language in Visual Studio.

But you don’t have to use C#. I’ve written similar games in a variety of languages: Ruby, Java, ActionScript, Prolog and Smalltalk to name just a few. Recently one of the students of my C# game programming course asked for some help with writing a game in Object Pascal (the native language of Delphi, and also of Lazarus). OK, so here goes…

Delphi lets you design, compile and debug Object Pascal applications

If you haven’t already got a copy of Delphi, you can download one here:  https://www.embarcadero.com/products/delphi/starter/free-download

This is not a tutorial on how to use Delphi. I am therefore assuming that you already know how to create a new VCL application, design a user interface and do basic coding. If you don’t, Embarcadero has some tutorials here: http://www.delphibasics.co.uk/

If you prefer an online video-based tutorial with all the source code, you can get a special deal on my Delphi & Object Pascal Course by clicking this link. 

The Adventure Begins

First I designed a simple user interface with buttons and a text field to let me enter the name of an object that I want to take or drop. The main game output is displayed in a TRichEdit box which I’ve named DisplayBox.

Now, I want to create the basic objects for my game.  I want a base Thing class which has a name and a description. All other classes in my game derive from Thing. Then I want a Room class to define a location and an Actor class for interactive characters – notably the player. I could put all these classes into a single code file. In fact, I prefer to put them into their own code files, so I’ve created the three files: ThingUnit.pas, RoomUnit.pas and ActorUnit.pas.

Here are the contents of those files:

unit ThingUnit;

interface

type
  Thing = class(TObject)
  private // hide data
    _name: shortstring;
    _description: shortstring;
  public
    constructor Create(aName, aDescription: shortstring);
    destructor Destroy; override;
    property Name: shortstring read _name write _name;
    property Description: shortstring read _description write _description;
  end;

implementation

constructor Thing.Create(aName, aDescription: shortstring);
begin
  inherited Create;
  _name := aName;
  _description := aDescription;
end;

destructor Thing.Destroy;
begin
  inherited Destroy;
end;

end.


unit ActorUnit;

interface

uses ThingUnit, RoomUnit;

type
  Actor = class(Thing)
  private
    _location: Room;
  public
    constructor Create(aName, aDescription: shortstring; aLocation: Room);
    destructor Destroy; override;
    property Location: Room read _location write _location;
  end;

implementation

constructor Actor.Create(aName, aDescription: shortstring; aLocation: Room);
begin
  inherited Create(aName, aDescription);
  _location := aLocation;
end;

destructor Actor.Destroy;
begin
  inherited Destroy;
end;

end.


unit RoomUnit;

interface

uses ThingUnit;

type
  Room = class(Thing)
  private
    _n, _s, _w, _e: integer;
  public
    constructor Create(aName, aDescription: shortstring;
      aNorth, aSouth, aWest, anEast: integer);
    destructor Destroy; override;
    property N: integer read _n write _n;
    property S: integer read _s write _s;
    property W: integer read _w write _w;
    property E: integer read _e write _e;
  end;

implementation

{ === ROOM === }
constructor Room.Create(aName, aDescription: shortstring;
  aNorth, aSouth, aWest, anEast: integer);
begin
  inherited Create(aName, aDescription);
  _n := aNorth;
  _s := aSouth;
  _w := aWest;
  _e := anEast;
end;

destructor Room.Destroy;
begin
  inherited Destroy;
end;

end.

And this is the code in the main file, gameform,pas. Note that the button event-handlers such as TMainForm.NorthBtnClick were created using the Delphi events panel prior to adding code to those methods:

unit gameform;
interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
  System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ExtCtrls,
  Vcl.ComCtrls,
  ThingUnit, RoomUnit, ActorUnit;

type
  TMainForm = class(TForm)
    DisplayBox: TRichEdit;
    NorthBtn: TButton;
    SouthBtn: TButton;
    WestBtn: TButton;
    EastBtn: TButton;
    LookBtn: TButton;
    CheckObBtn: TButton;
    TestSaveBtn: TButton;
    TestLoadBtn: TButton;
    Panel1: TPanel;
    DropBtn: TButton;
    TakeBtn: TButton;
    inputEdit: TEdit;
    InvBtn: TButton;
    procedure FormCreate(Sender: TObject);
    procedure LookBtnClick(Sender: TObject);
    procedure SouthBtnClick(Sender: TObject);
    procedure NorthBtnClick(Sender: TObject);
    procedure WestBtnClick(Sender: TObject);
    procedure EastBtnClick(Sender: TObject);
  private
    { Private declarations }
    procedure CreateMap;
  public
    procedure Display(msg: string);
    procedure MovePlayer(newpos: Integer);
    { Public declarations }
  end;

var
  MainForm: TMainForm;
  room1, room2, room3, room4: Room;
  map: array [0 .. 3] of Room;
  player: Actor;

implementation

{$R *.dfm}

procedure TMainForm.Display(msg: string);
begin
  DisplayBox.lines.add(msg);
end;

procedure TMainForm.CreateMap;
begin
  room1 := Room.Create('Troll Room', 'a dank, dark room that smells of troll',
    -1, 2, -1, 1);
  room2 := Room.Create('Forest',
    'a light, airy forest shimmering with sunlight', -1, -1, 0, -1);
  room3 := Room.Create('Cave',
    'a vast cave with walls covered by luminous moss', 0, -1, -1, 3);
  room4 := Room.Create('Dungeon',
    'a gloomy dungeon. Rats scurry across its floor', -1, -1, 2, -1);
  map[0] := room1;
  map[1] := room2;
  map[2] := room3;
  map[3] := room4;
  player := Actor.Create('You', 'The Player', room1);
end;

procedure TMainForm.FormCreate(Sender: TObject);
begin
  CreateMap;
end;

procedure TMainForm.LookBtnClick(Sender: TObject);
begin
  Display('You are in ' + player.Location.Name);
  Display('It is ' + player.Location.Description);
end;

procedure TMainForm.MovePlayer(newpos: Integer);
begin
  if (newpos = -1) then
    Display('There is no exit in that direction')
  else
  begin
    player.Location := map[newpos];
    Display('You are now in the ' + player.Location.Name);
  end;
end;

procedure TMainForm.NorthBtnClick(Sender: TObject);
begin
  MovePlayer(player.Location.N);
end;

procedure TMainForm.SouthBtnClick(Sender: TObject);
begin
  MovePlayer(player.Location.S);
end;

procedure TMainForm.WestBtnClick(Sender: TObject);
begin
  MovePlayer(player.Location.W);
end;

procedure TMainForm.EastBtnClick(Sender: TObject);
begin
  MovePlayer(player.Location.E);
end;

end.

So this is already a good basis for the development of an adventure game in Delphi. I have a map (an array) or rooms and a player (an Actor object) capable of moving around. There’s still much to do, however – for example, I need some way of taking and dropping objects and saving and restoring a game. I’ll look at those problems in a future article.

If you are seriously interested in programming text adventure games or learning Delphi, here are special deals on two of my programming courses.

Learn To Program an Adventure Game In C#

You will learn to…

• Write a retro-style adventure game like ‘Zork’ or ‘Colossal Cave’
• Master object orientation by creating hierarchies of treasure objects
• Create rooms and maps using .NET collections, arrays and Dictionaries
• Create objects with overloaded and overridden methods
• Serialize networks of data to save and restore games
• Write modular code using classes, partial classes and subclasses
• Program user interaction with a ‘natural language’ interface
• Plus: encapsulation, inheritance, constructors, enums, properties, hidden methods and much more…

https://bitwisecourses.com/p/adventures-in-c-sharp-programming/?product_id=943143&coupon_code=BWADVDEAL

Learn To Program Delphi

• 40+ lectures, over 6 hours of video instruction teaching Object Oriented programming with Pascal
• Downloadable source code 
• A 124-page eBook, The Little Book Of Pascal, explains all the topics in depth

https://bitwisecourses.com/p/learn-to-program-pascal/?product_id=792&coupon_code=BWMAGDELPHI

The Terrible Visual Studio 2019 New Project Dialog

Gahhhh! Why do Microsoft make changes that nobody asks for and nobody wants? A couple of years ago they suddenly put all the Visual Studio menus in capital letters (they undid that change after mass protests). Now in Visual Studio 2019, they've replaced a perfectly neat and functional New Project dialog with a sprawling, disorderly mess. I hope, oh how I hope, that this dialog will soon go the way of the capital-letter menus. In the meantime, if you can't work your way around it, I've just written this short guide on the Bitwise Books web site: http://bitwisebooks.com/visual-studio-2019-using-its-strange-new-project-dialog/