I'm coming into this blind. I saw a link to the 8th site and found out that 8th is a while new programming language and development environment that allows you to code once and run on:

• Windows
• OS X
• Linux
• Android
• iOS

Really?

As the 8th site says:

Program code is only written once, in 8th™, regardless of how many platforms are targeted. The code is then packaged to run on the target operating system, which may be any combination of Windows, OS X, Linux, Android or iOS. Differences between operating systems are handled by 8th™, letting the developer leverage existing knowledge across all platforms.

And it looks like simplicity is important to 8th. Here is the "Hello, World" program in 8th:

"Hello, world!\n" . bye

That's easy, all right.

I don't know enought about 8th, or about what exactly you can code with it, but the idea that these applications are so vigorously cross-platform really gets me thinking. Even just in the mobile space, the ability to code once for both Android and iOS is huge. And add to that all the major desktop OSes (Windows, OS X, Linux), and this could potentially be something.

There IS a catch (and truthfully, I didn't see it coming)

To produce "packaged applications" with 8th, you have to pay per year.

I'm not sure this is good, let alone -per-year good.

What do you think?

The Node.js server-side Javascript runtime is today’s hot thing. You might say it’s the Ruby on Rails of the ’10s. Where developers used to code in Perl and PHP, then Ruby/Rails, today’s startup-fueled web-development world is all about Javascript on the server, and Node is the grease that makes it all go.

And sitting atop the Node.js heap is Joyent, the company where Node creator Ryan Dahl was working when he came up with the idea and the code to make it run.

So even though Node.js is an open-source project, its direction is largely guided by the for-profit Joyent. And that doesn’t sit so well with some Node users/developers.

As reported in InfoWorld and elsewhere, a group of them just started a fork of Node.js called io.js, which is now living on GitHub and prepared to take the Node code in a community-driven direction.

As the io.js project’s “Read Me” text states:

"This repository began as a GitHub fork of joyent/node where contributions, releases, and contributorship are under an open governance model.

"We intend to release, with increasing regularity, releases which are compatible with the npm ecosystem that has been built to date for node.js."

As InfoWorld previously reported the Node forking threat has been floating around for awhile, and in response Joyent created an advisory board to get more community input into what has become one of the most-used open-source projects in the world of web-delivered application development.

Fighting, infighting, forking and just plain grumbling is nothing new to open-source projects. Friction over the transition from Python 2 to Python 3, the never-ending gestation of Perl 6, everything about Linux distribution Ubuntu and its SABDFL (self-appointed benevolent dictator for life) Mark Shuttleworth since he moved the buttons from right to left, Debian and the now-raging debate over the systemd init system that’s so much more than an init system … and the beat goes on.

The question is, does Joyent have enough developer (and major corporate) juice to keep Node as the glue holding together today’s Javascript-driven web stack?

The short-term bettor says yes, since Javascript on the server is so “now,” and corporate IT has wrapped its arms firmly around Node. But since Javascript on the server has gone from curiosity to total domination in a few short years, and there’s always something new on the hot-development-tool horizon, it’s anybody’s game.

If the many-horse race over “best Javascript web framework” is any indication, another player in Node’s space is nothing more than the familiar brand of healthy competition that keeps the technology world on its code-slinging toes.

Most forks come to nothing. Just like ex-Microsoft CEO Steve Ballmer once said in all his sweat-drenched glory, it usually comes down to “developers, developers developers.”

It's not a secret that I'm starting to look into the Ruby programming language. I've got a mess of second-hand books, plus there are plenty of helpful web sites.

I was looking into the gsub method of search/replacing in Ruby when I stumbled across something very useful: the insert method.

I'm sure there are plenty of better ways to do this, but the fact that I can do this and understand it ... that's something.

Here is what I'm talking about. I did it all in the interactive Ruby shell (aka irb) and have revised it because it's even easier to type out than I thought:

irb(main):017:0> phrase = "The quick brown fox jumped over the lazy dog's back"
=> "The quick brown fox jumped over the lazy dog's back"

irb(main):020:0> phrase.insert 0, "<bold>"
=> "<bold>The quick brown fox jumped over the lazy dog's back"

irb(main):024:0> phrase.insert -1, "</bold>"
=> "<bold>The quick brown fox jumped over the lazy dog's back</bold>"

I'm looking to figure out all the elements I need to convert my election-results Bash script to Perl, and one of the tasks involved is dealing with XML.

In the Bash script, I'm just treating the XML as text that needs to be hacked at with sed.

But in Perl, as in many languages I presume, there are modules to help with this.

XML::Simple takes a file in XML format and converts it to a "Perl representation," one of those "representations" being a Perl array. Here are some other links on parsing XML in Perl.

Perl Begin recommends avoiding XML::Simple and instead using XML::LibXML.

Now I'll have to figure out what to do with the data after Perl deals with the XML so I can turn it into the HTML I'll need later in the program.

I won't lie by saying that it is a lot easier to find recently written XML-parsing strategies for Python than it is for Perl.

With that in mind, before I close out this entry, here are some links on parsing XML in Python.

I'm continuing my reading of "Learning Perl."

The book is a bit dog-eared. Some of that is from carrying it around. But some of the wear is from actually reading the book.

I'm up to Page 74. I have been taking notes in the book and underlining things that seem important.

I meant to read this book with the Learning Perl Book Club, a reading group made up of Ode users.

That didn't work for me. The stopper was the "you need to do the exercises" part of the enterprise. While I had the time to do the reading, I had a lot of mental resistance to trying to hack at the exercises at the end of each chapter.

I know that doing the exercises in these books helps you "get" the concepts, but I just wasn't there yet.

Now that I'm a few chapters in, I want to start typing the book's programs into my local system, running them and playing around with them a bit. While that's less than going all in on the exercises, it's more than not touching the computer or using Perl at all.

Now is the time. I'm going to really learn to program.

I've been dabbling in programming for awhile now. I've mostly stayed within the friendly confines of the Bash shell on my local Linux system and the Linux servers on which I run various scripts and services.

I've been meaning to get deeper into real programming, whatever that is, for at least a couple of years. I would say it hasn't happened, but to a small extent it has. Now I'm ready to take the next step.

So what did happen?

A couple of years ago, I began writing little Bash scripts to automate my rsync-driven backups. With these little one- to two-liners, I didn't have to remember the exact syntax to do the rsync backup correctly and remember where my "exclude" file was living.

I also had trouble with screen blanking in Debian Wheezy. I finally figured out how to fix the problem with xset, and wrote a little Bash script to automate that process.

I have also written a bunch of scripts to automate posting and create an archive of this Ode site. Among these Ode-related scripts is a local Perl program that generates an Indexette date stamp. You can copy/paste it into your post file, or call the script from within a text editor, which is what I do with Gedit.

It's still a simple two-liner, albeit with more than a dozen lines explaining what's going on.

About a year ago, I started a more complicated programming project at my day job.

So what do I do at this job? I work for a bunch of local news web sites. I push content. I create web pages in an arcane CMS. I create blogs in a common CMS (WordPress). I fix broken things and solve problems. I take things that are separate and mash them together.

The project, the thing I've wanted to do, was to script together data from various sources, more specifically election results for the nine web sites I work on.

I wanted to do it in Perl. But when I finally decided to do it, I just didn't have the chops. But I did know Bash, and I learned (or learned more) about such Unix/Linux utilities as wget, cat, cp and sed to turn my data into HTML pages I could generate with cron and iframe into my various web sites.

Thus far I've been re-reading "Learning Perl", this time noting things that will help me in my election-results project.

I'm somewhere in the 40s in terms of pages, and I'm making notes in the book -- it's a real book, not an ebook -- in pencil.

• Search and replace is pretty much a core function in Perl, so I can safely say goodbye to sed.

• Concatenation can be done with a dot (a .) between items, so that takes care of cat.

• I would really like to pump data into an array and use Perl's foreach to process each line.

• Grasping scalars and arrays is going to be key.

• I'll have to look into grabbing data over HTML and bring it into the scalar or array. The LWP::Simple module looks like a good candidate for this. I could also use the full LWP.

• I'd like to code a date stamp into the data. I've already experimented with that in Perl for my Indexette date-stamper script.

• Eventually I'll need to write the results out to files on the web server. That shouldn't be too hard.

At some level, ends and means in computer programming dictate that whatever language gets you there is the right one.

If you want to work on a certain project, and that project's code happens to be written in PHP, that is something to think about.

Do you want to attract collaborators? From among the languages you like, pick a popular one.

Read the rest of this post

Read this: The Fall of Perl, the Web's Most Promising Language, by Conor Myhrvold

brian d foy says, "The Fall of Perl" would more suitably be titled "The Rise of Python"

Buddy Burden released the next post in his series on programming, life and everything.

As I said recently, I'm a huge fan.

This one is about "getting shit done":

I’m one of those people who wants to write code to solve every problem that comes along.  If I could figure out how to make a Perl script make my bed, or clean my room, then those things would certainly get done a hell of lot more often.  I’d put it in a cronjob.

I’ve written code to calculate my kids’ allowances, email daily chores to them, track my hours for clients, keep track of info when hiring employees, reset the database for my music player, search for things in my instant messaging logs, organize my music collection, figure out how much space I have left in my Dropbox, balance my checkbook, query package management systems regardless of which flavor of Linux I happen to be running at the moment, calculate Weight Watchers points, track my todo list, count lines of code, print out certain lines from a file, and make a Gimp plugin to help me make cards for my favorite wargame ... and that’s just a small fraction. 

...

I write a lot of code, even outside work.  If there’s any obvious way to use code to solve a problem (and sometimes even if the way is non-obvious), I’m going to write a program.  I can’t fix a car, I suck carpentry and plumbing, I’m not very good at yardwork or gardening, and I’m not even particularly useful at administering my family’s eclectic collection of personal computers, laptops, and tablets, but I can write the hell of out of some code.  And I’m the type of person who will gleefully spend days trying to solve a problem with code that I could have probably just done manually in a few hours, because I don’t mind spending days on a program, ’cause it’s fun.  But just because I don’t mind it doesn’t mean I want to do it all the time.  What I’d really prefer is to get in, write the code, and get out.  Just Get Shit Done.  And that’s what Perl lets me do.

That's a programmer, all right. I don't usually drop quotes this big into entries, but there's way more I could have quoted from this excellent entry.

Again, the entire series is essential reading.

Buddy Burden writes a great eight-part series, Perl and Me, on his approach to programming, how he came to code in Perl and what he thinks is wrong (and right) with the profession and teaching of programming.

It's not all about Perl, though much of it is. Every programmer should read it.

My favorite is Perl and Me, Part 7: The Most Powerful Weapon Which You Can Use to Change the World

I would offer a few quotes from Part 7, but the whole thing is so good that you should just go read it now), then go back to Part 1.

Read the rest of this post