Yesterday Microsoft launched a new version of Visual Studio. It's stuffed with new features, has a new shell, and introduces a major new release of the .NET Framework, so there is plenty to take in if you work on Microsoft's platform. In fact, with so many things clamouring for attention it would be easy to give little attention to the brand new language that comes in the package - Microsoft F#. Admittedly the language is not entirely new; it's been around for anyone to try for some time. Nevertheless, it is new to Visual Studio, and giving it the status of a fully-supported language alongside C# and Visual Basic is bound to have an impact.

So why bother with F#? As it happens, I'm writing this from Intel's software conference in Barcelona, where the topic under discussion is parallel programming. We've heard nothing about F# (even in Microsoft's presentation); yet F# is a functional programming language and inherently well-suited to concurrency. One of the key features is that variables are immutable by default, whereas in imperative languages like C# and VB the opposite is true. Immutability makes multi-threaded code much safer.

Here's what F#'s inventor Don Syme told me when I asked him what F# brings to concurrent and asynchronous programming:

There's three things. The first is a real focus on reducing the amount of mutable state in your programming. This means in essence that your mutable state is to be boiled down to the absolute essentials of what has to be mutable. If you do have some mutable state it's local to the user interface thread or local to an agent. But in general you can often completely eliminate the mutable state through this consistent set of functional programming techniques, often by passing some data around explicitly, rather than propagating the data everywhere implicitly by these sort-of global mutable tables. So a focus on immutability first is a major factor.

The second is this Async programming feature which essentially allows you to add lightweight reactions to the system, so you can have many objects waiting to be activated by a callback of some kind, and you can program these objects without doing what's called inversion of control. You can program a series of sequential execution, a series of web requests for example, go to one web site, go to the next web site, go to the next web site and so on, and you can write what we call asynchronous workflows to express this logic which would otherwise be encoded as a set of callbacks all the way through your code. This is extremely important when you're talking about handling errors in a series of asynchronous calls or perhaps accumulating a set of resources across the calls and making sure we clean up file connections and other things that happen during a computational process.

The last thing we bring is an Agent-based programming model built on top of the asynchronous model. This lets you define many hundreds of thousands of agents in memory, in a single process. And this is critical if you're reacting to many different external events such a web crawler having many different i/o requests outstanding at the same time, or processing many different images in parallel.

It's a compelling story; and there are other nice things about F# as well, like the succinct, easy to follow programming style it encourages.

Let me now put this together with a conversation I had yesterday with Intel's Chief Software Evangelist, James Reinders. I asked him about functional programming and he sighed, telling me that yes, languages like F# make parallel programming much easier, but that there was no sign of developers switching to them. In addition, he said, there is so much existing code out there that no functional language can succeed unless it can extend applications written in other languages.

It then struck me how well Microsoft has ticked that box with F#. It is a .NET language, so integrates easily with C# or Visual Basic, and it is presented as a language with which to create libraries for specific tasks, rather than as something you are likely to use for an entire application. It seems to me that it can deliver real value and is well worth exploring.

There's more on F# here; and look out for more from my interview with Don Syme soon.

I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.

Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.

Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:

• Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
• Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
• Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
• Eliminate duplication in your code; use abstraction.
• Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
• Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
• You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
• Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.

Agree? You can sign the Manifesto for Software Craftsmanship.

I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:

Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.

Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.

I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.

Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.

A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.

Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.

I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.

Microsoft's Eric Nelson conducted a poll on how many businesses still use Visual Basic 6. It is hard to make sense of the statistics, since there was a built-in bias:

This survey was sent out to individuals we "suspected" had Visual Basic 6.0 heritage but it was also widely advertised through the MSDN Flash to UK developers.

In other words, only Windows developers were consulted, and those more likely to be using VB 6 were specially targetted. Some results:

