On Tuesday 2003-01-07 at 11:29:06 -0500, [EMAIL PROTECTED] wrote: > >>>>> "David" == David K Trudgett <[EMAIL PROTECTED]> writes: > > On Monday 2003-01-06 at 17:21:28 -0500, [EMAIL PROTECTED] wrote: > > >> Namely, most of the senior development managers did NOT have any > >> background in sys admin, so they didn't have a context in which to > >> appreciate the language. The problem space they all worked in was > >> one in which perl was NOT necessarily optimal. > > David> Do you think Perl 6 will be a language that _is_ "optimal" for > David> many/most/all of those problem domains for which Perl 5 > David> currently isn't? > > I don't know, because I haven't really followed perl6 development that > closely, personally. > > However, I do think that perl6 will fare better when compared to Java, > C++, D-flat (oops, I mean C-sharp ;-), etc., but at this point, its a > purely academic argument, becuase there's not much to compare.
I suppose that's why I put "optimal" in quotes. There will probably never be any such beast as an "optimal" language in a literal sense. "Optimal for what?" will probably always be the pertinent question. I tend to agree, though, that Perl 6 looks like it's shaping up to put all those you listed (and more) into a very dusty "also ran" for developing solutions in many problem domains. [Why do we have "problem domains" and not "challenge domains", by the way? :-)] > > But, at the end of the day, I don't really care what University CS > course teach. Let me take this thread in a slightly diffent > direction... Nor do I really care. Perl 6 isn't being designed as a teaching language (nor any other Perl for that matter). I suspect that Perl will always be of interest to those who actually want to get down and *do* something, as opposed to those who like to amuse themselves with fifty different ways to sort things. :-) Not that sorting isn't important... I'm more interested in what will be practical to tackle with Perl 6 that wasn't really practical before. Perl in CS courses, and higher education in general, wouldn't be harmful in my opinion, except that it's not really suitable as a first language because of all the gotchas, special cases, strange punctuation, and so on and so forth. It certainly should be allowed as a project implementation language where the nature of the project isn't related to a particular programming language (or where the project is to, say, implement a "hash" data type ;-)). > > Why don't I care? Because I work on Enterprise Infrastructure, > designing, developng, deploying and maintaining *ULTRA* large scale > systems. Is "ULTRA" a technical term ;-) > The best staff we have are the people with a strong > background in hands-on systems administration. The best sysadmins, > and among them, the best developers, almost all come from a non-CS > background. (My own degrees are in Math and Physics, and *all* of my > computer skills were self taught -- never taken a CS course in my > life). The problem with Computer Science courses is that the word "science" fools people into thinking that it is. > > My personal bias (and I make no claims that these statements are > anything other than that -- my opinions, from my subjective viewpoint, > with my biases), are that the best Enterprise Architects are NOT the > CS-trained, hardcore application developers, they are the people with > Real Experience building, operating, and maintaining a real, working > system. You have to admit the possibility that there are CS people out there who have managed to reverse the brain damage... :-) Just joking, of course. > > The worst input on Enterprise Architecture tends to come from people > with a "pure" development background. The ones who have never found > themselves stuck in a comm room at 3AM trying to figure out why a > critical system won't reboot after a hardware failure, or the admins > who have to struggle with the network outages caused by runaway > applications flooding the network and your monitoring systems with > bogus traffic. People who don't understand the problem from all pertinent angles won't come up with good input. CS courses probably don't generally even consider the operational angle, and CS graduates probably then go into positions that further deprive them of that perspective. > > Far too many "developers" are too far removed from the installation, > configuration, and support of the software they write. That someone > else problem. Well, those problems are the domain of the sys admin, > and that's the skill set that really understands how to scale a > working system. > > Now, in practice, almost all of the really good perl hackers I know in > the sysadmin world are people like me: self-taught sysadmins, who > learned by trial through fire, through real world experiences. So, > while I would love to see perl more "accepted" in the academic world, > I don't see that happening as long as the Dark Art of system > administration is not more formally recognized by CS departments. It's just that CS people have defined systems admin out of their scope and jurisdiction, so to speak. They think of themselves as the racing car driver and don't give a whole lot of thought to the pit mechanics, to use a really bad car analogy (don't you just hate them :-)). > > Now, my first-hand experience with academia ended when I graduated > (some would say escaped) from grad school in 1986... yeah, I'm an old > man. The CS department treated us Math/Physics geeks with a > near-complete lack of respect, but perhaps that's atypical. Don't know about maths/physics geeks, but engineers used to cop a lot in the old days... :-) (e.g. "Before I came to xxx, I couldn't even spell 'engineer'. Now I are one." You get the idea.) David
