Re: [Boston.pm] Fwd: parrot now available as a Debian package
On Fri, Nov 18, 2005 at 05:01:39PM -0500, John Macdonald wrote: However, as I recall, NT was being developed for the Alpha at one point - I think it was available commercially for a while and not just internal to MS. Not to surprising, actually, since a large chunk of the original NT design team was hired away from DEC (Dave Cutler et al). If you're interested in this kind of history, go hunt up a copy of _Showstopper_ by G. Pascal Zachary. It's a chronicle of Dave Cutler and the effort to build the first version of WinNT. It's a great read. When Cutler's team jumped ship from DEC to MSFT, they wanted to build a bolder, better version of VMS. Initially, the GUI was not a core feature, but that changed somewhat quickly. Their original spec was to target the i860, a RISC chip from Intel, and explictly avoid the i386 because it was a dain-bread CPU. Some time early in the project, the concept of HAL (the hardware abstraction layer that's still in NT and its spawn) entered into the mix, as they thought about switching RISC chips since the i860 wasn't setting any speed records, meeting any price targets or volume production projections. As the deadline got closer, the pressure to deliver on 386 grew, to the point where the 386 was the preferred platform. The original releases supported i386(+), Alpha, MIPS, and PowerPC. After a release or two, it was a foregone conclusion that NT was an x86 operating system. The exception was DEC, who sold NT on Alpha *and* x86, and was the only game in town for the three customers who wanted 64-bit NT apps, or lots of memory/disk on their NT apps. NT/Alpha slowly fell through the cracks as DEC got bought and re-bought over the years. The only Alpha customers that mattered were those running OpenVMS... i-remember-when At one point in 1994/1995, I investigated alternative hardware for NT at the time, and it was impossible to find a PowerPC box for sale that was capable of running NT. (This was the time of the Mac's grand switch from the 68040 to the PPC 601/603/620.) NEC was selling MIPS/NT boxes, while DEC was selling Alpha/NT boxes (possibly the only vendors for each architecutre, FWIR). But all of these boxes tended to be around $5K or above, right about the time when Pentium desktops were starting to sink below the $1K mark, and server x86 boxes were reasonably priced at ~$3K. Of course, it was absolutely impossible to get any comparable performance data across architectures. The MIPS boxes were expensive, and presumably nothing faster than the Pentiums of the day (probably much slower). The only reason to use Alpha was to get the 64-bit addressing. There were some demos using 64-bit NT with 64-bit databases (and a king's ransom in memory) massively outperforming pick-your-platform with 32-bit architectures. /i-remember-when Z. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
[Boston.pm] Perl Products [was: ....]
On Thu, Mar 03, 2005 at 03:20:13PM -0500, Tom Metro wrote: Adam Turoff [EMAIL PROTECTED] wrote: If Perl per se matters to you that much, then you should find some way to make it your day job. Hmmm...isn't that sort of what were talking about? If there's no job market for Perl, that's kinda hard to do. Even if you run a business where Perl is embedded, there are challenges to using it if the marketplace shows resistance to it. There are businesses and products that are built on Perl where the implementation language is not a concern. RT and Bricolage come to mind. Another model is focusing on service, rather than the deliverable. plusthree does a lot of work in perl/mod_perl, and develop an open source CMS called Krang. They deliver solutions to their market, use open source as a way of preserving value, and tangentially use Perl as a means to that end. Focusing on the small job market for Perl is a red herring. One of the benefits to Perl is that developers are more productive, so you need fewer of them. It doesn't matter that you don't get 1000 resumes for a Perl position; it _does_ matter that you can get the 2 or 5 Perl hackers you need to start a project. Sure, there's a class of problems where not having the '100% Java' seal of approval is the kiss of death. But that ignores a huge segment of the market that just doesn't care about what's inside. Z. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] (also) Perl
On Mon, Feb 28, 2005 at 10:01:32AM -0500, Greg London wrote: From a game-theory point of view, I think certification is an overall win. The worst case scenario for certification would be that gurus have to get their manager to pay for them to take the test. The worst case scenario for no certification would be that perl gets replaced with some other language that has more programmers. That is a gross oversimplification. There are oodles of ways certification is a net loss; I won't rehash them; they've been mentioned ad nauseum here and elsewhere. Would you rather go through the trouble of taking a test to keep programming in perl? Or would you rather there be no perl jobs at all? The number of perl jobs is one metric, but certainly not the only one, and definitely not the most important one. At the end of the day, all that matters is can you get the job done? There are a few variations on that theme, like ...on time?, ...on budget?, ...with X staff?, ...with X performance?, ...on X platform?, and so on. The number of Perl job openings today, during the boom, or during the bust is largely irrelevant. Java was supposed to be the programming languages to end all programming languages. It wasn't then, and it isn't now. Interestingly, the whole Java community seems to be slowly awaking from it's overcomplexification of programming, and developing lightweight systems (the kind of stuff that's natural to write with Perl). Over time, we've seen legacy systems ditched for Perl reimplementations, and Perl systems ditched for PHP, Java, C#, C, and other reimplementations. It's all cyclical. If Perl makes it easy to solve problems, it'll win. If not, it deserves a lesser status. Same as any other technology from Assembly Language to Z-machines. Z. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] (also) Perl
On Mon, Feb 28, 2005 at 02:40:10PM -0500, Greg London wrote: My worst case scenario assumed that programmers knew that perl was the best language for the job at hand. So, your analysis is limited to only those who accept that Perl is the best language for the job? Hm My point remains: if you see _one_ worst case scenario (namely that some programmers get their managers to pay for certs) then you are ignoring a good deal of the issue. There are lots of ways this whole process can negatively impact Perl as a community. I raised a few of them. There are others. Some of those points are admittedly weak. Some of the points I raised cut to the core of the issue. There are a lot of other issues (both pro- and con-) that haven't been raised in this particular thread, but have been discussed (ad nauseum) over the last ~decade. Forgive me if I didn't summarize all of them today. after chastizing me for oversimplifying on at least two occaisions, you really need to show the same level of logical accuracy that you demand of me. Fair point. Let me say my peace with this: Perl Certification is a notoriously slippery permathread. All anyone has offered to date is annecdotal evidence on one side or another, tied together with a heavy dose of rhetoric (weak, strong, or both). And, yes, I plead guilty to that myself. In all of the discussions I've seen, all of the points raised in favor of certification boil down to this: If we had Perl certification, we would get benefits X, Y and Z. The crux of the problem, is that these questions aren't getting answered: - Can we create a certification that will deliver benefits X, Y and Z? - Is certification a necessary precondition for X, Y and Z? - Aren't problems X', Y' and Z' really caused by something else, not the lack of certification? - Are X, Y and Z important? Desirable? Achievable? - Shouldn't we really be focusing on A, B and C instead? Z. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] (also) Perl
On Mon, Feb 28, 2005 at 03:01:46PM -0500, Sean Quinlan wrote: The last time Perl had an upsurge in popularity, it was because Perl solved a new class of problem better than anything else. Might I suggest that the best way to increase adoption is to learn from our past successes instead of admiring the green fields in Redmond or Santa Clara? What can we learn from our past successes that will help future success? What new problems are there that Perl might be able to be a better solution for? You mention making mod_perl easier to manage (maybe we should aim down the road a bit though at mod_parrot?) - what other areas might increase Perl's usefulness? I'll be silent on mod_perl, parrot and web stuff. When CGI took off, Perl was the first tool to grab because CGI was a text problem, and Perl is great for slinging text. The area where I see a lot of growth is in testing. I just got finished writing a column for login about writing a couple of scripts to write a few hundred thousand regression tests. (No joke.) Perl's great for that, because testing requires three basic things: - a solid test framework (Test::More) - text munging (um, tr///) - glue into everything (DBI, Mech, XML, SOAP, REST, MD5, ) And if you want to run your test suite from the web, it's not like you don't have options. :-) ob-perl-is-great I don't know about anyone else, but every time I look at macros in Lisp, the backquotes and quasiquotation really knots my brain. But in Perl, writing code that generates code is much easier to comprehend: print $test EOT; use Test::More qw(no_plan); use LWP::Simple; my \$page = get($url); is (length(\$page) 1024, Page is longer than 1K); ... EOT Let's see. Where are the variables that are expanded _now_, and where are the variables that are being dropped into the generated code? :-) /ob-perl-is-great Z. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] joke CPAN modules
On Mon, Jan 26, 2004 at 02:20:30PM -0500, Uri Guttman wrote: well, we do have Acme:: for all the joke modules. no one should be fooled by a module from that namespace. all new joke modules should go there but some want their joke to be a little more realistic and sucker people. a joke module in Acme gives that surprise away. In all fairness, there are some joke modules that aren't in Acme:: that are obviously useless and won't ever be used in a real program, even unintentionally. See, for example Semi::Semicolons http://search.cpan.org/~mschwern/Semi-Semicolons-0.03/Semicolons.pm (It helps if you read :: as colons instead of just punctuation.) Z. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
