Tag Archives: on-programming

Meld: Outstandanding visual difference program

I’m in the midst of converting Spitbol to use the nasm assembler instead of the gnu gas assembler. As part of that I need to compare various versions of the assembly language files, and I so I went off to the web to find a visual difference program, by which I mean a program with the same — or better — functionality of the standard diff file comparator, but with graphical output.

I soon came across Meld.

I’ve been using it for a few days, and I have found it *very* helpful. I already found one conditional assembly statement that I had unintentionally altered. I doubt I would have found this using standard diff, or at best it would have taken me much longer to track it down.

Meld is in the Debian package list, and so can be found in most Linux distributions.

On Programming: Putting your own initials in your code

Are you a programmer. I know I am.

I’m currently working on Macro SPITBOL, a project I last worked on almost thirty years ago.

Today I decided to clean up some initialization code, to make it more compact, so I visited the SPITBOL tokenizer (tokens.spt), a file that I hadn’t looked at recently since it worked.

I noted at the start that it contained the comment:

it is based on earlier translators written by david shields, steve duff and robert goldberg.

I knew I had written some of the code, but wasn’t sure just which parts.

Then, while editing the file, I came across the label DSOUT. When I looked a little more, I found another: DSGEN.

That’s when I knew that I really had written some of this code, for I had intentionally left my fingerprints on it by fitting my initials into some of the names.

I then recalled other times I had made use of my initials when making up the names for some new code.

Making names is the part of the programming task that I bet non-programmers have never heard about.

Folks know that we programmers spend hours and hours in front of a screen typing. Some of them have even seen snippets of TV dramas or movies in which a nerdy-looking person is typing mysterious characters.

They know we are “writing code,” but only we folks who code know that one of the hardest parts of coding is coming up with names.

Each program defines its own universe — a world that you made up — and part of that universe is that everything important must be named: every procedure, every field, every argument, every local variable, every macro, every class, and so on.

A good naming convention is thus quite helpful. Indeed, many is the time that I’ve been stuck putting something new together because I didn’t have a scheme for generating the names, since you want names for related things to have similar forms. It makes the code more readable.

Eventually something comes together, and once you have your naming strategy down pat, the code may — on happy occasion — seem to write itself.

All of this is a roundabout way of wondering if other programmers express their craft by crafting their names into their code, or their employer’s code.

Are you a programmer? Have you done this? If so, please post a comment.

In my current role as a blogger, not a programmer, I assure you that your names will be kept anonymous…

PS: After posting this, I recalled a related incident from the Jikes days. We knew the code was going out in early December, so early in November I suggested to Philippe that we avoid making any major changes, so that we could concentrate on cleaning up the code, especially by making the names more uniform. The code by then was well over two years old, and we had put it together on the fly, as we learned the Java language and how to compile it. Also, we had recently revised much of the compiler to deal with an obscure feature called “inner classes.”

Talking Technology: Earth, Air, Fire, Water

This post was inspired by two recent posts. The first, by Redmonk’s Steve O’Grady, argues that The Technology Industry Talks Too Much About Technology. It concludes with

If it’s true, and it seems self-evident here that it is, that software is eating the world, technology will only become more important moving forward. In that context, quality of implementation will naturally play a role in sifting the winners from the losers. But as we move forward, it is worth remembering that the best technology not only doesn’t win all the time, it may not even win most of the time. For better and for worse.

I read Steve’s post because I’ve been a big fan of the Remonker’s going back to 2004 or so. I first dealt with Steve on a conference call during my days in IBM Strategy, when I spent a few months as part of a small team investigating commoditisation,open-source software, and their possible impact on IBM’s software business. One of the team hired Steve to get his insight.

I saw Steve’s post in part as a challenge. To wit, do I have anything useful to say about technology today? That led me to thinking about another post I read just yesterday, one that came to me in an indirect fashion.

I twit from time to time, and every so often Twitter informs me that I have a new follower. I find the arrival of a new Follower both surprising and interesting. Surprising in that I can’t see why anyone would follow anyone except Andy Borowitz and his hilarious tweets. Challenging in that I wonder why on earth would anyone give a damn about my tweeting.

In this case I learned my new Follower was Matt Walton, aka @MattWaltonRED, CEO of RED Method, a software development company in Austin that specializes in mobile software.

