Saturday, July 23, 2011

Cool Delphi Answer: The Vigenère cypher as a code sample.

I would like to draw your attention to this answer on StackOverflow, where Andreas Rejbrand, a noted Delphi coder, has implemented for your pleasure, the classic Vignere cipher, a notable historical algorithm in cryptographic history because it resists casual attempts to decrypt it much better than ancient simple-substitution cyphers.

As a challenge, Andreas has asked anybody who wants to, to try to crack an example bit of text that has been encrypted using this cypher. Since you know the algorithm, and it's a historical algorithm, the most wonderful part of this answer is that I hope someone takes him up on this, and learns a bit about cryptography by trying to crack this cipher. Andreas has offered 100 SEK for the winner.

I consider it an epic mini-hack, and a nice bit of community on StackOverflow. As well, I consider that putting such effort into building a Delphi answers sub-community on StackOverflow is one of the brilliant things that can help new Delphi users take hold and begin to grow into competent (and eventually expert) Delphi developers. And that is the answer to the problem I wrote about yesterday.

I think Delphi is cool. And Delphi programmers are the coolest.

Friday, July 22, 2011

Is being a Delphi Developer career suicide?

A very smart guy that I have worked with in the past said to me yesterday, that the time he spent working on a project written with Delphi was tantamount to career suicide. I have little to no external evidence to prove him wrong, and yet I believe he could not be more wrong.

Let's try to understand his perspective first, though. From his perspective, C# and Java and C++ all have a large number of jobs up on all the major job websites. And if Delphi truly remains (in my opinion) a secret weapon, that developers can use to gain an advantage, how come so little software is written with it? Okay, Skype for Windows is written in Delphi. But none of the other versions of Skype (for your phone, or your mac) are written with Delphi.

I see a vicious circle-of-perceptions. The circle goes like this: There are no delphi jobs because there are no delphi developers because there are no delphi books because there is no market for delphi books because there are no delphi jobs because there are no delphi developers..




And there are barriers to entry, and network effects. New developers coming out of school have a number of barriers to entry with Delphi, including the fact that both Visual Studio and Java are essentially free to learn. The language-popularity network effect is viciously effective, here.

So how is Delphi going to survive against Visual Studio (Express is free) and Java (Eclipse and Java are totally free)? My friend's answer is simple; It isn't going to. In fact, you could argue, it's already statistically irrelevant. It's popular to quote the TIOBE list for that purpose. Now being #14 (Delphi) and #16 (Pascal) on the TIOBE list means that Delphi is, in general about as obscure as Lisp, and RPG ILE. And in fact, I notice there are more jobs out there for RPG LE developers then for Delphi developers, in most cities.

But writing off Delphi on such a flimsy basis would be a shame, in my view. I believe that the real cost of writing software is, and always will remain, the salaries of the people, and that tools that make those people work better, are worth buying. Not only is it worth buying an IDE, it's worth buying a profiler, and components, and other tools, if they act as "force multipliers" that make you more productive. Delphi is a great tool. Its merits do not grow less important, when less people use it. So what does mass-popularity mean, anyways?

I guess Delphi fans consider themselves a bit avant-garde, rather than behind-the-times. But which are we really? Delphi is a great tool for lone-wolf developers, and even if the corporate use of Delphi died out, single-man-shops would remain a significant Delphi user base. Probably millions of people worldwide. And yet, there might be a million people still modifying their Visual Basic 6.0 apps, and half a million people keeping CA-Clipper based or Excel-spreadsheet based custom apps running, just barely.

Let's face it; Corporate adoption of Delphi is important to everybody who uses Delphi. I would like to see a renaissance of Delphi corporate use. I'd like to see an end to corporate attrition away from Delphi. If you search for jobs involving Delphi on major job sites, you'll find fully 50% of the mentions of Delphi are from companies that are shifting away from Delphi. I know of several places in my city, that have major products that were built in Delphi, that have moved away from Delphi in the last five years. The perception of Delphi being "a fading away thing" drove the decision in many cases, more than the technical merits of a rewrite of a Delphi app in C# or Java.

