> "Wouldn't it be cool if Superman fought Batman?"
Actually, one of the best parts of one of the best comic books *I've* ever read (The Dark Knight Returns) *is* the Superman vs. Batman fight, because Batman retained his humanity amongst the absolute worst of conditions and he defeats Superman because of that.
It was more than a fight... it was a kick in the teeth to the 80s and it's power-fixation. Batman in TDKR was a fascist of a stellar sort (much like Tyler Durden in "Fight Club"), but in the end he gave a damn, he took action, he made a difference while Superman supported a facade of a democracy.
This is more than a little scary guys. Haven't you all seen "Childs Play"? Don't you know what these dolls are capable of?
Buried within the MS archives are other, more... sinister warnings!
"Sometimes Barney plays with Daddy's gun" "Sometimes Barney watches Mommy getting dressed" "Sometimes Barney goes on a killing rampage and slaughters all the teenagers having sex in the house, because they are naughty, naughty, naughty!"
> BTW, even you can be bought. Indeed, > you most likely already have been.
Nah, I don't think so. I may have made some compromises in my life, but not on those sorts of principles. Drug test == no job for me, thank you. Not because I do massive bong hits or mountains of coke (I don't), but because it's bullshit, pure and simple. Why would I ever want to work for a moronic company that thinks a piss test proves anything? *It doesn't*. Many, many alcoholics are fine on the job, and blotto on the weekend... which is a risk if they drive, but doesn't affect their job at all, does it? Sober at work is all that the *average* employer should care about (note I say average, not the NSA, Lockheed, etc).
Baiscally, I don't need their job or want their job. I *do* have a really good job, I *don't* have to take a piss test, and I could get another (no-piss) job pretty much instantly (because I am very, very good in my field). So since I don't need to, I just plain will *not* submit to this lack of trust, Big-Brother attitude.
> Given that a large percentage of those who go > to prision return to prision.
Uh huh. And at least part of the reason is, they never get a "real" job and a path out of crime. In most cases, that's their own fault, but at least some of the time it's due to discrimination. I think a company can choose to do this... that's their decision, I guess. I just think it's a bad idea to make a blanket decision not to hire ex-felons. If everyone does that, that (duh), they *will* always be criminals!
...and felony != prison. You can be convicted of a felony and serve 30-60 days in a local jail, there are a lot of felony convictions for very minor crimes in the grand scheme of things.
> Screw that - employers have the right > to know about unlawful activities of > their (potential) employees.
No, I don't think they do. Not at all. The corporations own enough of this country, I don't want them to have any more. The law decides my guilt, innocence, and penalty. No one else.
> If you see oportunity and the only > thing between you an it is a plastic cup > and a quick check.
A little thing... and my dignity. No fsckin' way. They don't deserve to ask that of me.
If it's a sensitive military job, or something equivalent, then OK... I can see the justification. I still wouldn't submit to it, but I can see a plausible reason.
> I'd like to think that the organization > would run a criminal background > check on the employees actually handling > the information
"Past results are not an indication of future performance".
In other words, if I was a criminal in the past, does that mean I'll be one again? Or if I've never committed a crime, I will never commit one?
Come on, this means nothing! *Nothing*. I agree with what someone else posted -- pay your debt to society, then tell them to piss off. If these firms are concerned with security, let them monitor employees in some way -- clearly that is part of their business. But a background check by itself proves very little.
And drug tests? Don't get me started on those! What does my off-the-job activity have to do with my on-the-job activity? Nothing! If I light up a fat doob at work, by all means fire me... and fire those sales dudes who had a few drinks on their lunch hour with the client.
I also would never and will never work for a company that requires this. Great job? Too bad, I won't piss in a bottle or submit to my past being probed.
Why give up these rights, it's not worth any amount of money... your dignity and freedom are worth a lot more than that. I can't be bought. Can you?
We haven't found an app server we like yet. We've looked at the merits (or perceived merits) of BEA, Websphere, Enhyrda, etc... no clear winner.
Enhydra doesn't seem attractive - although it's free, it's not strong in EJB support right now (the major reason we'd even want to use an app server). Also, XMLC is a nice idea, but we have in-house solutions we like ever better (since they seem to fit the way we work best).
Zope might be worth looking at if you're still really just at the start of looking at solutions. If you've already decided to go with Java, for instance, I'm not sure if it's worth the time to look at Zope (does it handle non-PHP "stuff"?)
Right now, the best "app server" we've found is Apache + jserv (or Tomcat, it seems to work right now, and it uses Servlet API 2.2). Apache is just so configurable that it's a joy to use (and very performant). Jserv includes load-balancing and distributed computing as is (you can run as many jserv "servers" as you want, and round-robin among those; sessions are handled via session affinity, so you always get passed to the same server once a session is established).
Our big test will be soon, as we deploy this solution to our client. So far, we think we made the right choice... I think application servers (and the whole EJB technology) still need to mature more. For instance, there are plenty of indications that performance suffers using EJBs due to poor database translation layers (mapping calls to beans to calls to the database).
One interesting solution on the horizon is EJBoss along with Ozone, a pure-Java object database. This will be the next thing I evaluate after we launch this servlet project.
Actually, the article says the cost of the boxes is $73,000, much less than $365K, am I reading this wrong? The two-way boxen mentioned in the article (for $1830) sounds pretty cool by itself (I'll take one, please!).
The interesting thing is, they plan to devote serious attention to *app* porting and applying proven techniques from their RS/6000 architectures to this development. This sort of "validation" is always nice to see.
Interesting comment in the New York Times article:
"Microsoft has made it clear it will appeal whatever remedy the judge decides upon, unless Judge Jackson opts for the relatively modest changes in business procedures that Microsoft has already proposed to impose upon itself."
So, it's BiilG's way of saying "If we don't play my way, I'm taking my toys and going home!". I think Microsoft knows that if they play the waiting game, they win. The sad thing is, it seems like they have the legal means to play this game for a long time. I'm not sure how striking down an appeal could be expedited (or how it can be denied them). How long did AT&T manage to delay things (or did they? I was a youngun when the Baby Bells were born).
Hmm... Baby Bells. What will the new Microsoft BBU's (Battlin' Business Units) be called? MicroMicrosofts? Baby Bills?
This is becoming more and more common. In drug busts, you are usually taken for everything that's not nailed down. You have no rights, don't have to be guilty, and have little chance of getting your stuff back even if you beat the charge. It's called forfeiture, and it's how cops furnish their homes. I'm not joking, this actually happens. Same thing with getting busted for solicitation... your car usually gets seized.
All this in the name of "decency". It's all pretty indecent as far as I'm concerned. When are we going to realize this trickle of lost rights is turning into a flood?
Re:I scanned this book at B&N, and passed....
on
Object Oriented Perl
·
· Score: 1
No, I haven't taught a CS100 class... but I have taught several people Perl.
Of course you can do nasty things with the language... no doubt. But I think it's a silly argument (constantly presented) to bring out these cases and act like they are *how you have to program*.
You bring up some good examples. Yes, I *have* gotten bitten on at least one of those (the parameter shifting one). I learned from *that* to be more explicit, and now I always do this:
sub foo { my($a, $b) = @_; }
or (OO-style)
sub foo { my($self) = shift; my($a, $b) = @_; }
...it's just a matter of discipline, and the fact that I write to a very consistent style. Failure to do so is a problem in any language, isn't it?
...I'll agree with you, though, that Perl can more easily *hide* those sorts of errors. With More Than One Way to Do It, sometimes you run the risk of doing it the Wrong Way:-).
I've only seen like two pictures of her, but this layout looked horrible! Jesus, she looks like a tramp! I'm not saying that because she's naked, no shame in that , but she looks... fake. *Really* fake.
She sure as hell doesn't look like someone who could kick my ass at Quake, whereas the picture I saw of her in Details (?) scared me... she looked mad, bad, and dangerous as hell (I like 'em that way).
Oh well. Just another fake person, plenty of those in the world...
Re:I scanned this book at B&N, and passed....
on
Object Oriented Perl
·
· Score: 2
*shakes head*
I do not think (at this point in time) Perl syntax can be considered opaque. It certainly has plenty of strange things as a legacy of how it has grown over it's lifetime, but is this chunk of code so unclear?
use DBI::DBD;
my $dbh = DBI->connect('dbi:Oracle:', 'fooboy/foo@database');
..seems pretty easy to understand to me, once you know the basics that DBI is a database interface layer and IO::File is an object to do IO from files.
In it's basic structure and flow of control, Perl is pretty much the same (to me, at least) as it's close relatives (C, C++, Java). It lacks a lot of the complexities of those (and has plenty of it's own), but it's *not that hard* to learn!
I think, for instance, that Perl is a perfectly easy language to teach in a 100-level CS "Intro to Programming". No prior experience needed.
Re:This book revamped my Perl OO module creation
on
Object Oriented Perl
·
· Score: 1
Class::MethodMaker has been, without a doubt, the most important Perl module ever to my company. Probably even more important than the venerable CGI module (which is nice, but even the author himself seems to always want to move away from it in it's behemoth-ness and go to a set of simpler modules).
We've built entire dynamic object systems off of Class::MethodMaker (and adaptations of it's strategy of mucking with the symbol table).
The review and comments convinced me to check out the book, and I'm an old hand at OO Perl. I am constantly amazed that more people do not investigate it, because it is a very nice mix. No, it's not a "tight" OO language like Java... you shouldn't expect that. Instead, it's a nice mix of OO and procedural programming, and *you* get to pick how you want to mix things.
I would have to say, however, that almost none of my Perl programming at this point is procedural. Even simple scripts, as they grow beyond 50 lines or so, seem to adapt much better to an OO approach. I usually follow this approach:
1) If it's a big project (a web app or data import system dealing with many data sources), I immediately code it as OO, after doing some sort of object design (I've just started using UML a lot more)
2) If it's a small project (import one data file into Oracle, analyze one set of log files), I usually hack out something in straight Perl. No subroutines, just top-to-bottom code.
3) As things get more complex from #2, I will factor out subroutines inside the single script
4) If I then need to make #3 more complex (more data sources, etc.) I usually factor out even more code, create an object model, and then end up with a very short script ( 50 lines) that uses the objects to do it's dirty work.
So here, I've mixed OO and non-OO very smoothly... I find it's nice to be able to do that. I'm not sure how well Python would fit this scheme, but it might enable the same sorts of niceness... Certainly, I wouldn't be able to do this in Java, so Java isn't as compelling when the design process is very organic like this, and I might not have the time (or insight into the problem) to design an object model at the start.
What did their contract say? If they at all agreed to the (common as dirt) terms that the client owns the code, then they have no leg to stand on. If not, then the ad agency signed a very stupid contract -- you should always require rights in perpetuity to use the code as delivered. It might be different if you could be accused of developing derived works from the materials, but this is clearly what they were contracted for in the first place.
Sounds like lawyer-happy non-business people. No one with any sort of experience in contracting is going to believe they have a case by doing this, geez...
To respond to your points and offer what I've seen in my time in the trenches...
Java speed I agree, on the server side it's nicely fast. I think a lot of speed concerns with Java arise because GUI apps *are* perceptively slower. Swing seems to be a little inefficient. On the server, expect nicely fast results. With mod_perl, Perl is so close in speed that it usually doesn't matter... it may be more of a memory hog than the servlet instances, though.
OOP Java is strongly OO. Perl is not OO based, but it allows all the OO features Java does, and doesn't *restrict* you to pure OO. This may be good or bad, you decide.
Cross platform Java is cross platform (if you have a JVM and JDK for that platform). Perl is cross platform (if you have Perl compiled for that platform). Java has many servlet implementations. Perl has many persistance implementations (which are not identical, but not too far apart in how they work). [ Point to Java here (slightly)... servlets probably port easier than porting from one Perl persistance engine to another ]
Scaling I'd be hesitant to write small, one-off apps in Java. Perl is pretty good for this. Medium applications are a tie, I'd say, but my major client app I support and continue to work on is 55 KLOC in Perl and I find it quite maintainable and assign junior consultants to extend and bug-fix it all the time (so it's not just that I know the code myself).
Java is GC'ed This is nice. Perl GC is, well, not there. This is part and parcel of why mod_perl is prone to bloating at times. It seems easier to make Perl GC fail to correctly clean up than to fool Java GC...
I disagree ASP (or it's relations) are the next step after CGI. Maybe they are, but you're going to probably (IMHO) keep walking:-).
The problem is, those solutions don't give a lot of reuse (the level available varies, but from what I've seen only JSP gives you the kind of modular OO approach that *I* find gives maximum reuse and code sharing). They also intimately connect presentation and code. So now it's a lot harder to tell your graphics weenie "Hey, just code up the darn front-end using whatever obscene TABLE tags and javascript rollovers you want. Here is the data you'll be getting, stick it somewhere".
I've found that, having gone to the trouble of writing a data-driven templating system (1 1/2 times, the Java port is still in the works), the benefits of using it have let us take on more projects in less time.
Another thing to consider: does your app (and all the supporting functionality) really have to run via CGI? I alluded to this in my first couple posts (gee, I guess maybe I've hit on a topic I like to talk about;-) ); if you want to get creative, you can write a dedicated server process that handles the major points of functionality, things like:
- updating the order database - communicating with distributed objects - handling file conversion (we do this with TIFF -> GIF and TIFF -> PDF translations for a couple online systems we've written)
This system is written to be fast and to provide core services. It takes your best programmers to write it, and you test the hell out of it.
The front-end system can run anywhere, via any Web server, written in any language. So long as it can connect to the dedicated server (via URLs or a simple socket-based communications method), it can do simpler processing and the generic request/response cycle.
Your more junior people can easily handle writing the front end then -- they just use the API to the server, and handle the tasks of the presentation layer.
This means speed is less of an issue (the optimized server handles it, and can even act as a transaction processor or middleware), and the parts of the system that change most (the presentation and navigation) are easy to code and do not affect the underlying business logic.
Sometimes it helps to be creative like that, it's solved a lot of problems for us. Your dedicated server can even be as simple as something like Apache+jserv with some simple servlets that are accessed via URLs and return an XML document as a response. This also helps when you eventually want a more distributed, load-balanced system. Have too many image conversion requests? Add another dedicated box for that purpose, and made it part of a round-robin DNS scheme.
Perl is great for two other reasons: text processing in general is great (the language was built to do that as it's first design goal!), and regular expression support is first-class.
Given that most Web programming is pure text-processing work, Perl has a big leg up there. Java lacks simple text processing (it can do it, but the code is more verbose and harder to write), and C, although fast, has little text-processing built in to the standard library (other than scanf, strtok, and other functions I'd love to forget ever having learned ).
So yeah, another win for Perl. Text processing is easy to code, and fairly well optimized, given that it's the core of the language. I also find DBI/DBD easier than JDBC!
So, to reiterate, my preference is: Perl, Java, C, C++
But choose wisely! Pick something you feel competant to program in, something that addresses your needs of speed and complexity, and something that is maintainable!
As an aside, I skipped all those "code in page" paradigms: ASP, PHP, JSP. I just cannot pursue those sorts of paths, because in all my experience, the need to totally separate presentation and code is pretty strong.
"Hey, you got code in my HTML!" "Hey, you got HTML in my code!"
Not a nice mix:-). (As an alternative, we use a templating language with XHTML + XML that our code can "fill in" values in and branch around conditional text. Home grown, but very effectively for our purposes)
My comments on languages and their usefulness in Web programming (I have to make this short, but I've been doing this for a long time now, so email me if anyone has questions and wants my humble opinion)
Perl Awesome language. Great library support (stellar, really) and very easy to learn. Stick to good programming practices, avoid the dark side, and you can do a lot with it. For anything beyond trivial apps, mod_perl or a similar accelerator is definately needed. Object oriented programming is fairly nice; it allows OOP without being strictly wedded to it, and it has very powerful introspective and adaptive features (closures, ability to interrograte and modify the symbol table so you can actually *add* methods dynamically as the code runs. Wow. Allows multiple inheritence if you really need it). Database programming via DBI/DBD is very well supported.
Java Another good tool. A very nice OO syntax, strict exceptions to insure a robust system, and an architecture for using it with a Web server (Servlets). Add to that JDBC (which is well supported, and not hard to use or learn). Also add introspection and built-in RMI. I haven't used Enterprise Java Beans at all yet, but I like the concept. Implementations seem fairly weak and non-performant so far, however. I would prefer Java over Perl in cases where I needed to have a distributed system that might talk to other systems I didn't code or have ability to modify. In Java, CORBA and RMI are pretty easy to use, and EJB support will probably be well worth having in the somewhat near future. Java is a lot more inherently performant than Perl, although the difference between jserv and mod_perl is not all that huge in our tests.
Bad points of Java: the compile cycle bites once you're used to Perl (edit and run). It also is a tad too strict (again, once you're used to a more free-wheeling approach in Perl).
Tcl Phil at photo.net loves this. He uses it in AOLServer, which handles embedded Tcl (somewhat like mod_perl?). It has the same sort of benefits as Perl (no compile cycle, loose syntax and ability to do things more than one way, several libraries), but I personally never liked Tcl all that much. I wouldn't rule it out, though, check out photo.net.
C/C++ As usual, use this for maximum speed. Despite any claims people might make, Java is even in the best of cases not as fast as C. However, C is not going to be the fastest language to develop in, and since speed to market and ability to adapt are often key in Web programming, I tend to not consider C or C++ a good choice. The lack of a lot of external support or common specs hurts C and C++ -- I'm not aware of a server-independent API for "embedded" C code (like Servlets are for Java, for instance -- code that runs with the Web server persistantly or on some other persistant server). C could be great for implementing a separate server process that front-end scripts connect to from the Web server. Imagine a mod_perl front-end that connects to a server written in C -- this could be pretty fast and have a lot of flexibility.
Just throwing ideas out. Maybe this answers some part of your question??
Of course, you miss the fact that you can already know SQL (and know it quite "properly", thank you, not that I know what in the world you mean by that) and still think MySQL is quite a nice tool.
It's an RDBMS without a lot of overhead, which lets me deploy a site and leave it open to an "Oracle upgrade" at a later point.
To me, the important thing is, the system uses a RDBMS that I can access via Perl DBI and Java JDBC. Given that, porting the system should be very simple from the perspective of the application (little to no code changes).
I would suggest that if you were seriously thinking about a Digital Library project, you should familiarize yourself with the "state of the art" and what others are doing in real-world projects in this area.
I find that a lot of the work out there is very research oriented, and conducted by library science folks really, really concerned with "getting it right". It's a little *too* anal for my purposes, but you have to admit, all the 'i's are dotted and the 't's crossed.
I just wrapped up design on an object-oriented framework for a Digital Library project (modeled on my earlier work for Early English Books Online http://wwwlib.umi.com/eebo), and I found the work being done at Cornell very valuable as an inspiration. The Making of America II project is also an excellent overview of a well-thought-out Digital Library project.
So, for those interested in a little theory and practice, check these links out:
Ah, but the problem is, no one in this scenario signed any sort of contract. Certainly, no one at Circuit City signed any! Also, on the web orders (prior to this week) there was no indication of terms of service, requirement to buy the ISP, *nothing*. I ordered a piece of hardware. Now they are not selling me that hardware.
I'm getting my money back unless I see clearly that they are just blowing smoke out their ass and the units have not been changed.
My order was placed on 3/14. Their site says they are "still processing" it. I have also heard from Customer Service that my unit *will* be modded to be unhackable.
I happen to like masturbation. Anyone who doesn't is denying that pleasure is good. Why should I be ashamed of anything I do that makes me feel good and harms no one else?
"Just Say No" is what "the man" wants you to say. I refuse to let anyone else dictate to me what I'm allowed to do to myself.
Slashdot Mirror
> "Wouldn't it be cool if Superman fought Batman?"
Actually, one of the best parts of one of the best comic books *I've* ever read (The Dark Knight Returns) *is* the Superman vs. Batman fight, because Batman retained his humanity amongst the absolute worst of conditions and he defeats Superman because of that.
It was more than a fight... it was a kick in the teeth to the 80s and it's power-fixation. Batman in TDKR was a fascist of a stellar sort (much like Tyler Durden in "Fight Club"), but in the end he gave a damn, he took action, he made a difference while Superman supported a facade of a democracy.
This is more than a little scary guys. Haven't you all seen "Childs Play"? Don't you know what these dolls are capable of?
Buried within the MS archives are other, more... sinister warnings!
"Sometimes Barney plays with Daddy's gun"
"Sometimes Barney watches Mommy getting dressed"
"Sometimes Barney goes on a killing rampage and slaughters all the teenagers having sex in the house, because they are naughty, naughty, naughty!"
...consider this a warning.
> BTW, even you can be bought. Indeed,
> you most likely already have been.
Nah, I don't think so. I may have made some compromises in my life, but not on those sorts of principles. Drug test == no job for me, thank you. Not because I do massive bong hits or mountains of coke (I don't), but because it's bullshit, pure and simple. Why would I ever want to work for a moronic company that thinks a piss test proves anything? *It doesn't*. Many, many alcoholics are fine on the job, and blotto on the weekend... which is a risk if they drive, but doesn't affect their job at all, does it? Sober at work is all that the *average* employer should care about (note I say average, not the NSA, Lockheed, etc).
Baiscally, I don't need their job or want their job. I *do* have a really good job, I *don't* have to take a piss test, and I could get another (no-piss) job pretty much instantly (because I am very, very good in my field). So since I don't need to, I just plain will *not* submit to this lack of trust, Big-Brother attitude.
> Given that a large percentage of those who go
> to prision return to prision.
Uh huh. And at least part of the reason is, they never get a "real" job and a path out of crime. In most cases, that's their own fault, but at least some of the time it's due to discrimination. I think a company can choose to do this... that's their decision, I guess. I just think it's a bad idea to make a blanket decision not to hire ex-felons. If everyone does that, that (duh), they *will* always be criminals!
...and felony != prison. You can be convicted of a felony and serve 30-60 days in a local jail, there are a lot of felony convictions for very minor crimes in the grand scheme of things.
> Screw that - employers have the right
> to know about unlawful activities of
> their (potential) employees.
No, I don't think they do. Not at all. The corporations own enough of this country, I don't want them to have any more. The law decides my guilt, innocence, and penalty. No one else.
> If you see oportunity and the only
> thing between you an it is a plastic cup
> and a quick check.
A little thing... and my dignity. No fsckin' way. They don't deserve to ask that of me.
If it's a sensitive military job, or something equivalent, then OK... I can see the justification. I still wouldn't submit to it, but I can see a plausible reason.
> I'd like to think that the organization
> would run a criminal background
> check on the employees actually handling
> the information
"Past results are not an indication of future performance".
In other words, if I was a criminal in the past, does that mean I'll be one again? Or if I've never committed a crime, I will never commit one?
Come on, this means nothing! *Nothing*. I agree with what someone else posted -- pay your debt to society, then tell them to piss off. If these firms are concerned with security, let them monitor employees in some way -- clearly that is part of their business. But a background check by itself proves very little.
And drug tests? Don't get me started on those! What does my off-the-job activity have to do with my on-the-job activity? Nothing! If I light up a fat doob at work, by all means fire me... and fire those sales dudes who had a few drinks on their lunch hour with the client.
I also would never and will never work for a company that requires this. Great job? Too bad, I won't piss in a bottle or submit to my past being probed.
Why give up these rights, it's not worth any amount of money... your dignity and freedom are worth a lot more than that. I can't be bought. Can you?
We haven't found an app server we like yet. We've looked at the merits (or perceived merits) of BEA, Websphere, Enhyrda, etc... no clear winner.
Enhydra doesn't seem attractive - although it's free, it's not strong in EJB support right now (the major reason we'd even want to use an app server). Also, XMLC is a nice idea, but we have in-house solutions we like ever better (since they seem to fit the way we work best).
Zope might be worth looking at if you're still really just at the start of looking at solutions. If you've already decided to go with Java, for instance, I'm not sure if it's worth the time to look at Zope (does it handle non-PHP "stuff"?)
Right now, the best "app server" we've found is Apache + jserv (or Tomcat, it seems to work right now, and it uses Servlet API 2.2). Apache is just so configurable that it's a joy to use (and very performant). Jserv includes load-balancing and distributed computing as is (you can run as many jserv "servers" as you want, and round-robin among those; sessions are handled via session affinity, so you always get passed to the same server once a session is established).
Our big test will be soon, as we deploy this solution to our client. So far, we think we made the right choice... I think application servers (and the whole EJB technology) still need to mature more. For instance, there are plenty of indications that performance suffers using EJBs due to poor database translation layers (mapping calls to beans to calls to the database).
One interesting solution on the horizon is EJBoss along with Ozone, a pure-Java object database. This will be the next thing I evaluate after we launch this servlet project.
Actually, the article says the cost of the boxes is $73,000, much less than $365K, am I reading this wrong? The two-way boxen mentioned in the article (for $1830) sounds pretty cool by itself (I'll take one, please!).
The interesting thing is, they plan to devote serious attention to *app* porting and applying proven techniques from their RS/6000 architectures to this development. This sort of "validation" is always nice to see.
Interesting comment in the New York Times article:
"Microsoft has made it clear it will appeal whatever remedy the judge decides upon, unless Judge Jackson opts for the relatively modest changes in business procedures that Microsoft has already proposed to impose upon itself."
So, it's BiilG's way of saying "If we don't play my way, I'm taking my toys and going home!". I think Microsoft knows that if they play the waiting game, they win. The sad thing is, it seems like they have the legal means to play this game for a long time. I'm not sure how striking down an appeal could be expedited (or how it can be denied them). How long did AT&T manage to delay things (or did they? I was a youngun when the Baby Bells were born).
Hmm... Baby Bells. What will the new Microsoft BBU's (Battlin' Business Units) be called? MicroMicrosofts? Baby Bills?
This is becoming more and more common. In drug busts, you are usually taken for everything that's not nailed down. You have no rights, don't have to be guilty, and have little chance of getting your stuff back even if you beat the charge. It's called forfeiture, and it's how cops furnish their homes.
I'm not joking, this actually happens. Same thing with getting busted for solicitation... your car usually gets seized.
All this in the name of "decency". It's all pretty indecent as far as I'm concerned. When are we going to realize this trickle of lost rights is turning into a flood?
No, I haven't taught a CS100 class... but I have taught several people Perl.
:-).
Of course you can do nasty things with the language... no doubt. But I think it's a silly argument (constantly presented) to bring out these cases and act like they are *how you have to program*.
You bring up some good examples. Yes, I *have* gotten bitten on at least one of those (the parameter shifting one). I learned from *that* to be more explicit, and now I always do this:
sub foo {
my($a, $b) = @_;
}
or (OO-style)
sub foo {
my($self) = shift;
my($a, $b) = @_;
}
...it's just a matter of discipline, and the fact that I write to a very consistent style. Failure to do so is a problem in any language, isn't it?
...I'll agree with you, though, that Perl can more easily *hide* those sorts of errors. With More Than One Way to Do It, sometimes you run the risk of doing it the Wrong Way
I've only seen like two pictures of her, but this layout looked horrible! Jesus, she looks like a tramp! I'm not saying that because she's naked, no shame in that , but she looks... fake. *Really* fake.
She sure as hell doesn't look like someone who could kick my ass at Quake, whereas the picture I saw of her in Details (?) scared me... she looked mad, bad, and dangerous as hell (I like 'em that way).
Oh well. Just another fake person, plenty of those in the world...
*shakes head*
I do not think (at this point in time) Perl syntax can be considered opaque. It certainly has plenty of strange things as a legacy of how it has grown over it's lifetime, but is this chunk of code so unclear?
use DBI::DBD;
my $dbh = DBI->connect('dbi:Oracle:', 'fooboy/foo@database');
my $file = IO::File->new($inputFileName);
while($in = $file->getlines()) {
$dbh->execute($in);
}
..seems pretty easy to understand to me, once you know the basics that DBI is a database interface layer and IO::File is an object to do IO from files.
In it's basic structure and flow of control, Perl is pretty much the same (to me, at least) as it's close relatives (C, C++, Java). It lacks a lot of the complexities of those (and has plenty of it's own), but it's *not that hard* to learn!
I think, for instance, that Perl is a perfectly easy language to teach in a 100-level CS "Intro to Programming". No prior experience needed.
Class::MethodMaker has been, without a doubt, the most important Perl module ever to my company. Probably even more important than the venerable CGI module (which is nice, but even the author himself seems to always want to move away from it in it's behemoth-ness and go to a set of simpler modules).
We've built entire dynamic object systems off of Class::MethodMaker (and adaptations of it's strategy of mucking with the symbol table).
The review and comments convinced me to check out the book, and I'm an old hand at OO Perl. I am constantly amazed that more people do not investigate it, because it is a very nice mix. No, it's not a "tight" OO language like Java... you shouldn't expect that. Instead, it's a nice mix of OO and procedural programming, and *you* get to pick how you want to mix things.
I would have to say, however, that almost none of my Perl programming at this point is procedural. Even simple scripts, as they grow beyond 50 lines or so, seem to adapt much better to an OO approach. I usually follow this approach:
1) If it's a big project (a web app or data import system dealing with many data sources), I immediately code it as OO, after doing some sort of object design (I've just started using UML a lot more)
2) If it's a small project (import one data file into Oracle, analyze one set of log files), I usually hack out something in straight Perl. No subroutines, just top-to-bottom code.
3) As things get more complex from #2, I will factor out subroutines inside the single script
4) If I then need to make #3 more complex (more data sources, etc.) I usually factor out even more code, create an object model, and then end up with a very short script ( 50 lines) that uses the objects to do it's dirty work.
So here, I've mixed OO and non-OO very smoothly... I find it's nice to be able to do that. I'm not sure how well Python would fit this scheme, but it might enable the same sorts of niceness... Certainly, I wouldn't be able to do this in Java, so Java isn't as compelling when the design process is very organic like this, and I might not have the time (or insight into the problem) to design an object model at the start.
What did their contract say? If they at all agreed to the (common as dirt) terms that the client owns the code, then they have no leg to stand on. If not, then the ad agency signed a very stupid contract -- you should always require rights in perpetuity to use the code as delivered. It might be different if you could be accused of developing derived works from the materials, but this is clearly what they were contracted for in the first place.
Sounds like lawyer-happy non-business people. No one with any sort of experience in contracting is going to believe they have a case by doing this, geez...
To respond to your points and offer what I've seen in my time in the trenches...
Java speed
I agree, on the server side it's nicely fast. I think a lot of speed concerns with Java arise because GUI apps *are* perceptively slower. Swing seems to be a little inefficient. On the server, expect nicely fast results.
With mod_perl, Perl is so close in speed that it usually doesn't matter... it may be more of a memory hog than the servlet instances, though.
OOP
Java is strongly OO. Perl is not OO based, but it allows all the OO features Java does, and doesn't *restrict* you to pure OO. This may be good or bad, you decide.
Cross platform
Java is cross platform (if you have a JVM and JDK for that platform). Perl is cross platform (if you have Perl compiled for that platform). Java has many servlet implementations. Perl has many persistance implementations (which are not identical, but not too far apart in how they work).
[ Point to Java here (slightly)... servlets probably port easier than porting from one Perl persistance engine to another ]
Scaling
I'd be hesitant to write small, one-off apps in Java. Perl is pretty good for this. Medium applications are a tie, I'd say, but my major client app I support and continue to work on is 55 KLOC in Perl and I find it quite maintainable and assign junior consultants to extend and bug-fix it all the time (so it's not just that I know the code myself).
Java is GC'ed
This is nice. Perl GC is, well, not there. This is part and parcel of why mod_perl is prone to bloating at times. It seems easier to make Perl GC fail to correctly clean up than to fool Java GC...
I disagree ASP (or it's relations) are the next step after CGI. Maybe they are, but you're going to probably (IMHO) keep walking :-).
The problem is, those solutions don't give a lot of reuse (the level available varies, but from what I've seen only JSP gives you the kind of modular OO approach that *I* find gives maximum reuse and code sharing). They also intimately connect presentation and code. So now it's a lot harder to tell your graphics weenie "Hey, just code up the darn front-end using whatever obscene TABLE tags and javascript rollovers you want. Here is the data you'll be getting, stick it somewhere".
I've found that, having gone to the trouble of writing a data-driven templating system (1 1/2 times, the Java port is still in the works), the benefits of using it have let us take on more projects in less time.
Another thing to consider: does your app (and all the supporting functionality) really have to run via CGI? I alluded to this in my first couple posts (gee, I guess maybe I've hit on a topic I like to talk about ;-) ); if you want to get creative, you can write a dedicated server process that handles the major points of functionality, things like:
- updating the order database
- communicating with distributed objects
- handling file conversion (we do this with TIFF -> GIF and TIFF -> PDF translations for a couple online systems we've written)
This system is written to be fast and to provide core services. It takes your best programmers to write it, and you test the hell out of it.
The front-end system can run anywhere, via any Web server, written in any language. So long as it can connect to the dedicated server (via URLs or a simple socket-based communications method), it can do simpler processing and the generic request/response cycle.
Your more junior people can easily handle writing the front end then -- they just use the API to the server, and handle the tasks of the presentation layer.
This means speed is less of an issue (the optimized server handles it, and can even act as a transaction processor or middleware), and the parts of the system that change most (the presentation and navigation) are easy to code and do not affect the underlying business logic.
Sometimes it helps to be creative like that, it's solved a lot of problems for us. Your dedicated server can even be as simple as something like Apache+jserv with some simple servlets that are accessed via URLs and return an XML document as a response. This also helps when you eventually want a more distributed, load-balanced system. Have too many image conversion requests? Add another dedicated box for that purpose, and made it part of a round-robin DNS scheme.
Duh. Forgot some good points.
:-).
Perl is great for two other reasons: text processing in general is great (the language was built to do that as it's first design goal!), and regular expression support is first-class.
Given that most Web programming is pure text-processing work, Perl has a big leg up there. Java lacks simple text processing (it can do it, but the code is more verbose and harder to write), and C, although fast, has little text-processing built in to the standard library (other than scanf, strtok, and other functions I'd love to forget ever having learned ).
So yeah, another win for Perl. Text processing is easy to code, and fairly well optimized, given that it's the core of the language. I also find DBI/DBD easier than JDBC!
So, to reiterate, my preference is:
Perl, Java, C, C++
But choose wisely! Pick something you feel competant to program in, something that addresses your needs of speed and complexity, and something that is maintainable!
As an aside, I skipped all those "code in page" paradigms: ASP, PHP, JSP. I just cannot pursue those sorts of paths, because in all my experience, the need to totally separate presentation and code is pretty strong.
"Hey, you got code in my HTML!"
"Hey, you got HTML in my code!"
Not a nice mix
(As an alternative, we use a templating language with XHTML + XML that our code can "fill in" values in and branch around conditional text.
Home grown, but very effectively for our purposes)
My comments on languages and their usefulness in Web programming (I have to make this short, but I've been doing this for a long time now, so email me if anyone has questions and wants my humble opinion)
Perl
Awesome language. Great library support (stellar, really) and very easy to learn. Stick to good programming practices, avoid the dark side, and you can do a lot with it.
For anything beyond trivial apps, mod_perl or a similar accelerator is definately needed.
Object oriented programming is fairly nice; it allows OOP without being strictly wedded to it, and it has very powerful introspective and adaptive features (closures, ability to interrograte and modify the symbol table so you can actually *add* methods dynamically as the code runs. Wow. Allows multiple inheritence if you really need it).
Database programming via DBI/DBD is very well supported.
Java
Another good tool. A very nice OO syntax, strict exceptions to insure a robust system, and an architecture for using it with a Web server (Servlets). Add to that JDBC (which is well supported, and not hard to use or learn). Also add introspection and built-in RMI.
I haven't used Enterprise Java Beans at all yet, but I like the concept. Implementations seem fairly weak and non-performant so far, however.
I would prefer Java over Perl in cases where I needed to have a distributed system that might talk to other systems I didn't code or have ability to modify. In Java, CORBA and RMI are pretty easy to use, and EJB support will probably be well worth having in the somewhat near future.
Java is a lot more inherently performant than Perl, although the difference between jserv and mod_perl is not all that huge in our tests.
Bad points of Java: the compile cycle bites once you're used to Perl (edit and run). It also is a tad too strict (again, once you're used to a more free-wheeling approach in Perl).
Tcl
Phil at photo.net loves this. He uses it in AOLServer, which handles embedded Tcl (somewhat like mod_perl?). It has the same sort of benefits as Perl (no compile cycle, loose syntax and ability to do things more than one way, several libraries), but I personally never liked Tcl all that much. I wouldn't rule it out, though, check out photo.net.
C/C++
As usual, use this for maximum speed. Despite any claims people might make, Java is even in the best of cases not as fast as C. However, C is not going to be the fastest language to develop in, and since speed to market and ability to adapt are often key in Web programming, I tend to not consider C or C++ a good choice. The lack of a lot of external support or common specs hurts C and C++ -- I'm not aware of a server-independent API for "embedded" C code (like Servlets are for Java, for instance -- code that runs with the Web server persistantly or on some other persistant server). C could be great for implementing a separate server process that front-end scripts connect to from the Web server. Imagine a mod_perl front-end that connects to a server written in C -- this could be pretty fast and have a lot of flexibility.
Just throwing ideas out. Maybe this answers some part of your question??
Of course, you miss the fact that you can already know SQL (and know it quite "properly", thank you, not that I know what in the world you mean by that) and still think MySQL is quite a nice tool.
It's an RDBMS without a lot of overhead, which lets me deploy a site and leave it open to an "Oracle upgrade" at a later point.
To me, the important thing is, the system uses a RDBMS that I can access via Perl DBI and Java JDBC. Given that, porting the system should be very simple from the perspective of the application (little to no code changes).
I would suggest that if you were seriously thinking about a Digital Library project, you should familiarize yourself with the "state of the art" and what others are doing in real-world projects in this area.
I find that a lot of the work out there is very research oriented, and conducted by library science folks really, really concerned with "getting it right". It's a little *too* anal for my purposes, but you have to admit, all the 'i's are dotted and the 't's crossed.
I just wrapped up design on an object-oriented framework for a Digital Library project (modeled on my earlier work for Early English Books Online http://wwwlib.umi.com/eebo), and I found the work being done at Cornell very valuable as an inspiration. The Making of America II project is also an excellent overview of a well-thought-out Digital Library project.
So, for those interested in a little theory and practice, check these links out:
Digital Library Links and Resources:
http://www.ifla.org/II/diglib.htm
Cornell Digital Library Research Group
http://www.cs.cornell.edu/cdlrg/
Making of America II
http://sunsite.berkeley.edu/MOA2/
FEDORA (an architecture for information storage and retrieval, *very* nice).
http://www.cs.cornell.edu/cdlrg/FEDORA. html
Ah, but the problem is, no one in this scenario signed any sort of contract. Certainly, no one at Circuit City signed any! Also, on the web orders (prior to this week) there was no indication of terms of service, requirement to buy the ISP, *nothing*. I ordered a piece of hardware. Now they are not selling me that hardware.
I'm getting my money back unless I see clearly that they are just blowing smoke out their ass and the units have not been changed.
My order was placed on 3/14. Their site says they are "still processing" it. I have also heard from Customer Service that my unit *will* be modded to be unhackable.
I'm pretty pissed, to say the least.
I happen to like masturbation. Anyone who doesn't is denying that pleasure is good. Why should I be ashamed of anything I do that makes me feel good and harms no one else?
"Just Say No" is what "the man" wants you to say. I refuse to let anyone else dictate to me what I'm allowed to do to myself.