I became quite excited when I noted that RED Method’s newest project is EventMethod, a new cloud-based product for mobile event management. I’ve been helping a friend build a website for his startup, and managing events is one of the requirements. (That’s the reason I wrote about Drupal few posts back.) I then went on to read some of Matt’s blog posts.

I was quite impressed with one of them, Why Should Business Care About Mobile?. Indeed, a simple two-word phrase, one I don’t recall seeing before, gave me new insight into the state of software today, and some possible opportunities for the technology we are working on here at HARDBOL.

So let’s talk Technology. To keep it simple, let’s look at one simple question:

What is the single most important element in the computing industry today?

This is the kind of question that folks who talk — and write — about technology love to ask, as answering it takes lots of time, and may even put some bread on the table.

There are many options. Is it a single company? Say Apple, Facebook, or Google? Or all three together?

Or is it single hot technology? Smartphone? Tablets?

Perhaps new software? Node.js? HTML5?

And so it goes, more grist for analyst’s mill.

My own view can be expressed in a single word:

The most important element in the computing industry today is itself an element: Silicon.

Silicon is the second most abundant element in the earth’s crust, and the lifeblood of the computer industry. Silicon — in the form of sand — is the basis of one of the oldest yet still most useful, technologies: glass.

The ancient Greeks believed the world was made of four Classical Elements: Earth, Air, Fire, and Water.

Glass is the combination of two of them: Earth (sand) and Fire (energy).

Glass is magical. It is not a metal, yet it can be quite hard. It is impermeable to water and most other liquids. Best of all, it is transparent, and forms the windows that bring light into our homes while keeping the wind and rain at bay.

Glass, like any technology, can be abused as well as used. Consider, for example, the Window Tax introduced over three centuries ago:

The window tax was a property tax based on the number of windows in a house. It was a significant social, cultural, and architectural force in England, France and Scotland during the 18th and 19th centuries. To avoid the tax some houses from the period can be seen to have bricked-up window-spaces (ready to be glazed at a later date), as a result of the tax. It was introduced in 1696 and was repealed in 1851, 156 years after first being introduced. Spain and France both had window taxes as well for similar reasons.

Britain not only adopted the Window Tax — which condemned generations of people to houses with a few number of small windows –but applied another technology, in the form of the Industrial Revolution, to spend well over a century perfecting the means to coat those windows with ash, soot, and other industrial effluvia, making it even harder for the hapless Brits to see outside. Witness London’s Great Smog of ’52, the worst air pollution event in the history of the UK. Over 12,000 died.

Silicon, the key element in glass, is also the key element in modern computing, for it has the physical properties that enable the fabrication of transitors measuring a few nanometers across upon a silicon substrate. We use these transistors to assemble gates, registers, memory, and the other components of the modern microchip.

Within the last twenty years, a new form of glass has become another key technology in computing: fiber optic cable.

Or as the ancient greeks might have expressed it:

Earth (silicon) + Fire (energy) = Glass
Earth (silicon) + Fire (heating) + Water (cooling) = Wafer Substrate
Earth (silicon) + Fire (energy) = Fiber Optic Cable
Fiber Optic Cable + Fire (radio) + Air = Wireless
Computer + Wireless = Mobile

Within the last five years, silicon in the form of glass has emerged as yet another key element in computing: the glass display of a smartphone.

This new use of glass has changed the nature of computing itself, at least for the vast majority of users.

Ten years ago everyone used keyboard and mouse to create and manipulate information viewed through a glass screen. Today most people compute not by looking at a glass screen, but by touching a glass screen.

It was while reading Matt’s post that I came across the phrase “surface computing.” I don’t recall seeing it before, but I instantly knew what it meant.
See Surface computing and Surface Computer — a surface computer is a computer that interacts with the user through the surface of an ordinary object, rather than through a monitor and keyboard — and Multi-touch.

Since I found it so insightful, I here take the liberty of quoting much of Matt’s post:

First, in order to answer this, let me ask another question. Why should anyone care about surface computing? After all, maybe only a few have ever even heard of this, and even fewer, perhaps, even understand how surface computing changed mobile, and how mobile will change surface computing.

But, if you just look past the novelty of the mobile smartphone device, and really look at what has happened, you’ll notice that it isn’t the phone capability that has changed, it’s the computing capability within a very small device wrapped up in a sexy package–all accessed by the tiny tip of your skinny fingers, or in my case, fat fingers.

