On Sun, 16 May 2004, Michal Altair Valasek wrote: > |And finally, for the $64000 question: Can you explain me WTF > |difference > |does it make for a report tool, that reads text files and spits HTML > |(and that it is absolutely not performance critical), the > |language that it is written in? > > It's not important what language uses the given application. Runtime is what > is important. > > For typical Windows system administrator, running Perl or Java application > is pain in the ass. The runtimes are complicated to install and setup and > tends to break any given security architecture existing. > > In the above situation, installing such runtime is a truly religious > experience: you can't understand it, you must blindly faith in it. > > When installing any standard Windows application, I am able to interact with > it. If there are any problems, I can try to solve them. In case of > miscellaneous runtimes such as Java, Perl, Cygwin and so on, all you know > about your system architecture (and as I am Microsoft MVP, it's not too > little in my case) is worthless. You can install it and then it either runs > (and you can simply pray for it to be reliable) or it does not run. In the > second case you generally can't do anything, because it does not interact > the proper way regarding to your operating system. > > Situation of .NET framework is different. It's runtime, which is written in > style of being cooperative with Windows OS. It's supported. It's documented > the obvious way. It's incorporated in operating system (in case of Windows > 2003 and above) and so on. > > Not everybody is prepared to give their vital system as hostage of some > totally strange runtime he knows nothing about. > > I have nothing against Perl or any other programming language. There are > systems, where they are at home. Use them there. All attepmts to do > something else are mostly *failing* in production environment.
Honestly, you said such a huge amount of non-senses that I was almost tempted to delete the message. Then I relalized that you must be in drugs to even dream to spit those statements. I will talk about Perl here, since it is the one that (luckily) 98% of XMail scripts use. 1) Difficult to install?? You get an installer EXE, you follow three steps and it's done. Clean install, no huge messes with system DLLs replacements. Simply an EXE plus support libraries in the specified directory. Never had *one* problem with the Perl interpreter on Windows. On Unix, it's just there. 2) Able to interact with it?? You have the freakin' source code of the runtime and all associated libraries. And this is actually never needed due to the stability of the runtime. The source code style also is pretty good, with a thin abstraction layer, plus platform independent C code. 3) It is supported??? Here signs of drugs clearly weighs in. If you ever find a bug in the interpreter (or one of the libraries), you post a message to the community, and when you wake up you're likely to have the solution in your mailbox. Try that with MS. Also, a code library like CPAN is something that others can only dream. 4) Are mostly *failing* in production environment??? You'd be suprised to know that a huge part of the internet Web pages is driven by Perl and PHP CGIs. I'm not really good in example *failures*, but I can list one because I spend quite some money in it: http://www.amazon.com For the ones that don't know, Amazon.com uses Mason: http://www.masonhq.com If you were talking about Windows, I still do not know what you are talking about. We use Perl for automation everywhere and we didn't have a single problem with it (on both Windows and Unix). It is so stable to actually become a little bit boring. For this specific example, we are talking about something that reads text files and spits HTML, and it is not even close to be performance critical. So let's see. Last time I checked Perl was pretty damn good to parse text files, and also its support for HTML formatting was not only comprehensive but also thoroughly tested by huge amount of Perl CGI scripts all around the world. Also, we are not talking about parsing MS Exchange log files but we are talking about XMail log files, that has a blended community of Unix and Windows users. Tell me again why such tool should be written in C#? To run in 0.34 seconds while the Perl version would take 3.8 seconds? I honestly don't give a damn about the language those things are written in. I do hate though, that platform dependency being brought up when it is not even close to be needed. Expecially when we are talking about something that interfaces with an application that has a very uniform adoption amont Unix and Windows users. Note that, I here say platform dependency about C#, because until I see a Unix community behind C# like the one I see behind Perl, I do not even consider things like Mono or DotGnu. - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
