From: "David Ihnen" <dav...@norchemlab.com> >> They know it because everybody tell them so. Most web sites are done >> in PHP, most job offer for web programmers ask for PHP experience... > Then they don't know, they just repeat what others say. So I guess all > we can do is repeat what we know from experience, and hope that others > repeat it too...?
Yes of course, but I usually receive responses like "oh, perl, that ugly language? Python's much nicer and Ruby too. Can you do with perl what you can do with Python?" And I know that there is a screen reader for Windows and another one for Linux/Solaris which is made in Python, but it would be much harder to do the same thing with perl, so I can't say anything. I think that Perl is the best for web programming and system admins, but Python is better for interacting with the operating systems, especially with Windows, and with programs made in DotNet and Java. >> So who should pay those PHP programmers in order to motivate them? > Somebody who wants a program, and is smart enough to know that the > engineers are better choosers of the software language than they are. I don't know too many companies of this kind... And finally, the management of those companies could tell "ok, let's use Perl", but they will find that there are no perl programmers available, so they'll be convinced that perl is a language which is not used very much in these days, and that it would cost them more if they would like to create perl programs. >> > Who cares? Hiding source code is valueless. >> >> Maybe in your country. In my country 10 euro means too much and >> actually even 1 euro means too much if the same thing can be got for >> free, legally or not. > You taking it and using it doesn't impact anything, and the companies > have to understand that. Its just some ideas and organization, > pretending you can keep other people from knowing how you did something > just makes it less supportable by anybody - good software can be bad > software just because its obfuscated like that. Those who matter will > actually pay for your software because they want the support and > customization that comes with it. If they're not going to pay up front, > they're more likely to pay later - keeping them from using the software > at all won't help. So why obfuscate or worry about it? Because the clients pay once when they receive the program, and because the programmers usually don't trust their clients. They think that the IT guys of the client could just get the program, change it and sell it to another company. >> > You get what you pay for I guess. >> >> Well, they can get a free support offered for Zend Optimizer (or how >> it is called the Zend Decoder). > Free support as in open-source community stuff? Or as in a commercial > company spending their time to help you with something that they don't > get paid for? Zend is paid for, because they offer the Zend Optimizer for free and ask for money just for the Zend Encoder, so those programmers that want protection should buy it from Zend, but if they want this, they could have support for it from the hosting companies. A perl programmer doesn't need to pay for Filter::Crypto. He could use it for free, but the hosting companies won't offer support for it. >> Of course they care. If the same thing can be done cheaper using PHP, >> they will surely choose PHP. >> (The quality doesn't matter, because here the things are so fast >> changing, and the easiness of maintenance doesn't matter for most, >> because who knows what will happen after a few years. > Experience says in a few years, you'll want to augment and enhance your > application. But they don't have the experience, eh? Well, if they > want throw-away programs they'll get throw-away programs. And have to > pay for them over and over again. The savings are false. The companies > who chose wisely will get further. But that is a subtle pressure in the > market - perhaps even less so than the idea being implemented - thus > making our advocacy more or less moot. A working program is all that > matters to an end user, not a good or badly engineered program. How can > we convince them that the underlying engineering is important? Short of > organized crime techniques at least. >:) That's true. The languages that don't require wiseness for beeing appreciated have a big advantage these days. Without wiseness, perl can't be appreciated, and this is a big minus, because these days there are much more programmers and much more applications users than 15 years ago, and the inteligence level of all the programmers of the world decreases if the number of them increases. >> I've seen that the newbies always want recommendations, and think that >> there should be a recommended way of doing things, a best way. > Do you think there is a way to stop them from thinking that? Yes, by offering them not a single solution like Python pretends to do, but a few solutions, with recommendations for each solution. Perl offers an infinite number of solutions and it is harder to test them all and choose what's the best. For the same reason it is hard to find a team of perl programmers that know the same modules and have the same style of programming, use the same editors... >> Well, there is no such thing for perl. Perl is not a language, but it >> is more languages. >> If a programmer uses Catalyst and DBIx::Class and HTML::FormFu there >> is a language, if he uses CGI::Application and Rose::DB::Object it is >> another language, if he uses CGI.pm is another one, and there may >> appear other differences if they use mod_perl or fastcgi or just CGI, >> or if they use classic OOP or Moose, Template-Toolkit or Mason. >> >> It is not bad that we can choose, but the beginners don't know what to >> choose, and finally they would find all these confusing and start >> using RoaR or PHP. > Which is a state but not a solution. Are we supposed to agree on a > 'best in class solution pattern' and advertise/promote it on sites like > perl.org as a way to counteract the 'too many options' indecisive nature > of humanity? Not just a single solution, but 3, 4, 5, but not an infinite number of solutions. After the beginner would read the recommendations for all those few solutions, they would be able to choose one, and start using it, and then they'll understand that they can mix those solutions and create another one prefered by them, because this wouldn't be a problem after they would know Perl better. Shorter said, perl is not very much targeted to the beginners. >> Not exactly, because most of the PHP programmers don't work for >> themselves, but for other clients > Now you're getting down the fundamental risk levels. The bad programmer > is a risk to his employer, not to himself. This is a very interesting > pattern in our economy. Yes, long time risk. And the problem is that some companies are warned and know about this risk, but prefer to take it, because some economies are fragile and the short time costs are more important than the long time ones. > So its not the programmer in the end that made the bad decision, its the > client? Yet, the client trusted the programmer to choose a technology. > There's something afoul here. There can be no evolution to better > programmers because the badness of the programmer has almost no effect > on the decision. Yes, the client decides, and that's why languages like PHP are prefered. But there are other reasons for what other languages like Python are prefered. There might be more reasons, but some I've seen are: the fact that Python's OOP default style is much better than perl's one, the fact that Python could interact better with programs made in other languages like Java, the fact that most users consider Python's syntax more clear than perl's syntax, the fact that Python has some good modules that are very helpful under Windows... Most perl programmers consider Windows a bad OS, consider that Perl's web services shouldn't be necessarily compatible with those of Java or DotNet, don't care about low end users that need to use free web hosting companies... and this doesn't mean that it is bad, but it limits very much the target of this language, so we can say that perl is the best, but only for a very small number of developers. >> The good news is that some software companies started to see that this >> is a problem and don't consider PHP a great idea anymore. > Thank Dog. Now to get that pattern more widespread. Ideas? Promoting this would be very hard, because there is a big market for PHP applications, so even if they know that PHP is not a great language, they know that they can find easy PHP programmers for employing them, so it won't cost them too much, and that they would also find clients for those applications. >> The bad news is that those software companies start to use more and >> more DotNet and Java, and don't even think to Perl, because they know >> that perl is harder to maintain, that perl is write-only and other >> things like these. > But they don't even really know. Do they know they don't know? I don't really know if they know, but I think that most of them don't really care. This is because they know that storing perl applications costs more than storing PHP applications, and they would find fewer clients, and the most important, they know that they can't find perl programmers very easy. >> Yes, Perl 4 style of programming, or using CGI.pm might create code >> which is harder to maintain, but there isn't a big software company >> that promotes perl and tell them that this is not true anymore. > By this I assume you mean that you have to be 'big' in order to have any > credibility in choosing your technology? Absolutely. I've seen companies that bought an Oracle database not because they really needed it, but because they heard that "Oracle is the best", and because the software companies distribute Oracle for a good commision, so they promote Oracle and not PostgreSQL or something else. I don't know if Zend also makes this kind of arrangements with their corporate clients, but it could be possible... Octavian