The bag phone, or the famous phone from Wall Street, the Motorola Brick, represented two technologies converging: the microprocessor and the signal infrastructure owned by the telecoms. Within 20 years, the phone had flown through its evolution, at a crazy speed. What I find interesting is, however, isn’t the evolution of the phone, but the ever-increasing speed of the signal, of the connectivity. Seriously, think about the connectivity coupled with our smartphone devices today. They are fast, very fast, and they are only going to get faster.

What the mobile device essentially does is that it provides a link to a key, to an identity that you control, that you own. It is just like you having a set of keys for your existence in that the device will become that for you. This, however, I will save for another, more in-depth, blog entry. But, because we are now coming to a convergence of tiny microprocessors, as far as ram and network connectivity are concerned, the market struggles with UI.

If the mobile device is the key to your identity, it is essential that you be able to access that identity quickly (connectivity) and easily (UI). How are people supposed to click on such tiny buttons, became the concern. Speed and connectivity were already solved issues thanks to telecoms, so we trained a whole generation of people to type on a little keyboard on a mobile phone to fix the secondary issue.

Then, in stepped Apple, giving us what we truly needed: a touch screen. It was, at the time, something only a very few were talking about in meetings, on blogs or vlogs. It was an area in which people were experimenting, but where in which they couldn’t crack the code for a commercial product. The solution was surface computing.

Overall, I’m sure you can find a few people with differences of opinion about what surface computing really is and how it will be used in the future, but you should care about it because it is the solution to all things mobile. Without surface computing, connectivity, speed, size, none of it would matter.

Surface computing changed the history of mobile and took it from a telecom business and brought it back to the tech world. In my humble opinion, we started surface computing back with the first touch screen, and it is just now beginning to mature.

Not even telecoms can predict where this one is going. Can you?

This expresses well a vague feeling I have had for some time. As a programmer for over forty years, I know the game has changed, and in a much more dramatic fashion that such “innovations” as object-oriented programming, Java, HTML/XML, and so forth.

The notion of “surface computing” captures the new paradigm. We no longer type on a keyboard and look at glass. Now we touch touch that glass, tap on it, rotate it, and talk to a microphone placed near the glass.

There is yet another great change going on.

Until now the majority of users have used keyboards with English characters and looked at English text, in the form of ASCII, displayed on a glass screen. It doesn’t take too many more characters, say several hundred, to display the languages commonly spoken in Europe and the Americas.

It is only a matter of time — and it may even have already happened — until most of the content of the Internet is not in English, and within the same span most of text displayed on the world’s smartphones will not be in English.

There is an additional change that has already happened, but has gone largely unnoticed.

Today’s smartphones have the computing power of a 1990’s supercomputer. That this is not fully appreciated can perhaps be explained by noting that the processor speed is not apparent because most applications have as their workload a series of simple exchanges of information with a web server, the speed of which is much slower. Also, the base languages of the dominant players — Apple’s Objective C and Google’s Java/Darvik — are both complex and too low-level for most programmers. There are lots of cycles left to permit the use of higher-level languages to write mobile applications.

With great change come both challenges to established players and opportunities for new entrants.

To me the great opportunity is to enable the use of higher-level languages, first by working at the hardware level — just above the silicon substrate — to make them more efficient; then by promoting their use to write applications at a higher level.

Any such system must thus provide full and efficient support for Unicode. A Smartphone user will not learn another language just to use it. Any taint of a non-native language will be an invitation to competitors.

I’m not sure if I’m right or wrong on this, but I do expect to spend the next few years finding out.

In praise of git and its hub: Bug fixing made easy.

I got an email from Craig Wright earlier today about Linux SPITBOL:

Dave, I hate to be the bearer of bad news, but I think I have found a minor bug (probably mostly cosmetic) in the version of Spitbol for Linux that you recently posted.

If you look at lines 7938/7947 of v38.min, you will find two minor errors:

7938 *
7939 * LISTING HEADER MESSAGE
7940 *
7941 HEADR DAC B$SCL
7942 DAC 25
7943 DTC /Macro SPITBOL Version 3.7/
7944 *
7945 HEADV DAC B$SCL FOR EXIT() VERSION NO. CHECK
7946 DAC 4
7947 DTC /3.8.1/