I don't want my friend's pronouncement about Delphi to be true. But I'm looking to the future of Delphi, beyond Delphi XE, to change that. I believe Delphi is on the brink of a renaissance. A new level of functionality would help. But the thing that Delphi needs most of all is better documentation, and tutorials, and needs to encourage new user adoption by having more cheap or free training materials. These barriers to entry are surmountable. The new user experience in Delphi XE is not as simple and easy to get started in as Delphi 7 was. I think that those who love Delphi and want to grow the community, so that Delphi usage goes up in corporations and at startups, need to focus on the new-user's out of box experience. I am going to write a series of posts on what I think can be done.

I'm also going to play with the Delphi Welcome Page, and make my own version that is friendly for new users. I'll also record some screen-casts with New User Tutorials and post them on here. Here's my homework for you Delphi fans; Go make a tutorial video and post it on your blog. Explain why Delphi works for you, and why it solves problems that make it worth your while to learn a tool that other people are dismissing because it's not C#, and it's not Java, and it's not C++.

To survive, being awesome is not enough. The best way to save the future for Delphi is to make sure it's easy for people to learn it, and get up to speed. I think that a new big-fat-book, that covers as much ground as the Mastering Delphi or Delphi Developers Guide books did, is needed. I think about 500 tutorial videos are needed. I think that a lot of creative pricing and promotion is needed. The Delphi Starter edition was a great idea, and I heartily approve of it. I'm excited and positive about Delphi's future. But I think it's time to confront the elephant in the room; Delphi is neither dead nor dying, and it's not in the top-ten on TIOBE either. If you need to feel better by putting something else down; Feel bad for the SmallTalk folks. SmallTalk was supposed to be the biggest thing ever, and now at #48 on the TIOBE index, it's down there below COBOL and APL.

You know what's career suicide? COBOL and SmallTalk are career suicide. Except, I bet if you're really good at either one of them, you'd have more offers than you knew what to do with. The world is a big place. The internet is large. Guess what. Being in the top ten isn't necessarily going to be that great for your career either. I know you can get some big money these days working on RPG ILE and COBOL. Any takers?

Tuesday, July 12, 2011

64-bit Delphi Preview.


This has been up for a little while on the Embarcadero Delphi web page, but I am sure there are people who are interested in knowing more about the future of 64 bit delphi.

If you're willing to sign up for the Preview Beta, and you get accepted to the Beta, you can try the 64 bit Delphi compiler today! Check it out here on Embarcadero's website. According to the website, it's not guaranteed that all who apply will get in. A video is available at the website link where Embarcadero’s David Intersimone takes you for a tour of the Delphi 64-bit compiler.

Thursday, July 7, 2011

Delphi open source component: TComPort




The TComPort component was originally written by Dejan Crnila, it was modified a bit by other people, including me, among others. It didn't need much tweaking, other than a bug fix here and there, and support for new Delphi versions as it came along. The latest version 4.11b is available on SourceForge here.

Like a lot of developers who need to do serial communication, I started using Turbo Power's very capable AsyncPro product, which is still alive, and doing well. I have said some negative things in the past about AsyncPro, because the complexity in it mixed poorly with the complexity in my products, and when I had to debug things, I found it really hard to debug AsyncPro. But I should introduce a policy here on Delphi Code Monkey; I intend to publically do penance for stupid things I have said in the past. AsyncPro is a fabulous component set, and nothing negative I have said in the past should be held as more correct than the simple fact that lots of people use, and still use AsyncPro, and are happy with it.

Nevertheless, as a person who believes strongly in the "smaller is beautifuller" concept, almost to an absurd degree, and who has found that the less code I put in my application, the less my application breaks in horrible ways, I still prefer TComPort for the cases where I need to do serial communication in a delphi app.

TComPort seems like exactly what I needed for my purposes. So what were my purposes? I wrote applications that did the following things:

1. Talk to industrial or scientific or laboratory equipment, over an RS-232 or RS-485 link. Some of this equipment including Programmable Logic Controllers, using a common protocol called "Modbus RTU", or simple Ascii (text based) serial protocols, some with, and some without checksums. For modbus capable PLCs, I wrote a descendant component that does Modbus client communications, for Delphi, that can talk to a wide range of industrial and process control, and scientific equipment that implements this protocol.





2. Talk over a direct cable link, or a modem link, to equipment at a remote site. This is incredibly powerful. One application I wrote in the mid 1990s had dialup remote control of an emergency power grid that could be remotely activated by the power utility company in a major midwestern US city, whenever the grid needed additional capacity.





Here are things that I didn't need TComPort to do, things that would make AsyncPro a better choice than TComPort:

3. I did not need a full featured "video terminal emulator" that did fifteen different terminal emulations, including a reliable VT-52, or PC ANSI terminal emulation. You might need this, if you had to connect to an old computer system that provided serial terminals.

4. I didn't need to use the file transfer protocols from the BBS era, that include XModem, and ZModem.

Back in the DOS and BBS days, long before the Internet, those of us who used to "go online" used to do so using DOS programs called "Terminal programs", and plastic boxes called "modems", that let your plain old phone line talk at incredibly high speeds, between 300 and a few thousand bits per second. Just about everything that you could do in Telix, you can do in AsyncPro. AsyncPro (formerly from TurboPower, now open source) is better than TComPort, if you need a full featured video terminal emulator, or x/y/zmodem file transfers. If you still wanted to write a Telix for Windows in Delphi, Async Pro would be perfect for you.

So having given AsyncPro its due, let me proceed to why I like TComPort:

A. Small, Fast, Light.
B. Simple thread and event model.

One common place that serial ports still show up these days is in the IT world. Sometimes you might have a network router, or VPN box, that has a serial terminal that you might want to talk to. At one of my old workplaces, we had a building alarm system that had a serial port cable. We logged the alarm activity on our servers, using a little capture program, originally in VB, which I rewrote in Delphi.
Just because.

If you want to drop a component on a form, and talk through a serial port, check it out. Your programs can remotely interact with, control, or supervise a wide variety of equipment out there. You could even attempt to write the Auto-Dialer that figured so prominently in the 1980s movie War Games. Please don't hack our national electrical grids though, or I will have to hunt you down and give you a wedgie. Also the CIA and FBI might want to talk to you. Be good. Thanks.

If you have problems with this component, you can talk about it on the forums on sourceforge, and we'll try to help you out.

I could use a little help getting the component working again in C++Builder, so if you're a C++Builder expert out there, please check in with me. We need you.



Wednesday, July 6, 2011

The Things I love About Delphi

Disclosure: At the time I wrote this, I was working for Embarcadero, but not on the Delphi/RADStudio team. I do not get paid money to say nice things about Delphi, but whether I did, or I didn't, I would say nice things about Delphi anyways. I no longer work at Embarcadero, and I still don't get paid to say nice things about Delphi, and I still think it's the best language/IDE/tool in the universe.



When I started learning programming, I was using a Commodore 64. I never stopped learning. I learned C/C++, I learned Python. I learned Objective-C. I learned a bit of Java. I learned some Smalltalk. If you love programming, you love continuous learning. I have a particular habit of learning new languages. But I always come back to Delphi when its time to Get Stuff Done.

While using Delphi every day I still learn something new every day. Sometimes, it pays to go deep in your learning, especially with Delphi. If I could always learn without getting tired, without getting frustrated, and without getting sometimes a little teensy weensy bit angry, I would be a better programmer, but I would be somewhat less human.

Because I am a mere mortal, a human being, I prefer Delphi to everything else I have ever used, because it is a programming environment created by, and for human who want the following things:

1. Quick, if not instant, results. I don't want to wait all day for a build.

2. Little or no accidental complexity. Accidental complexity is most simply defined by me, in laymans terms as "crazy crap that you shouldn't have to do, and that renders a system unfit for use by humans".

3. I want to write an application that runs well on Windows.


If you have ever tried to write a Windows application, you will see that you have a lot of choices. So why choose Delphi? Every programming language or tool choice introduce tradeoffs, and complexities. Remember in my previous post, where I said that "when all you have is a hammer, everything looks like a nail". Well, Delphi is the best hammer out there, if your nail is "write an app on windows".

If you only wanted to write an application for Windows, and you wanted it to just work, and not require any runtimes or complex installation scripts just to get it to run on someone else's PC, running any version of Windows since Windows 2000, then Delphi is the very best thing ever. If you wanted to target Windows 98 at this late date, you still could, but you would have to use Delphi 7 or 2007, not Delphi 2009 or later. Delphi requires no runtimes. Delphi runs fast. Building apps in Delphi is easy. Complex user interface requirements can be cut down to "done" by addition of some components. The language is powerful, and you can build amazing stable codebases in Delphi, unit test them, and work in a very fast "agile" RAD method, and build great things, in Delphi.

You can also use Delphi to build spectacular piles of Crap. I would like to humbly confess that not every application that I have ever written in Delphi is an application I am proud of. Some of them have been crap. But I learn from those mistakes, and each time I make different ones, and the results are (hopefully) better and better each time. I fully believe in object-oriented programming, and I fully believe in unit-testing. I believe in self-improvement and personal growth, as a developer. Never, ever, has Delphi held me back. If you started today learning to write Windows applications in C#, or Java applications, you will hit walls, at some points, walls that for me, Delphi Code Monkey do not exist.

Here's what I get out of Delphi that I don't get anywhere else:

1. Complete a RAD workflow. I will give a demo of what a complete RAD workflow is, in a subsequent demo. If you have ever used Delphi or Visual Basic 6, you know what a complete RAD workflow is.

2. Flow Mode. Flow mode is about freedom from distractions. If you are driving your car and you are thinking about driving the car, thinking about where they put the darn gear-shift, and how exactly you're going to manage to park this thing, then you are not in flow mode. If however, you and the machine are one, then you are in flow mode. Flow mode requires the "RAD workflow" above. Flow mode also proceeds from the beauty of the Delphi Object Pascal language, which I will write about later.

3. Platform Fit, without the Fat, while minimizing External Runtime Dependencies. "Running Light without Overbyte" was the old tagline from the venerable "Doctor Dobbs Journal". I like to write apps that belong on Windows, that look right on windows, and perform properly on windows, and which install without any trouble on windows, and which (seemingly paradoxically) have almost no dependencies on additional Windows technologies, especially not flaky ones like MSXML, WinInet, Internet Explorer embedded views (SHDocVw), etc. I will write a separate blog post about this "work on Windows, but don't swallow everything that comes out of Redmond" philosophy later, and the reasons for it. Most of those reasons come from having gotten burned by the poison-pill effect of adopting Microsoft's technologies. While I use Windows, and quite like it (Windows 7 is great), I abhor almost all the additional layers and components that they have put on top. I abhor them, because Microsoft has made me suffer like no other company has ever made me suffer. Bugs in Windows components have caused me more pain than anything else in my programming career. This pain is deserving of comment, and I will expand on it later.


4. Delphi Components. Components, and their designtime and runtime elements are the best part of Delphi. Imitated, or reimplemented rather, in C#, and the .Net Framework, and copied poorly again in the "Java Beans" model, they are missing key elements of what makes them great in Delphi. If you have never tried Delphi, you have never experienced the amazing capabilities of the component model. There is nothign to equal them. Not coincidentally, there is nothing out there to equal the delphi component ecosystem that exists in the wild. Sadly, the commercial field of component vendors is much thinned as of late, but the remaining companies selling commercial delphi components sell great stuff. The delphi Open Source Component ecosystem is thriving. I will write about that separately as well.

5. Delphi programmer community. My fellow delphi developers. You guys rock.

6. The Object Pascal language, a thing of beauty. More or less. I'll write about the beauty, and the warts, in another place.

7. The VCL framework. The most awesome framework ever written for windows, although a little long in the teeth, still quite respectable. The "Properties and Events" elements of the VCL framework merit special mention, and I will cover them later.

8. The IDE. The Rad Studio XE IDE is the richest IDE I have ever used. Not just a text editor, it contains "Together" based refactoring and diagramming, audits and metrics (for Boring Manager Rob's benefit, as well as Code Monkey's benefit). Recently, the IDE added the F6 key "IDE Insight" which is my favorite IDE feature ever.

9. Direct Windows API access, painlessly. Thanks to Delphi's native integration with Windows, and the giant Windows unit, almost every core API of windows is already available to me. For anything really advanced, or out-of-the-core-kernel/user dlls, the JEDI API project provides wrappers for almost everything under the sun.

10. Small is beautiful. Delphi creates (for the year 2011) pretty small output, when you want it. If you go back to Delphi 7, you can get insanely small executables. This is really handy in lots of places, and not just for virus writers.

And that, my friends, is why Delphi is the best thing out there.

Tuesday, July 5, 2011

What does Code Monkey mean?

This is a fan-made video for the Jonathan Coulton song "Code Monkey"....



(Update: replaced original low budget fan video with an anime style fan video).

A code monkey is someone who writes code, who loves to write code, eat cheetos, and drinks mountain dew. There are some substitutions possible here. Some days I might prefer Hickory Sticks, or Coke. However, a code monkey is clearly not a "Boring Manager Rob".

A "Boring Manager Rob" is someone who is interested more in metrics, and gantt-charts and burndown rates, and moving 30,000 bugs from one bug-tracking database to another one. A Code Monkey, in my view, would rather quit than stop doing what he likes to do, which is build beautiful code, elegant applications, and polished usable software products that end users love using. Or maybe, if you're Jonathan Coulton, you'll quit your dead-end junior software job, working for Boring Manager Rob, and become an independant geek troubadour. Since my guitar playing is definitely not up to scratch, I think I'll keep writing code, and let JoCo write songs about writing code.

The term Code Monkey is usually applied to Junior Programmers, and that can only be used in an ironic sense in my case. I've been writing software in Pascal (and then Delphi) since 1989, and I started writing Commodore 64 basic and assembly language in 1984, and so I'm not exactly a junior programmer any more. I'm pretty gray, but what I really like doing is writing code. I have managed teams, and I have done my fair share of Engineering Software Process Management. Meh.

I like code. And so, for as long as I can, I'll keep writing software.

Welcome to Delphi Code Monkey

My name is Warren, and I'm a Delphi Geek. In this blog, I intend to write about writing applications for Windows, and eventually about writing cross-platform applications.

I might do a few deep-dives into some Win32 internals, and I might write a bit about my philosophy of writing applications.

I started using Turbo Pascal 5 in high school, and I have been using Delphi since version 1.0, and I've made the 16 bit to 32 bit transition, and the Ansi to Unicode conversion (Delphi 2009), and I hope that when the 64 bit version of Delphi arrives, I'll navigate the 32 bit to 64 bit transition as well. And since it seems inevitable that Delphi will be going cross-platform some day, I wouldn't be surprised if I start writing about Cross-Platform stuff.

I work all day in Windows, and I know Windows inside out, but I actually like the Mac and Linux platforms better. I've done a fair amount of Python, C, and C++ on Linux, and I've started learning Objective-C on Mac, so I might write a bit about things other than Delphi, but I will always try to include a Delphi angle in everything I write. Delphi developers should learn Python, C#, C++, and other languages. That way when people criticize us because we're just using Delphi because we're too stupid, or too lazy to learn anything new, since we started in the 1980s in TurboPascal, we can politely point out that we use lots of other languages too. If you don't, then you deserve to be critiqued as a one-note-Johnny.

I also plan to discuss my favorite coding aphorisms, sayings, practices, and techniques. Let's start with a great one:

When all you have is a hammer, everything looks like a nail.


I think the meaning is obvious. But just in case it isn't, consider a person who only knows one programming language, and only knows certain parts of that tool, its language, and its libraries and components. When you don't know something, you limit your ability to solve problems creatively, reliably, and properly.