Good Lord, you're gonna scare away the beginners who have questions about perl!
> > Hi, > > I'm a beginner that doesn't even have perl yet. > > I woul like to know whether Perl is faster or Java for business > > applications. > > Paul has already provided the correct Party Line from the > typical Perl Advocate. So I'll be stuck trying to defend the > grey beards position. > > As for KH's variation on the theme, now we start to move > towards the place where we have some parameters to really work with. > > To save some space I will try to 'speak in uri' - > > One of the places I have been ranting on this is: > > http://www.wetware.com/drieux/CS/SoftEng/GP/funcOrNotFunc.html > > Where I discuss the matters of "code reuse" - the OO process > by means of 'class/sub_class' - in Proceduralist languages > this is the library - in Perl it is the Module - the problem > in perl is that the perl5 OO implementation is not as good as > it can be, perl6 may 'solve all of that' - and we will see at > what costs. > > If you want to be way trendy then you of course want to be > looking at the Objective Caml Language: > > cf: http://www.ocaml.org/ > > Since this is a language where first order functionality > exists and it allows for the use of OO in the few possible > edge cases where that may actually have some 'requiredNeff'. > > Assuming that one were truly seeking 'ubiquity' for 'human > interface' then of course one has already come to understand > that one is either going to be writing CGI or mod_perl and/or > apache modules - since of course no 'real Operating System' > can exist but that it is fully integrated into a webBrowser. > { and we thought the emacs folks were a bit over the edge. } > At which point one is really talking in terms of what > specific type of Tomcat Servlet v. mod_perl v. apache module > were you really planning to write.... > > { old guys of course will be thinking in terms of Perl/Tk - > because they do not understand that Operating Systems that > are not a part of a webBrowser are passe.... and still have > this irrational belief that there were kernels that were not > browser plug-ins. } > > { for those of you new to writing device drivers - please, do > not assume that simply because your VB based device driver > allowed you to use 'standard IO' reads of flat files for > configurations - that this will allowed in an adult Operating > System - and no, you can not put 'printf()' or 'fprintf()' > statements in to do your kernel debugging. Nope - Not an option. } > > As for the specific question of Large Database - we of course > must pause and ask whether or not the system is a 'data > mining' project where it will be used for secondary 'decision > matrix analysis' - and speed is not the issue - or are we > talking in terms of an OLTP - at which point the real > question is who is doing the database design and shielding > the running daemons from the DB itself by doing the > appropriate "stored procedures" and transaction abstractions > - at which point we're also wondering why you want to do the > API to that in anything but 'c' because you really want to > have the most portable 'assembler code' processing system > that works from statically linked compile time code re-use - > because you are not at all interested in engaging in the > run-time dynamically loadable link level library hassles of > version skew as the libfoo.2.so really is not backwardly > compatible with the libfoo.1.so and you are not too sure how > to fully back out all of the code that needs to use the old > form since the process installed them as > > libfoo.so -> libfoo.<int>.so > > and there can only be ONE! > > At which point we could get into the discussions about > whether polymorphism is a good idea, as well as whether or > not java - which expressly avoids multiple class inheritance > - fully got away from all of that with the 'implements' that > allows the maze of twisty little passages as you find that > there are 'structural' issues getting the extends stuff to > work and play well with the implements stuff.... > > We should of course write up the problems associated with the > whole process of 'kargo kulting' - In which the blind pass > along what they heard to help the deaf find a way to smell a > fart... Which has more to do with whether or not you > personally should be wearing the trendy T-shirt that says: > > "WARNING: does not work and play well with others." > > Especially if you keep hacking out work arounds for what the > 'realCoders[tm]' > were supposedly 'developing' and finding that this is so much > more pathetically stoopidly implemented and maintained in > perl than in one of those 'real coding languages' that are > the topic of hotBuzz. > > Hence - just as you should have learned at least one > assembler language to know why you write that stuff in 'c' - > you need to know Perl so that you know why you don't write > 'fast code' in an object oriented programming paradigm - > since you really do not want to wait around while it bloats > up reimplementing in each object a common set of methods for > all gets and sets so that it can be fully encapsulated... > > Or because you find that hey, speed is not the need, hence > why not just use this Module - rather than re-implement it as > a flat stack of functions.... So that you can get on with the > truly important part of your life - impressing your friends > and neighbors in the various forms of DickSizeWars[tm] that > are your TechNoir moment as you still haven't quite figured > out how to hack access to a gender appropriate person - > because they don't come with any of the standard networking > protocols.... > > But aren't they suppose to have at least an RS-232 port? > > > ciao > drieux > > --- > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