I think that line 7943 should be 3.8.1 and not 3.7 (perhaps 3.8 would be okay)

I think that line 7946 should be DAC 5 instead of DAC 4

I am sending you my comments by private email instead of posting them on the blog.

Java programmer, Spitbol lover since college at Ohio State, and woodturner (hobby only)
–Craig

He not only found the bug, he read the Minimal source, probably the first person to do so — except for old-time SPITBOL implementers like myself — in over a decade, and my new friend Craig even gave the correct fix!

This, by the way, is one of the reasons I *really* love open-source.

I put Craig’s advice into practice. I made his suggested edits, checked that SPITBOL still compiled, used his email as the basic text of the git commit message, pushed up the change to github, and then sent Craig a reply to his email.

All this took about five minutes.

The really nice thing is that github even makes the commit available as a separate URL. For example, see github commit 24e17d5bc730db168a6fe799012d3ece7d24041.

Not only do you see the commit LOG, you can also see the source changes that resulted from it.

This is *so* much better than how I did this over ten years ago in the Jikes days, when I had to extract text from email messages,fix the code, reply to the submitter, build a new release, run tests, create a tarball, update the web site, and so forth.

Today you just fix it, test it, and push it.

Your work is then automatically published in a form open to all, comments and source included, in a visual form very pleasing to the eye.

This is the kind of thing developers just love, and so it’s no surprise that the VC folks are starting to throw money at Github, because the VC’s know that *all* savvy open-source developers, and their code, will eventually be found at github.

The key point to me, as a developer, is not that github made my job easier. It is that by making it easier, and by displaying the work so well, github made it more likely that I would give credit where credit was due, and that is something we value dearly.

The SNOBOL Chance in Hell Software License

A few days ago, while working on SPITBOL, I looked up Wikipedia’s SNOBOL entry. While perusing it I came across a section about the history of the name SNOBOL that was new to me. It linked to a blog post by Dave Farber, one of the creators of the language WORTH READING Wikipedia entry on SNOBOL — the TRUE story NOT Wikipedias. I found it immensely amusing.

By the way, when I mentioned this to my friend Peter Capek, he said the story was new to him also, and that he knows Dave Farber. (No surprise there — he knows EVERYBODY.)

I smiled, and moved on. But I’ve just found a way to make use of that charming story, so here we go…

As part of my work on SPITBOL I’m putting together a “library” of documents and example programs: github daveshields/spitbol-library.git.

I’ve started with files obtained from Mark Emmers exellent SNOBOL site, via FTP.

All of these files have been available from the site via anonymous (available to anyone) FTP for at least a decade, some for more than two decades.

Mark either wrote the sample programs or obtained permission to distribute them, but as yet there is no license associated with them.

I plan to include the appropriate license language — most likely two-clause BSD — as time permits, but I see no reason not to put them out now.

However, I know folks are more comfortable with some license language, so until further notice here is license in effect for the examples:

You may copy, distribute, or alter this code as you see fit. It has been freely available for over a decade.

Thus, we are confident there is a SNOBOL Chance in Hell that trouble will come your way by doing so.

Would OSI approve this? I’d like to think so, but I won’t put them to the test.

Software Sabbatical: September 2009 to June 2012

I parted ways from IBM as a full-time employee at the end of February, 2009. I was brought back a few weeks later for a part-time gig working on a compiler design. That lasted until early September 2009.

I then decided to take a break from programming. Having put the bread on the table working as a programmer and research scientist for over forty years, I stepped back from my terminal to see what life was like on the other side.

Life was good — it still is.

I felt no urge to do any serious coding until recently, when one of my children suggested an interesting software challenge. Since attacking it will mainly involve lots of string processing, and to help bring my programming skills, such as they are, back up to snuff, I have decided to begin by resuming work on the port of Macro Spitbol to Linux.

 

I’ll write about that effort in the next post.

 

In any event, hope to see you soon on github.

 

thanks,dave

  • Pages

  • February 2020
    M T W T F S S
    « Mar    
     12
    3456789
    10111213141516
    17181920212223
    242526272829  
  • RSS The Wayward Word Press

  • Recent Comments

    Sahana’s Respo… on A brief history of Sahana by S…
    Sahana’s Respo… on A brief history of Sahana by S…
    James Murray on On being the maintainer, sole…
    James Murray on On being the maintainer, sole…
    mrrdev on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated