Fed up with Microsoft (.NET)

December 9, 2007 11:36 AM

Best programming language for internal automation?

I don't have any formal programming training but have written and read enough that my code is fairly 'tight' - all object-oriented, all of my projects utilize code-reuse from the classes I've created, etc.

I write programs to automate tasks I perform as a DB admin. I have one intra-office app with an interface but all the others are just desktop apps (most without forms) for automation - a lot of data-access, file preparation & archival, data-logging, etc. We are on a Microsoft platform so most of my code is in VB6, some in VB.NET, some in VBScript, and some in SQL. I have flirted with JavaScript and C# and don't think I'd have much trouble switching.

Over the years I've grown increasingly frustrated at Microsoft's direction with regards to the security implementation in Vista, the ever-changing/expanding nature of .NET, etc. After a year of wanting to wipe Vista I finally did, putting 64-bit XP on my machine...what a relief! I've also seen the advantages of open source - its flexibility, availability, cross-platform nature, and constant innovation by other programmers and users.

Anyway, after re-installing everything, some of my compiled VB.NET programs no longer work! The particular project sparking this question was compiled and stable for over a year on 32-bit XP and Vista; it is suddenly broken (even after I checked to ensure it was compiled to run on x86 - a gotcha I'd already run into on 64-bit). I have had this happen before when the latest & greatest '.NET framework' or VisualStudio version was released, and frankly I'm sick of it.

After struggling for hours to track down the reason for my program suddenly being broken I just said "screw it" and started re-writing it in VBScript...though there are lots of disadvantages to a scripting language (especially error-handling and forms), the BIG advantage is that every VBScript program I've written during the past 7 years still works perfectly on the 8 or 10 flavors of Windows on my network. I never have to install special frameworks or DLLs (depending upon what object model I'm referencing) or anything else - it just works.

So my question is this: what would you recommend for non-web intranet programming of the sort I'm doing? Something that will work well on all flavors of Windows from 2000 Server to Vista 64, allow disk and network drive access (with the Windows Server security model), easy data access for SQL Server and Microsoft Access, etc.? A good IDE would be nice too, particularly when I'm learning the language - please throw in any IDE recommendations you have as well (Sharp?).

I'm guessing Java would be the way to go but I'm just wondering if there are other recommendations. Thanks!

posted by jjsonp to computers & internet (21 comments total)

I use vbscript (*). I know it's windows technology, but it's got good integration into the windows operating system, there's tonnes of examples of usage on the web and its not compiled.

An example of a utility I use creates a new IIS virtual folder, updates the registry, changes the permissions on some files and adds some new user accounts.

I've also had some luck with Python, but the integration isn't there to the same degree.

(*) I say I use VBScript, but I may be using the windows scripting host with vbscript. Needless to say, I have text files with the extension .vbs which when double clicked or called from a command prompt do the things I need.
posted by seanyboy at 11:49 AM on December 9, 2007

I'd say .NET is designed to be a lot more portable than VBScript; you may be confusing the extensive legacy binary compatibility features of later Windows versions with the code being portable.

