Unfortunately, I don't think you can use the '+=' with that form, because Number() returns a new Number object. Still, I'd say that's a little easier to look at and understand than your version, even if it is a little longer to type. It was a hard learned lesson for me way back when I first ran into this "bug", but it's pretty much just habit now. Any time I am dealing with a variable that has the remotest possibility of not being a Number, I always throw Number() around it before I use it.
That said, I do agree with you that the language designers really had a serious brain fart when they didn't make a separate concatenation operator, but it's far too late to add one now, and I don't think it will ever happen. Besides, even if one was added, Internet Explorer would take ten years to add support for it, so it would be essentially useless anyway. (Hey Microsoft, when are we going to see JavaScript 1.5 in IE, huh?)
Actually, JScript has been pretty much abandoned as a supported language in ASP.NET. I work for a company that uses ASP / JScript as the server side platform, and while we've been looking at.NET for a long time, one of the things that has caused us to put off the transition for a very long time is that the lack of JScript as a (usable) language in ASP.NET will require us to completely retrain almost all of our current web developers. For a while we were looking into PHP as an upgrade path because it was more similar to ASP, and because a lot of developers here (myself included) have previous PHP experience. Fortunately (IMO, at least) that plan got shot down because we could never get PHP on IIS stable enough to consider it a valid option.
Actually, the minimum is 3. 1) HTML 2) CSS 3) JavaScript
JavaScript makes a good^W decent server side language as well. Sure, it's not the greatest language available, but on the other hand it's nice be able to use all of the same libraries/conventions on the server side as you do on the client side, which for some applications may outweigh the benefits of using an otherwise superior language.
As for XML (and the various associated schemas), yuck. I suppose if you were a masochist you would do it that way. Personally, the only time I ever deal with XML is when a client explicitly requests an XML web service. Otherwise I just use JavaScript (a.k.a. JSON) as the transport language as well. Really, though, it doesn't matter one bit what your transport is. All you have to do is write serialize/deserialize functions for both the client and server that agree on a common format, whether it be JSON, XML, or brainf*ck. Beyond that, you never have to look at it again.
And finally, others have pointed this out as well, but I just want to say it again:
3) the non-existent security regarding JS code; anyone can see it.
You have two separate sentences here, and they have nothing at all to do with each other. (Unless by security you are referring to preventing people from stealing and reusing your JavaScript code and not security of the application code, but that's a completely different animal.)
Thanks. Glad to see I;m not the only one who gets this. JavaScript really is a great language. It's too bad that when most people think of JavaScript, they can't get past the DOM incompatibilities, which have very little to do with JavaScript... and also, BTW, aren't even that bad any more. With a small handful of simple wrappers (mostly to account for attachEvent vs. addEventListener, and the different ways of instantiating an xmlHttpRequest) the differences between the IE, Gecko, and other browser DOMs are almost unnoticeable. IMO, the only serious compatibility problem in modern web development is IE's awful CSS support (and lack of any way to perform event capturing in IE, but I've mostly accepted that I just have to be willing to live without it.) which has pretty much nothing at all to do with JavaScript.
In November, a researcher who focuses most of his attention on bugs in database giant Oracle's software announced his intention to launch a "Week of Oracle Database Bugs" project during the first week of December. The researcher abruptly canceled the project shortly after the initial announcement, without offering any explanation.
Maybe he just couldn't find enough for a whole week?
If you actually look in deeper, you will find that the coffee was so hot, it scalded and caused horrible burns.
Maybe you need to look a little deeper. The temperature that McDonalds served its coffee at is not only in the temperature range recommended by most coffee producers, it is also lower than Starbucks, Einstein bros (at least the ones around here), and several other widespread coffee chains currently serve their coffee, and lower even some newer home coffee makers. If McDonalds was really serving their coffee at an unsafe temperature, coffee temperatures should have come down since then. If anything, they've gone up.
Even if the coffee had actually been boiling, it would not have been enough to cause third degree burns just from having it spilled on her. I know - I've spilled boiling liquids on myself before. The problem was not just that she had coffee spilled on her- she then sat in the puddle of nearly boiling coffee.
You shouldn't group Oracle and PostgreSQL together like that. In my experience, PostgreSQL is about as easy as MySQL to set up (actually easier, in my opinion). On the other hand, I would rather have major dental work done without anesthetic than set up one more Oracle database ever again. Personally, I think Oracle goes out of their way to make it as difficult as possible to prop up the market for $80K/yr DBA's.
Perhaps(*), but how many of the performance comparisons that show MySQL being so much faster than everything else use InnoDB? The MySQL guys like to have their cake and eat it too in this regard. Most performance comparisons I've seen show MySQL without all of the referential integrity enabled, but whenever anyone points that out, the MySQL fans cover their ears and say "InnoDB! InnoDB! I'm not listening..."
(* - This is even assuming that I trust the MySQL developers to know enough about database integrity to implement InnoDB properly, which I don't.)
I'm all for getting rid of pennies, but good God please, don't replace them with more coins. Coins are awful to carry around. I already pretty much ignore any coin smaller than a quarter, and I mostly only keep those so that I have a few around to feed parking meters on the rare occasion that I have a need to. It would be irritating as hell to have to walk around with a pocket full of coins that are actually worth something. If you're annoyed at machines that spit out a dozen coins in change, it seems that a far simpler fix would be to switch to a machine that gives you bills for change.
That was something that I never quite got used to the last time I was in Europe- the sheer number of coins I ended up carry around. And I couldn't ever get rid of them, either. If I tried to give somebody in a store 10.32 for a 5.32 charge, they would stare blankly back at me for a second, hand me back the.32, as well as another 4.68 in coins, and I'd have three times the number of coins I started with. By the time I left, I had accumulated about 15 Euros in coins.
And, no, hybrid drivetrains don't have to be more complicated than "normal" powertrains - if you look at the Prius, it has only a single (planetary) gearset for the transmission and no clutch or automatic clutchpacks to wear out.
No, but on the other hand, after about 80,000 miles you'll have to replace the batteries, and that will cost you far more than putting in a new clutch (or even a new transmission) every 10,000 miles.
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
Actually, I do know who he is, and I have a great deal of respect for the work that he has done. I wasn't addressing his statements, I was addressing yours.
And I never actually called anyone a poor programmer. My statement was "Anyone who says 'language X is a poor language because in order to implement Y with language X, you first have to implement all of these features from language Z' is probably saying more about themself than about language X." As far as I know, he's never said that, and for that matter, neither you never actually said it either, although you certainly very heavily implied it. Anyway my real point was that you spent far more of that post criticizing Java (which was IMO misplaced) than providing any useful discussion.
# Spend a lot of time on the road? Want to check your account(s) from your hotel room? Take all your tokens. Which, BTW, means that the spouse cannot check while you are away unless each account issues one token per spouse or other authorized account user (which, BTW, adds cost for the institution). # You have an emergency of some sort and must have access to your account, but forgot/lost your token, the battery died, whatever. Is there a secondary mechanism that will allow you to access your account which does not rely on the use of the security token? If so, you've just doubled the institution's cost of doing business with no net benefit to the institution.
Well, in those cases, I guess we'd just be completely screwed. I mean, it's not like there was ever a time that we didn't have easy online access to all of our bank account information, was there?
Personally, I wouldn't mind the situation that you describe. It would give me secure access to all of my account information when I am at home, when I am most likely to want it. When I am not at home, I can just keep doing what I've always done in the past- call my bank, or *gasp*, go there in person. Since I pretty much only use online banking when I am at home as it is, I think it would be a reasonable trade off- a little extra security for very little lost convenience.
Even if your list were accurate and verifiable (it's not):
You completely miscounted the number of Congressmen in the U.S. government
You've listed 4 numbers of arrests, but 0 numbers of actual convictions
Twice you say that a number of people were accused of something, but not whether any of the accusations were ever verified
In some cities, people get "stopped" for drunk driving at random checkpoints all the time, whether or not they've been drinking
Being sued doesn't necessarily mean you've done anything wrong, only that someone thought you were a good target for a lawsuit
Most successful businessmen also have a number of failures under their belt as well. One of the marks of successful people is the ability to keep trying when confronted with setbacks.
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
I don't doubt that Haskell is a very cool language, although I haven't had an opportunity to try it out yet- as far as I've been able to tell, it wouldn't be very useful for my primary areas of work.
My comment regarding his post was directed at this:
The Java code must explicitly model and simulate many Haskel features like first order functions, memoization, pattern matching, partial evaluation, lazy evaluation, declarative programming, and functional programming. That requires many abstract interfaces, concrete classes and brittle lines of code.
While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise.
I was not claiming that the Java code could be made as small as the Haskell code. I was merely arguing that it was probably made needlessly "brittle and verbose" by trying to emulate the Haskell implementation in a very dissimilar language, and that saying that the Java code must emulate those Haskell features (and is therefore necessarily complex and brittle) is more likely the mark of a poor (or stubborn) programmer than of a poor programming language.
It's not so much being an asshole as realizing that as the number of people on the road increases you have to be more focused on watching out for yourself and that no one will ever hit you given a reasonable opportunity to avoid it (exempting cab drivers).
I live near Denver, which by many people's standards is a pretty large city, and the drivers here drive me crazy because they are far too nice to be driving in city this size. They'll slow down an entire freeway because the driver on the onramp and the driver in the right lane both keep slowing down further and further trying to let the other go first. Seriously, guys, just step on the gas and go- it's not that hard. I realize that my driving standards might be a little f*ed up, having first learned to drive in Southern California, and then spent 8 years in Chicago, but there's no reason I should have to hit my brakes when I'm 5 cars back from a guy trying to merge, and it's nearly unfathomable to me that one busy onramp can back up a three lane highway for over a quarter of a mile.
However, I suspect that to get any benefit when tailgating / drafting, you need to be extremely close to the vehicle - way to close for most peoples comfort.
It depends on the size and shape of the vehicle. It's generally possible to draft off of a large tractor-trailer without being closer than most people are comfortable with, but it's still probably a bad idea, because while you may consider the following distance to be quite safe, you are still in the semi driver's blind spot.
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 1
That's an awful lot of cutting and pasting just to take a worthless jab at the Java language. While I haven't even looked at the code, and I don't really know all that much about either language, I can guess just from your description that the reason that the Java version is so complex is that the Haskell version was written first, and then somebody tried to write the Java version using exactly the same logic as the Haskell version, and therefore ended up reimplementing half of Haskell in the process. As much as people seem to get that not all programming languages are equal, I'm consistently surprised at the number of people who seem to think that you should be able to implement an algorithm in exactly the same way in every language. I see the same thing in a lot of the new "AJAX frameworks" that take 80k of JavaScript to implement 20k worth of features because in the process they decided to bolt on 60k of syntactic sugar to make JavaScript look like Java/C#/whatever.
Hm, I have yet to see a free money or debit card reader anywhere
That's funny, because I see a free debit card reader at every store I walk in to. About the only time I ever use cash is on road trips (mostly for drive-throughs) or if I'm buying something for my wife that I don't want her to see on the credit card statement the next day (and occasionally if I don't want to get harassed about buying a new computer game).
My sister in law isn't blind, but she can't use cash- she gets a skin rash from handling coins (except pennies, i think) because of one of the metals that they use. She literally puts everything she ever buys on a card, so it's certainly possible.
Does Novell often pay millions of dollars for "protection" for its customers when it does not believe that the threat has any substance?
Obviously, it believes that there is some substance to the threat, or they wouldn't have paid any money. The thing is, you're looking at the wrong threat. By now, if nothing else, the one thing we should all have learned from SCO is that you don't need to be in the right to cost another company a lot of money litigating. Whether Novell believes SuSe infringes on any of Microsoft's patents or not, the threat of a lawsuit from Microsoft still exists. I suspect the Novell looked at $40 million vs. the cost of successfully defending even one patent case against Microsoft in a long drawn out battle, and figured it was a no-brainer.
And it probably is worth the money just to have something to show their potential customers. Sure they can tell their customers till they are blue in the face that Novell does not infringe on any Microsoft patents, but how often do you listen to anything that someone trying to sell you something says without a grain a salt? Having an agreement in writing from Microsoft that they can show their customers could easily be worth $40 million to them, even if Novell itself doesn't think it's necessary.
To borrow a quote from Shigeru Miyamoto, "A delayed game is eventually good, a bad game is bad forever." I think that applies to pretty much any software project, though of course "good" is relative to the user.
Unfortunately, these keyboards are getting very hard to find. I'm not sure which I fear more- not being able to find a new one when my current keyboard dies, or getting a computer with no PS/2 keyboard port the next time I upgrade.
Slashdot Mirror
You can always use Number()/String() to force typing:
document.theform.hours.value = Number(document.theform.hours.value) + 1;
Unfortunately, I don't think you can use the '+=' with that form, because Number() returns a new Number object. Still, I'd say that's a little easier to look at and understand than your version, even if it is a little longer to type. It was a hard learned lesson for me way back when I first ran into this "bug", but it's pretty much just habit now. Any time I am dealing with a variable that has the remotest possibility of not being a Number, I always throw Number() around it before I use it.
That said, I do agree with you that the language designers really had a serious brain fart when they didn't make a separate concatenation operator, but it's far too late to add one now, and I don't think it will ever happen. Besides, even if one was added, Internet Explorer would take ten years to add support for it, so it would be essentially useless anyway. (Hey Microsoft, when are we going to see JavaScript 1.5 in IE, huh?)
Actually, JScript has been pretty much abandoned as a supported language in ASP.NET. I work for a company that uses ASP / JScript as the server side platform, and while we've been looking at .NET for a long time, one of the things that has caused us to put off the transition for a very long time is that the lack of JScript as a (usable) language in ASP.NET will require us to completely retrain almost all of our current web developers. For a while we were looking into PHP as an upgrade path because it was more similar to ASP, and because a lot of developers here (myself included) have previous PHP experience. Fortunately (IMO, at least) that plan got shot down because we could never get PHP on IIS stable enough to consider it a valid option.
1) HTML
2) CSS
3) JavaScript
JavaScript makes a good^W decent server side language as well. Sure, it's not the greatest language available, but on the other hand it's nice be able to use all of the same libraries/conventions on the server side as you do on the client side, which for some applications may outweigh the benefits of using an otherwise superior language.
As for XML (and the various associated schemas), yuck. I suppose if you were a masochist you would do it that way. Personally, the only time I ever deal with XML is when a client explicitly requests an XML web service. Otherwise I just use JavaScript (a.k.a. JSON) as the transport language as well. Really, though, it doesn't matter one bit what your transport is. All you have to do is write serialize/deserialize functions for both the client and server that agree on a common format, whether it be JSON, XML, or brainf*ck. Beyond that, you never have to look at it again.
And finally, others have pointed this out as well, but I just want to say it again:
You have two separate sentences here, and they have nothing at all to do with each other. (Unless by security you are referring to preventing people from stealing and reusing your JavaScript code and not security of the application code, but that's a completely different animal.)
Thanks. Glad to see I;m not the only one who gets this. JavaScript really is a great language. It's too bad that when most people think of JavaScript, they can't get past the DOM incompatibilities, which have very little to do with JavaScript... and also, BTW, aren't even that bad any more. With a small handful of simple wrappers (mostly to account for attachEvent vs. addEventListener, and the different ways of instantiating an xmlHttpRequest) the differences between the IE, Gecko, and other browser DOMs are almost unnoticeable. IMO, the only serious compatibility problem in modern web development is IE's awful CSS support (and lack of any way to perform event capturing in IE, but I've mostly accepted that I just have to be willing to live without it.) which has pretty much nothing at all to do with JavaScript.
Maybe he just couldn't find enough for a whole week?
Normally I'm not one to pick on spelling or grammar errors, but "liable", which you probably meant to use, is a very different thing from "libel".
Maybe you need to look a little deeper. The temperature that McDonalds served its coffee at is not only in the temperature range recommended by most coffee producers, it is also lower than Starbucks, Einstein bros (at least the ones around here), and several other widespread coffee chains currently serve their coffee, and lower even some newer home coffee makers. If McDonalds was really serving their coffee at an unsafe temperature, coffee temperatures should have come down since then. If anything, they've gone up.
Even if the coffee had actually been boiling, it would not have been enough to cause third degree burns just from having it spilled on her. I know - I've spilled boiling liquids on myself before. The problem was not just that she had coffee spilled on her- she then sat in the puddle of nearly boiling coffee.
You shouldn't group Oracle and PostgreSQL together like that. In my experience, PostgreSQL is about as easy as MySQL to set up (actually easier, in my opinion). On the other hand, I would rather have major dental work done without anesthetic than set up one more Oracle database ever again. Personally, I think Oracle goes out of their way to make it as difficult as possible to prop up the market for $80K/yr DBA's.
Perhaps(*), but how many of the performance comparisons that show MySQL being so much faster than everything else use InnoDB? The MySQL guys like to have their cake and eat it too in this regard. Most performance comparisons I've seen show MySQL without all of the referential integrity enabled, but whenever anyone points that out, the MySQL fans cover their ears and say "InnoDB! InnoDB! I'm not listening..."
(* - This is even assuming that I trust the MySQL developers to know enough about database integrity to implement InnoDB properly, which I don't.)
I'm all for getting rid of pennies, but good God please, don't replace them with more coins. Coins are awful to carry around. I already pretty much ignore any coin smaller than a quarter, and I mostly only keep those so that I have a few around to feed parking meters on the rare occasion that I have a need to. It would be irritating as hell to have to walk around with a pocket full of coins that are actually worth something. If you're annoyed at machines that spit out a dozen coins in change, it seems that a far simpler fix would be to switch to a machine that gives you bills for change.
.32, as well as another 4.68 in coins, and I'd have three times the number of coins I started with. By the time I left, I had accumulated about 15 Euros in coins.
That was something that I never quite got used to the last time I was in Europe- the sheer number of coins I ended up carry around. And I couldn't ever get rid of them, either. If I tried to give somebody in a store 10.32 for a 5.32 charge, they would stare blankly back at me for a second, hand me back the
No, but on the other hand, after about 80,000 miles you'll have to replace the batteries, and that will cost you far more than putting in a new clutch (or even a new transmission) every 10,000 miles.
Actually, I do know who he is, and I have a great deal of respect for the work that he has done. I wasn't addressing his statements, I was addressing yours.
And I never actually called anyone a poor programmer. My statement was "Anyone who says 'language X is a poor language because in order to implement Y with language X, you first have to implement all of these features from language Z' is probably saying more about themself than about language X." As far as I know, he's never said that, and for that matter, neither you never actually said it either, although you certainly very heavily implied it. Anyway my real point was that you spent far more of that post criticizing Java (which was IMO misplaced) than providing any useful discussion.
Well, in those cases, I guess we'd just be completely screwed. I mean, it's not like there was ever a time that we didn't have easy online access to all of our bank account information, was there?
Personally, I wouldn't mind the situation that you describe. It would give me secure access to all of my account information when I am at home, when I am most likely to want it. When I am not at home, I can just keep doing what I've always done in the past- call my bank, or *gasp*, go there in person. Since I pretty much only use online banking when I am at home as it is, I think it would be a reasonable trade off- a little extra security for very little lost convenience.
My comment regarding his post was directed at this:
I was not claiming that the Java code could be made as small as the Haskell code. I was merely arguing that it was probably made needlessly "brittle and verbose" by trying to emulate the Haskell implementation in a very dissimilar language, and that saying that the Java code must emulate those Haskell features (and is therefore necessarily complex and brittle) is more likely the mark of a poor (or stubborn) programmer than of a poor programming language.
You know, a lot of cars have their headlights on all the time now, right? Even my cheapo little Corolla has daytime running lights.
It's not so much being an asshole as realizing that as the number of people on the road increases you have to be more focused on watching out for yourself and that no one will ever hit you given a reasonable opportunity to avoid it (exempting cab drivers).
I live near Denver, which by many people's standards is a pretty large city, and the drivers here drive me crazy because they are far too nice to be driving in city this size. They'll slow down an entire freeway because the driver on the onramp and the driver in the right lane both keep slowing down further and further trying to let the other go first. Seriously, guys, just step on the gas and go- it's not that hard. I realize that my driving standards might be a little f*ed up, having first learned to drive in Southern California, and then spent 8 years in Chicago, but there's no reason I should have to hit my brakes when I'm 5 cars back from a guy trying to merge, and it's nearly unfathomable to me that one busy onramp can back up a three lane highway for over a quarter of a mile.
It depends on the size and shape of the vehicle. It's generally possible to draft off of a large tractor-trailer without being closer than most people are comfortable with, but it's still probably a bad idea, because while you may consider the following distance to be quite safe, you are still in the semi driver's blind spot.
That's an awful lot of cutting and pasting just to take a worthless jab at the Java language. While I haven't even looked at the code, and I don't really know all that much about either language, I can guess just from your description that the reason that the Java version is so complex is that the Haskell version was written first, and then somebody tried to write the Java version using exactly the same logic as the Haskell version, and therefore ended up reimplementing half of Haskell in the process. As much as people seem to get that not all programming languages are equal, I'm consistently surprised at the number of people who seem to think that you should be able to implement an algorithm in exactly the same way in every language. I see the same thing in a lot of the new "AJAX frameworks" that take 80k of JavaScript to implement 20k worth of features because in the process they decided to bolt on 60k of syntactic sugar to make JavaScript look like Java/C#/whatever.
That's funny, because I see a free debit card reader at every store I walk in to. About the only time I ever use cash is on road trips (mostly for drive-throughs) or if I'm buying something for my wife that I don't want her to see on the credit card statement the next day (and occasionally if I don't want to get harassed about buying a new computer game).
My sister in law isn't blind, but she can't use cash- she gets a skin rash from handling coins (except pennies, i think) because of one of the metals that they use. She literally puts everything she ever buys on a card, so it's certainly possible.
Obviously, it believes that there is some substance to the threat, or they wouldn't have paid any money. The thing is, you're looking at the wrong threat. By now, if nothing else, the one thing we should all have learned from SCO is that you don't need to be in the right to cost another company a lot of money litigating. Whether Novell believes SuSe infringes on any of Microsoft's patents or not, the threat of a lawsuit from Microsoft still exists. I suspect the Novell looked at $40 million vs. the cost of successfully defending even one patent case against Microsoft in a long drawn out battle, and figured it was a no-brainer.
And it probably is worth the money just to have something to show their potential customers. Sure they can tell their customers till they are blue in the face that Novell does not infringe on any Microsoft patents, but how often do you listen to anything that someone trying to sell you something says without a grain a salt? Having an agreement in writing from Microsoft that they can show their customers could easily be worth $40 million to them, even if Novell itself doesn't think it's necessary.
Obviously he never played Daikatana.
Both of which are Christian...
WHAT!?!? Crazy Talk!
0 /Graphics.htm
The pipe key goes below the Enter Key.
http://support.dell.com/support/edocs/acc/sil_600
Unfortunately, these keyboards are getting very hard to find. I'm not sure which I fear more- not being able to find a new one when my current keyboard dies, or getting a computer with no PS/2 keyboard port the next time I upgrade.