• 86.53% of respondents still program with VB 6
• 87.62% actively maintain VB 6 applications
• 46.81% have more than 100,000 lines of VB 6 code running
• 42.58% plan to keep their applications in VB 6 for the forseeable future, even though most respondents believe that neither runtime nor the development environment is now supported by Microsoft
• 51.76% plan to migrate their VB 6 applications to .NET (mostly to VB.NET, but a fair amount to C#), but are in no hurry to do so: most said "over the next three years"

See the original post for more detail. I'd like to know more about the wider picture - how many companies overall still use VB 6 - but although these figures are skewed I can well believe that there is a lot of VB 6 out there.

Incidentally, the respondents are correct in believing that the VB 6 IDE is no longer supported. Extended support ended in March 2008. However, note that Visual Basic for Applications, which partly shares the same runtime, remains part of Office and therefore is supported. The VB 6.0 runtime is supported at least until 10 years after the release of Windows Server 2008; see this paper for exactly what is and is not included.

I noticed that msvbvm60.dll, along with other VB 6.0 runtime files, is also in my beta copy of Windows 7. I guess that will nudge the support life for the runtime even further into the future.

The bottom line is that Microsoft would be crazy to release a mainstream version of Windows that could not run VB 6 applications. For the most part, laggard VB 6 developers are safe, though there could be third-party components that stop working. Another point is that VB 6 will always be 32-bit.

All this prompts a few observations.

First, if you have skills in VB 6.0, it looks like you will be in demand for a while.

Second, my own views on VB 6.0 are mixed. I recognize that it was a revolutionary and very capable tool; but if anyone is inclined to wax lyrical about its merits, I point them towards Verity Stob's Thirteen Ways to Loathe VB and Bring your Hatchet by Bruce McKinney. At best, it is a flawed platform.

Third, I do see the sense in leaving well alone in many cases. VB 6.0 is lightweight compared to .NET, and runs on a wider range of hardware. Migrating code is perilous unless you have rigorous unit tests; some quirk in VB may catch you out, so that ported code does not work in quite the same way.

It strikes me that there is little value in migrating from, say, a VB 6.0 client application to a .NET Windows Forms application. My instinct would be either to leave it be, or redesign it as a web application. Otherwise the risk is that your new ported application will be just like the old version, but slower.

Microsoft has a summary of the options here, which seems to promote the idea of hybrid applications, perhaps using the Interop Forms Toolkit to embed .NET controls in VB 6 forms. Maybe, but there is a danger of getting the worst of both worlds. That said, every case is different so there is little value in generalizing. The important thing is to have a technical and business rationale for the path you choose.

It's hard not to love PHP: fast, powerful, and useful for anything from quick web scripts to major applications. The trouble is, PHP is just too forgiving for my taste. I've been working with PHP recently and occasionally made some silly errors (my excuse: it was late). I mostly work in other languages, so from time to time I would forget that in PHP variables all begin with a $ character. In other words, I wrote code like this:

$err = 0;
 if (err)

 {

     print("<b>No match with this username and password. Please try again.</b>");

 }

Unfortunately for me, the code ran fine. PHP sees err as an undefined constant which it assumes has a string value of 'err', so the if condition passes. For those used to strongly-typed languages such as C,Java or C#, this kind of error is unexpected, as in those languages the equivalent code will not even compile. Silent errors are particularly dangerous, since they are more likely to make it into production code with possibly calamitous consequences.

I guess the solution is not to make errors like that; but if you are like me, anything the tools can do to help catch errors is welcome. One possibility is to change the error_reporting value in php.ini. If you set it to a strict setting like this:

error_reporting  =  E_ALL | E_STRICT

then PHP will report likely problems in a manner that even a tired programmer will notice:

Check out the comments in php.ini for a description of the options. You would likely only use a strict setting like this in your development environment, not in production.

A snag with this approach is that many PHP libraries out there do not expect such a strict setting and will throw up all sorts of warnings. It wasn't a problem for me, as on this occasion all the code was mine.

As an aside, I've enjoyed working with PHP. I used to find that it almost encouraged spaghetti code, but the object-orientation introduced in PHP 5.0 has made it easier to structure applications in a way that I like. I've also started using the PHP Development Tools (PDT) in Eclipse. If you use this together with an instant PHP environment such as XAMPP, it is easy to set up a desktop for PHP development with luxuries like syntax highlighting, code-completion, and step-through debugging. Taking all these things together, I've found that most of my objections to using PHP no longer apply.

Ever since .NET burst onto the scene back in early 2002, Microsoft has promoted it as the primary platform for custom applications. For sure it has plenty of advantages, including automatic memory management, a modern programming language called C#, and a rich class library encompassing both Windows and Web development. The Windows Presentation Foundation, touted as the next generation of the Windows user interface, can only be programmed using .NET.

Unfortunately .NET also has downsides. The first is potentially troublesome deployment, thanks to the large runtime required. The problem has not gone away even though Windows now comes with .NET as standard, since new versions appear regularly. The second issue is performance. Although a just-in-time compiler enables .NET code to run at near-native speed, there is still a heavy memory overhead. The result is that .NET applications generally load and run more slowly than native code equivalents.

The trade-off here is that ease of programming compensates for slower performance. It's true; but not all developers realise that the choice is not only between C# and Visual Basic on the one hand, and the intricacies of Visual C++ on the other. Before turning up as Microsoft's chief architect for C#, Anders Hejlsberg worked at Borland on a language called Object Pascal and a development tool called Delphi. There is some family resemblance, particularly if you include Delphi's Visual Component Library (VCL), which wraps the Windows API with a class library that is equally as capable as the Microsoft Foundation Classes, but much easier to code against. Unlike Microsoft's .NET tools, Delphi compiles directly to native code, and it is feasible to create applications that have zero dependencies, run like lightning, and work on versions of Windows right back to 2000.

Delphi's recent history has been unsettled. Borland delivered some unsuccessful .NET editions and messed with the IDE. The Delphi side of the business was then spun off into a separate entity called CodeGear, which was recently acquired by Embarcadero, best known for database design tools such as ER Studio. Fortunately the compiler remained as good as ever, and the signs are that Delphi's new home will be good for the product. The company has just released Delphi 2009, the first version with proper support for Unicode. A companion product called C++ Builder has the same VCL, but uses C++ in place of Delphi's Pascal variant. These releases also introduce language enhancements including generics and anonymous methods.

Delphi is not the answer to every software problem, and its documentation is poor compared to what you may be used to with MSDN, but in the right context it works like magic. Aside from .NET, every corner of the Windows API is open to it, including services, native code DLLs, COM components, and fiddly software like custom actions for the Windows Installer. The Delphi IDE is once again mature. If you have ever looked with horror at the tens or hundreds of megabytes demanded by .NET for your small Windows Forms utility, or found yourself troubleshooting some obscure problem installing the .NET Framework, Delphi is well worth investigating.