a certain person discovered they were a cylon and ultimately confessed it to Adama.
Only when the situation became dire enough. Which I actually thought was a pretty decent part of the show. However, before he did that he managed to get a six pregnant and all but give away the fact that he was a cylon. Furthermore, why did he give away the others? I was waiting for him to turn himself in (seemed like the situation was going to force it sooner or later), but I saw no reason why he'd need to reveal the identity of everyone else.
you are arguing about human nature - for which there are no cut and dried rules
Certainly. However, there's one thing that's certain. In any human population, traits will be far more varied than we see in BSG. While their personalities are different, their approaches to handling tough situations seem to be almost universal. Given the opportunity, nearly every person on the show makes the wrong decision. That's simply not realistic.
It is just as reasonable to say that he chose to gamble that he would never be found out, considering just how few surviors there were AND just how few political survivors there were (wasn't roselyn like 47th in line for the presidency?) it seems like a plenty reasonable gamble to me.
And yet he was found out. And STILL didn't start controlling information. When a six shows up and says that you sabotaged the colonies, it's probably a pretty damn good time to say, "She's a cylon!" Not only will it help get you out of conviction, but it will give you a nice out for future recriminations. (Like what happened with Roslyn later on.) Sure, he'd take a hit in the public eye, but he knew that Adama and the President needed him. That meant that he could have rebuilt after such a setback. Instead he rots in a cell and waits for a sentence of execution, all while the power of his trump card wanes.
Of course, you might say "well, that's a stupid idea." But consider how it would have played out for a moment. You don't just jump up and accuse someone at the table. He would have pulled Adama aside and told him that he watched this lady die during the attack on Cobol. Which can only mean that she's actually a cylon and thus must be the spy that sabotaged the defense computers. At best, it's his word against hers. They would have both been thrown in detention, and the falsified evidence would have eventually come to light. Baltar would now be blame free, and Adama would have a Cylon captive. Win-win for Baltar.
Instead, the show played up various metaphysical questions to no real purpose. I can tell you that if I'm on death row, worrying about the metaphysical meaning of my navel is not my first concern. I'd swing back to reality and start playing on the trust relationships I'd developed (however thin) until I can find a solution in my favor. Especially in a situation where the opponent has such a weak hand. (i.e. She's definitely a Cylon AND Baltar knows that her evidence is falsified.)
Baltar displays this sort of political acumen elsewhere in the series. Why did he fail so badly in this situation? He didn't even try. That's what really blows my mind.
The closest they came to tackling moral quandries was Picard looking distressed for his "I'm going to ignore the prime directive" monologues.
You do realize that TOS was under heavy fire from the CBS news agency because of their sci-fi commentary on the Vietnam war?
Star Trek asked all kinds of questions. Do we have a right to arm the locals to fight back against Klingon oppression? Should we fight the Klingons for having turned a peaceful people into pawns in their war? Does Kirk have the right to take vengeance on a dictator who is repentant of his ways? Do we have a right to kill off the indigenous population so that we can mine the materials we need? Would you kill someone you love if it meant saving billions of people and making the future a better place? Is it acceptable for mixed races to fall in love?
Star Trek was very much the BSG of its day. It asked all the hard questions that were on people's minds at the time. The difference is that it didn't let the abyss stare back at you. It exposed these problems as an agent of change rather than suggesting helplessness.
The Next Generation did continue the tradition with many hard questions. (e.g. Who Watches the Watchers, The Survivors, The Host, The Outcast, The High Ground, etc.) However, the questions were framed in the softer, more tolerant culture of the time. Now we're coming back around to hard questions which BSG raises. But the show does nothing to look those questions in the eye. It simply treats them as there and moves on. Nothing more, nothing less.
Yeah, that's called "realism." People in real life often rarely grow sufficiently large backbones to "do the right thing" either, particularly when they're threatened and running for their lives.
Sorry, I don't buy it. I watch the show and think of analogous situations in my own life. Humans are social creatures, many of whom have trouble with secrets. Somebody tends to speak up in nearly any situation. Whether anyone listens to them or not is another matter, but very few secrets are maintained. Yet everyone in BSG has the necessary personality traits to keep even the smallest of secrets. That's realistic?
Like frak'n hell!:-P
And, as for secrets, is there any one of us who doesn't carry a TON of those around with them?
I think you're confusing secrets kept for privacy reasons with the types of secrets kept in BSG. My work is not secret. If I screw up on the job, trying to keep that a secret is eventually going to bite me in the ass. Instead, if I screw up, it's important to admit that I screwed up so that I can control the potential recrimination. If the environment is so poor that mistakes are overreacted to, then it's time to get out of that environment because it isn't going to be lasting much longer.
Same with the example of Baltar's situation. He screwed up, but he didn't screw up badly. By withholding the information, he managed to ensure his recrimination at a later date. Someone like the character portrayed on the series is smarter than that. He would have talked it up from the get-go, releasing bits and pieces in a favorable light. Then when Roselin "remembered" him being with the six, no one (including Roselin) would have been able to find personal fault there. Particularly not without finding fault with themselves for working alongside the likes of Sharon.
Do you wake up every day and tell your wife that she's become a fat, bitter shrew and that you don't want to be married to her anymore because you want to go find a cute younger woman who isn't a fat, bitter shrew? Do you tell your kids that you're disappointed that they're not as smart or handsome as you'd hoped they'd be? Do you tell your boss he's a fucking idiot and that you think you could do a better job than him? Do you tell you mother that you don't want to visit her or call her because you're too different from her now to have anything to talk about? Do you tell yourself that you're not the hero of the story, just another loser in a world full of losers?
This honestly comes across more like you've got personal problems than secrets. And in the real world, the types of people who hold these opinions very often voice them very loudly. After all, a divorce is the ideal outcome in the first situation, obviously you feel your kids should be doing something different in the second situation (so why NOT tell them?), the fourth suggests you're trying to cut off communications with your family anyway (even if you don't say it, you'll say it without saying it), and the last is just a plain bizarre example. (Depression maybe?)
As for the third example, this one is the closest to the truth. Except that we generally don't say anything out of politeness and fear for our jobs. That doesn't mean that we don't still make it clear as a bell. Human communication isn't always done with words.
I think you fail to understand.Net, and why this is actually a good thing
I've been doing servlet code for over a decade. I can still take the code from one of those old applications and make it run in a modern J2EE server. No changes necessary.
The fact that Microsoft needed to make such radical changes after only a single release suggests that they have a problem with their engineering. No other server-side technology changes so radically between versions.
Being able to run original ASP alongside ASP.NET I can understand. Needing to run ASP.NET 1.x alongside 2.0 I don't. That's just bad engineering.
As for DLL hell, that's another problem with Microsoft's engineering. Microsoft likes to make libraries global. That's a bad idea for this very reason. J2EE apps bundle libraries inside the web application. So even if you have one app that requires an incompatible version of a lib, it won't impact another app running on the same server. Only if and when an API is stable and mature does it get moved up to a global level. And Sun takes the approach of getting input from the entire industry before making such a commitment. Thus you may or may not like an API, but a given API is not going to remove support for previous versions.
Microsoft takes the approach of imposing their will on the industry rather than asking for their opinion. You don't like Microsoft's API options? Don't worry, we'll impose a new and incompatible one next week.:-/
I have to agree. One of the more frustrating aspects of the show is that the characters very rarely grow a sufficiently large backbone to Do the Right Thing(TM). And then it's pretty much only because they're forced to do so. Using a corporate environment as an analog, my company would have bitten the dust long ago if every employee kept secrets like they do in BSG. The fact that the Cylons didn't manage to wipe them out in the first season is purely an artifact of it being fiction.
Of course, there are plenty of situations where the secrets would be justified. e.g. If you know you're a cylon, do you really want to expose that amongst a ship full of cylon-haters? But some of the stuff is just plain ridiculous. Take Baltar as an example. By keeping his involvement with the destruction of the colonies a secret, he's basically accepting responsibility for his actions. Yet his character never accepts responsibility for his actions! A real individual like that would have carefully controlled the release of that information, being careful to spin it as something out of his control. Blame the cylons. Blame the dead government. Blame everybody, but make sure that it's not something that can come back and bite you in the ass.
I still like many aspects of the show, but the characterizations just get weird sometimes. And as you said, they end up blowing by the moral quandaries rather than taking the Star Trek approach of tackling them head-on.
I can't think of any nice way to put this, so I'll just go with you fail it.
Don't you get tired of typing.NET after everything? That's as obnoxious of a marketing scheme as putting "Sun Java" before every name.
ASP.NET is not a "scriptlet-type technology", not any more so than JSF is - in fact, much like JSF, it's component-oriented.
Scriptlet technology is a core part of ASP.NET whether you like to admit it or not. Ideally it should not be used, but it is there. And JSF is an awful technology. Comparing ASP.NET to JSF is a mark against the ASP platform.
And in any case, the analog to ASP controls and data binding is taglibs like JSTL. (Exactly like I said in my original post.) Except in JSP you have a choice. You can use an alternative lib to JSTL or even create your own. The JSTL package is pretty powerful though, so there's little need to swap it out.
The correct (no quotes needed) way to write ASP.NET markup is to use components and data binding.
Yes, the whole "runat=server" thing I was just lamenting. Worst idea ever. It works great for basic websites, but it does. not. scale. I managed to at least figure out a way to evaluate tag names dynamically so that I could loop through a collection of tags. The ASP.NET programmer I inherited the project from was so impressed he said he'd make that a standard part of his toolkit. Just peachy.
As for the control options, they get really limiting really fast. Microsoft is the master at making the simple things stupidly easy. This gives the impression of power. But it fades very quickly when you try to scale the solution up or do anything that's outside the realm of "normal" usage. That's where the power to develop and deploy your own unified solutions comes in handy.
And don't even get me started on the amazing lack of a servlet analog. HTTPHandlers/HTTPModules are a poor excuse for an alternative, and tend to be divorced from the rest of the application. (Microsoft's take: Cohesive whole? What's that and why would you want it?) Oh and deployment. Oh the pain, the pain! Why oh why do I have to configure every little piece? Complain about J2EE all you want, but deployment is incredible.
I'm not sure what's wrong with a website running IIS, either.
Nothing. As long as you want a webserver. If you want a full blown application server, things fall apart quickly. Did I mention the deployment and cohesion issues? I'm not sure if these can be overstated. Application server functionality is a bolt-on module to IIS. At its core, it's really just a web server like Apache. J2EE is the opposite philosophy. It's an application server first with standard web server functionality hosted as one of the many applications running in the application space.
The end result is that easy things in J2EE take a bit more work, but the hard things are brain-dead simple. (e.g. dynamically interpreting URLs) Meanwhile, easy things are made even easier in IIS, but the hard things become convoluted and incredibly difficult.
Last time I checked, the NetCraft top10 uptime list had quite a few of those, which means that they do work.
FWIW, uptime measures uptime. Nothing more, nothing less. The top sites for uptime tend to be the ones with the most static content. The more dynamic your content is, the harder it is to maintain both the application and the uptime on a per-machine basis. (Case in point: The top 2 sites on Netcraft's list are a porn site and a site for a pasta product.) That's okay though. Clustering and fail-over features exist for that very reason. If you need to take a server down, your availability does not go away. And at the end of the day, that's a lot more important than your uptime numbers.
Can you recommend any good beginner references to get started with J2EE stuff?
FWIW, you should probably start with Glassfish (aka Sun Java System Application Server) and Netbeans. That combination is extremely smooth for J2EE development and will have you up and running in no time flat. (Plus it's all open source.;-)) Just visit Netbeans.org and grab the full version or the version with Glassfish bundled.
Once you get it setup, you can configure features like the JDBC connections through the admin console on http://localhost:4848. The default user/pass is admin/adminadmin.
You can then review the official tutorial here. It covers the concepts pretty well. Truth be told, though, you can skip most of the details for now and jump straight to servlets. Servlets are Java objects that respond to network requests. HTTPServlets thus have methods like doGet, doPost, doPut, etc. All you have to do is read in the parameters passed and write out to the output stream. Due to their relative simplicity, the JavaDocs tend to be the best reference for programming servlets:
(Don't be fooled, though. Simple ideas are some of the most powerful.)
The one part that's not covered by the JavaDocs is the deployment. You will need to understand the web.xml file for mapping servlets to URIs. Thankfully, Netbeans has some GUI tools that can help you understand the format and how it works. Advanced servlet development can have a whole chain of cool stuff like classes that intercept requests before and after the servlet runs (filters) and event listeners on session creation and destruction.
Once you understand servlets, then you can move on to JSP pages. At their simplest, JSP pages are HTML with code that get compiled internally by the server into servlets that print out the HTML. (Take a look at the generated code sometime to understand JSPs inside and out.) Modern JSPs should be written with taglibs. Taglibs basically work off the page attributes collection. Rather than working with solid page variables, entries are created inside the hashtable used to store page attributes. (These are attributes that exist only for the period of the request.) The standard pattern for these is that you execute a tag to retrieve a collection of information, then you use tags to output and/or loop through the values.
Servlets and JSPs can be chained by using the RequestDispatcher.include and forward methods. This allows you to not only include one page inside another, but you can also use the page attributes to forward data around. e.g. Let's say you have a servlet that reads from the database in response to a user's input. It can then dump the results into an attribute and call off to a JSP for rendering of that data.
Once you get that stuff down, you can start looking into the other features of J2EE. The JNDI directory is a wonderful way to handle connection pools. Don't put your connection information in your pages! Let the J2EE server manage the pools through the directories. This will make your application more adaptable. JMX allows you to wire up all kinds of meta-data about your app in the same way that SNMP is used to manage network devices. The authentication system can be used to automatically restrict resources without having to write protection code into your application. Java messaging can be used to send messages between systems. JavaMail is obvious. Support for SOAP/XML-RPC/REST and other features are built into the server and are easy to use. EJBs are best ignored unless you're developing a compute engine. (If you don't know what that is, all the more reason to ignore EJBs.) Java Server Faces should be avoided at all costs.
While that just barely scratches the surface of J2EE power and scalability, hopefully it will be enough to get you started.:-)
The PNG hack for IE6 has some rather fatal drawbacks, particularly if you want to use it to replace background images instead of just regular s.
Fair enough. On the sites I used pngfix, I haven't run into these issues. Of course, these days I've started "firing" customers who use IE at all. Hobby sites are tons of fun that way. Wish I could do that at my day job.;-)
PNG8 is an interesting aside, but only marginally better than just serving GIFs to IE6.
FWIW, everything in the article is about marginal improvements. There's no huge bang to be had out of any of the article's suggestions, save for the fact that they'll save significant bandwidth and server resources given the massive number of visitors the site is probably seeing at the moment.
First hit on Google. Remember to search only the "X-Aspnet-Version" (remove the quotes) part of that text. BTW, as efficiencies go, this is a pretty minor one. It matters for a site like whitehouse.gov because they're likely to get a few million visits per day. (At least in the short term.) Very few websites have that problem, so I wouldn't worry too much about it.:-)
That "gobbldy-gook" generates valid XHTML, if you tell it to.
So does every other page templating technology known to man. I can do it in ColdFusion if you ask me to. That doesn't make ColdFusion a particularly good language for scalable site development. Nor does it make ASP.NET anything special. And if I never see more code like this, it will be too soon:
Bwahaha... sorry. There are better templating engines than ASP.NET 2.0, but JSP is not one of them - not in a million years.
Because ASP.NET can output XHTML code? Listen, I've looked at nearly every template language and framework on the market. 90% of them result in coding one's self into a corner. JSP may be simple, but that's it's strength, not its weakness. Especially when you break up your JSP code into smaller pieces and use a higher level abstraction at the servlet level to produce more maintainable code.
I was there when the first version of Tapestry was introduced the internet. It was an interesting idea, but it took quite a few revisions to make it into something useful. Today it's an alternative to JSPs for rendering, but it by no means retires the use of JSPs. Same with Velocity and Wicket. And if you try to introduce me to Spring as if it's the latest and greatest thing (rather than a technology that's been around since the turn of the century), I will have to smack you.;-)
Of course, all of this just points to the flexibility of the J2EE platform. (Primarily the servlet layer, but using a full J2EE implementation has a variety of pleasant advantages.) Which is why I feel like getting a lobotomy every time I have to work with ASP.NET 2.0 code. It's like going from a Cadillac to a Power Wheels. (Pow-pow-power wheeeeeelsss...)
JSP is no better than classic ASP; it's arguably quite a bit worse than classic ASP since it isn't language agnostic.
Language agnostic is pointless when you're not writing code. Correctly written JSP 2.0 files should have no scriptlets in the pages. All the code should be in behind-the-scenes APIs or in parent servlets that use the page for rendering. The JSP solution is far more flexible than the ASP page-backing code files solution, and generally encourages better written code. Looking at ASP.NET pages that reference tags by IDs makes me want to tear my hair out in frustration. ("NO! You do NOT make six instances of the same tag so you can populate them in the page-backing code file! Arrrgghhh!!!")
On a broader note,.NET's language agnosticism is a farce. You can have any color you want (slate, charcoal, basalt, jet, etc.) as long as it's black. There are no real differences between the languages. They have all been modified to fit the C# mold.
JSP is a defunct and outstandingly annoying technology to work with that encourages all sorts of bad habits.
Whatever helps you make it through the day. I've worked with ASP.NET long enough to know that a bit of reality disconnect makes the pain a little more bearable.;-)
And don't forget you can't easily do transparent PNG's until IE6 is finally flushed out of our system
Put pngfix.js in an IE conditional tag if it bothers you. I refuse to stop the progress train because of Microsoft's ill-gotten monopoly.
If they were using ASP.NET MVC you wouldn't have even known the thing was running ASP.NET.
I confess, I haven't used ASP.NET 3.5/MVC yet. It would have been handy back when I inherited an ASP.NET project. Unfortunately, after my poor experiences with ASP.NET's scalability (or lack thereof), I'm not really inclined to develop another site in ASP.
As a former President once mumbled, "Fool me once, shame on you. Fool me twice... you ain't gonna fool me again.":-P
Did I say anything to suggest otherwise? As of right now, ASP.NET is ASP. Pointing out that they are different is like pointing out that Windows 95 != Windows XP when someone criticizes "Windows". Especially when "ASP.NET 2.0" is clearly spelled out in my post.
Now if you want to hear me complain about the inanity of ASP.NET 2.0 and 1.x being incompatible with each other, thus necessitating the need for both engines to run alongside each other in support of legacy modules, just keep it up.;-)
The whitespace.gov site has lots of whitespace characters.
Hmm... Freudian slip? FWIW, most of the whitespace is probably generated by the ASP technology they used. Spots where code goes can often generate unexpected whitespace. It's just a side effect of using scriptlet-type technologies.
Don't get me started on the "correct" way to write ASP. The tag-substitution gobbldy-gook encourages all kinds of bad page-development practices. The request-time attributes + templating taglibs seen in JSP provide a much cleaner separation between logic and HTML.
The whitehouse.gov site uses more GIFs than PNGs.
Ouch. Welcome back to 1996. Web developers looking for the smallest file size really need to learn that there is such a thing as palletized PNGs. They're even smaller than GIFs, even.
The whitehouse.gov site uses heavy JPG compression.
This is one place where my reaction is "BFD". As long as it looks acceptable under most circumstances, the people with the carefully color calibrated monitors (*cough*yeslikeme*cough*) can suffer a bit. Heck, half the JPGs on the internet look like garbage, so I'm not too worried about artifacting in the gradients.
The whitehouse.gov site uses IIS 6.0. The whitehouse.gov site uses ASP.NET 2.0.
Can we choose the right technologies for a website? No we can't! Thankfully, the President isn't hired to choose the best technology to run his website.;-)
I have a rather conflicted view on JS2. There are a lot of aspects I like about it, yet I understand the various arguments against it. I think both sides have a lot of merit in their arguments and should be heard out. Perhaps most telling is that the only widely-deployed implementation of JS2 (ActionScript 2.x) actually compiles its code down to JS1 code. (Do a decompile of a Flash 8 movie sometime and you'll see what I'm talking about.)
More to the point, most of the features offered by AS2 can be accomplished in AS1 or require a compiler to be effective additions. In result, I think the market's current solution is the best solution. Which is for complex projects to use a JS2 compiler as an intermediary step for type checking and object translation. The end results will operate and interface correctly in the browser, but the abstractions will be a bit more familiar to traditional programmers.
Of course, the implication is that large-scale projects CAN be done in JS1. And I'm going to voice that opinion right now. (e.g. See Pixtastic for a well-architected and scalable application.) The catch-22 is that JS development leaves more power in the hands of the developer. This forces the developer to decide on the best organization for his project.
Unfortunately, leaving more power in the hands of developers can be disastrous for programmers with insufficient seniority. They create a huge mess, then they curse the language for its apparent failures. Languages like Java force them to think a particular way about project organization, so why should Javascript leave so many options open?
These are the people for which JS2 is a very good idea. JS2 promotes good development practices without completely removing the underlying power that makes Javascript such a great language to work with. Thus my opinion on why the market will choose JS2 compiled to JS1 in the same way that C++ is a powerful object system on top of C. (Though a little less hokey in practice.;-))
Is there something wrong with "MyObject.prototype.mymethod = function() {};"? Or are you referring to the fact that a function can always be reapplied to a different object context? This is actually a feature, not a bug. It makes functions highly portable across your code. Yes, this means that passing a function as a parameter can create some issues, but that is what closures are for. Rather than creating entire objects to implement interfaces, you can create a very [i]private[/i] communication channel at any time with a closure. Doing this in a structured language like Java is a pain and a half and generally leads to the practice of exposed, but undocumented APIs.
Ever wondered where why your this in your function suddenly is something else?
Not since I understood Javascript scoping. Once that was done, my issues with what "this" is disappeared.
No scopes of visibility
This is a myth. A popular myth, but a myth none the less. Javascript works by implicit visibility rather than explicit visibility. Thus:
function MyObject() { var value = 0;/*private*/ this.pubvalue = 0;//public
this.getValue = function() { return value; };
this.setValue = function(newValue) { value = newValue; }; }
But I don't recommend it. Usually you want to reduce your footprint to as little as possible. Zero is ideal. e.g.:
(function() {
var myvar;
function myFunction() {}
alert("I can put code here willy-nilly and it will never impact the parent context unless I specify. Weee!"); })();
Unless you need to share out public APIs:
var MyAPI = (function() {
function myFunc() {}; //Create a proxy object to expose only the public parts of this inner sanctuary.
return {myFunc: myFunc}; })();
If I were to sum up your complaints (and those of 95%+ of people programming Javascript) I would do it like this: You're trying to write C-Style code in a LISP-style language. Stop it. Things get better after that.:-P
Go watch this video series: http://video.yahoo.com/watch/111593/1710507 I guarantee you'll have a few "aha!" moments. Especially when it comes to scoping. Once you understand how to make JS scoping work for you rather than against you, life gets a lot easier.
The following text is garbage to make Slashdot's stupid filters happy. Ignore it. Apologi
Unless you can come up with a thoroughly researched and peer-reviewed paper which accounts for all the more recent approaches to static type checking (like typeful programming, dependent types, etc.) supporting this, I'd say you were full of shit.
I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code. The unfortunate result is that developing for a statically-typed vs. dynamically-typed language makes little difference to this process.
That being said, there are some advantages to a statically-typed language. e.g. There are no untested code segments with typing errors waiting to blow up. The code may blow up for other reasons, but typing won't be one of them. (Unless you force a cast, that is. Casted objects can blow up quite nicely.)
The other area where it's a good idea is when your code will share out or access a standard interface outside your project. In such cases, typing can create a contract that ensures the correct use of all APIs.
That's why I suggested the use of a JS2.0 compiler for times when typing is important. JS2.0 is a softly typed language. Typing can be defined to ensure correctness, but typing is not required. This allows for interfaces and APIs to be exposed properly while leaving the individual developer a free hand to design his code in a classless fashion.
I'm not going to write an entire dissertation on this, so see Bruce Eckel's excellent article on this issue for a decent introduction to the compile-time checking issue.
Besides, JavaScript gets what is arguably the most important feature of any language, namely scoping, completely and utterly wrong.
You've just pointed a finger at the very thing Javascript gets absolutely correct. While the scoping system may seem weird and even incorrect to coders with experience in other C-style languages, the Javascript scoping system is what welds the OOP aspects of the language together with the functional aspects of the language. If you changed the scoping system, you'd completely destroy Javascript's object system in addition to gimping its functional aspects. Which would leave you with the just the crappy procedural code that your average web developer creates for neat webpage effects.
It would be more accurate to say it's object-oriented, except that implies OOP, which it isn't.
I think you're confusing "class based" with "object oriented". Javascript is very much an Object Oriented language. Otherwise, how would this code work?
(You can save yourself the trouble of creating an HTML file by using this page to test it.)
Prototype-based OOP can do almost everything Class-based OOP can do, except that it is far more flexible at runtime. You lose some compile-time checking, but it's been found that strict compile-time checking doesn't offer nearly as much error-catching benefit as was originally envisioned.
If you're absolutely in love with compile-time checking, consider a Javascript 2.0/ECMAScript 4.0 compiler. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.
It's pretty easy to leak memory without meaning to by creating a closure you didn't want.
Generally speaking, that's a problem with Internet Explorer. (That took them FOREVER to fix.) You can still leak memory by foolishly creating closures all over creation, but for the most part it's pretty difficult to leak memory on accident. At least, no more or less difficult than it is with your average OOP language.
Javascript is just one more language, but it's a VERY popular language and a hell of a lot more people know it and use it then C# or GNU-C or anything else.
While the language is VERY popular, I disagree that a "hell of a lot more people know it" than most other GNU languages. The vast majority of coders have no idea how to correctly write Javascript. In fact, you can't even say that Javascript is an Object Oriented, LISP-like functional language on Slashdot (of all places) without ten or twelve people trying to tell you you're wrong.
Which sucks. Because Javascript is an AWESOME language. Plus the modern VMs (as opposed to the last-generation interpreters) are getting quite fast. Fast enough to use JS for anything short of compute-intensive applications. Even professional video games could use it as a scripting language with the right underlying APIs. (See my sig for how far it's come with Web games.)
My hope is that as Javascript shows up in more places, developers will take the time to sit down and truly understand the language. And maybe we can even get a few books on the market that don't suck.;-)
Java software is portable and generally a hell of a lot less painful to setup and configure. (Which I guarantee from experience, Apache DS is much smoother than SJDS.) Believe it or not, there's a hell of a lot of advantages to having your server software written in Java.
If you have a bias against Java, you might want to check it at the door pronto. You're cutting yourself off from some of the best server-side software in the industry.
*shrug* It works. The admin interface is a little wonky at times, but otherwise nice. Adding LDAP fields is a pain in a half, though. You have to modify the schema file directly and restart the directory server. Not exactly user-friendly.
Personally, I've been keeping my eye on Apache Directory Server. It's modern, it's Java-based, it's easy to setup, it's open source, and it's made by Apache. What more could you want?;-)
That's exactly what I mean. We've put up with really bad marketing from Sun for too long. So bad that if it were a movie, it would be one of those Lion Gate direct-to-DVD films that is so bad it first wraps around to good, then keeps going to wrap around to "worse than the most horrible atrocity ever committed by Hollywood".
I say we storm Sun and take over the headquarters. Viva la Revolución!:-P
Slashdot Mirror
Only when the situation became dire enough. Which I actually thought was a pretty decent part of the show. However, before he did that he managed to get a six pregnant and all but give away the fact that he was a cylon. Furthermore, why did he give away the others? I was waiting for him to turn himself in (seemed like the situation was going to force it sooner or later), but I saw no reason why he'd need to reveal the identity of everyone else.
Certainly. However, there's one thing that's certain. In any human population, traits will be far more varied than we see in BSG. While their personalities are different, their approaches to handling tough situations seem to be almost universal. Given the opportunity, nearly every person on the show makes the wrong decision. That's simply not realistic.
And yet he was found out. And STILL didn't start controlling information. When a six shows up and says that you sabotaged the colonies, it's probably a pretty damn good time to say, "She's a cylon!" Not only will it help get you out of conviction, but it will give you a nice out for future recriminations. (Like what happened with Roslyn later on.) Sure, he'd take a hit in the public eye, but he knew that Adama and the President needed him. That meant that he could have rebuilt after such a setback. Instead he rots in a cell and waits for a sentence of execution, all while the power of his trump card wanes.
Of course, you might say "well, that's a stupid idea." But consider how it would have played out for a moment. You don't just jump up and accuse someone at the table. He would have pulled Adama aside and told him that he watched this lady die during the attack on Cobol. Which can only mean that she's actually a cylon and thus must be the spy that sabotaged the defense computers. At best, it's his word against hers. They would have both been thrown in detention, and the falsified evidence would have eventually come to light. Baltar would now be blame free, and Adama would have a Cylon captive. Win-win for Baltar.
Instead, the show played up various metaphysical questions to no real purpose. I can tell you that if I'm on death row, worrying about the metaphysical meaning of my navel is not my first concern. I'd swing back to reality and start playing on the trust relationships I'd developed (however thin) until I can find a solution in my favor. Especially in a situation where the opponent has such a weak hand. (i.e. She's definitely a Cylon AND Baltar knows that her evidence is falsified.)
Baltar displays this sort of political acumen elsewhere in the series. Why did he fail so badly in this situation? He didn't even try. That's what really blows my mind.
You do realize that TOS was under heavy fire from the CBS news agency because of their sci-fi commentary on the Vietnam war?
Star Trek asked all kinds of questions. Do we have a right to arm the locals to fight back against Klingon oppression? Should we fight the Klingons for having turned a peaceful people into pawns in their war? Does Kirk have the right to take vengeance on a dictator who is repentant of his ways? Do we have a right to kill off the indigenous population so that we can mine the materials we need? Would you kill someone you love if it meant saving billions of people and making the future a better place? Is it acceptable for mixed races to fall in love?
Star Trek was very much the BSG of its day. It asked all the hard questions that were on people's minds at the time. The difference is that it didn't let the abyss stare back at you. It exposed these problems as an agent of change rather than suggesting helplessness.
The Next Generation did continue the tradition with many hard questions. (e.g. Who Watches the Watchers, The Survivors, The Host, The Outcast, The High Ground, etc.) However, the questions were framed in the softer, more tolerant culture of the time. Now we're coming back around to hard questions which BSG raises. But the show does nothing to look those questions in the eye. It simply treats them as there and moves on. Nothing more, nothing less.
Sorry, I don't buy it. I watch the show and think of analogous situations in my own life. Humans are social creatures, many of whom have trouble with secrets. Somebody tends to speak up in nearly any situation. Whether anyone listens to them or not is another matter, but very few secrets are maintained. Yet everyone in BSG has the necessary personality traits to keep even the smallest of secrets. That's realistic?
Like frak'n hell! :-P
I think you're confusing secrets kept for privacy reasons with the types of secrets kept in BSG. My work is not secret. If I screw up on the job, trying to keep that a secret is eventually going to bite me in the ass. Instead, if I screw up, it's important to admit that I screwed up so that I can control the potential recrimination. If the environment is so poor that mistakes are overreacted to, then it's time to get out of that environment because it isn't going to be lasting much longer.
Same with the example of Baltar's situation. He screwed up, but he didn't screw up badly. By withholding the information, he managed to ensure his recrimination at a later date. Someone like the character portrayed on the series is smarter than that. He would have talked it up from the get-go, releasing bits and pieces in a favorable light. Then when Roselin "remembered" him being with the six, no one (including Roselin) would have been able to find personal fault there. Particularly not without finding fault with themselves for working alongside the likes of Sharon.
This honestly comes across more like you've got personal problems than secrets. And in the real world, the types of people who hold these opinions very often voice them very loudly. After all, a divorce is the ideal outcome in the first situation, obviously you feel your kids should be doing something different in the second situation (so why NOT tell them?), the fourth suggests you're trying to cut off communications with your family anyway (even if you don't say it, you'll say it without saying it), and the last is just a plain bizarre example. (Depression maybe?)
As for the third example, this one is the closest to the truth. Except that we generally don't say anything out of politeness and fear for our jobs. That doesn't mean that we don't still make it clear as a bell. Human communication isn't always done with words.
I've been doing servlet code for over a decade. I can still take the code from one of those old applications and make it run in a modern J2EE server. No changes necessary.
The fact that Microsoft needed to make such radical changes after only a single release suggests that they have a problem with their engineering. No other server-side technology changes so radically between versions.
Being able to run original ASP alongside ASP.NET I can understand. Needing to run ASP.NET 1.x alongside 2.0 I don't. That's just bad engineering.
As for DLL hell, that's another problem with Microsoft's engineering. Microsoft likes to make libraries global. That's a bad idea for this very reason. J2EE apps bundle libraries inside the web application. So even if you have one app that requires an incompatible version of a lib, it won't impact another app running on the same server. Only if and when an API is stable and mature does it get moved up to a global level. And Sun takes the approach of getting input from the entire industry before making such a commitment. Thus you may or may not like an API, but a given API is not going to remove support for previous versions.
Microsoft takes the approach of imposing their will on the industry rather than asking for their opinion. You don't like Microsoft's API options? Don't worry, we'll impose a new and incompatible one next week. :-/
I have to agree. One of the more frustrating aspects of the show is that the characters very rarely grow a sufficiently large backbone to Do the Right Thing(TM). And then it's pretty much only because they're forced to do so. Using a corporate environment as an analog, my company would have bitten the dust long ago if every employee kept secrets like they do in BSG. The fact that the Cylons didn't manage to wipe them out in the first season is purely an artifact of it being fiction.
Of course, there are plenty of situations where the secrets would be justified. e.g. If you know you're a cylon, do you really want to expose that amongst a ship full of cylon-haters? But some of the stuff is just plain ridiculous. Take Baltar as an example. By keeping his involvement with the destruction of the colonies a secret, he's basically accepting responsibility for his actions. Yet his character never accepts responsibility for his actions! A real individual like that would have carefully controlled the release of that information, being careful to spin it as something out of his control. Blame the cylons. Blame the dead government. Blame everybody, but make sure that it's not something that can come back and bite you in the ass.
I still like many aspects of the show, but the characterizations just get weird sometimes. And as you said, they end up blowing by the moral quandaries rather than taking the Star Trek approach of tackling them head-on.
I can't think of any nice way to put this, so I'll just go with you fail it.
Don't you get tired of typing .NET after everything? That's as obnoxious of a marketing scheme as putting "Sun Java" before every name.
Scriptlet technology is a core part of ASP.NET whether you like to admit it or not. Ideally it should not be used, but it is there. And JSF is an awful technology. Comparing ASP.NET to JSF is a mark against the ASP platform.
And in any case, the analog to ASP controls and data binding is taglibs like JSTL. (Exactly like I said in my original post.) Except in JSP you have a choice. You can use an alternative lib to JSTL or even create your own. The JSTL package is pretty powerful though, so there's little need to swap it out.
Yes, the whole "runat=server" thing I was just lamenting. Worst idea ever. It works great for basic websites, but it does. not. scale. I managed to at least figure out a way to evaluate tag names dynamically so that I could loop through a collection of tags. The ASP.NET programmer I inherited the project from was so impressed he said he'd make that a standard part of his toolkit. Just peachy.
As for the control options, they get really limiting really fast. Microsoft is the master at making the simple things stupidly easy. This gives the impression of power. But it fades very quickly when you try to scale the solution up or do anything that's outside the realm of "normal" usage. That's where the power to develop and deploy your own unified solutions comes in handy.
And don't even get me started on the amazing lack of a servlet analog. HTTPHandlers/HTTPModules are a poor excuse for an alternative, and tend to be divorced from the rest of the application. (Microsoft's take: Cohesive whole? What's that and why would you want it?) Oh and deployment. Oh the pain, the pain! Why oh why do I have to configure every little piece? Complain about J2EE all you want, but deployment is incredible.
Nothing. As long as you want a webserver. If you want a full blown application server, things fall apart quickly. Did I mention the deployment and cohesion issues? I'm not sure if these can be overstated. Application server functionality is a bolt-on module to IIS. At its core, it's really just a web server like Apache. J2EE is the opposite philosophy. It's an application server first with standard web server functionality hosted as one of the many applications running in the application space.
The end result is that easy things in J2EE take a bit more work, but the hard things are brain-dead simple. (e.g. dynamically interpreting URLs) Meanwhile, easy things are made even easier in IIS, but the hard things become convoluted and incredibly difficult.
FWIW, uptime measures uptime. Nothing more, nothing less. The top sites for uptime tend to be the ones with the most static content. The more dynamic your content is, the harder it is to maintain both the application and the uptime on a per-machine basis. (Case in point: The top 2 sites on Netcraft's list are a porn site and a site for a pasta product.) That's okay though. Clustering and fail-over features exist for that very reason. If you need to take a server down, your availability does not go away. And at the end of the day, that's a lot more important than your uptime numbers.
FWIW, you should probably start with Glassfish (aka Sun Java System Application Server) and Netbeans. That combination is extremely smooth for J2EE development and will have you up and running in no time flat. (Plus it's all open source. ;-)) Just visit Netbeans.org and grab the full version or the version with Glassfish bundled.
Once you get it setup, you can configure features like the JDBC connections through the admin console on http://localhost:4848. The default user/pass is admin/adminadmin.
You can then review the official tutorial here. It covers the concepts pretty well. Truth be told, though, you can skip most of the details for now and jump straight to servlets. Servlets are Java objects that respond to network requests. HTTPServlets thus have methods like doGet, doPost, doPut, etc. All you have to do is read in the parameters passed and write out to the output stream. Due to their relative simplicity, the JavaDocs tend to be the best reference for programming servlets:
http://java.sun.com/products/servlet/2.2/javadoc/
(Don't be fooled, though. Simple ideas are some of the most powerful.)
The one part that's not covered by the JavaDocs is the deployment. You will need to understand the web.xml file for mapping servlets to URIs. Thankfully, Netbeans has some GUI tools that can help you understand the format and how it works. Advanced servlet development can have a whole chain of cool stuff like classes that intercept requests before and after the servlet runs (filters) and event listeners on session creation and destruction.
Once you understand servlets, then you can move on to JSP pages. At their simplest, JSP pages are HTML with code that get compiled internally by the server into servlets that print out the HTML. (Take a look at the generated code sometime to understand JSPs inside and out.) Modern JSPs should be written with taglibs. Taglibs basically work off the page attributes collection. Rather than working with solid page variables, entries are created inside the hashtable used to store page attributes. (These are attributes that exist only for the period of the request.) The standard pattern for these is that you execute a tag to retrieve a collection of information, then you use tags to output and/or loop through the values.
Servlets and JSPs can be chained by using the RequestDispatcher.include and forward methods. This allows you to not only include one page inside another, but you can also use the page attributes to forward data around. e.g. Let's say you have a servlet that reads from the database in response to a user's input. It can then dump the results into an attribute and call off to a JSP for rendering of that data.
Once you get that stuff down, you can start looking into the other features of J2EE. The JNDI directory is a wonderful way to handle connection pools. Don't put your connection information in your pages! Let the J2EE server manage the pools through the directories. This will make your application more adaptable. JMX allows you to wire up all kinds of meta-data about your app in the same way that SNMP is used to manage network devices. The authentication system can be used to automatically restrict resources without having to write protection code into your application. Java messaging can be used to send messages between systems. JavaMail is obvious. Support for SOAP/XML-RPC/REST and other features are built into the server and are easy to use. EJBs are best ignored unless you're developing a compute engine. (If you don't know what that is, all the more reason to ignore EJBs.) Java Server Faces should be avoided at all costs.
While that just barely scratches the surface of J2EE power and scalability, hopefully it will be enough to get you started. :-)
Fair enough. On the sites I used pngfix, I haven't run into these issues. Of course, these days I've started "firing" customers who use IE at all. Hobby sites are tons of fun that way. Wish I could do that at my day job. ;-)
FWIW, everything in the article is about marginal improvements. There's no huge bang to be had out of any of the article's suggestions, save for the fact that they'll save significant bandwidth and server resources given the massive number of visitors the site is probably seeing at the moment.
First hit on Google. Remember to search only the "X-Aspnet-Version" (remove the quotes) part of that text. BTW, as efficiencies go, this is a pretty minor one. It matters for a site like whitehouse.gov because they're likely to get a few million visits per day. (At least in the short term.) Very few websites have that problem, so I wouldn't worry too much about it. :-)
So does every other page templating technology known to man. I can do it in ColdFusion if you ask me to. That doesn't make ColdFusion a particularly good language for scalable site development. Nor does it make ASP.NET anything special. And if I never see more code like this, it will be too soon:
*sigh*
Because ASP.NET can output XHTML code? Listen, I've looked at nearly every template language and framework on the market. 90% of them result in coding one's self into a corner. JSP may be simple, but that's it's strength, not its weakness. Especially when you break up your JSP code into smaller pieces and use a higher level abstraction at the servlet level to produce more maintainable code.
Oh for the love of God. You have no idea what you're talking about.
http://java.sun.com/products/jsp/
Use JSTL. Don't use JSF. There, good to go.
I was there when the first version of Tapestry was introduced the internet. It was an interesting idea, but it took quite a few revisions to make it into something useful. Today it's an alternative to JSPs for rendering, but it by no means retires the use of JSPs. Same with Velocity and Wicket. And if you try to introduce me to Spring as if it's the latest and greatest thing (rather than a technology that's been around since the turn of the century), I will have to smack you. ;-)
Of course, all of this just points to the flexibility of the J2EE platform. (Primarily the servlet layer, but using a full J2EE implementation has a variety of pleasant advantages.) Which is why I feel like getting a lobotomy every time I have to work with ASP.NET 2.0 code. It's like going from a Cadillac to a Power Wheels. (Pow-pow-power wheeeeeelsss...)
Language agnostic is pointless when you're not writing code. Correctly written JSP 2.0 files should have no scriptlets in the pages. All the code should be in behind-the-scenes APIs or in parent servlets that use the page for rendering. The JSP solution is far more flexible than the ASP page-backing code files solution, and generally encourages better written code. Looking at ASP.NET pages that reference tags by IDs makes me want to tear my hair out in frustration. ("NO! You do NOT make six instances of the same tag so you can populate them in the page-backing code file! Arrrgghhh!!!")
On a broader note, .NET's language agnosticism is a farce. You can have any color you want (slate, charcoal, basalt, jet, etc.) as long as it's black. There are no real differences between the languages. They have all been modified to fit the C# mold.
Whatever helps you make it through the day. I've worked with ASP.NET long enough to know that a bit of reality disconnect makes the pain a little more bearable. ;-)
256 color PNGs work correctly in IE6. No need to do anything special.
Put pngfix.js in an IE conditional tag if it bothers you. I refuse to stop the progress train because of Microsoft's ill-gotten monopoly.
I confess, I haven't used ASP.NET 3.5/MVC yet. It would have been handy back when I inherited an ASP.NET project. Unfortunately, after my poor experiences with ASP.NET's scalability (or lack thereof), I'm not really inclined to develop another site in ASP.
As a former President once mumbled, "Fool me once, shame on you. Fool me twice... you ain't gonna fool me again." :-P
Did I say anything to suggest otherwise? As of right now, ASP.NET is ASP. Pointing out that they are different is like pointing out that Windows 95 != Windows XP when someone criticizes "Windows". Especially when "ASP.NET 2.0" is clearly spelled out in my post.
Now if you want to hear me complain about the inanity of ASP.NET 2.0 and 1.x being incompatible with each other, thus necessitating the need for both engines to run alongside each other in support of legacy modules, just keep it up. ;-)
Hmm... Freudian slip? FWIW, most of the whitespace is probably generated by the ASP technology they used. Spots where code goes can often generate unexpected whitespace. It's just a side effect of using scriptlet-type technologies.
Don't get me started on the "correct" way to write ASP. The tag-substitution gobbldy-gook encourages all kinds of bad page-development practices. The request-time attributes + templating taglibs seen in JSP provide a much cleaner separation between logic and HTML.
Ouch. Welcome back to 1996. Web developers looking for the smallest file size really need to learn that there is such a thing as palletized PNGs. They're even smaller than GIFs, even.
This is one place where my reaction is "BFD". As long as it looks acceptable under most circumstances, the people with the carefully color calibrated monitors (*cough*yeslikeme*cough*) can suffer a bit. Heck, half the JPGs on the internet look like garbage, so I'm not too worried about artifacting in the gradients.
Can we choose the right technologies for a website? No we can't! Thankfully, the President isn't hired to choose the best technology to run his website. ;-)
I have a rather conflicted view on JS2. There are a lot of aspects I like about it, yet I understand the various arguments against it. I think both sides have a lot of merit in their arguments and should be heard out. Perhaps most telling is that the only widely-deployed implementation of JS2 (ActionScript 2.x) actually compiles its code down to JS1 code. (Do a decompile of a Flash 8 movie sometime and you'll see what I'm talking about.)
More to the point, most of the features offered by AS2 can be accomplished in AS1 or require a compiler to be effective additions. In result, I think the market's current solution is the best solution. Which is for complex projects to use a JS2 compiler as an intermediary step for type checking and object translation. The end results will operate and interface correctly in the browser, but the abstractions will be a bit more familiar to traditional programmers.
Of course, the implication is that large-scale projects CAN be done in JS1. And I'm going to voice that opinion right now. (e.g. See Pixtastic for a well-architected and scalable application.) The catch-22 is that JS development leaves more power in the hands of the developer. This forces the developer to decide on the best organization for his project.
Unfortunately, leaving more power in the hands of developers can be disastrous for programmers with insufficient seniority. They create a huge mess, then they curse the language for its apparent failures. Languages like Java force them to think a particular way about project organization, so why should Javascript leave so many options open?
These are the people for which JS2 is a very good idea. JS2 promotes good development practices without completely removing the underlying power that makes Javascript such a great language to work with. Thus my opinion on why the market will choose JS2 compiled to JS1 in the same way that C++ is a powerful object system on top of C. (Though a little less hokey in practice. ;-))
Is there something wrong with "MyObject.prototype.mymethod = function() {};"? Or are you referring to the fact that a function can always be reapplied to a different object context? This is actually a feature, not a bug. It makes functions highly portable across your code. Yes, this means that passing a function as a parameter can create some issues, but that is what closures are for. Rather than creating entire objects to implement interfaces, you can create a very [i]private[/i] communication channel at any time with a closure. Doing this in a structured language like Java is a pain and a half and generally leads to the practice of exposed, but undocumented APIs.
Not since I understood Javascript scoping. Once that was done, my issues with what "this" is disappeared.
This is a myth. A popular myth, but a myth none the less. Javascript works by implicit visibility rather than explicit visibility. Thus:
More info here.
There are more ways to do namespacing in Javascript than Carter has little pills. e.g.:
Which can then be instantiated with:
Some people even use a helper function to reduce the vulnerability that a package will get overwritten:
But I don't recommend it. Usually you want to reduce your footprint to as little as possible. Zero is ideal. e.g.:
Unless you need to share out public APIs:
If I were to sum up your complaints (and those of 95%+ of people programming Javascript) I would do it like this: You're trying to write C-Style code in a LISP-style language. Stop it. Things get better after that. :-P
Go watch this video series: http://video.yahoo.com/watch/111593/1710507 I guarantee you'll have a few "aha!" moments. Especially when it comes to scoping. Once you understand how to make JS scoping work for you rather than against you, life gets a lot easier.
The following text is garbage to make Slashdot's stupid filters happy. Ignore it. Apologi
I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code. The unfortunate result is that developing for a statically-typed vs. dynamically-typed language makes little difference to this process.
That being said, there are some advantages to a statically-typed language. e.g. There are no untested code segments with typing errors waiting to blow up. The code may blow up for other reasons, but typing won't be one of them. (Unless you force a cast, that is. Casted objects can blow up quite nicely.)
The other area where it's a good idea is when your code will share out or access a standard interface outside your project. In such cases, typing can create a contract that ensures the correct use of all APIs.
That's why I suggested the use of a JS2.0 compiler for times when typing is important. JS2.0 is a softly typed language. Typing can be defined to ensure correctness, but typing is not required. This allows for interfaces and APIs to be exposed properly while leaving the individual developer a free hand to design his code in a classless fashion.
I'm not going to write an entire dissertation on this, so see Bruce Eckel's excellent article on this issue for a decent introduction to the compile-time checking issue.
You've just pointed a finger at the very thing Javascript gets absolutely correct. While the scoping system may seem weird and even incorrect to coders with experience in other C-style languages, the Javascript scoping system is what welds the OOP aspects of the language together with the functional aspects of the language. If you changed the scoping system, you'd completely destroy Javascript's object system in addition to gimping its functional aspects. Which would leave you with the just the crappy procedural code that your average web developer creates for neat webpage effects.
I think you're confusing "class based" with "object oriented". Javascript is very much an Object Oriented language. Otherwise, how would this code work?
(You can save yourself the trouble of creating an HTML file by using this page to test it.)
Prototype-based OOP can do almost everything Class-based OOP can do, except that it is far more flexible at runtime. You lose some compile-time checking, but it's been found that strict compile-time checking doesn't offer nearly as much error-catching benefit as was originally envisioned.
If you're absolutely in love with compile-time checking, consider a Javascript 2.0/ECMAScript 4.0 compiler. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.
Generally speaking, that's a problem with Internet Explorer. (That took them FOREVER to fix.) You can still leak memory by foolishly creating closures all over creation, but for the most part it's pretty difficult to leak memory on accident. At least, no more or less difficult than it is with your average OOP language.
While the language is VERY popular, I disagree that a "hell of a lot more people know it" than most other GNU languages. The vast majority of coders have no idea how to correctly write Javascript. In fact, you can't even say that Javascript is an Object Oriented, LISP-like functional language on Slashdot (of all places) without ten or twelve people trying to tell you you're wrong.
Which sucks. Because Javascript is an AWESOME language. Plus the modern VMs (as opposed to the last-generation interpreters) are getting quite fast. Fast enough to use JS for anything short of compute-intensive applications. Even professional video games could use it as a scripting language with the right underlying APIs. (See my sig for how far it's come with Web games.)
My hope is that as Javascript shows up in more places, developers will take the time to sit down and truly understand the language. And maybe we can even get a few books on the market that don't suck. ;-)
Java software is portable and generally a hell of a lot less painful to setup and configure. (Which I guarantee from experience, Apache DS is much smoother than SJDS.) Believe it or not, there's a hell of a lot of advantages to having your server software written in Java.
If you have a bias against Java, you might want to check it at the door pronto. You're cutting yourself off from some of the best server-side software in the industry.
*shrug* It works. The admin interface is a little wonky at times, but otherwise nice. Adding LDAP fields is a pain in a half, though. You have to modify the schema file directly and restart the directory server. Not exactly user-friendly.
Personally, I've been keeping my eye on Apache Directory Server. It's modern, it's Java-based, it's easy to setup, it's open source, and it's made by Apache. What more could you want? ;-)
We're closed now!
That's exactly what I mean. We've put up with really bad marketing from Sun for too long. So bad that if it were a movie, it would be one of those Lion Gate direct-to-DVD films that is so bad it first wraps around to good, then keeps going to wrap around to "worse than the most horrible atrocity ever committed by Hollywood".
I say we storm Sun and take over the headquarters. Viva la Revolución! :-P