I wrote: Is it realistic to use perl with DBI for a large project for a big company? Should we use java servlets CGI instead of perl CGI? We had a meeting today about this. Maby I was bad at presenting perl, but they choosed servlets. I lost. :-( http://www.javasoft.com/marketing/collateral/servlets.html I thank you all for the answers about using perl in big projects. I would like to continue the discussion. I don't know if this is the proper place for that. But I continue for now. The goal is to have a development tool there you realy fast can put together different components. The components shold work together without side effects. New programmers have to be able to quickly understand a single component to make modifications. 1. Java forces you to make structured programs. You don't have to invent a programming structure. The controls ar built in to the language. 2. Java has many development tools. Drag'n drop programming interfaces. Meta-tools for object-oriented programming, documentation, version control etc. The graphical interface makes it somwhat easier to use without having to learn the details about it. 3. I don't get it, but they din't seem to be impressed of CPAN, the perl community or the Perl Clinic. Like: "We can't depond on the free support fromhighschool students that wrote cool perl modules. We will get in the situation there we can't get help just becuse the programmer student has a paper to do." And the rule out the Perl Clinic because it doesn't sound serious enough. Six-packs and "money back" is not the type of support we seeks. We want dedicated professional programmers, tied with support contracts on a per year basis. The Perl clinic seems more like a hacker support for isolated fixes. We can't use modules at CPAN just like that. What kind of quality control has they gone through? Many of the DBD modules seems to be in alpha or beta stage. The price of the modules isn't an issue. The fact that the modules doesn't cost anything is not a plus, but their shifting quality is a minus. :-( 4. The future. Is it better to take every chanse to build competence in java? There seems to be more java programmers availibel than perl programmers. At least in my company. The answers on this list tells me that there has been big projects with perl dbi. But is this the normal case? Maby most projects has been developed in C++ or other languages? I would realy like a remedy for the points above. All you who has developed big programs: how do you structure the components to eliminate mistakes and enable fast development? / Jonas Liljegren --- > 1. Java forces you to make structured programs. You don't have to invent a > programming structure. The controls ar built in to the language. If by that you mean "object-oriented" then you are correct. Perl IS a structured language as well, but does not force all code into a single paradigm as does Java. > 2. Java has many development tools. Drag'n drop programming interfaces. So, if it's important that people be able to write code without understanding what they're doing ;^) Seriously, I wrote a Perl framework for developing new web services. A manager here, who did not know either Perl or HTML, was able to develop a new service (consisting of a back-end into the database and a dozen or so web forms) in a week. She's still raving about how easy it was (even though it wasn't drag-n-drop). > 3. I don't get it, but they din't seem to be impressed of CPAN, the perl > community or the Perl Clinic. Like: "We can't depond on the free support > fromhighschool students that wrote cool perl modules. If they cared to look, they'd find that many of those modules are written by people who are very highly respected members of industry in the field appropriate to the module. In fact, I know of no high school students who write Perl modules - they are all doing Java because "it's cool". > their shifting quality is a minus. Again, this runs contrary to the fact that the CPAN modules are generally above industry standards in quality. > 4. Is it better to take every chanse to build competence in java? It depends on your goals. java is a young, immature language. This is evidenced by the fact that there is no standard for either syntax or semantics yet. That's not to say it's bad, just new. I don't want to develop a big app in Java, because there's no guarantee that I won't have to continually rewrite it as the language evolves. Thanks to Microsoft, Java is less and less portable each day. I don't want to develop code that needs to be rewritten when we upgrade our hardware. Java has had fewer CPU years or existence, meaning there are likely to be bugs which have not yet been found. Perl's been around for CPU centuries. Perhaps I'm too conservative, but my goals in developing large apps are to get the app working and be robust and maintainable, not to use the latest buzzwords. > But is this the normal case? Maby most projects has been > developed in C++ or other languages? My project was developed in by 4 experienced devlopers in C++ first. Two years later the resulting 25,000 lines of code became too much to maintain. I single-handedly rewrote it in 1200 lines of Perl in 2 months. The resulting code is simple, portable, and more robust than the C++ code it replaced. > I would realy like a remedy for the points above. All you who has > developed big programs: how do you structure the components to eliminate > mistakes and enable fast development? Get someone who knows how, and give them free reign. I can explain what I do, but not how to do it. Software architecture is performed most effectively by a dictatorship, not a democracy. / Michael P Lindner mpl@wnmail.wndev.att.com --- These are all classic reasons against using 'free' software, and have been hashed and rehashed across the net, for almost any software package. You are dealing with typical management cluelessness, and there are not enough words in the dictionary to change those opinions. Logic will get you nowhere. My experience is that the only way to change managerial attitudes is to prove it - show something cool that works, that took you half the time, a tenth the cost, and is twice as good as their solution. Then, you might get buy in, if you're lucky. / Avi Baumstein avi@ufl.edu --- I honestly feel your company has missed the whole point of what the 'Internet' is/was/should be... Perl is as structured as you can stand it, but also makes allowancesfor less experienced programmers 'who are just learning the ropes.' All levels of programmers benefit from using Perl. With all seriousness, Perl has become the SysAdmins language of choicenot because of 'a money-back' slogan, but because it works - consistently... > We can't use modules at CPAN just like that. What kind of quality > control has they gone through? Many of the DBD modules seems to be in > alpha or beta stage. The code is in beta or alpha because Perl Module developers arean honest crowd. I myself am working on distributed Calendar interface for Solaris, so my staff can access their Calendars via a Web Browser, it stays in Alpha because it is always changing, improving. Perl people try hard not too push bugware, vaporware, victimware... The Internet community as a whole is self-policing, if one of the developers distributes something bad, it will only happen once before word gets out and they are banned, black listed, if not severely chastised... I myself am using Perl to categorize and document an entire FTP mirror - about 20GB - weekly; not a big project... Most of the projects I have seen which are big revolve around massive text processing - in which Perl kicks massive ass. (IMHO :-) I would hazard a guess that if a person is a logical, generally goodprogrammer in another langauge - they would be a logical, generally good programmer in Perl. Java, not Perl, can make you a good programmer if you are a bad programmer. Life doesn't work that way... But I would hazard a guess that Perl, at least, would be more forgiving and allow a generally bad programmer to produce reasonable solutions... (IMHO) / Bill Jones bill@astro.fccj.cc.fl.us --- I work with DBI and a number of Java database interfaces daily. Although Java is being pushed vary hard to get up to speed, at this point it is still far behind Perl and will be for some time. The biggest issue I have ever had with DBI is installing the drivers for some databases. -The Oracle and MiniSQL drivers install pretty cleanly now, but the Informix drivers are still a nightmare and the braindead config for it just trys to make it harder. However, once any of the drivers install I have absolutely no problem with them. > The goal is to have a development tool there you realy fast can put > together different components. The components shold work together > without side effects. New programmers have to be able to quickly > understand a single component to make modifications. Hmm, sounds like Perl to me. :-) > 1. Java forces you to make structured programs. You don't have to invent > a programming structure. The controls ar built in to the language. This I've always found only useful as a crutch for new and/or simply bad programmers. Funny thing is, no matter how "structured" one trys to force a language to be, they *always* manage to find ways to create write-only code. I've worked with Java apps in the 100k line range with absolutely no way to reuse any of it without cut and paste, and even then you would be better off rewriting it because it's so bad... Good programmers write good code. Bad programmers write bad code. There is *NO* way to make a bad programmer write good code. No language with *ever* change that. Python tried, and failed, and it's more "structured" then Java. > 2. Java has many development tools. Ditto for Perl (and pretty much any other programming language). > Drag'n drop programming interfaces. And this is a Good Thing...? For building GUIs it's not bad, but not for much else. -And I think perl has a Tk GUI builder somewere. > Meta-tools for object-oriented programming, Yhon... > documentation, pod > version control RCS > etc. The graphical interface makes it somwhat easier to use without > having to learn the details about it. See comments above about bad programmers only being able to write bad code no matter what pretty GUI interfaces you have them use. > 3. I don't get it, but they din't seem to be impressed of CPAN, the perl > community or the Perl Clinic. Like: "We can't depond on the free support > fromhighschool students that wrote cool perl modules. We will get in the > situation there we can't get help just becuse the programmer student has > a paper to do." This, is why everything is shipped in source form. Managers *love* support contracts, but I rarely find them anywere close to as useful as source. Managers like them because managers hate taking responsibility. They like to pass the buck: "Mr Smith, we have tracked the bug down to a problem Oracle's new JDBC driver. But it's ok, we have a trouble ticket into them and will let you know when it's fixed.". This meens the manager can truthfully sit back and say, "Sorry, until [insert your supplier here] fixes x, y, and x there is nothing my group can do. It's not our fault.". No one can get upset with them for not fixing the problem fast enough because it's not there problem per-sey. > And the rule out the Perl Clinic because it doesn't sound > serious enough. Six-packs and "money back" is not the type of support we > seeks. We want dedicated professional programmers, tied with support > contracts on a per year basis. The Perl clinic seems more like a hacker > support for isolated fixes. Hmm, can't comment here as I haven't used them. -When one of my fellow programmers finds a bug in perl or a module here, they normally come to me and I find/fix it, so at this point we don't need a Perl support contract. :-) I do understand that this is not always (or even oftin) the case for others. > We can't use modules at CPAN just like that. What kind of quality > control has they gone through? I love when this one comes up. No, they are right. Vary, vary few perl modules have ever gone though any "formal" QC. This is the case with most free software. I more oftin then not find however, that free software (with free source) is *much* more reliable then commercial software. Why? Because the people that are writing are doing so because they want to, not because they got stuck on the project. Because the source is available, so anyone that finds a bug can also find a fix and submit it back to the authors thus speeding up the process. The entire freeware cycle is a far better QC system then will ever be found in pure commercial software. > Many of the DBD modules seems to be in alpha or beta stage. In name only, not quality. As the readme for the DBI module states, it was only in beta because the interface was not set in stone. It is now, as 1.0 was just released, however it has been rock solid for a vary long time now. > 4. The future. Is it better to take every chanse to build competence > in java? They are both tools. They both do different jobs better or worse then the other. Java makes nice client GUI applications. Perl (and C) make *much* better server side servlets and servers. > There seems to be more java programmers availibel than perl > programmers. At least in my company. If this is the case for your company, then going Java might be a better answer for you. I highly doubt however, that you will find more good Java programmers then good Perl programmers. -You will however, find lots of bad Java programmers that are jumpping onboard the hype and not much else (old VB and C++/MFC people mostly (blgh)). > The answers on this list tells me that there has been big projects with > perl dbi. But is this the normal case? Yes, but again it depends on the application. I actually prefer Java for the client side (delivered via Merimba or similar "tuner" system). > Maby most projects has been developed in C++ or other languages? It depends. I would vary rarely, if ever recommend C++ to be used for server code, but like everything else it depends on exactly what you are trying to do. That said, Perl and C are what I recommend mostly. > I would realy like a remedy for the points above. All you who has > developed big programs: how do you structure the components to eliminate > mistakes and enable fast development? By componets (at least in Perl), do you meen modules? This can not be answered in a single message. This is an issue that will change from project to project depending on what the design team (or person) desides is the best way. There basic guidelines, but they are no different they one would find in any number of textbooks. /Zenin zenin@best.com --- Let state here that I'm an object-oriented programmer with C++/Java. I'm also a web developer in Java, VBScript and Perl. I'm pretty much a generalist, utility programmer. > The goal is to have a development tool there you realy fast can put > together different components. The components shold work together > without side effects. New programmers have to be able to quickly > understand a single component to make modifications. This can be accomplished with both Java and Perl. The OO nature of Java is rather stronger than Perl's, so developing components without side effects is somewhat easier in Java. Both are about as easy to understand. > 1. Java forces you to make structured programs. You don't have to invent > a programming structure. The controls ar built in to the language. This won't help bad programmers make good programs. Nothing will. > 2. Java has many development tools. Drag'n drop programming interfaces. > Meta-tools for object-oriented programming, documentation, version > control etc. The graphical interface makes it somwhat easier to use > without having to learn the details about it. GUI IDEs make it easier for someone who doesn't know what they are doing to write code that doesn't work. I can be as productive in Perl in 'vi' as with Java in a nice GUI envirnonment. It's just a little nicer. > 3. I don't get it, but they din't seem to be impressed of CPAN, the perl > community or the Perl Clinic. Like: "We can't depond on the free support > fromhighschool students that wrote cool perl modules. We will get in the > situation there we can't get help just becuse the programmer student has > a paper to do." High school students, seasoned professionals, devoted hobbyists. And if the author can't help, then there are thousands of others willing to step up and help. You won't find that in the commercial compiler companies. I've had huge problems getting M$, Sun, Oracle and other commercial companies to respond to problems, let alone do anything about them. Once they finally admit that something might be wrong with their product (only happened twice in 20 years of programming), the most common response has been "It will be fixed by the next release in a year". Wow, what response time! > And the rule out the Perl Clinic because it doesn't sound > serious enough. Six-packs and "money back" is not the type of support we > seeks. We want dedicated professional programmers, tied with support > contracts on a per year basis. The Perl clinic seems more like a hacker > support for isolated fixes. I've never used the Perl Clinic, but support contracts are a great way for software companies to make butt-loads of money without actually having to perform work. Many times I've seen little movement from companies, even though we had 'Platinum Super Deluxe' level support costing more than the original product cost. Many of the people who offer support for Perl *are* 'dedicated professional programmers'. > We can't use modules at CPAN just like that. What kind of quality > control has they gone through? Many of the DBD modules seems to be in > alpha or beta stage. The price of the modules isn't an issue. The > fact that the modules doesn't cost anything is not a plus, but their > shifting quality is a minus. :-( I've found Alpha versions in CPAN to be more bug free than most bug-fixed releases of commercial software. DBI specifically has given me absolutely no problems. OTOH, Microsoft Office 97 (after adding 2 service packs) has given me more problems than any other piece of software I've ever used. > 4. The future. Is it better to take every chanse to build competence > in java? There seems to be more java programmers availibel than perl > programmers. At least in my company. This is a legitimate problem. Ramp up time in learning a new language could suck a week or two from your schedule at the beginning. > The answers on this list tells me that there has been big projects with > perl dbi. But is this the normal case? Maby most projects has been > developed in C++ or other languages? It all depends on what you want. More client-server GUI programs have been written in C++ than either Java or Perl. More web server and administrative programs have been written in Perl than any other language. > I would realy like a remedy for the points above. All you who has > developed big programs: how do you structure the components to eliminate > mistakes and enable fast development? One consideration not mentioned in all this is that Java is still a developing language. Though it is more stable than a year ago, it still has elements that are in beta-test: Swing, etc. Perl is currently more stable in terms of the language than Java is. / Brett Slocum slocum@io.com