From joelmeulenberg at yahoo.com Tue Sep 18 22:04:25 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: FW: Newsletter #9 from O'Reilly UG Program In-Reply-To: Message-ID: <20010919030425.95754.qmail@web13007.mail.yahoo.com> > Java and XSLT > http://oreilly.com/catalog/javaxslt/ > Sample Chapter 5: XSLT Processing with Java > http://oreilly.com/catalog/javaxslt/chapter/ch05.html This one is somewhat interesting to me. (Though I am nervous about some of what I see going on in the XML world. It seems like we've now got many SGML/HTML-oriented people without a strong background in data management who are equipped with their new XML "hammer" and they're trying to apply it to stuff that ain't exactly a nail.) I'm curious, is anyone in the group doing much with Java, J2EE, XSLT, etc.? +Joel __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From matthew_heusser at mcgraw-hill.com Wed Sep 19 08:24:58 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: FW: Newsletter #9 from O'Reilly UG Program Message-ID: <85256ACC.004A66E8.00@corpny55wls01.mcgraw-hill.com> We use XSL to transform XML into HTML. (We use it as a transformation language.) In other words, we use it XSL like a transformer to turn an entry into a XML database into a web page with the correct formatting, links, etc. I hope that makes sense. Matt H. From joelmeulenberg at yahoo.com Wed Sep 19 23:41:00 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: FW: Newsletter #9 from O'Reilly UG Program In-Reply-To: <85256ACC.004A66E8.00@corpny55wls01.mcgraw-hill.com> Message-ID: <20010920044100.86210.qmail@web13004.mail.yahoo.com> > We use XSL to transform XML into HTML. (We use it > as a transformation language.) In other words, > we use it XSL like a transformer to turn an entry into > a XML database into a web page with the correct > formatting, links, etc. > > I hope that makes sense. I think so, but I'm curious about more details. What do you mean by an "XML database"? Is that a relational database in which some of the values happen to be snippets of XML? Do you use XSLT to transform the XML into anything besides HTML? Is your XML more of a document or is it more like a data file? If it's more like a data file, then I'm curious about your opinions/experiences with storing the data in independent hierarchical data structures (i.e.- the XML documents) in contrast to storing data in relations (tables) in a DBMS? (Not that any of today's SQL DBMSs actually implement the relational model of data, but they're the closest thing to it.) TIA. +Joel ===== "Men never do evil so completely and cheerfully as when they do it from religious conviction." - Blaise Pascal __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From matthew_heusser at mcgraw-hill.com Thu Sep 20 07:18:40 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff Message-ID: <85256ACD.004362A4.00@corpnj148ls02.mcgraw-hill.com> ... uhh .. sorta. Let me try to explain ... SQL Databases are slow, expensive, and take clock cycles. If you've got to store a lot of data on a local PC, you don't want to be shipping a copy of SQL Server with every app. That said ... >What do you mean by an "XML database"? Here's the deal. Use a nifty, propietary way to store data in a compact format. Create a process to turn a single item (product, set of products, whatever) into into XML using MS Tools. This is done on-demand, so we don't need to store the data in XML format. Use XSL to transform that XML into HTML. This allows us to separate the data storage layer (proprietary) from the business logic (make XML) from the presentation layer ("Stock" HTML pages that are filled dynamically). If you think about it, you can create several different XSL "templates", and apply a different Template to get a different view of the data. This is just like "skins" in windows media player, only different. >If it's more like a data file, then I'm curious about your >opinions/experiences with storing the data in independent hierarchical >data structures (i.e.- the XML documents) Too much disk space. >in contrast to storing data in relations (tables) in a DBMS? Too much disk space. And too expensive. (Or hard to maintain, if you're an open-sourcer) And takes too many clock cycles. If I _had_ to have the functionality of a database with >10,000,000 records and I _needed_ to beat the performance of MS Access, I'd probably look for a Indexed Squential Access Method (ISAM) database product, like the old informix. Failing that, I'd try to find a way to get some of the functionality of a database without the cost/performance penalty. (Especially if you find yourself in a sitatuation where you only need to get data out of the database, not add to it.) Just my $0.02. Is anyone using XML in Perl? Perl.Net? Visual Perl? Komodo? Ruby? Anything cool in West Michigan? (No, use cgi; does not count.) Matt H. From sml at zfx.com Thu Sep 20 08:35:46 2001 From: sml at zfx.com (Steve Lane) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff References: <85256ACD.004362A4.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <3BA9F0B2.8389472A@zfx.com> matthew_heusser@mcgraw-hill.com wrote: > >in contrast to storing data in relations (tables) in a DBMS? > > Too much disk space. > And too expensive. (Or hard to maintain, if you're an open-sourcer) > And takes too many clock cycles. > > If I _had_ to have the functionality of a database with >10,000,000 records > and I _needed_ to beat the performance of MS Access, I'd probably look > for a Indexed Squential Access Method (ISAM) database product, like the > old informix. i use MySQL for this purpose. i'm not aware of any diskspace / too expensive / hard to maintain issues with it. -- Steve Lane From matthew_heusser at mcgraw-hill.com Thu Sep 20 08:46:47 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff Message-ID: <85256ACD.004B7571.00@corpnj148ls02.mcgraw-hill.com> >i use MySQL for this purpose. i'm not aware of any >diskspace / too expensive / hard to maintain issues >with it. How do you use your Database? How many gigs of data do you ship per month? (Or are you centralized on a web-server?) What OS's do you support? Where does the DB reside? Are you distributed, loosely coupled, tightly coupled, etc? curious, Matt H. From sml at zfx.com Thu Sep 20 09:28:46 2001 From: sml at zfx.com (Steve Lane) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff References: <85256ACD.004B7571.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <3BA9FD1E.A9741069@zfx.com> matthew_heusser@mcgraw-hill.com wrote: > > >i use MySQL for this purpose. i'm not aware of any > >diskspace / too expensive / hard to maintain issues > >with it. > > How do you use your Database? > How many gigs of data do you ship per month? > (Or are you centralized on a web-server?) > > What OS's do you support? Where does the DB > reside? Are you distributed, loosely coupled, > tightly coupled, etc? our databases contain data for websites. i don't understand your questions; maybe we're talking two totally different database usages. re-state your questions and i'll try to answer them. -- Steve Lane From matthew_heusser at mcgraw-hill.com Thu Sep 20 09:48:43 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Databases Message-ID: <85256ACD.00512097.00@corpnj148ls02.mcgraw-hill.com> >our databases contain data for websites That's what I was trying to get at. If you use the web to transmit data, hurrah for you. You can use any of a wide selection of databases to store information. But, what if you have to transmit > 500MB per user, and the data changes monthly? What if more than 50% of your customer base has a 56K modem or slower? 25% of your customers don't even have a web connection? Well ... then a desktop application might make more sense than a web-based app. So, if you're shipping a desktop application, then you probably want a database to store the data ... and you begin to run into issues of size/price/speed. And my previous emails, hopefully, begin to make sense. Make more sense? See why 1 database per customer is a bigger deal than 1 database at all? Matt H. From sml at zfx.com Thu Sep 20 10:54:41 2001 From: sml at zfx.com (Steve Lane) Date: Wed Aug 4 00:01:16 2004 Subject: Databases References: <85256ACD.00512097.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <3BAA1141.5B6B3D0F@zfx.com> matthew_heusser@mcgraw-hill.com wrote: > > >our databases contain data for websites > > That's what I was trying to get at. If you use the > web to transmit data, hurrah for you. You can use > any of a wide selection of databases to store > information. > > But, what if you have to transmit > 500MB per user, > and the data changes monthly? What if more than 50% > of your customer base has a 56K modem or slower? > 25% of your customers don't even have a web connection? > > Well ... then a desktop application might make more > sense than a web-based app. well certainly if your customers can't access the web (which sounds bizarre to me, but whatever), you are forced to make a non-web app. i don't understand why "data changes monthly" would favor a database-per-customer application. and "transmit > 500MB per user" could mean anything at all, depending on if that's >500 Mb required to be transferred in 1 minute, 1 hour, 1 day, etc. > So, if you're shipping a desktop application, then > you probably want a database to store the data ... > and you begin to run into issues of size/price/speed. > > And my previous emails, hopefully, begin to make > sense. i guess. it sure took enough of them to get to your main point, which i guess is that each customer has to have their own database copy running on their machine. for that case, why not try one of the DBI modules that don't require a server? yes, this requires a Perl install on the user's machine, which i'll bet is a solved problem. > Make more sense? See why 1 database per customer > is a bigger deal than 1 database at all? absolutely not. it's a different deal, not a "bigger" deal. -- Steve Lane From beaker457 at hotmail.com Thu Sep 20 15:27:05 2001 From: beaker457 at hotmail.com (Ben Carlson) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff Message-ID: http://www.devshed.com/Client_Side/XML/XSLBasics2/ Devshed has some pretty good tutorials on web junk. Ben Carlson >From: matthew_heusser@mcgraw-hill.com >To: grand-rapids-pm-list@happyfunball.pm.org >Subject: XSL & Stuff >Date: Thu, 20 Sep 2001 08:18:40 -0400 > > > > >... uhh .. sorta. Let me try to explain ... > >SQL Databases are slow, expensive, and take >clock cycles. If you've got to store a lot of >data on a local PC, you don't want to be shipping >a copy of SQL Server with every app. That >said ... > > >What do you mean by an "XML database"? > >Here's the deal. Use a nifty, propietary way to store >data in a compact format. Create a process to turn a >single item (product, set of products, whatever) into into >XML using MS Tools. This is done on-demand, so >we don't need to store the data in XML format. > >Use XSL to transform that XML into HTML. > >This allows us to separate the data storage layer (proprietary) >from the business logic (make XML) from the presentation >layer ("Stock" HTML pages that are filled dynamically). > >If you think about it, you can create several different XSL "templates", >and apply a different Template to get a different view of the data. > >This is just like "skins" in windows media player, only different. > > >If it's more like a data file, then I'm curious about your > >opinions/experiences with storing the data in independent hierarchical > >data structures (i.e.- the XML documents) > >Too much disk space. > > >in contrast to storing data in relations (tables) in a DBMS? > >Too much disk space. >And too expensive. (Or hard to maintain, if you're an open-sourcer) >And takes too many clock cycles. > >If I _had_ to have the functionality of a database with >10,000,000 records >and I _needed_ to beat the performance of MS Access, I'd probably look >for a Indexed Squential Access Method (ISAM) database product, like the >old informix. Failing that, I'd try to find a way to get some of the >functionality >of a database without the cost/performance penalty. (Especially if you >find yourself in a sitatuation where you only need to get data out of the >database, >not add to it.) > >Just my $0.02. > >Is anyone using XML in Perl? Perl.Net? Visual Perl? Komodo? Ruby? >Anything cool in West Michigan? (No, use cgi; does not count.) > > >Matt H. > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From albert.tobey at priority-health.com Thu Sep 20 16:12:48 2001 From: albert.tobey at priority-health.com (Albert P Tobey) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff In-Reply-To: <85256ACD.004362A4.00@corpnj148ls02.mcgraw-hill.com> References: <85256ACD.004362A4.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <1001020372.3562.39.camel@linuxws1> > Is anyone using XML in Perl? Perl.Net? Visual Perl? Komodo? Ruby? > Anything cool in West Michigan? (No, use cgi; does not count.) > I'm using XML in perl using the XML::Parser::PerlSAX module for parsing some configuration files and sending some data across the network. It'd be really nice if perl could validate the XML first, but I'll just have to make do with eval { $parser->parse() };. Nothing I'm doing is over a couple kilobytes/object, so I'm not playing in the RDBMS world (Joel will sleep better). I don't see XML as being useful for data _storage_, but it's great for middleware and the like. I can publish data in XML and any hoser with some kind of XML library (perl,python,C,Java,?) can come along and interpret it however he pleases. The downside is that XML will always consume more resources (disk,cpu,bandwidth,etc) due to it's verbose nature. > >What do you mean by an "XML database"? > > Here's the deal. Use a nifty, propietary way to store > data in a compact format. Create a process to turn a > single item (product, set of products, whatever) into into > XML using MS Tools. This is done on-demand, so > we don't need to store the data in XML format. > > Use XSL to transform that XML into HTML. > > This allows us to separate the data storage layer (proprietary) > from the business logic (make XML) from the presentation > layer ("Stock" HTML pages that are filled dynamically). > There is no such thing as a 'nifty' proprietary data storage layer. The only thing nifty about it is that the developer (you?) can buy himself some more job security. Why not just use compressed XML and feed it through a SAX (PerlSAX) parser so that you don't waste a lot of disk space? While it's not a great way to store data, it does remove another layer of complexity in your application, and when you get hit by a Greyhound bus, the poor guy who has to maintain your app can read it because it's standards-based stuff. Plus, you can use common tools like 'patch' on the xml to save on the bandwidth for updates (yes, you can obtain these tools for Win32 native). > Too much disk space. > And too expensive. (Or hard to maintain, if you're an open-sourcer) > And takes too many clock cycles. > > If I _had_ to have the functionality of a database with >10,000,000 records > and I _needed_ to beat the performance of MS Access, I'd probably look > for a Indexed Squential Access Method (ISAM) database product, like the > old informix. Lies, Lies (another lie), Lies. Depending on what you want, you can get BerkelyDB, Mysql, PostgreSQL, and any number of other database type applications for free or very low cost. Most of them (esp. BerkelyDB and MySQL) are very easy to administer/maintain and embed well into applications. If you're working in perl, BerkelyDB is very nice to use and is extremely fast even up to 2gb of data if you use it correctly. Mysql has very little disk/memory overhead, is fast even on 200mhz pentium boxes, can be accessed from just about any language (C, perl, Java (JDBC), VB (ODBC), and can run on many platforms, including win32. Once you set it up, you forget about it, so it'd work well embedded in an application. I have a fairly heavily used MySQL instance on a linux machine here that hardly ever registers on my load monitor, and I haven't had to even think about it in months. Make sure you know the facts before you make assertions in the future. Oh yeah - MySQL can do ISAM IIRC. -Al Tobey Priority Health -- "Open source" means that anyone can get a copy of the source code. Developers can find security weaknesses very easily with Linux. The same is not true with Microsoft Windows. Microsoft, "What Every Retailer Should Know", February 2001 ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. ******************************************************************** From joelmeulenberg at yahoo.com Fri Sep 21 00:58:44 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: XSL & Stuff In-Reply-To: <85256ACD.004362A4.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <20010921055844.13967.qmail@web13004.mail.yahoo.com> Wow! I didn't expect such a flurry of comments to come out of the questions I asked. I was actually more interested in your opinions/experience with using "trees" (strictly hierarchical structure which allows only 1-to-many relationships between entities) as the fundamental model for your data as opposed to using relations as the fundamental model for your data. I'll ask a couple more questions about that below... > >What do you mean by an "XML database"? > > Here's the deal. Use a nifty, propietary way to store > data in a compact format. Create a process to turn a > single item (product, set of products, whatever) into into > XML using MS Tools. This is done on-demand, so > we don't need to store the data in XML format. > > Use XSL to transform that XML into HTML. > > This allows us to separate the data storage layer (proprietary) > from the business logic (make XML) from the presentation > layer ("Stock" HTML pages that are filled dynamically). > > If you think about it, you can create several different XSL > "templates", > and apply a different Template to get a different view of the data. I dig. Using XSLT to "repurpose" the data, etc. (Two transformations seems a little heavy, but I'm sure it's not that big of a deal.) I'm wondering how the "make XML" step embodies "business logic"? I'm also wondering how one would query the proprietary data store? > >If it's more like a data file, then I'm curious about your > >opinions/experiences with storing the data in independent > hierarchical > >data structures (i.e.- the XML documents) > > Too much disk space. > > >in contrast to storing data in relations (tables) in a DBMS? > > Too much disk space. > And too expensive. (Or hard to maintain, if you're an open-sourcer) > And takes too many clock cycles. I'm not so interested in physical storage aspects, etc. I'm more interested in how you like working with a hierarchical model of data as opposed to a relational model of data. *Both* hierarchical databases and a relational databases (in the abstract sense - I'm not referring to any particular SQL product (none of which are quite relational anyway)) *can* be stored compactly and can perform well given the right implementation. (Indeed some of the followup comments of others suggest that has been their experience.) It's your feelings/experiences with the fundamental abstractions (i.e.- tree versus relation) that I'm wondering about. The shortcomings of always trying to shoehorn data into a strictly hierarchical structure were recognized decades ago and that's why the idea of hierarchical databases was essentially abandoned in the 1980's. (e.g.- The hacks that people had to use to handle a many-to-many relationship in a model of data that only allowed one-to-many relationships were horrible.) Have you felt any "impedance mismatch" between your data and the strictly hierarchical structure imposed by XML? I could ramble some more, but I've been told my emails get too long and then no one wants to read them, so I'll stop here. : ) Thanks for the clarification so far. +Joel __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From matthew_heusser at mcgraw-hill.com Fri Sep 21 09:34:23 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Matt Heusser's Lies, lies, lies Message-ID: <85256ACE.00524ADB.00@corpny55wls01.mcgraw-hill.com> Warning: Open-Source Religious Argument. >Make sure you know the facts > before you make assertions in the future. I'm sorry - Mr. Tobey, you obviously know more about my business than I do. But seriously ... >There is no such thing as a 'nifty' >proprietary data storage layer. Companies base thier entire business model on Propietary Data Storage Layers. Think 'Quicken', Think 'MS Word', Think 'AutoCad DWG.' Think 'PowerPoint.' Think 'data file' instead of 'data base' and it begins to make sense. Sure, you can make money with open source, but it doesn't fit well into a content/subscription model. My customers actually pay money for our software and content on a subscription basis. That's very different thant the IT services world. In your solution, I would give away the keys to the kingdom! >The only thing nifty about it is that the developer >(you?) can buy himself some more job security. Fine, Let's avoid the flames and stick to facts. Seriously, we have 10 developers here. We hired a contractor to do a great deal of the programming on our Data Storage Tier. He's gone, and if I quit, someone else would be up and running shortly. If we lost all 10 developers, that would be bad - but we have a half-dozen information developers who know how to build catalogs in our proprietary format. I think this is coming down to the differences between shrink-wrapped software and the uses of Perl. And this is a perl list. Perhaps I've been remiss. Joel asked me how we use XML, and I started talking about how we use XML. Perhaps I assumed a knowledge base that does not exist about win32 shrink-wrapped software development. If so, I apologize. >Lies, Lies (another lie), Lies. Depending on what you >want, you can get BerkelyDB, Mysql, PostgreSQL, and >any number of other database type applications for free >or very low cost. Most of them (esp. BerkelyDB and MySQL) I want to re-distribute the database and run it on the user's desktop. BerklelyDB is attractive for that, but if I want to redistribute it, I have to ship the source code and pay a fee. (1) Considering that I want my data to be encrypted and stay that way (only accessable through my data handlers), that's not a very good choice. [I know, we're back to open source again ... what can I say? I work for an intellectual property company. I may not like your opinions, but I do recognize that you have a right to them.] MySQL is the same way(2) Wasn't PostGreSQL produced by Great Bridge Software? Aren't they out of business? (3) Wasn't it produced under the GPL? Essentially, you're repeatedly suggesting that I ship an open-source database to individual client machines. I'm suggesting that that doesn't fit with the client-side app content/subscription model, and you can tell by reading the license agreements to those apps. Disagree? Have experience developing shrink-wrapped applications and want to chime in? Have a few more Databases you'd like to discuss? I'd love to hear it. Matt H. References: 1. http://www.sleepycat.com/licensing.html 2. https://order.mysql.com/ 3. http://www.greatBridge.com From matthew_heusser at mcgraw-hill.com Fri Sep 21 10:07:22 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Lies, lies, lies II Message-ID: <85256ACE.00553447.00@corpny55wls01.mcgraw-hill.com> Warning: Open-Source Religious Argument. Doing a bit more research, postGreSQL does have a license agreement that is not too terribly restrictive, and it was started by the university of California. Here's what the readme says about porting: >1.4) What non-unix ports are available? > > Client > > It is possible to compile the libpq C library, psql, and other > interfaces and binaries to run on MS Windows platforms. In this case, > the client is running on MS Windows, and communicates via TCP/IP to a > server running on one of our supported Unix platforms. A file > win31.mak is included in the distribution for making a Win32 libpq > library and psql. PostgreSQL also communicates with ODBC clients. > > Server > > The database server can run on Windows NT and Win2k using Cygwin, the > Cygnus Unix/NT porting library. See pgsql/doc/FAQ_MSWIN in the > distribution or the MS Windows FAQ on our web site. We have no plan to > do a native port to any Microsoft platform. When companies start saying things like "well, it might be possible, but we designed it for UNIX ..." I get worried. Oh, and Cygwin is produced under the GNU licensing model. If we could make it work, we'd have to call in the lawyers, and then ... we probably couldn't make it work. Can anyone think of a "open source" software company that has generated real profits using the shrink-wrap model? (Offhand?) Matt H. From joelmeulenberg at yahoo.com Fri Sep 21 13:32:54 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: The GR.pm Liars Club In-Reply-To: <85256ACE.00524ADB.00@corpny55wls01.mcgraw-hill.com> Message-ID: <20010921183254.23705.qmail@web13005.mail.yahoo.com> (Tangent: Anyone remember that old gameshow called the "Liars Club"?) I'm finding all this flamage strangely exhilarating. : ) > Wasn't PostGreSQL produced by Great Bridge Software? Aren't they > out of business? (3) Wasn't it produced under the GPL? As for PostgreSQL, it grew out of the Postgres Project at Berkeley under Michael Stonebraker (which grew out of the Ingres Project at Berkeley). As you'd expect, it's licensed under the BSD license, so you'd have no problems with distribution I guess. Regardless, I wouldn't recommend having your furniture info/catalog app run on Postgres. : ) +Joel __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ From beaker457 at hotmail.com Fri Sep 21 14:16:41 2001 From: beaker457 at hotmail.com (Ben Carlson) Date: Wed Aug 4 00:01:16 2004 Subject: Lies, lies, lies II Message-ID: Warning: Open-Source Religious Argument. >If we could make it work, we'd have to call in the lawyers, and then ... we >probably couldn't make it work. Quote from the Simpsons: "Send in our deadliest weapon, the Lawyers". > Can anyone think of a "open source" software company that has >generated >real profits using the shrink-wrap model? (Offhand?) A free software company that makes money charging for their software, that does not make sense. What the company can charge for is the services that come with the software such as Red Hat. If they had stopped making aquistions they would have shown a healthy profit already. Correct me if I'm wrong, but I would imagine there are plenty of people making a living off of Linux. Plenty of programmers, distribution, Admins that make a very comfortable living. In fact I believe Red Hat stock has done pretty well in the past and what do they really produce? As a programmer I would not be comfortable with creating a format and software to read the format, then charging money for both the data and format. Because we specialize in technology does that mean we should be milking people for profits because we can make a format for reading data? Ben Carlson _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From albert.tobey at priority-health.com Fri Sep 21 14:45:38 2001 From: albert.tobey at priority-health.com (Albert P Tobey) Date: Wed Aug 4 00:01:16 2004 Subject: Rephrase: uninformed asserstions that happen to be false In-Reply-To: <85256ACE.00524ADB.00@corpny55wls01.mcgraw-hill.com> References: <85256ACE.00524ADB.00@corpny55wls01.mcgraw-hill.com> Message-ID: <1001101538.3561.339.camel@linuxws1> My appologies to everybody for a not-really-but-kinda-sorta-perl-related thread on this list. -- Matthew, Do not simply label me an open source zealot. I can be one, but I'm not because I understand (just as most knowledgable OSS advocates) that some current business practices require propriety over their IP. The point I was trying to make is that you /could/ use OSS, not that you have to, or not even that the products I mentioned would suit the task. I could poke holes in your arguments all day long, but I'm guessing that it'll be a waste of my breath. I could carry this thread on forever if unchecked, so I'll make this may last word unless others on the list ask for clarification. You'll notice I will reiterate a couple points - it is because I find those points to be especially important for anybody reading this to understand. The fact that your company is peddling shrinkwrapped software is irrelevant to the points that I'm making. The fact is that all of the products I mentioned can be directly included into a boxed product without paying a fee or directly including the source. The only requirement, even under the GPL, is that you make the source available - ftp, or just a link to the original author/maintainer's site. If you are linking a library or connecting to a database that is under the LGPL or GPL, respectively, you DO NOT have to open the source to your product. You only need to make modifications to GPL covered products available to your customers. As for proprietary data models, they're absolutely worthless no matter how you slice it, unless you're interested in lock-in Microsoft style (read: monopoly). MS Word DID NOT gain dominance because of some silly data format - it did because it's one of the best product available in its class and is by far the best marketed. Has anybody ever said, "gee, word is great because their doc format is so cool." More often I hear the opposite, especially when it comes to editing the document outside of Word. How many times have people requested applications to index doc files for a web portal or to translate to other formats? Why, now, is the industry starting to move over to XML which is, by nature, non-proprietary? If you're interested in protecting your content, use 3DES or AES encryption - you can either buy or get for free (and use freely) software to do the encryption for you. Anybody who has an inkling about security and cryptography can tell you that obfuscation buys you absolutely nothing. So, especially, in the case of 'data files', cramming data into some proprietary and obfuscated format usually done out of ignorance and jealousy. Perhaps in the case of an application like Oracle ('data base') I can see the need to use 'proprietary' formats because their business model is based entirely on the performance and stability of their database, not content or user applications. I don't have time for details on where proprietary makes sense, but there are some very good websites out there like www.opensource.org and www.fsf.org that can explain it better - especially check out Eric Raymond's essays that can be found on opensource.org and his book "The Cathedral and the Bazaar". ... > Sure, you can make money with open > source, but it doesn't fit well into a content/subscription model. Huh? That's one of the _best_ ways to make money with OSS. Give away the software, charge for the content. > My customers actually pay money for our software and content on > a subscription basis. That's very different thant the IT services world. > In your solution, I would give away the keys to the kingdom! You can still charge all you want for both the software and the content, even if you use non-proprietary data files and even some OSS software in your product. Obviously, you haven't read the licenses or you don't understand them. Do you think Oracle or Nvidia have to release sources because they have code compiled by gcc and binutils and links to the GNU C library? No. This is why I go off when I see inaccuracies about OSS - because you are just one of thousands of misinformed people who get around spouting half-truths and false statements. Ignorance is never an excuse. > >The only thing nifty about it is that the developer > >(you?) can buy himself some more job security. > Fine, Let's avoid the flames and stick to facts. > Seriously, we have 10 developers here. We hired a contractor to do > a great deal of the programming on our Data Storage Tier. He's gone, > and if I quit, someone else would be up and running shortly. If we lost > all 10 developers, that would be bad - but we have a half-dozen > information developers who know how to build catalogs in our > proprietary format. Ahh, but if it were an open format, you wouldn't have needed that contractor at all and new developers would already know what's going on, day 1. > I want to re-distribute the database and run it on the user's desktop. > BerklelyDB is attractive for that, but if I want to redistribute it, I have > to ship the source code and pay a fee. (1) Considering that I want > my data to be encrypted and stay that way (only accessable through > my data handlers), that's not a very good choice. [I know, we're back > to open source again ... what can I say? I work for an intellectual > property company. I may not like your opinions, but I do recognize > that you have a right to them.] > > MySQL is the same way(2) Umm. You didn't read the licenses did you. While I don't know the Berkely license as well as OSS or GPL, I do know that you don't have to pay a fee, and I'm pretty sure you don't have to distribute the source at all. This is why Apple chose BSD code for OS X and not Linux or other OSS stacks - BSD does not require you to publish your modifications at all and there's no fee. MySQL has been released under the GPL, so regardless of what MySQL (there are two companies selling slightly different versions) charges for support or whatever, you can distribute it unmodified as much as you want with only a README to point to the source. MySQL's license changed only about a year ago, so you may be thinking of their old license. And, yes, PostgreSQL is GPL IIRC and it is still under active development by a couple groups - Redhat's RedHat Database is based on the PGSQL code, for instance. Many OSS companies do have instances where you pay, but it's not for the code - it's for specific feature enhancements, distribution media, support, or content. > Essentially, you're repeatedly suggesting that I ship an open-source > database to individual client machines. I'm suggesting that that doesn't > fit with the client-side app content/subscription model, and you can tell > by reading the license agreements to those apps. The key word is suggest. I'm making the point that you could use any of the available open source software and not endanger your business model. In fact, it may enhance the bottom line of your company by cutting back on developer time to produce the product - or leave more time for interface and other enhancements instead of reinventing wheels. I was not referring to the technical capability of any of those products to fulfill your needs. But, I cannot think of many ~500mb storage applications that couldn't be handled easily by MySQL, BerkelyDB, or even a good XML/SAX parser. If you're not encrypting data (I'm guessing not), then you should be using an industrial-strength encryption algorithm if you're that concerned about the propriety of your data. Obfuscation of data is like using a cheap paddlock on your castle's front gate. Paddlocks are only good for keeping honest people honest: any crook with an acetylene torch can access your data no matter how good your paddlock. Use AES and it's like a titanium safe - crooks can hack and cut for years and still not get in. > Have a few more Databases you'd like to > discuss? I'd love to hear it. Oh yeah - there's a great SQL engine that's fully commercial and designed specifically for embedded applications (e.g. shrinkwrap) called Solid SQL. Do a google search. You'd be surprised how many apps use it. Again, I really don't care what you do with your applications, but I do care when people spread false information. While I'd love to debate this further, I don't have the time. Just make sure you know what you're talking about the next time you try to disregard OSS. Just think, Perl would not be anywhere near where it is today if it weren't for open source development and the communities that have grown up around it's open nature. -Al Tobey -- "Open source" means that anyone can get a copy of the source code. Developers can find security weaknesses very easily with Linux. The same is not true with Microsoft Windows. Microsoft, "What Every Retailer Should Know", February 2001 ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. ******************************************************************** From matthew_heusser at mcgraw-hill.com Fri Sep 21 14:47:03 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: To Clarify ... Message-ID: <85256ACE.006CD66B.00@corpnj148ls01.mcgraw-hill.com> If you're enjoying the flame war ... To Clarify: We have two (2) shrink-wrapped packages. One is pretty much just a directory of product information. It's a nifty little compilation of data. It's _FREE_. I think they make up the money in advertising. The second involves a great deal of custom/automation/value-added work, which we allows users to edit and manipulate to create orders. We charge for this second one. If one of the McGraw-Hillians who left the fold would like to comment for a balance perspective, that might be nice. Apparently, my communication skills leave much to be desired. Matt H. From matthew_heusser at mcgraw-hill.com Fri Sep 21 15:22:20 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Fine, I'll stop too ... Message-ID: <85256ACE.0070A0BE.00@corpny55wls01.mcgraw-hill.com> I love this. Write a three-page message to "end the thread", then declare victory. At this game, whoever gets the last word gets to declare victory. (Or maybe the first one to declare victory?) So, I'll stop playing too. Let me make this clear: (1) Yes, our data is encrypted. (2) Most of the other assumptions you made about our business model in the previous email are wrong too, so (3) Obviously, I've done a poor job explaining the position of my company. (The other conclusion, that you aren't perfect, is obviously impossible.) (4) Yes, in final conclusion, I do agree with you, we _could_ use an OSS database for our software. After my company has invested literally man-years of analysis, we don't think that's the best idea. (5) This all started because I dared state that there are price/speed/size considerations for using Relational Databases as opposed to other data formats. (6) Can we safely say that #4 is true, or am I still a ___? Matt H. From chuckwilliams1 at home.com Sat Sep 22 05:35:20 2001 From: chuckwilliams1 at home.com (Chuck Williams) Date: Wed Aug 4 00:01:16 2004 Subject: Supporting Material Message-ID: <3BAC6968.FC87723F@home.com> My boss asked me to find some supportive Perl material for him to pass at an IT meeting. Our web group has been moved to the IT division. They are primarily Sun/Oracle but Perl is pretty much unknown to them. (Of course it's an exec-level meeting and my boss is the only programmer in attendance anyway.) In this meeting they're going to decide whether our primary language is Perl or something else (he told me 'Java' -- I think the choice must go deeper than that). My employer is www.sme.org and I won't say the word "simple". Let's just say I've been asked to find STRAIGHT TALKING, easy-to-understand material making our case. Articles from major traditional trade magazines are best. Below are a few I've pulled from dozens I looked at yesterday. I'm looking for a few more. Any suggestions? - Chuck Williams =============== PERL 6 TO DEBUT IN AUGUST ================= http://www.computerworld.com/cwi/story/0,1199,NAV47_STO42013,00.html =============== PERL RELEASE HISTORY ================= http://www.perldoc.com/perl5.6/pod/perlhist.html =============== JSP vs. PERL ================= http://www.infoworld.com/articles/op/xml/01/07/30/010730opcringely.xml =============== OPEN SOURCE ================= http://www.infoworld.com/articles/op/xml/01/08/27/010827oppetreley.xml From joelmeulenberg at yahoo.com Sun Sep 23 15:02:45 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: Supporting Material In-Reply-To: <3BAC6968.FC87723F@home.com> Message-ID: <20010923200245.71649.qmail@web13005.mail.yahoo.com> > Our web group has been moved to the IT division. They are primarily > Sun/Oracle but Perl is pretty much unknown to them. (Of course it's > an > exec-level meeting and my boss is the only programmer in attendance > anyway.) > > In this meeting they're going to decide whether our primary language > is > Perl or something else (he told me 'Java' -- I think the choice must > go > deeper than that). Yikes. An executive level meeting is going to dictate what programming language should be used (or "preferred" or whatever) at your company? I can understand a group of software development leads/management/developers getting together to explore, discuss, and decide such a matter, but executives? Wow. > My boss asked me to find some supportive Perl material for him to > pass > at an IT meeting. Magazine/web articles are nice, but I'd recommend the "try it before you buy it" approach whenever possible. e.g.- Take a couple typical small webish projects (or maybe just portions of projects if you don't have any "small" projects) and try doing them in a Java environment (e.g.- servlets) and a corresponding Perl environment (e.g.- mod_perl). And if you do non-web development, repeat this exercise for representative projects from those realms. Honestly, what you'll probably find is that for certain kinds of work Java is better suited, and for others, Perl is better suited. For example, I have a hard time imagining Java being better than Perl for sysadmin scripting type work. But for larger, OO-architected systems, Java is likely a better choice than Perl (not that you can't do it in Perl, but Java is probably a better fit). Since both Java and Perl can work for many kinds of projects, I suspect a greater consideration may be which language most of the developers are familiar with - or maybe how much infrastructure (code libraries, APIs, app frameworks, etc.) your company has already built in either language. If you're going to be be doing a lot of interaction with Oracle, the Perl DBI is really quite nice (and the DBD::Oracle driver is solid). IMHO, JDBC is kinda painful to use by comparison. > My employer is www.sme.org and I won't say the word "simple". Let's > just > say I've been asked to find STRAIGHT TALKING, easy-to-understand > material making our case. Articles from major traditional trade > magazines are best. > > Below are a few I've pulled from dozens I looked at yesterday. > > I'm looking for a few more. Any suggestions? I would also caution you against basing any decision solely on articles because then you are opening yourself up to doing what the marketeers would have you do. Java has been successful because of its merits but also because it has a lot of marketing muscle behind it. e.g.- I've seen articles comparing the performance of Java servlets to Perl CGI scripts (non-mod_perl) (apples and oranges really) - from Sun. Perl has been successful despite a lack of marketing. In other words, Perl must have some very compelling merits to have become this successful. I did a quick search for "Java versus Perl" type articles, but didn't find much. If I find anything, I'll be sure to forward it to the list. +Joel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From joelmeulenberg at yahoo.com Sun Sep 23 15:02:50 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: Supporting Material In-Reply-To: <3BAC6968.FC87723F@home.com> Message-ID: <20010923200250.51475.qmail@web13006.mail.yahoo.com> > Our web group has been moved to the IT division. They are primarily > Sun/Oracle but Perl is pretty much unknown to them. (Of course it's > an > exec-level meeting and my boss is the only programmer in attendance > anyway.) > > In this meeting they're going to decide whether our primary language > is > Perl or something else (he told me 'Java' -- I think the choice must > go > deeper than that). Yikes. An executive level meeting is going to dictate what programming language should be used (or "preferred" or whatever) at your company? I can understand a group of software development leads/management/developers getting together to explore, discuss, and decide such a matter, but executives? Wow. > My boss asked me to find some supportive Perl material for him to > pass > at an IT meeting. Magazine/web articles are nice, but I'd recommend the "try it before you buy it" approach whenever possible. e.g.- Take a couple typical small webish projects (or maybe just portions of projects if you don't have any "small" projects) and try doing them in a Java environment (e.g.- servlets) and a corresponding Perl environment (e.g.- mod_perl). And if you do non-web development, repeat this exercise for representative projects from those realms. Honestly, what you'll probably find is that for certain kinds of work Java is better suited, and for others, Perl is better suited. For example, I have a hard time imagining Java being better than Perl for sysadmin scripting type work. But for larger, OO-architected systems, Java is likely a better choice than Perl (not that you can't do it in Perl, but Java is probably a better fit). Since both Java and Perl can work for many kinds of projects, I suspect a greater consideration may be which language most of the developers are familiar with - or maybe how much infrastructure (code libraries, APIs, app frameworks, etc.) your company has already built in either language. If you're going to be be doing a lot of interaction with Oracle, the Perl DBI is really quite nice (and the DBD::Oracle driver is solid). IMHO, JDBC is kinda painful to use by comparison. > My employer is www.sme.org and I won't say the word "simple". Let's > just > say I've been asked to find STRAIGHT TALKING, easy-to-understand > material making our case. Articles from major traditional trade > magazines are best. > > Below are a few I've pulled from dozens I looked at yesterday. > > I'm looking for a few more. Any suggestions? I would also caution you against basing any decision solely on articles because then you are opening yourself up to doing what the marketeers would have you do. Java has been successful because of its merits but also because it has a lot of marketing muscle behind it. e.g.- I've seen articles comparing the performance of Java servlets to Perl CGI scripts (non-mod_perl) (apples and oranges really) - from Sun. Perl has been successful despite a lack of marketing. In other words, Perl must have some very compelling merits to have become this successful. I did a quick search for "Java versus Perl" type articles, but didn't find much. If I find anything, I'll be sure to forward it to the list. +Joel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From joelmeulenberg at yahoo.com Sun Sep 23 15:03:22 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: Supporting Material In-Reply-To: <3BAC6968.FC87723F@home.com> Message-ID: <20010923200323.30682.qmail@web13001.mail.yahoo.com> > Our web group has been moved to the IT division. They are primarily > Sun/Oracle but Perl is pretty much unknown to them. (Of course it's > an > exec-level meeting and my boss is the only programmer in attendance > anyway.) > > In this meeting they're going to decide whether our primary language > is > Perl or something else (he told me 'Java' -- I think the choice must > go > deeper than that). Yikes. An executive level meeting is going to dictate what programming language should be used (or "preferred" or whatever) at your company? I can understand a group of software development leads/management/developers getting together to explore, discuss, and decide such a matter, but executives? Wow. > My boss asked me to find some supportive Perl material for him to > pass > at an IT meeting. Magazine/web articles are nice, but I'd recommend the "try it before you buy it" approach whenever possible. e.g.- Take a couple typical small webish projects (or maybe just portions of projects if you don't have any "small" projects) and try doing them in a Java environment (e.g.- servlets) and a corresponding Perl environment (e.g.- mod_perl). And if you do non-web development, repeat this exercise for representative projects from those realms. Honestly, what you'll probably find is that for certain kinds of work Java is better suited, and for others, Perl is better suited. For example, I have a hard time imagining Java being better than Perl for sysadmin scripting type work. But for larger, OO-architected systems, Java is likely a better choice than Perl (not that you can't do it in Perl, but Java is probably a better fit). Since both Java and Perl can work for many kinds of projects, I suspect a greater consideration may be which language most of the developers are familiar with - or maybe how much infrastructure (code libraries, APIs, app frameworks, etc.) your company has already built in either language. If you're going to be be doing a lot of interaction with Oracle, the Perl DBI is really quite nice (and the DBD::Oracle driver is solid). IMHO, JDBC is kinda painful to use by comparison. > My employer is www.sme.org and I won't say the word "simple". Let's > just > say I've been asked to find STRAIGHT TALKING, easy-to-understand > material making our case. Articles from major traditional trade > magazines are best. > > Below are a few I've pulled from dozens I looked at yesterday. > > I'm looking for a few more. Any suggestions? I would also caution you against basing any decision solely on articles because then you are opening yourself up to doing what the marketeers would have you do. Java has been successful because of its merits but also because it has a lot of marketing muscle behind it. e.g.- I've seen articles comparing the performance of Java servlets to Perl CGI scripts (non-mod_perl) (apples and oranges really) - from Sun. Perl has been successful despite a lack of marketing. In other words, Perl must have some very compelling merits to have become this successful. I did a quick search for "Java versus Perl" type articles, but didn't find much. If I find anything, I'll be sure to forward it to the list. +Joel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From joelmeulenberg at yahoo.com Sun Sep 23 16:57:39 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:16 2004 Subject: Supporting Material Message-ID: <20010923215739.82026.qmail@web13005.mail.yahoo.com> > I did a quick search for "Java versus Perl" type articles, but didn't > find much. If I find anything, I'll be sure to forward it to the > list. Here's an interesting article comparing Python (very similar to Perl, but "cleaner") to Java. (If Perl didn't exist today or hadn't existed before Python, I'd be doing a lot of programming in Python.) I especially like the code snippet comparisons. The amount of code to accomplish those tasks is essentially the same in both Perl and Python. The amount of code you have to write in Java is significantly greater: http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html This "Tale of Five Languages" is amusing: http://www.python.org/doc/langquest.html Here's an article entitled "What's wrong with Perl" that favors Python over Perl, but also mentions Java a little along the way: http://www.garshol.priv.no/download/text/perl.html Here's an old article about Java and Perl: http://www.perl.com/pub/a/language/versus/java.html Here's a good comparison of languages to Python from Python's primary author: http://python.bilkent.edu.tr/doc/essays/comparisons.html Sorry most of these are all so Python oriented. I just kept finding interesting articles that favored Python. Many of Python's strengths are also Perl's strengths (those that are unique to Python are stressed in the articles). Of course, Python doesn't have as large a user base as Perl. Nor does it have a code library as comprehensive as the Perl CPAN. +Joel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From matthew_heusser at mcgraw-hill.com Mon Sep 24 07:31:05 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Asserations Message-ID: <85256AD1.0044826B.00@corpnj148ls02.mcgraw-hill.com> Folks: Here's an idea that I hope can keep us from falling into flame wars. In the future, If you want to refute an assertion of objective fact, let's try to provide references. For example, someone recently posted that Red Hat was a profitable company that shrink-wraps and sells open source software. I pointed to Red Hat's SEC Filings of 20 July, 2001, (Available from Investor Relations off www.redhat.com), that point out that that is not, in fact, the case. Please, let's not get into the "is not / is too" game. Let's stick to objective fact, and objective experience where it is appropriate. (Such as when Steve Lane pointed out that yes, there are wireless systems that have HTML-like widget sets. That information I do appreciate.) Otherwise, we won't learn anything from each other. And, opinionated as I am, that's why I'm here. Matt H. PS: 1. while () { s/ship\sthe\ssource\scode/make freely available/g; # (That was poorly worded on my part) } 2. Earlier, Mr. Tobey wrote: >Huh? That's one of the _best_ ways to make money with OSS. >Give away the software, charge for the content. Can you give me some examples of profitable companies that do this with a product-oriented (not service-oriented) model? 3. I shouldn't have used the phrase "properitary data format", that was handing over a loaded gun. hmm ... perhaps I should have said "A non-SQL database that meets our needs?" From matthew_heusser at mcgraw-hill.com Mon Sep 24 07:31:28 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Perl Vs. Everything else Message-ID: <85256AD1.00448BFD.00@corpnj148ls02.mcgraw-hill.com> Earlier, Joel Wrote: >Honestly, what you'll probably find is that for certain kinds of work >Java is better suited, and for others, Perl is better suited. I tend to agree, but the problem is convincing folks that there is more than one way to do it. Management is probably more familiar with terms like "Homogenous Assignment" than code, so I'd try explaining that langauges are like people. Personally, I would try to make the argument that there is no single, general-purpose language that works best in ALL situations. If there was, we'd all be using it. Having a chief architect select a unified architecture might be best. (Mythical Man Month, Robert Brooks . If you can get them to read one book on software engineering, it's this one.) If switching to Java Means re-writing code, I'd check out: http://www.joelonsoftware.com/stories/storyReader$47 I'd also do some research in the area of learning/teaching/improving in multiple languages is better long-term. Trying to fence into one language short-term to cut the budget ends up costing more and we all know it; I'm curious if someone has proved it. http://www.norvig.com/21-days.html Matt H. From matthew_heusser at mcgraw-hill.com Mon Sep 24 08:23:23 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Interesting URL Message-ID: <85256AD1.0049B540.00@corpnj148ls01.mcgraw-hill.com> Just thought this was interesting: http://www.perl.com/pub/a/2000/12/advocacy.html Matt H. From matthew_heusser at mcgraw-hill.com Mon Sep 24 08:33:15 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: More Perl Advocacy Message-ID: <85256AD1.004A9BBA.00@corpnj148ls01.mcgraw-hill.com> http://prometheus.frii.com/~gnat/yapc/2000-advocacy/ Matt H. ---------------------- Forwarded by Matthew Heusser/C-I-G on 09/24/2001 09:30 AM --------------------------- Matthew Heusser 09/24/2001 09:23 AM To: grand-rapids-pm-list@happyfunball.pm.org cc: Subject: Interesting URL Just thought this was interesting: http://www.perl.com/pub/a/2000/12/advocacy.html Matt H. From sml at zfx.com Mon Sep 24 08:47:56 2001 From: sml at zfx.com (Steve Lane) Date: Wed Aug 4 00:01:16 2004 Subject: Interesting URL References: <85256AD1.0049B540.00@corpnj148ls01.mcgraw-hill.com> Message-ID: <3BAF398C.90B83397@zfx.com> matthew_heusser@mcgraw-hill.com wrote: > > Just thought this was interesting: > > http://www.perl.com/pub/a/2000/12/advocacy.html yep, Dominus is super-cool; just about anything he writes is worth reading. i think this article is at least somewhat inspired by a talk Nathan Torkington gave at YAPC 19100 (or 1999, don't remember). i'm a sucker for any article that quotes Bill James, anyway. :) -- Steve Lane From bill_day at mcgraw-hill.com Mon Sep 24 08:42:51 2001 From: bill_day at mcgraw-hill.com (bill_day@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Perl Vs. Everything else Message-ID: <85256AD1.004CF946.00@corpnj148ls01.mcgraw-hill.com> As a perspective I'd like to share a true story of the executives who brought us the grand unifying language theory. There are a few on this mailing list who will remember, but to protect the innocent, I will tell you they are no longer in the McGraw-Hill domain. I think it was 1996 or 97. A man we had never met before came from our N.J. offices and informed us that they had signed a multi-million dollar contract with a high tech startup in silicon alley. In the future all programming work would be done in VB. One outsourced project was done in VB, and one in house project was done in VB. The silicon alley startup was fired. The applications remain largely untouched because the people who did the work have moved along, and nobody else cares to touch them. The VERY NEXT TRIP of an executive from N.J. we were told that all work would be done in Java/CORBA. I don't know if you remember the state of Java in 96, but it was still very primitive, and it was very difficult to accomplish much of anything useful. NO projects were EVER completed in Java/CORBA. We remain primarily C++ shop with some Perl, because that is the culture of the programmers who do the work. The lesson to be learned here: We lost a lot of talented people, and wasted a lot of time because executives were making decisions that are outside their area of expertise. When bad decisions were made the smart people left. Have your resume ready. From sdpoling at home.com Mon Sep 24 10:38:49 2001 From: sdpoling at home.com (Steve D Poling) Date: Wed Aug 4 00:01:16 2004 Subject: Perl Vs. Everything else In-Reply-To: <85256AD1.004CF946.00@corpnj148ls01.mcgraw-hill.com> Message-ID: This raises an interesting issue in the light of the caveats about "throwing software away" (http://www.joelonsoftware.com/stories/storyReader$47). How does one switch from Language A to Language B without "throwing it all away"? The boys at Q2 (the silicon alley contractor) did just that when they came in and took a C/C++ project into VB. That project was doomed for a number of reasons: company selection based upon cronyism (Kevin/Uday), distrust of the MGH bungie bosses (Jack/Rich/Frank), the threat that Q2 would be used to "beat up Grand Rapids." That failure had as many non-technical reasons as technical ones. I worked with the Q2 guys and found them competent, albeit married to VB. Q2's switch to VB (and idiotic politics) forced a complete rewrite. The application was a fairly simple container app that leveraged many VBX/OCX/ActiveX components. I thought that was a Good Thing. The bad thing is that nobody was smart enough (myself included) to insist that this simple container app be written in C/C++ and build upon the extant codebase. I try to be pragmatic and ecclectic. Different languages solve different problems more or less graciously. UI-centric applications are more quickly prototyped in VB. C/C++ applications are more modular. M$ propaganda says .NET is being all things to all people. One may be able to craft applications where different modules are implemented in different languages. Perl for text/string/data munging, VB for snappy UIs, C/C++ for heavy algorithms, and C# to make Bill Gates richer. This may seem evil to people who think one language should do it all. Time will tell. Think back on "throwing it all away" when changing languages is a strategic goal. In the .NET world, you can evolve between languages one module at a time. smiles and cheers, steve p.s. The "silicon alley" company, Q2, was founded by James Glick, the author of _Chaos_. A fact I always found hugely amusing/ironic. > -----Original Message----- > From: owner-grand-rapids-pm-list@pm.org > [mailto:owner-grand-rapids-pm-list@pm.org]On Behalf Of > bill_day@mcgraw-hill.com > Sent: Monday, September 24, 2001 9:43 AM > To: grand-rapids-pm-list@happyfunball.pm.org > Subject: Re: Perl Vs. Everything else > > > > As a perspective I'd like to share a true story of the executives > who brought us > the grand unifying language theory. There are a few on this > mailing list who > will remember, but to protect the innocent, I will tell you they > are no longer > in the McGraw-Hill domain. > > I think it was 1996 or 97. A man we had never met before came > from our N.J. > offices and informed us that they had signed a multi-million > dollar contract > with a high tech startup in silicon alley. In the future all > programming work > would be done in VB. One outsourced project was done in VB, and > one in house > project was done in VB. The silicon alley startup was fired. The > applications > remain largely untouched because the people who did the work have > moved along, > and nobody else cares to touch them. > > The VERY NEXT TRIP of an executive from N.J. we were told that > all work would be > done in Java/CORBA. I don't know if you remember the state of > Java in 96, but it > was still very primitive, and it was very difficult to accomplish much of > anything useful. NO projects were EVER completed in Java/CORBA. > > We remain primarily C++ shop with some Perl, because that is the > culture of the > programmers who do the work. > > The lesson to be learned here: We lost a lot of talented people, > and wasted a > lot of time because executives were making decisions that are > outside their area > of expertise. When bad decisions were made the smart people left. > Have your > resume ready. > > > From beaker457 at hotmail.com Mon Sep 24 11:19:16 2001 From: beaker457 at hotmail.com (Ben Carlson) Date: Wed Aug 4 00:01:16 2004 Subject: Asserations Message-ID: > Here's an idea that I hope can keep us from falling into >flame wars. In the future, If you want to refute an assertion >of objective fact, let's try to provide references. All right, let us go back to the email I sent regarding my claim. I claimed that the statement you made would be extremely hard to fathom. You issued a challenge of finding an Open Source company that makes a profit on shrink wrapped software. How can a company that makes free software make a profit on selling free software? It does not make sense. The statement below you claimed that I posted that I said Red Hat was a profitable company that shrink wraps and sells open source. That is totally incorrect of what I said in the email. I claimed that Red Hat sells services related to Red Hat, in which I thought that was the better business model. > For example, someone recently posted that Red Hat was >a profitable company that shrink-wraps and sells open source >software. I pointed to Red Hat's SEC Filings of 20 July, 2001, >(Available from Investor Relations off www.redhat.com), that point >out that that is not, in fact, the case. I would like to point out in the very same report for Red Hat's SEC filing there is a section called "Risk Factors" in which these statements are made: Very 1st paragraph "Our open source software business model is unproven." 2nd paragraph "We have not demonstrated the success of our open source business model, which gives our customers the right to freely copy and distribute our software. No other company has built a successful open source business." "Few open source software products have gained widespread commercial acceptance partly due to the lack of viable open source industry participants to offer adequate service and support on a long term basis. In addition, open source vendors are not able to provide industry standard warranties and indemnities for their products, since these products have been developed largely by independent parties over whom open source vendors exercise no control or supervision." Of course they have not demonstrated the success, as stated in their first paragraph, their busniness model is unproven. They have also stated that for the reason that this has not received widespread commercial acceptance is partly due to lack of service and support on a long term basis. As your claim to their filings of profits, I redirect you to look at the market as a whole has been doing with tech stocks in general. Could someone stop switching the coffee Matt normally drinks with new Folgers Crystals! Ben Carlson _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From matthew_heusser at mcgraw-hill.com Mon Sep 24 12:16:49 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Asserations Message-ID: <85256AD1.005F1714.00@corpnj148ls01.mcgraw-hill.com> Ben Carlson Wrote: >The statement below you claimed that I posted that I said Red Hat was a >profitable company that shrink wraps and sells open source. That is totally >incorrect of what I said in the email. No, Ben, you didn't say that. Joe Harnish did. I didn't quote you, because your argument was a bit different, and would take us in yet another direction, and, believe it or not, I do like to do work occasionally. :-) Ben Also asked: >How can a company that makes free software >make a profit on selling free software? Netscape and RedHat both tried to shrink wrap and sell thier software, along with tutorials, "special editions", books, etc. IMHO, this was designed to penetrate the I-won't-install-software-unless-it-comes-in-a-box crowd. And, while that may have earned them a bit of market share, it just wasn't profitable. For the record, I agree, a services model for RedHat IS a better model. Tom Christensen & Co has been making a go of it for quite some time, and they ARE profitable. Matt H. From chuckwilliams1 at home.com Wed Sep 26 04:29:00 2001 From: chuckwilliams1 at home.com (Chuck Williams) Date: Wed Aug 4 00:01:16 2004 Subject: Java, Perl, etc. Message-ID: <3BB19FDB.D3EDC322@home.com> We think with the many hundreds of hours of Perl that went into making our web site since '96 there's no way that body of work could be converted to another language in any reasonable way. Those scipts and our presence make a compelling case for Perl. Our web group was in the Publications Division until this summer and we chose our own course. So it was Perl and Oracle. We work primarily in the vi editor in Unix so there's your culture. Moving to IT this summer was ok by me. Except for the desktops, our Information Technology Division is all Unix, Oracle. And although anything's possible, I took their background to be a good omen. Now when my boss told me to get some supporting material for Perl together, I still think we're ok. 1.) At least Perl is still in the running. That says a lot for a language from the Open Source world. 2.) I'm thinking Java would make a good move for a guy like me. It would also keep our web site in the right "world" for years to come. By comparison, the wrong "world" would be, in my opinion, endless variations on all the web solutions that seem to come and go with the seasons. So my boss asked particularly for magazine articles and that's what I'm trying to dig up for him. It's his call what he wants to bring to their meeting. Our IT staff has a number of programmers who want to work on the web site. Do they want to learn Perl? I doubt it. It's likely they already have a Java background. It was interesting what Joel wrote about the Perl DBI (which we use) vs Java in that case. I know we could be better programmers too and so new blood would be a good thing in that sense. They're going to try their hand at our Intranet as a test case. My boss told me once they get laughed out of the water with cheesy graphics, they'll probably say the heck with it. Well who really knows until it happens. But I do know that a business with so much invested in graphic talent is pretty harsh when web sites aren't both graphically and functionally appealing. I saw Dominus speak this summer in Montreal. He's very interesting. Perl's great for many things. Well it's incredible at text manipulation. But you have to be flexible in programming. -- Chuck Williams =================================== >From Chuck Williams: My boss asked me to find some supportive Perl material for him to pass at an IT meeting. Joel Wrote: Honestly, what you'll probably find is that for certain kinds of work Java is better suited, and for others, Perl is better suited. For example, I have a hard time imagining Java being better than Perl for sysadmin scripting type work. But for larger, OO-architected systems, Java is likely a better choice than Perl (not that you can't do it in Perl, but Java is probably a better fit). Since both Java and Perl can work for many kinds of projects, I suspect a greater consideration may be which language most of the developers are familiar with - or maybe how much infrastructure (code libraries, APIs, app frameworks, etc.) your company has already built in either language. If you're going to be be doing a lot of interaction with Oracle, the Perl DBI is really quite nice (and the DBD::Oracle driver is solid). IMHO, JDBC is kinda painful to use by comparison. I would also caution you against basing any decision solely on articles because then you are opening yourself up to doing what the marketeers would have you do. The amount of code you have to write in Java is significantly greater: http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html This "Tale of Five Languages" is amusing: http://www.python.org/doc/langquest.html Here's an article entitled "What's wrong with Perl" that favors Python over Perl, but also mentions Java a little along the way: http://www.garshol.priv.no/download/text/perl.html Here's an old article about Java and Perl: http://www.perl.com/pub/a/language/versus/java.html Here's a good comparison of languages to Python from Python's primary author: http://python.bilkent.edu.tr/doc/essays/comparisons.html >From Matthew: I tend to agree, but the problem is convincing folks that there is more than one way to do it. Management is probably more familiar with terms like "Homogenous Assignment" than code, so I'd try explaining that langauges are like people. I'd also do some research in the area of learning/teaching/improving in multiple languages is better long-term. If switching to Java Means re-writing code, I'd check out: http://www.joelonsoftware.com/stories/storyReader$47 http://www.norvig.com/21-days.html >From Bill Day: We remain primarily C++ shop with some Perl, because that is the culture of the programmers who do the work. >From Steve Poling: http://www.joelonsoftware.com/stories/storyReader$47 I try to be pragmatic and ecclectic. Different languages solve different problems more or less graciously. UI-centric applications are more quickly prototyped in VB. C/C++ applications are more modular. M$ propaganda says .NET is being all things to all people. One may be able to craft applications where different modules are implemented in different languages. Perl for text/string/data munging, VB for snappy UIs, C/C++ for heavy algorithms, and C# to make Bill Gates richer. This may seem evil to people who think one language should do it all. Time will tell. Think back on "throwing it all away" when changing languages is a strategic goal. In the .NET world, you can evolve between languages one module at a time. From matthew_heusser at mcgraw-hill.com Wed Sep 26 07:17:42 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:16 2004 Subject: Java, Perl, etc. Message-ID: <85256AD3.00434822.00@corpnj148ls02.mcgraw-hill.com> >They're going to try their hand at our Intranet as a test case Why not shoot for some metrics? Executives (especially engineers) seem to love metrics. Take a small, but non-trivial web project connecting a database to a web front-end. Have the java guys estimate how long it would take them to write in EJB or whatever. Do you own estimates with CGI,DBI,Perl, etc. Compare numbers. You'll probably win. If they get obstinate, then I'd suggest having both teams actually _do_ the project.(1) That will give you some effort/time estimates for equivilant applications. But, then again, that would be pushing your shop toward one general-purpose language, and that's like, all bad and stuff. Matt H. (1) - If your company is insistent on picking a "best" programming langauge, but too busy to invest 24 man-hours of research into the decision ... there's a problem. From jbuist at tridenttechnology.com Wed Sep 26 15:59:36 2001 From: jbuist at tridenttechnology.com (Justin Buist) Date: Wed Aug 4 00:01:16 2004 Subject: Java, Perl, etc. In-Reply-To: <3BB19FDB.D3EDC322@home.com> Message-ID: Long time lurker here... though I'd pipe up on the subject though. Some perl mongers I met at a Sun security summit at Calvin a while back got me interested in the group. Regretfully I never took the time to come to a meeting of any sort but I've enjoyed the lively discussion on the list lately. Anyway... back to the point. > Our web group was in the Publications Division until this summer and we > chose our own course. So it was Perl and Oracle. We work primarily in > the vi editor in Unix so there's your culture. How archaic... you should have dumped vi for vim a long time ago. :) > happens. But I do know that a business with so much invested in graphic > talent is pretty harsh when web sites aren't both graphically and > functionally appealing. As others have said what it comes down to is what kind of tasks must your intranet perform? As we all know some things are more cumbersome in Perl which would be easier in Java and vice versa. There's more than one way to do a website in Java too. I'll iterate through the stuff I've played with and know about. ColdFusion: Great if you can't actually program and your website is nothing more than DB queries. It better be small too -- managing these CFML templates is a bear once they become over a couple of hundred lines. Functions don't actually exist in this language so what I'd do it a single file in any other language, if broken out into "tags", becomes 10-20 files. Horrid. Perl: Nevermind, you all know the pros/cons to this one. PHP: Syntax reminds me of Perl; easy to learn... fairly well documented; good user community around it too. I like it; we converted a CF project to PHP recently and did it blindingly fast. Much faster than the oringal CF development by about 1/4th. Part of that was because the team changed slightly by bringing out fastest ASP/VBScript guy onto the project and making him learn PHP. I like the way PHP works with Apache too, seems like a much more stable and faster application server than CF. ASP/VBScript: Same category as PHP for me, though I'm not very well versed in it. I just don't like the way the language acts and it looks too much like VBA while still being different. Huge source of confusion for me but I'm neither a good VBScript nor VBA programmer. Java Servlets: Nice model for "heavy lifting" sites. You can pull in all sorts of XML tools to get the job done and build nice packagable products out of it. We're in the final stages of a project which was both Servlets and a Java Application which shared common objects between the two of them. Our database -> PDF publication framework was originally going to be web based using FOP (http://xml.apache.org/fop) but it was pulled over to the client side application with little work. Java JSP: Inherits the ugly nature of a tag based framework like CF. I just don't agree with using a language as powerful as Java and intermingly it so absurdly with the presentation layer. It tries to abstract the two layers apart but I've seen (and heard) that it's easy for programmers to just do the wrong thing here. I just have to ask though, why isn't PHP on the table here? Justin Buist Trident Technology, Inc. 4700 60th St. SW, Suite 102 Grand Rapids, MI 49512 Ph. 616.554.2700 Fx. 616.554.3331 Mo. 616.291.2612 From chuckwilliams1 at home.com Thu Sep 27 04:47:10 2001 From: chuckwilliams1 at home.com (Chuck Williams) Date: Wed Aug 4 00:01:16 2004 Subject: Java, Perl, etc. References: Message-ID: <3BB2F59D.FF0E7CA4@home.com> Justin, Good review of current technologies. Well considering I'm not active in them. Especially appreciated the line between JSP and Java. It's kinda what I was afraid of. I went to a seminar a few nights ago on .Net and was told MS did a great job of ripping Java and JSP off (really, that's what they said: http://www.westlake.com). So thanks for the warning 'cuz there's people walking around here singing about Java Servlet Pages. Seriously though I'm more interested in Java now that the folks on this list pitched in. I suspect our IT is heading towards XML. I know there's a lot of PDF activity here too. PHP? Yeah as if they consult me before making every move! Hah. I don't have a clue what technologies they do and don't look at. In my mind I imagine though they wonder "what does Chuck think about ...". I've been to (too many) web sales marketing meetings here until I realized the execs are clueless and my time is better spent learning and exploring all the tools I currently have like Perl, Oracle, Unix. Just for the record our web group has never touched the company intranet. So when IT (who's new to the party) volunteered to work on it to practice their skills we just kinda laughed inside. -- Chuck Williams ==================================== Justin Buist wrote: > Long time lurker here... though I'd pipe up on the subject though. Some > perl mongers I met at a Sun security summit at Calvin a while back got me > interested in the group. Regretfully I never took the time to come to a > meeting of any sort but I've enjoyed the lively discussion on the list > lately. Anyway... back to the point. > > > Our web group was in the Publications Division until this summer and we > > chose our own course. So it was Perl and Oracle. We work primarily in > > the vi editor in Unix so there's your culture. > > How archaic... you should have dumped vi for vim a long time ago. :) > > > happens. But I do know that a business with so much invested in graphic > > talent is pretty harsh when web sites aren't both graphically and > > functionally appealing. > > As others have said what it comes down to is what kind of tasks must your > intranet perform? As we all know some things are more cumbersome in Perl > which would be easier in Java and vice versa. There's more than one way > to do a website in Java too. I'll iterate through the stuff I've played > with and know about. > > ColdFusion: > Great if you can't actually program and your website is nothing more than > DB queries. It better be small too -- managing these CFML templates is a > bear once they become over a couple of hundred lines. Functions don't > actually exist in this language so what I'd do it a single file in any > other language, if broken out into "tags", becomes 10-20 files. > Horrid. > > Perl: > Nevermind, you all know the pros/cons to this one. > > PHP: > Syntax reminds me of Perl; easy to learn... fairly well documented; good > user community around it too. I like it; we converted a CF project to PHP > recently and did it blindingly fast. Much faster than the oringal CF > development by about 1/4th. Part of that was because the team changed > slightly by bringing out fastest ASP/VBScript guy onto the project and > making him learn PHP. I like the way PHP works with Apache too, seems > like a much more stable and faster application server than CF. > > ASP/VBScript: > Same category as PHP for me, though I'm not very well versed in it. I > just don't like the way the language acts and it looks too much like VBA > while still being different. Huge source of confusion for me but I'm > neither a good VBScript nor VBA programmer. > > Java Servlets: > Nice model for "heavy lifting" sites. You can pull in all sorts of XML > tools to get the job done and build nice packagable products out of it. > We're in the final stages of a project which was both Servlets and a Java > Application which shared common objects between the two of them. Our > database -> PDF publication framework was originally going to be web based > using FOP (http://xml.apache.org/fop) but it was pulled over to the client > side application with little work. > > Java JSP: > Inherits the ugly nature of a tag based framework like CF. I just don't > agree with using a language as powerful as Java and intermingly it so > absurdly with the presentation layer. It tries to abstract the two layers > apart but I've seen (and heard) that it's easy for programmers to just do > the wrong thing here. > > I just have to ask though, why isn't PHP on the table here? > > Justin Buist > Trident Technology, Inc. > 4700 60th St. SW, Suite 102 > Grand Rapids, MI 49512 > Ph. 616.554.2700 > Fx. 616.554.3331 > Mo. 616.291.2612 From chuckwilliams1 at home.com Thu Sep 27 05:04:08 2001 From: chuckwilliams1 at home.com (Chuck Williams) Date: Wed Aug 4 00:01:16 2004 Subject: Java, Perl, etc. References: <85256AD3.00434822.00@corpnj148ls02.mcgraw-hill.com> Message-ID: <3BB2F998.4EAE802A@home.com> Matt, Yeh this makes sense. I'll bring it up. No ... not too controversial. I know some big brains some where at our place have spent much more than 24 hours wondering about the future languages we should use. I think it's possible we'll have a mixed environment of Perl and Java for a long long time. Why? Because there's an incredible amount of Perl running our sites. Too much for anyone to re-write. Also now our new bosses are asking for standards and documentation. With going on six years of Perl scripts to work from (much by my boss) you can imagine there's a lot of experimentation in there. I'm thinking this morning just suggesting that everything recent my boss has written is the standard and be done with it. As you can tell I'd rather program than explain things to other people. Yes yes yes our stuff contains documentation. In fact one of the links I passed around here (and to him) was the Perl version history. It's like if we're going with Perl than I can see it but if we're moving to Java than it's just busy work. Hmm. Anyway thanks for the suggestion.. -- Chuck Williams =============================== matthew_heusser@mcgraw-hill.com wrote: > >They're going to try their hand at our Intranet as a test case > > > Why not shoot for some metrics? Executives (especially engineers) > seem to love metrics. > > Take a small, but non-trivial web project connecting a database to a > web front-end. Have the java guys estimate how long it would take them > to write in EJB or whatever. Do you own estimates with CGI,DBI,Perl, etc. > > Compare numbers. You'll probably win. > > If they get obstinate, then I'd suggest having both teams actually _do_ > the project.(1) That will give you some effort/time estimates for equivilant > applications. > > But, then again, that would be pushing your shop toward one general-purpose > language, and that's like, all bad and stuff. > > > > Matt H. > > (1) - If your company is insistent on picking a "best" programming langauge, > but too busy to invest 24 man-hours of research into the decision ... there's > a problem.