I like to open with a joke.  I won’t this time, I’ll close with one.  And then I will let Bob Newhart make it funny.

I have spent my entire professional career at here at SlickEdit, and almost from the start, I have handled our version control support.  This means a couple of things:

  • I have only used (on a day-to-day basis) the version control systems that we have used here at SlickEdit.  In the early days we used our mutli-file diff feature.  I prefer to think of this as a testament to how good our diff feature is rather than what you are thinking – which is probably “that is pure insanity”.  In later years we used CVS.  Eventually we moved to Subversion.  A little sooner than we wanted because of how it handles branches – this is another story.
  • Because I have to handle supporting them in SlickEdit, I have tested most of the free and commercially available version control systems (and a few that are no longer commercially available) on small source bases.  I have not actually used all of them, I have some experience with them.  The technical term for this in our industry is, “I know enough to be dangerous”.

We have 3 kinds of version control support in SlickEdit:

  1. Basic “command line” support, where we will run your checkin command according to a specified command line where the file name is filled in.
  2. SCC support – For version control systems that have an SCC provider, we will communicate with it and provide the level of support that SCC allows for.  This can be frustrating because if an SCC system crashes, it will cause SlickEdit  to crash.  This happens occasionally because SCC providers tend to do their testing with Visual Studio, and not other systems.
  3. “Specialized Support” – This is what we provide for CVS, Subversion, git, and now Mercurial.  We provide a GUI for viewing what files you have modified, what files are out-of-date (where possible), and a nice history dialog, among other things.  Initially we did this sort of support for CVS because it was a different animal than the systems supported by 1 and 2.  CVS is more directory oriented, rather than file oriented.  This is true of all of the systems that have this kind of support.
Unfortunately, none of our support is a replacement for a basic level of understanding of  how to use your version control system.  This is increasingly true as time goes on.  If you do not understand how Mercurial works, even though we provide some nice GUI interfaces, using Mercurial through SlickEdit will still prove confusing at best.  For Mercurial specifically, I would recommend the Joel Spolsky tutorial, especially if you are an experienced Subversion user, as it is tailored for that.  Joel’s assertion is that Mercurial is better.  As of this writing, I still prefer Subversion, but he makes some interesting points.  Either way, it is an excellent introduction to Mercurial.

So, now SlickEdit supports Mercurial, which a little different from git, which is a little different from Subversion, which was a little different from CVS.  So, if you’re sitting at home in your basement (excuse me, “office”) writing a version control system that is going to solve the issues with Mercurial that weren’t solved in git, that weren’t solved in Subversion, that weren’t solved in CVS, I would like to say (politely):


Enough already.  The next version control system released needs to offer some real improvements over what is currently available.  Since I have to support it, I’ll be the judge of what is a real improvement.  Just contact me here… I’m easy to find.  I’ve been here my entire adult life, integrating version control systems, comparing files, and working on my manifesto (no, this isn’t it.  This doesn’t even scratch the surface).

P.S. The last couple of paragraphs are supposed to be funny.  I understand the differences/advantages of  these different systems, you don’t need to leave me nasty comments.

P.P.S. If you didn’t find any of what I wrote funny, take a few minutes and allow Bob Newhart to make you laugh.

If you don’t find this funny, I can’t help you.

If you’re in need of one last gift for the techie on your holiday shopping list, we suggest the following.

Caffeinated Soap
No, we’re not making this up. 
Between end-of-year project deadlines, gift shopping, and other holiday preparations, a coder can get really squeezed for time. And you don’t want to back a programmer into a corner where they have to choose between sufficient caffeination and personal hygiene. This should avoid any such unpleasantness.

A Blunt Instrument
There are situations in which you simply cannot improve upon a large hammer.  This is the reason that the B-52 has had such a long lifespan. This orange beauty will allow your beloved techie to vent frustration upon keyboards, desks, recalcitrant Solaris machines, etc without the risk of forehead or hand injury.

A “Come home for dinner late” card
It’s surprising how many bugs are found just after the “I’ll be home by 6:15 for dinner” phone call. Your programmer is now torn between a promise to loved ones and a dedication to hunting down that crash before calling it a day. Give them a Monopoly-style “Get out of dinner, free” card so that at least once this year week, they can arrive late without guilt.

A USB-chargeable flashlight
A USB flashlight is insidious in its irresistible blend of techie-seducing features. First off, it’s a USB device. *Anything* USB (and to a lesser extent FireWire) is worthy of investigation. Secondly, it’s the size and shape of most trade show trinkets, which programmers are wired at birth to hoard. Thirdly, it has a genuinely useful function, which all but ensures your coder will make every effort to rationalize this gadget’s place in the laptop bag for years to come.

Carpal Tunnel Therapy
Because sometimes you gotta play hurt.
(Not yet verified, but I think this thing can also make homemade ravioli…)

Yoga Gear
Not only is this great for relieving the tension of long hours frozen at the keyboard, it appears to also be a crafty way of furthering ones career.

The problem of retiring mainframe developers has been well publicized in recent years. Mainframe systems are not going anywhere, and programmers now expect to be working within the comforts of a modern IDE, rather than on a simple terminal. Eclipse-based front ends have become great solutions for this new generation of programmers working on mainframe systems.

Since the Eclipse IDE has become so popular for mainframe developers, we have been dedicating more and more resources to our mainframe language support. The SlickEdit editor is even now integrated into the Compuware Workbench:

Supports a vast array of programming languages for source code editing, powered by SlickEdit.

PL/I is one of the mainframe languages that got a major support upgrade in the newly released SlickEdit Core v3.7.1. The SlickEdit editor now has full support for parsing structures, includes, and even statement level tagging for PL/I code.

SlickEdit Core also has great support for COBOL, JCL, REXX, and other languages. If you are a mainframe developer coding in an Eclipse-based environment, try out the latest version of the SlickEdit Core plugin for free.

« Previous PageNext Page »