Moving everything from VBScript/VB6/whatever to .NET languages (VB.NET, C#, others) would be a lot easier and sensible than rewriting everything in Java (and repeating all of your mistakes). .NET has basically the same model of VM, code portability, and so on as Java, so use what legacy you have. Plus once you standardize on .NET you don't have to worry about what flavor of Windows is being dealt with.
posted by mezamashii at 12:00 PM on December 9, 2007

I mostly live between the mac and linux world, but for doing automated work in the PC world I found that the easiest thing to do was install activestate perl and then just write perl scripts. Usually it was work along the lines of searching for and within files and copying them or portions of them, a task which perl is well suited for. I think Activestate does tcl/tk as well if you want to make pretty GUIs for your tools, but I haven't tried their implementation so I can't speak to that. I have no idea how it would work with actual windows services as they lie outside the realm of things I care about.
posted by frieze at 12:00 PM on December 9, 2007

I'm not sure why you want to move away from VBScript. It's not the best language around but it does everything that you're looking for and you already know it.
posted by purephase at 12:03 PM on December 9, 2007

Maybe I'm missing something, but I'm not seeing why vbscript isn't doing the job for you. As seanyboy says, when doing automation stuff in Windows vbscript is hard to beat in terms of the tight integration via WMI. You mention that one of its deficiencies is an inability to create UI's for it. Have you looked into HTML Applications? This is what I use when I need to write a quick automation task in Windows that requires a cleaner method for user input than command line parameters or repeated InputBox()'s. It does require basic HTML knowledge but that's fairly easy to pick up. It just seems kind of silly to make basic task automation any harder than it needs to be.
posted by saraswati at 12:03 PM on December 9, 2007

No offense, but most of the time when I've heard of someone with "no formal programming training" who writes "great code" that no one else has ever touched, the code in question is a horribly complicated rats nest.

If you are having difficulty figuring out why your code is breaking, it probably has less to do with the programming language and more to do with the code base spiraling out of control. As you said, vbscript has less error handling, so it may just be that your vbscript apps are failing in subtle ways that you can't detect.

The .NET Framework is actually fairly stable compared to a lot of other libraries, so if you are having a hard time maintaining your code because of the small changes to the libraries over the years, that would be a big red warning flag for me.

I may be biased because I do most of my work in .NET, but I would suggest using .NET to do any serious Windows programming work. The framework is linked up to the inner workings of Windows much more than Java or any other alternative, and the exception handling and general OO facilities built into the language are fairly advanced.
posted by burnmp3s at 12:51 PM on December 9, 2007 [1 favorite]

It's not really clear to me what you're trying to do, but Nant is the open-source tool of record for automating build processes and things like that on Windows. It handles a bunch of tasks natively, plus people have written extensions for others and you can always call out to external scripts.
posted by yerfatma at 12:57 PM on December 9, 2007

all object-oriented, all of my projects utilize code-reuse from the classes I've created, etc.

I'd suggest backing off from that direction, and it's not just me.
posted by StickyCarpet at 1:16 PM on December 9, 2007

Thanks for the responses.

The reason I'm looking for alternatives is because I've greatly enjoyed the open source programs I've used as compared to Microsoft products (Firefox, FileZilla, OpenOffice, etc.). I find that these programs tend to be more easily obtained - being free and all - more user-friendly, more adaptive, etc. So I'm hopeful that open source programming languages may share some of the same benefits.

With regards to the 'simplicity' of my automation tasks...it could be these are simple but it just depends on where you're coming from. For instance the .NET program I'm having problems with is called from another VB6 program...it in turn calls an exe which converts two text files to Access tables, then runs some SQL to join them up, then uses the Access object model to export the result as text, then compresses the output and places it on a network drive, then returns control to the calling VB6 program. So that's the sort of functionality I need. I'm not sure how well Perl handles disk access, external program calls, etc. - I imagine it's fine.

I'm not opposed to using VBScript or even .NET (since I already use both); I just want to know what open source alternatives are available and what people who use them recommend.

As far as a philosophical/computer-science level debate regarding object-orientation and code re-use goes, I'm not really interested in that in this question; it is far outside the scope of what I"m trying to address. This methodology has served me well over the years and while I will read the link StickyCarpet submitted I'm *not* looking for a new paradigm at this point, just better and more consistent tools than the constant framework alterations forced by .NET.
posted by jjsonp at 1:35 PM on December 9, 2007

jjsonp, no offense, but if you're "not interested in that in this question" (discussion of your lack of formal programming instruction, use of OOP and code-reuse, etc.), why did you mention them in your incredibly verbose question lead-in? I'd argue that you ostensibly thought they were relevant to your question... and others seem to agree, remarking that they might be part of the problem.
posted by delfuego at 1:49 PM on December 9, 2007

Delfuego, I'm not interested because of the reasons I stated: OOP has worked fine for me. I'm looking for tools to address my problems at an actual job, not endless debates about which paradigm is most appropriate (I'm reading the comments on the link and it actually has nothing to do with OOP, has hundreds of comments, etc.).

If you're not going to answer my question with something substantive but rather just complain that it was 'incredibly verbose', why are you wasting my time commenting? Leading in with "no offense" does not excuse your then saying something offensive and not answering the question in any way.
posted by jjsonp at 2:04 PM on December 9, 2007

If I were you I'd look into Windows Powershell
posted by jouke at 2:20 PM on December 9, 2007

I agree that it would be useless to debate the pros/cons of OOP here because that debate has been going on for the past 20 years or so and there's no reason to hash it out here again.

For instance the .NET program I'm having problems with is called from another VB6 program...it in turn calls an exe which converts two text files to Access tables, then runs some SQL to join them up, then uses the Access object model to export the result as text, then compresses the output and places it on a network drive, then returns control to the calling VB6 program.

That's what I mean about the code probably being a rats nest. Did you originally plan to have this many layers of redirection in this process, or did it evolve into that over time? Most of the time a program starts out as simple and gets more and more complex over time. At some point it becomes unmaintainable.

What specific problems are you having with .NET in terms of changes? Open source programming languages are much more loosely controlled, and therefore have many more issues with breaking changes. For example, PHP constantly introduces changes that break compatibility with older versions of the language.

It seems like consolidating most of your existing code to .NET would work, because it should be fairly easy to port your existing code to the framework based on the sorts of things you are doing.
posted by burnmp3s at 2:43 PM on December 9, 2007

You're not going to get any better than .NET in terms of ease-of-use or appropriateness-as-a-tool for programming Windows stuff. Switching to C# may help you feel better about it though, especially if you like the idea of Java, because C# is basically Java with the benefit of a few years' hindsight.

All the high-level interfaces to MS-proprietary crap live in .NET now, and you're going to be swimming upstream if you try to use other tools. Not that it can't be done, but it can't be done in a way that's going to save you any time or headaches.
posted by moift at 3:22 PM on December 9, 2007

For doing automation in Windows, the programming language you pick is actually secondary, since most of what you're doing is just method calls on assorted Windows objects anyway. Any programming language that lets you get at the underlying objects will do the job, and the reason it all feels horrible is not because there's anything wrong with the language you're using, it's that Windows just is horrible.

Regardless of which toolset you use, working on open-source stuff is always going to feel better than working on Windows stuff, because you always know that when things break, you will be able to track down the reasons why, if they're sufficiently important to you. With proprietary code like Windows, there's always going to be a wall of nondisclosure in your way at some point.

That said: VBScript and .NET are very Windows-centric; JavaScript not so much. It will do you no harm to switch from VBScript to JScript for your general Windows object glue requirements.
posted by flabdablet at 4:50 PM on December 9, 2007

As a single dev wanting to write code fast in the minimum number of linesof written code, has a huge library of externally provided modules (via CPAN, excellent capability to push stuff out to the web (I recommend Catalyst) or as standalone scripts, I really suggest that you have a good close look at perl.

The book learning perl will be to basic for you, Intermediate Perl may be useful, half of Perl Best Practices is great (which half is left up to you as the reader to decide ;)) and the community just rocks.

Having said that, if you're doing perl dev on Windows use Strawberry Perl. Don't worry too much about the "alpha" label. The distribution is alpha, the tools contained within the distribution are production grade.

Oh yeah, IO, talking to external programs is what perl was built for. There is a reason that it's been described as "the duct tape of the internet".
posted by singingfish at 6:06 PM on December 9, 2007

It will do you no harm to switch from VBScript to JScript for your general Windows object glue requirements.

Unless you ever get stuck and want to Google for help. The nice thing about the mainstream .NET languages on Windows is how easy it is to find help and how often something you need is actually in one of the enormous libraries. If I could, I'd do all my Windows scripting in Python, but I'd be on my own or relying on some very slim resources in certain esoteric areas.
posted by yerfatma at 6:43 AM on December 10, 2007

Powershell would be nice as well, but it's not available for Win2K or anything older.
posted by yerfatma at 6:44 AM on December 10, 2007

I'd try Java if I were you. It's pretty similar to .net but you don't need to download the "latest and greatest." It's open source, under the GPL and you'll always be able to get old versions of the JDK. And unless you do something really weird involving external libraries, you programs will be able to run on most any computer you'd like. Linux, Windows, Mac, etc.
posted by delmoi at 12:17 PM on December 10, 2007

Thanks everyone. I figured out the VB.NET thing (sort of): deleted the project, created a new one, cut-and-pasted the text of the module (from a backup) into a new one, re-built...it worked fine. Some sort of directory or GUID stored by .NET I believe. Though the directory structure where I store my projects is identical.

I will look into Java, Catalyst, and the Windows Powershell - thanks again.
posted by jjsonp at 2:44 PM on December 10, 2007

yerfatma, any Googleable solution to a Windows automation problem that presents a solution in VBScript is going to be trivially modifiable for JScript, since both languages use the same mechanisms to access the same underlying Windows objects. The only reason I recommended moving from VBScript to JScript is to avoid mental "stuckness" in a proprietary BASIC-like language when a functionally equivalent industry standard (JavaScript) is available to do the same job, even to the extent of being supported by the proprietary vendor.

Really, though, my main point is that getting automation jobs done with Windows is all about understanding how to use the objects and API's that Windows exposes, and that the glue you use to hold it all together doesn't actually matter much.
posted by flabdablet at 3:58 PM on December 10, 2007