So, the metric system sucks because... some people do a shoddy job when translating recipes into milliliters? Because whenever you see more than a single decimal digit, that is the case. Because God didn't actually ordain that food tastes better when produced with ingredients measuring an even number of "cups" or "pinches" or whatever system you find superior.
Did you not ever learn not to put metal in the microwave? And with the microwave radiation combined with the gravitons and graviolis we are all going to end up in 1947.
The first a foremost mission of my browser is provide myself with a pleasurable and/or useful browsing experience. Everything else is secondary, including any and every kind of technical standard. This goes for any piece of software, it must be useful and usable (in that order) first, technically competent second. Standard compliance and, more generally, technical excellence, is means to an end, never the end itself.
At least parts of MS has understood this for a long time. Depressingly few in the OS community appreciates the full consequences of this even today. Too much technology with a little usability on top, exactly the wrong priority.
I believe they think more in terms of what kind of money it has made it's creator. Ingvar Kamprad is now one of the riches men alive.
(And there are many reasons, one of them is that we live in a consumerist society where most young people don't actually want to inherit their parents furniture (which their parents, having a home of their own and a great many years of expected lifespan ahead of them, need for themselves anyway), or even use the furniture they bought themselves 10+ years ago. Furniture are now disposable fashion/lifestyle items.)
I shop at IKEA because there I pay about one fourth of what I would do in a proper furniture store, I presently have limited funds, and I don't necessarily see myself using the same furniture in 15 years. That said, their sofas just look too cheap to bear.
But you did say you wanted to "save the earth"? It's very easy to talk that talk, but as long as you're no even attempting to walk the walk, you're only so much hot air.
"The ultimate tradegy is not the action of the evil people But the inaction of the good"
To refuse to take _any_ action to save the earth because there are others whose methods you don't approve of who shares that particular goal, is stupid. The "driver's seat" you talk about doesn't exist per se, it's not a real position held by real people. The "environmental movement" is not a homogenous group whose political opinions or agenda you can label. Some parts of it, sure. Large parts of it, possibly. All of it, no way.
The only way to get the socialist wacko's out of the drivers seat is to refuse them to hold it. The only people who can do that are people like you. The only way you can do that is by actually presenting an alternative set of policies which will achieve the goal of saving the earth without sacrificing your goals.
And in the event that that is impossible, and your political agenda in it's entierty (I refuse you to monopolize words like "freedom") turns out to be impossible to align with saving the earth, you have a problem. I have a hard time to accept the "goodness" of a political agenda which inevitabvly leads to the destruction of our habitable planet. But at the moment this problem is theoretical and you are in the position to change the perception. As long as you and refuse to do anything for reasons that are nothing but a bad excuses, the notion that conservatism and environmental responsibility are mutually exclusive will continue to look increasingly likely. And it's your fault, not the political wacko's.
If you think you know enough to outright dismiss a diverse movement consisting of millions of individuals and thousands of independant organizations all over the world as socialist, you really are ignorant.
Until you answer the question of _how_ you propose to save the environment without sacrificing an inch of your (admirable) political ideals you only look like so much of an hypocrit.
I really think I understand what you mean, but frankly, i cannot help but reading "I sure as hello _don't_ want to change so I'll make any excuse I can for doing nothing". It's fine to dislike a large part of the environmental movement, ignorant to dismiss all of it (you don't know enough to make such a blanket statement about it), and stupid to use it as an excuse for doing nothing. If you don't like the way things are done/associated with, do it better. As long as you don't, don't expect to convince anyone of anything but the fact that you don't want to be inconvenienced by environmental concerns.
> And that's the problem. The government should not be using force to dictate what kinds of cars people drive.
So 'natural' resources, such as clean air and water, should always be free to consume at no reprecussion or cost? Because in the real world, neither of those things are worthless, or ultimatly costless to those who have to maintain them. It seems entierly reasonable to me to enforce payment (taxes, if you will) for using and abusing exhaustible resources, even natural ones.
Right. I haven't quoted any data, because I haven't actually claimed to know anything about this matter (ie gun control). I did claim that I found the one specific paper you linked, well, unsatisfactory (ie it seemed to me to contain gratious assumptions and jump to conclusions, but that was from a quick reading). You do have more data/statistics/papers than this one to base your heart felt opinion on, don't you?
As for the naivete, well, there are a number of assumptions in the ops post. Just an example:
"Criminals are just like anybody else, they look at the risks vs the rewards" Absolutely not warranted, a recent figure I saw was that a conservative estimate suggests that 60-70%, possibly up in the 90s, of inmates in Swedish prisons are mentally unstable (eg ill in some way). You can't just assume they'll reason like "normal people". The very same thing is actually hinted in the paper you linked (calling it a myth that "normal people" are involved in many shootings).
His conclusions might be reasonable. But his "logic" is of _no value_ to prove that. And this kind of crap isn't used by the one side of this debate only, as you probably are aware.
Blanket claims like "If more people had guns in their home there would be fewer home robberies" derived without looking if the assumptions are actually reasonable are worthless. That is my claim. Nothing else.
I, specifically, wasn't refering to any handgun statistics, but to death penalty/crime statistics. I did so with the intent of discouraging trusting the kind of naive logic the op used by showing a statistical counter example. I have an opinion on the handgun issue, but I have not expressed it in this thread. I just happen to think that naive logic clouds the issue more than clarifies it.
There might be a case to make for guns (or gun control), but naive logic isn't a good way to make it. Ofcourse, this is slashdot...
(The paper you linked was frankly unimpressive. Statistics have their very own set of problem, eg they can be hard to analyze and don't necessarily reveal casuality.)
Yeah, and the death penalty really makes for less crimes as well? Check the statistics, trying to use naive logic on these kinds of social phenomena is doomed. Your claim above, while seemingly logical, is _absolutely useless_. Crap. Nonsense.
Repeat: I will not use naive logic to analyze complex social phenomena.
I'm late, but you really have no clue and basis for these statements:-/
"C++ selects the method to call based on the types supplied to the method. That's exactly the same pattern matching functional languages have."
Ok, the way you confuse polymorphism, overloading, and pattern matching in this statement is just dear. Runtime or compile time? Same difference!
"There is nothing safe with type inference, as I previously demonstrated. "
No, you certainly did not demonstrate this, you demonstrated that you don't know what OCaml's type inference does for you.
"I've talked about an error, not a choice: someone mistakenly types 'list' instead of 'map': the error will propagate deep in the code."
If you've programmed in such a way that this is true, you only have _one_ place to fix it, just like with your typedeffed code. This is a matter of abstraction, in OCaml as well as in C++.
And type inference and common interfaces are actually contrary, as the overloading, since type inference has to resolve types at compile time it can't properly resolve overloaded functions like an explicitly typed language can. And that's a problem, with OCaml, which we resort to functorial interfaces for solving (i e we dont have overloading but allow parametrisation on name spaces, achieving the same affect in a more controlled manner), since OCaml doesn't have type classes like Haskell does. Look at the great lenghts C++ and Java goes to make sure to define common interfaces for collections and iteration. And for good reason, common interfaces are a _good thing_. Exactly because you can change a 'map' to a 'list' in one place and get great effects.
You should actually bother to learn stuff properly before showing of, well, your ignorance.
The decision to use a non-tail-recursive List.map implementation was a choice for supperior efficiency in the (far more) common case, e g with smaller lists, where it's significantly faster than List.rev_map. People who needs to deal with 50000 element long lists can cope with using List.rev_map or switching to a different data structure like, say, an array or a dynamic vector. These kind of engineering tradeoffs, efficiency vs generality and similar, _needs_ to be made, and the fact that OCaml chose to optimize for the common case and chose efficieny over theoretical beauty (while giving easy access to a more general solutin) should actually tell you that OCaml is a serious product and not an academic curiousity (as much as I adore those) or a beginners toy. You can think they traded the wrong way, certainly, but their decision absolutely isn't one of ignorance or immaturity.
As for a recursion depth of 50000 being too low, how deep does your recursion usually take you before you start considering the tail-recursive option? If you need greater recursion depth, increase your stack. Simple as that. As for the default, trying it out with Python I got a maximum recursion depth of between 900 and 1000, and that's a practical product used by many. C with msys/mingw/gcc on winXP got a limit of around 72000. That's really not all that much better than the 65000 I got from the OCaml interpreter for the same simplistic program on the same machine.
Ehrm, that's a problem of education, needing better intro texts, not of the language. Here's the truth: functional programming is no harder to imperative programming. It only appears that way because most of the current educational material isn't written by people who understand the needs of non-programmers. The bracketing is only a problem for those who are used to different syntaxes really.
> In programing, unexpected side-effects in functions is generally considered to be impolite. I think this applies to UI, too.
Ahhh, but don't you see, it's really the same thing. You only need to realize that the programming language is nothing but the most powerful and complex computer UI you're using.
So... you've had it with GUI and usability because marketing is clueless?
OSS software authors/designers don't have to worry about marketing. Ergo they can (and darn well should), as this article suggests, do the Right Thing(tm). Or, to be more true to the article, they can _avoid_ to do the Wrong Thing, since the Right Thing might vary with audience while the Wrong Thing is universal (i e its defined as not being the right thing for anybody). That's really what it ammounts to. You personally prefer xterms, that is an entierly valid preference for some, and a completly idiotic thing to suggest that everyone should adapt to. But that is an awful excuse for designing a useless GUI. If you're going to do it, at least try to avoid doing it wrong. Marketing is a much better excuse, but its an excuse that most OSS developers don't have.
To which there is only one reply: so what? Your customer at that point already represented a small percentage of the market, and that percentage was only headed towards an increasingly irrelevant piece of the economic pie. You don't engineer, build, and sell a new processor for yesterdays or todays market, you do it for tomorrows. You just have to make sure the compability mode isn't unusably slow for a large percentage of the market (for the P2 it wasn't, if only because of the fact that the 16bit market had already imploded).
Your customer was better of using the old P2, nigh on everyone else got way better mileage out of that PIII.
It's not about ignoring errors, it's about the central idea that you'll never, _ever_, be able to write 100% perfect code, and if you could your code will be so full of error checking that it's both unreadable and, as a result, unmaintainable, masking logic bugs and similar. It's a better economy to come up with better ways to deal with failure than trying to prevent it altogether. And the final solution will be more stable.
This is an important realisation: Failure is inevitable, how you deal with it is what matters.
I'll just clarify a fact that has been missed or somewhat obfuscated by other replies. You're completly confused as to relationship between macros/templates as found in C++/LISP and how they are used for achieving genericity in C++ on one hand and true generics as found in Ada, ML, C#, or Java 1.5. With the latter kind the generic functions/types can be statically type checked in isolation, long before it is instantiated as must be done for C++. When they type check they are type safe and end up providing much greater type safety than Java 1.4's idiom did, by providing type constraint on type parameters and type guarantees on collection content.
Generics are not templates, but genericity can be achieved using templates. However, since generics aren't as powerful as templates they are also very easy to make perfectly type safe. You have some (fun) learning to do!
But the professor who taught the Optimizing Compiler course I took also believed the EPIC play was a step in the wrong direction. He believed that the demands it puts on compiler tech are infeasible to meet at all, let alone in a reasonable timeframe.
It might also be a mistake to believe that future software technologies will reward (=won't punish) extensive static compile time analysis over dynamic run time decisions. Advanced compiler tech is about proving invariants, and that is hard to do when information is lacking (i.e. compile time).
It might not be bad tech, but it could very well be a poor tradeoff.
And whooooosh, there goes the article flying way above most posters head. Where did he say he thought using Python or any main stream scripting language for developing entire mobile apps on today's hardware was a great idea?
I believe he was talking about domain specific scripting language doing high level abstraction stuff. That's not the same thing as having the full script compiler (text interpreter) and a general purpose language on the phone. That probably refers to using stuff where a few script instructions invoke speedier compiled code with simple conditionals. Stuff like "if (keypressed up) move ship up", not "if (inkey blurb blurb) plot pixel 1, plot pixel 2,...." or even "if (inkey blurb blurb) erase ship, ship position = ship position - 1, draw ship".
High level really means that. A small (and these can be really small, a _few_ k is often plenty) bytecode interpreter with special purpose high-level commands can do wonders for productivity and can be plenty speedy. It's a very attractive technique for developing software.
Slashdot Mirror
So, the metric system sucks because... some people do a shoddy job when translating recipes into milliliters? Because whenever you see more than a single decimal digit, that is the case. Because God didn't actually ordain that food tastes better when produced with ingredients measuring an even number of "cups" or "pinches" or whatever system you find superior.
Yes, that's called an interpreter with a time limit.
Did you not ever learn not to put metal in the microwave? And with the microwave radiation combined with the gravitons and graviolis we are all going to end up in 1947.
Ehrm, look at these value series for million, billion, trillion, and quadrillion:
American:
10^6, 10^9, 10^12, 10^15
Brittish:
10^6, 10^12, 10^18, 10^24
Now tell me the American way is "more logical", 'cause it seems less so from where I sit at my keyboard.
The first a foremost mission of my browser is provide myself with a pleasurable and/or useful browsing experience. Everything else is secondary, including any and every kind of technical standard. This goes for any piece of software, it must be useful and usable (in that order) first, technically competent second. Standard compliance and, more generally, technical excellence, is means to an end, never the end itself.
At least parts of MS has understood this for a long time. Depressingly few in the OS community appreciates the full consequences of this even today. Too much technology with a little usability on top, exactly the wrong priority.
I believe they think more in terms of what kind of money it has made it's creator. Ingvar Kamprad is now one of the riches men alive.
(And there are many reasons, one of them is that we live in a consumerist society where most young people don't actually want to inherit their parents furniture (which their parents, having a home of their own and a great many years of expected lifespan ahead of them, need for themselves anyway), or even use the furniture they bought themselves 10+ years ago. Furniture are now disposable fashion/lifestyle items.)
I shop at IKEA because there I pay about one fourth of what I would do in a proper furniture store, I presently have limited funds, and I don't necessarily see myself using the same furniture in 15 years. That said, their sofas just look too cheap to bear.
Or shorter:
"We will step up to the platter and do our part if YOU first stop the wackos"
Which sound like an excuse in the light of the fact that neither I nor anyone else actually CAN stop these wackos in a free country.
But you did say you wanted to "save the earth"? It's very easy to talk that talk, but as long as you're no even attempting to walk the walk, you're only so much hot air.
"The ultimate tradegy is not the action of the evil people But the inaction of the
good"
To refuse to take _any_ action to save the earth because there are others whose methods you don't approve of who shares that particular goal, is stupid. The "driver's seat" you talk about doesn't exist per se, it's not a real position held by real people. The "environmental movement" is not a homogenous group whose political opinions or agenda you can label. Some parts of it, sure. Large parts of it, possibly. All of it, no way.
The only way to get the socialist wacko's out of the drivers seat is to refuse them to hold it. The only people who can do that are people like you. The only way you can do that is by actually presenting an alternative set of policies which will achieve the goal of saving the earth without sacrificing your goals.
And in the event that that is impossible, and your political agenda in it's entierty (I refuse you to monopolize words like "freedom") turns out to be impossible to align with saving the earth, you have a problem. I have a hard time to accept the "goodness" of a political agenda which inevitabvly leads to the destruction of our habitable planet. But at the moment this problem is theoretical and you are in the position to change the perception. As long as you and refuse to do anything for reasons that are nothing but a bad excuses, the notion that conservatism and environmental responsibility are mutually exclusive will continue to look increasingly likely. And it's your fault, not the political wacko's.
If you think you know enough to outright dismiss a diverse movement consisting of millions of individuals and thousands of independant organizations all over the world as socialist, you really are ignorant.
Until you answer the question of _how_ you propose to save the environment without sacrificing an inch of your (admirable) political ideals you only look like so much of an hypocrit.
I really think I understand what you mean, but frankly, i cannot help but reading "I sure as hello _don't_ want to change so I'll make any excuse I can for doing nothing". It's fine to dislike a large part of the environmental movement, ignorant to dismiss all of it (you don't know enough to make such a blanket statement about it), and stupid to use it as an excuse for doing nothing. If you don't like the way things are done/associated with, do it better. As long as you don't, don't expect to convince anyone of anything but the fact that you don't want to be inconvenienced by environmental concerns.
> And that's the problem. The government should not be using force to dictate what kinds of cars people drive.
So 'natural' resources, such as clean air and water, should always be free to consume at no reprecussion or cost? Because in the real world, neither of those things are worthless, or ultimatly costless to those who have to maintain them. It seems entierly reasonable to me to enforce payment (taxes, if you will) for using and abusing exhaustible resources, even natural ones.
Right. I haven't quoted any data, because I haven't actually claimed to know anything about this matter (ie gun control). I did claim that I found the one specific paper you linked, well, unsatisfactory (ie it seemed to me to contain gratious assumptions and jump to conclusions, but that was from a quick reading). You do have more data/statistics/papers than this one to base your heart felt opinion on, don't you?
As for the naivete, well, there are a number of assumptions in the ops post. Just an example:
"Criminals are just like anybody else, they look at the risks vs the rewards"
Absolutely not warranted, a recent figure I saw was that a conservative estimate suggests that 60-70%, possibly up in the 90s, of inmates in Swedish prisons are mentally unstable (eg ill in some way). You can't just assume they'll reason like "normal people". The very same thing is actually hinted in the paper you linked (calling it a myth that "normal people" are involved in many shootings).
His conclusions might be reasonable. But his "logic" is of _no value_ to prove that. And this kind of crap isn't used by the one side of this debate only, as you probably are aware.
Blanket claims like "If more people had guns in their home there would be fewer home robberies" derived without looking if the assumptions are actually reasonable are worthless. That is my claim. Nothing else.
I, specifically, wasn't refering to any handgun statistics, but to death penalty/crime statistics. I did so with the intent of discouraging trusting the kind of naive logic the op used by showing a statistical counter example. I have an opinion on the handgun issue, but I have not expressed it in this thread. I just happen to think that naive logic clouds the issue more than clarifies it.
There might be a case to make for guns (or gun control), but naive logic isn't a good way to make it. Ofcourse, this is slashdot...
(The paper you linked was frankly unimpressive. Statistics have their very own set of problem, eg they can be hard to analyze and don't necessarily reveal casuality.)
Yeah, and the death penalty really makes for less crimes as well? Check the statistics, trying to use naive logic on these kinds of social phenomena is doomed. Your claim above, while seemingly logical, is _absolutely useless_. Crap. Nonsense.
Repeat: I will not use naive logic to analyze complex social phenomena.
I'm late, but you really have no clue and basis for these statements:-/
"C++ selects the method to call based on the types supplied to the method. That's exactly the same pattern matching functional languages have."
Ok, the way you confuse polymorphism, overloading, and pattern matching in this statement is just dear. Runtime or compile time? Same difference!
"There is nothing safe with type inference, as I previously demonstrated. "
No, you certainly did not demonstrate this, you demonstrated that you don't know what OCaml's type inference does for you.
"I've talked about an error, not a choice: someone mistakenly types 'list' instead of 'map': the error will propagate deep in the code."
If you've programmed in such a way that this is true, you only have _one_ place to fix it, just like with your typedeffed code. This is a matter of abstraction, in OCaml as well as in C++.
And type inference and common interfaces are actually contrary, as the overloading, since type inference has to resolve types at compile time it can't properly resolve overloaded functions like an explicitly typed language can. And that's a problem, with OCaml, which we resort to functorial interfaces for solving (i e we dont have overloading but allow parametrisation on name spaces, achieving the same affect in a more controlled manner), since OCaml doesn't have type classes like Haskell does. Look at the great lenghts C++ and Java goes to make sure to define common interfaces for collections and iteration. And for good reason, common interfaces are a _good thing_. Exactly because you can change a 'map' to a 'list' in one place and get great effects.
You should actually bother to learn stuff properly before showing of, well, your ignorance.
The decision to use a non-tail-recursive List.map implementation was a choice for supperior efficiency in the (far more) common case, e g with smaller lists, where it's significantly faster than List.rev_map. People who needs to deal with 50000 element long lists can cope with using List.rev_map or switching to a different data structure like, say, an array or a dynamic vector. These kind of engineering tradeoffs, efficiency vs generality and similar, _needs_ to be made, and the fact that OCaml chose to optimize for the common case and chose efficieny over theoretical beauty (while giving easy access to a more general solutin) should actually tell you that OCaml is a serious product and not an academic curiousity (as much as I adore those) or a beginners toy. You can think they traded the wrong way, certainly, but their decision absolutely isn't one of ignorance or immaturity.
As for a recursion depth of 50000 being too low, how deep does your recursion usually take you before you start considering the tail-recursive option? If you need greater recursion depth, increase your stack. Simple as that. As for the default, trying it out with Python I got a maximum recursion depth of between 900 and 1000, and that's a practical product used by many. C with msys/mingw/gcc on winXP got a limit of around 72000. That's really not all that much better than the 65000 I got from the OCaml interpreter for the same simplistic program on the same machine.
Ehrm, that's a problem of education, needing better intro texts, not of the language. Here's the truth: functional programming is no harder to imperative programming. It only appears that way because most of the current educational material isn't written by people who understand the needs of non-programmers. The bracketing is only a problem for those who are used to different syntaxes really.
> In programing, unexpected side-effects in functions is generally considered to be impolite. I think this applies to UI, too.
Ahhh, but don't you see, it's really the same thing. You only need to realize that the programming language is nothing but the most powerful and complex computer UI you're using.
So... you've had it with GUI and usability because marketing is clueless?
OSS software authors/designers don't have to worry about marketing. Ergo they can (and darn well should), as this article suggests, do the Right Thing(tm). Or, to be more true to the article, they can _avoid_ to do the Wrong Thing, since the Right Thing might vary with audience while the Wrong Thing is universal (i e its defined as not being the right thing for anybody). That's really what it ammounts to. You personally prefer xterms, that is an entierly valid preference for some, and a completly idiotic thing to suggest that everyone should adapt to. But that is an awful excuse for designing a useless GUI. If you're going to do it, at least try to avoid doing it wrong. Marketing is a much better excuse, but its an excuse that most OSS developers don't have.
To which there is only one reply: so what? Your customer at that point already represented a small percentage of the market, and that percentage was only headed towards an increasingly irrelevant piece of the economic pie. You don't engineer, build, and sell a new processor for yesterdays or todays market, you do it for tomorrows. You just have to make sure the compability mode isn't unusably slow for a large percentage of the market (for the P2 it wasn't, if only because of the fact that the 16bit market had already imploded).
Your customer was better of using the old P2, nigh on everyone else got way better mileage out of that PIII.
Read the last post at
http://c2.com/cgi/wiki?FailFast
It's not about ignoring errors, it's about the central idea that you'll never, _ever_, be able to write 100% perfect code, and if you could your code will be so full of error checking that it's both unreadable and, as a result, unmaintainable, masking logic bugs and similar. It's a better economy to come up with better ways to deal with failure than trying to prevent it altogether. And the final solution will be more stable.
This is an important realisation: Failure is inevitable, how you deal with it is what matters.
I'll just clarify a fact that has been missed or somewhat obfuscated by other replies. You're completly confused as to relationship between macros/templates as found in C++/LISP and how they are used for achieving genericity in C++ on one hand and true generics as found in Ada, ML, C#, or Java 1.5. With the latter kind the generic functions/types can be statically type checked in isolation, long before it is instantiated as must be done for C++. When they type check they are type safe and end up providing much greater type safety than Java 1.4's idiom did, by providing type constraint on type parameters and type guarantees on collection content.
Generics are not templates, but genericity can be achieved using templates. However, since generics aren't as powerful as templates they are also very easy to make perfectly type safe. You have some (fun) learning to do!
But the professor who taught the Optimizing Compiler course I took also believed the EPIC play was a step in the wrong direction. He believed that the demands it puts on compiler tech are infeasible to meet at all, let alone in a reasonable timeframe.
It might also be a mistake to believe that future software technologies will reward (=won't punish) extensive static compile time analysis over dynamic run time decisions. Advanced compiler tech is about proving invariants, and that is hard to do when information is lacking (i.e. compile time).
It might not be bad tech, but it could very well be a poor tradeoff.
And whooooosh, there goes the article flying way above most posters head. Where did he say he thought using Python or any main stream scripting language for developing entire mobile apps on today's hardware was a great idea?
...."
I believe he was talking about domain specific scripting language doing high level abstraction stuff. That's not the same thing as having the full script compiler (text interpreter) and a general purpose language on the phone. That probably refers to using stuff where a few script instructions invoke speedier compiled code with simple conditionals. Stuff like
"if (keypressed up) move ship up",
not "if (inkey blurb blurb) plot pixel 1, plot pixel 2,
or even "if (inkey blurb blurb) erase ship, ship position = ship position - 1, draw ship".
High level really means that. A small (and these can be really small, a _few_ k is often plenty) bytecode interpreter with special purpose high-level commands can do wonders for productivity and can be plenty speedy. It's a very attractive technique for developing software.
*tick*c k*
1,289,646,7458 9,646,747 ...
:-)
1,289,646,743
*tick*
1,289,646,744
*ti
1,289,646,745
*tock*
1,289,646,744
*tick*
*tick*
1,289,646,746
*tick*
1,2
Gee, I'm really glad they provided a singular digit precision