Thanks for the info. It was my inference that a broker will only loan shares that, with statistical near-certainty, it will never need to call in, but I didn't know how this was arranged. This no doubt explains why it's hard to find shares to short today!
That is an amusing quote, and I don't disagree, but how long can SCO really drag this out? Especially given SCO's insistence on bringing the public into this (and even though they're delaying resolution with a smokescreen of vagueness and equivocation), I don't see the courts letting us remain in limbo for more than a couple years. And I don't think the markets could ignore a court decision against SCO!
This was also clear from the ineptitude of their slide presentation: If there were any competant techs in the company, the execs would at least have had them sanity check the presentation to avoid making fools of themselves. Which evokes the amusing image of SCO execs and lawyers staring dumbly at Linux and SysV code in Word and, with only the fuzziest comprehension, trying to figure out what to paste into PowerPoint.
As long as you didn't highly leverage yourself borrowing those shares (in which case your broker may require you to buy them back), just remember why you shorted them and wait. Do you see any new evidence that SCO will come out on top? If not, just remember, the market can be stupid, but reality eventually intervenes.
Granted, the longer they take to crash, the lower your return per time is, but I'd bet you're still sitting on some valuable shorts. (Unless you're forced to buy them because your broker needs them to close long positions. Do any experienced investors here know how likely that is and under what scenarios it happens?)
If my broker had shares to lend me, I'd short them. Does anyone know where you can still do this?
Saying they'll all of a sudden "get it" and make sure their patches work is [naive|disingenuous|dumb].
I didn't say "all of a sudden", and "screw up a few times" was probably an understatement. Maybe they'll continue screwing up for years, and we'll all get a good laugh out of it. The difference is, if these screw-ups get automatically installed on millions of home computers, the public embarrassment factor will be much higher than for an SQL Server botch. That's the sort of experience they'ell learn from.
Bet on it, Microsoft will figure it out eventually. They already have one of the best security response processes (not the most secure software!) in the business, having started with one of the worst.
Microsoft and others aren't going to stop producing buggy software.
(Really, the effort would be Herculean.) So when there's a hole that will
harm users, and knowing that most users won't voluntarily apply patches,
what are they supposed to do? Saying "you should have patched" doesn't help
their image, and doesn't help computing in general. When exploits can
spread across the net in minutes, it's not even tenable for sophisticated
users. Having users apply their own patches is an inherently losing
proposition.
What's likely to happen? Microsoft will screw up a few times, to great
embarrasment, then they will by economic necessity learn how to make
reliable patches. After all, their only alternative is the greater
embarrasment of rampant worms and viruses. The rest of the industry
(including free software) will see that it is possible, and be pressured to
do the same. It may be rocky for a while, but the end result is that millions of naive
users will have reasonably secury systems. This is a huge improvement over
today.
I don't write a lot of Python, so there may be some more subtle gotchas I haven't run across, but two flaws in its whitespace rules instantly jump out at me:
Continuation lines suck. They're visually ugly and a pain when editing. Why can't Python assume a line is a continuation when it starts to the right of the previous line? NB: don't give me any "good programmers don't need long lines" clap-trap.
Whitespace sensitivity is not optional. There is no "long-hand" to resort to when you want it "your way"--or want to protect your code against mangling in transit.
I do regularly use another whitespace-sensitive language that does not have these problems: Haskell. So when I program Python, I feel acutely that Python got it wrong.
was recently Conumer Reports top-rated laser printer. You can get it pretty cheap if you look around, and frankly I think it's worth it just for the satisfaction of really crisp text. I don't actually own a printer, but I wouldn't mess around with an inkjet if I needed one.
(That said, Consumer Reports doesn't pay much attention to lasers, probably because most home users want to print color pictures. The only others they reviewed were the HP 1000 and 1200se, which both also got excellent marks.)
In the US the GPS coordinates are only used for emergencies and not yet for actually providing value to the user in other situations.
I can't figure this out. I first saw this feature in a phone over a year ago, and it seems common now. So all the manufacturers have gone to the expense of adding GPS to their phones, yet they don't even include a simple "what are my coordinates" feature in the UI. What are they waiting for?
The FSF has expanded the explanation of its position (about
which I asked Eben Moglen in his slashdot
interview), but I still don't buy it.
Under Section 7, the "field of use" restriction is a "conditions are imposed
on you [the distributor of GPL'ed software] that contradict the conditions
of this License". The "conditions of this license" require, for example,
that those receiving distributions of GPL'ed software have the right to run
the program for any purpose (Section 0), the right to modify it for any
purpose (Section 2), etc.
Yes, the patent license imposes conditions on "you"; and yes, those
receiving the software may not have all the rights (ie, unfettered
modification) that the GPL requires. But the second is not caused by the
first, and therefore section 7 does not apply.
Specifically, as I understand, the hypothetical patent licenses would say
something like, "this license permits you to practice patent P only for the
purposes of implementing standard S". It would not say anything about the
terms under which you may distribute your implementation. The fact that
others will be restricted in how they may modify your software is due to
their license from the patent holder (even if it happens to be the same
license you have), not due to a "condition imposed on you".
The "detailed step-by-step example" makes the fallacy more plain:
However, he knows full well of a condition on that code that contradicts the
GPL (violating Section 7) -- namely, he knows that C's patent license
prohibits folks from taking his URL parsing code and putting it into, say, a
search engine. Therefore, under GPL Section 7, he is prohibited from
redistribution.
I similarly know full well that C's patent licence prohibits folks from
taking GNU Emacs and adding URL parsing code. By this logic, I am
prohibited from redistributing Emacs.
The only difference between the two cases is that a large class of modifications (any that would remove the program from the scope of the patent license) is prohibited in the first, while a smaller class (any that would bring Emacs under the scope of the patent) is prohibited in the second. But this is immaterial to the GPL.
That's what mozilla.org is all about. A technology demonstration.
While millions of people want a decent browser. Yes, there are free
alternatives and there are offshoots of mozilla, but people use mozilla.
You're saying the developers are right to ignore them? That's inconsiderate
and plain stupid.
As I said, I have no problem with this guy working on his research project.
Someday, hopefully, it will have the benefits you're talking about. But
people have been promising programs that learn about you for decades, so
forgive me if I'm not wildly optimistic.
Finally, I don't understand the criticism of Mozilla's current
autocomplete behaviour.
Ok, you got me started. Like I said, some of the problems are lack of
simple features, some are UI bogosities, and they all add up to making the
URL bar a miserable experience. (I'm using the unix version, in case it
matters.)
Can't scroll backwards to recently visited sites.
Can't search, except on the first letters.
Can't complete part of a URL. Ie, just the hostname part or just the
next path element. When I've visited large parts of a site, this would let
me navigate much mor efficiently. Funny, I thought the web was a
hierarchical namespace.
Can't show only the next part of the path. So if I know the site I'm
looking for starts with an 's', I have to scroll through a million slashdot
entries to find it.
Can't complete only the characters that are common to all entries. Ie,
if I've been to slashdot.org and slashnot.org, I should be able to type
"sl" and complete to "slash".
Doesn't remember bookmark keywords. I search with "? foo" and I often
want to repeat searches.
Only shows a small number of completions at once.
Most of the information about a history entry is cut off. In
particular, I see only a few characters of the site's title, which is often
crucial to figuring out which entry I want. It will even show two entries
that are indistinguishable! They should use the full window width, and let
me scroll if not everything is showing, or something.
If I quickly type "si<tab>", it completes to "http://slashdot.org". No,
that's not a typo. Mozilla can't even get keyboard input right!
It grabs the keyboard and mouse while the list of completions is
showing, so I can't do anything else (even switch programs) without clicking
somewhere to stop autocomplete. (This is true even if there were no
completions!)
No way to make it only come up if I hit a key.
If I have some text copied that I want to paste into the URL bar, and I
first start editing the URL, then click the middle button to paste, it
doesn't paste. I first have to click to stop auto-complete, then paste.
If I'm in the URL bar but autocomplete is not showing (eg, because I
used the arrow keys), there's no way to bring it up again without typing
more at the end of the URL.
The way I think completion should work is to match the shortest matching non-unique segment.
<snip>
Damn straight. Leave it to the mozilla people to turn to machine learning when obvious heuristics and UI tweaks would have a much more immediate benefit, and when there are many time-tested examples to follow. It's clear that there aren't enough people in the project who just want a good browser. Autocomplete appears to be a case of copy whatever NS4/IE does, and who cares if it's actually useful?
I know the machine learning part is just one guy's pet project, and I'm not trying to stop him. It's just that the glaring deficiencies he points out shouldn't exist in the first place.
But heck, while I'm at it, here is a criticism of the machine learning approach: Part of the value of shell autocomplete is that it's predictable. I can type some letters, tab, more letters, tab, without pausing, because I know what the completions will be. Machine learning risks giving up this benefit. It may still be a win, though, especially for beginners. We'll see.
The heart beats only so many times before wearing out (as an aside almost all animals have the same number of lifetime heart beats regardless of size, environment etc except humans have about 3X as many)
This is readily debunked. Start with bats and most birds.
Trust me, I don't. (In fact, I loathe SQL. And I didn't even mention SQL in the original message, although I believe it is often the lesser of evils.)
SQL needs indices because they're required to meet the relational model. If you're not relational, you don't need them.
Huh? The relational model does not include indices at all. And any sort of processing of large amounts of data benefits from indices. You just have to build them yourself without a database system.
we don't need trasactions because our commands are already atomic.
Which means you have to write all of the roll-back processing by-hand if you want any non-trivial commands. By the way, atomicity is only one aspect of a transaction.
First of all: it does have queries. The difference is that you write them in (for instance) Java. And that's not "good enough for now", that's several orders of magnitude more powerful than SQL.
In the same sense that assembly code is more powerful than Java. I'll take relational algebra (which, admittedly, is crappily implemented in SQL) over procedural Java any day, unless I have very particular needs.
transactions (for instance object synchronization in Java,
I hope I don't have to tell you that serialization is in a whole different ballpark from transactions.
Queries are run against pure Java language objects, giving developers all the flexibility of the Collections API and other APIs, such as the Jakarta Commons Collections and Jutil.org.
In other words, "it doesn't have queries". What real project doesn't (eventually) need queries? And even if writing your queries "by hand" in Java is good enough for now, what real project doesn't eventually need indices, transactions, or other features of a real database system?
There's a reason why it's dismissed out-of-hand. That's because the
industry has to work with real computers, not virtual machines.
That's a bizarre thing to say. Do you think that Python code doesn't
eventually execute real machine instructions on real ints, floats, and
pointers? What evidence do you have that the programmer's view of "data"
should match the hardware's view of data? For certain performance-critical
or low-level code this is necessary, of course. But I'd much rather have a
higher-level view of the world. It's simlpy more productive.
Since when is Java a "primitive" language?
Will you accept that C is a primitive language? What does Java has that C
doesn't? Garbage collection, which is old hat (what languages in use today
besides C and C++ don't have garbage collection?). A simplistic object
system to which it does not even adhere faithfully (int et al). It doesn't
have pointers, but it does have unsafe casts, so it's not type-safe. If you
add generics and boxing, I'll probably take Java out of the primitive
category.
Or is this just your bias that all strongly typed languages are
primitive?
No!! Haskell, for example, is quite advanced.
p.s. I am not a Java fan.
I am neither a Java fan nor a Python fan.
That's why you only accept string input, and validate as a string, and
only then convert it to your strong typed data.
I'm glad you do. But it will take you longer to process the text than it
would in Python. Is there any chance that you would do more careful
validation, or at least emit more meaningful error messages, if you were
programming in Python? This is a perfect example of how "scripting"
features may lead to greater robustness.
We all want code that we can see is logically correct without a
compiler.
I still contend that it is much harder to produce such "obviously correct"
code in a low-level language. You lose concision, mechanical details get in
the way, and related pieces are in different parts of the code. All of
these things make reading harder.
But compilers are also useful tools to catch those dumb mistakes that we
all make.
I really don't deny that. I just don't think the sacrifice in productivity
and expressivity are worth it, just to catch these errors. Have you tried a
language like Haskell? One of the wonderful things about it is it catches
type errors without imposing a burden on the programmer.
PS. Thanks for replying thoughtfully to an admittedly trollish message.
It's a shame that this view is dismissed out-of-hand by the industry. Of course, this is an industry so conservative that a primitive language like Java is considered "state of the art". I sometimes wonder which will happen first: the industry wakes up to the possible productivity improvements of runtime-typed languages, or type-inferencing languages become convenient and accessible enough to take over. Either one would be a great day.
Those who say "why would I ever choose not to have certain errors detected at compile time" are missing the big picture. The errors that can be caught by static typing are only the beginning of the errors that can occur in a software system. And they are the ones that will be caught easily in testing. If the uncertainties of runtime typing encourage you to write more tests, so much the better! And have you noticed how much easier it is to whip up tests, and to add the extra code to deal with corner cases, in such languages? In my experience, strongly-typed code tends to be more susceptible to unexpected inputs, just because it's such a pain to handle and test them.
Further, runtime-typed languages are usually better at slaying the real dragons of software developments: the complex errors that are beyond the scope of typing. Guido said a wise thing:
You can also easily write a small piece of code in Python and see that it works.
As a maintainer, I would much rather have code that I can see is logically correct with my eyes, than code that a compiler can tell me type checks. High-level languages are much better at expressing complex ideas in clear code; in C and Java, the idea gets lost in the mechanical details.
My experience has convinced me that a strong team can produce more robust code in a runtime-typed language than a similar team using a traditional strongly-typed language, given the same amount of time. The first team also has more leeway in trading robustness for speed of completion, when that counts.
Tell him that judges prefer plain language. Of course, your boss's boss probable uses terms like "monetize" and "action item", in which case this is a lost cause.
Slashdot Mirror
This must mean that Bruce Perens isn't afraid ESR is going to shoot him anymore.
Thanks for the info. It was my inference that a broker will only loan shares that, with statistical near-certainty, it will never need to call in, but I didn't know how this was arranged. This no doubt explains why it's hard to find shares to short today!
That is an amusing quote, and I don't disagree, but how long can SCO really drag this out? Especially given SCO's insistence on bringing the public into this (and even though they're delaying resolution with a smokescreen of vagueness and equivocation), I don't see the courts letting us remain in limbo for more than a couple years. And I don't think the markets could ignore a court decision against SCO!
This was also clear from the ineptitude of their slide presentation: If there were any competant techs in the company, the execs would at least have had them sanity check the presentation to avoid making fools of themselves. Which evokes the amusing image of SCO execs and lawyers staring dumbly at Linux and SysV code in Word and, with only the fuzziest comprehension, trying to figure out what to paste into PowerPoint.
Granted, the longer they take to crash, the lower your return per time is, but I'd bet you're still sitting on some valuable shorts. (Unless you're forced to buy them because your broker needs them to close long positions. Do any experienced investors here know how likely that is and under what scenarios it happens?)
If my broker had shares to lend me, I'd short them. Does anyone know where you can still do this?
MacGyver used pencil erasers.
I didn't say "all of a sudden", and "screw up a few times" was probably an understatement. Maybe they'll continue screwing up for years, and we'll all get a good laugh out of it. The difference is, if these screw-ups get automatically installed on millions of home computers, the public embarrassment factor will be much higher than for an SQL Server botch. That's the sort of experience they'ell learn from.
Bet on it, Microsoft will figure it out eventually. They already have one of the best security response processes (not the most secure software!) in the business, having started with one of the worst.
What's likely to happen? Microsoft will screw up a few times, to great embarrasment, then they will by economic necessity learn how to make reliable patches. After all, their only alternative is the greater embarrasment of rampant worms and viruses. The rest of the industry (including free software) will see that it is possible, and be pressured to do the same. It may be rocky for a while, but the end result is that millions of naive users will have reasonably secury systems. This is a huge improvement over today.
-
-
I do regularly use another whitespace-sensitive language that does not have these problems: Haskell. So when I program Python, I feel acutely that Python got it wrong.Continuation lines suck. They're visually ugly and a pain when editing. Why can't Python assume a line is a continuation when it starts to the right of the previous line? NB: don't give me any "good programmers don't need long lines" clap-trap.
Whitespace sensitivity is not optional. There is no "long-hand" to resort to when you want it "your way"--or want to protect your code against mangling in transit.
(That said, Consumer Reports doesn't pay much attention to lasers, probably because most home users want to print color pictures. The only others they reviewed were the HP 1000 and 1200se, which both also got excellent marks.)
I can't figure this out. I first saw this feature in a phone over a year ago, and it seems common now. So all the manufacturers have gone to the expense of adding GPS to their phones, yet they don't even include a simple "what are my coordinates" feature in the UI. What are they waiting for?
You must not have checked the link before you posted, since it has been dead at least since last night. Anyone know why? What was the last update?
Yes, the patent license imposes conditions on "you"; and yes, those receiving the software may not have all the rights (ie, unfettered modification) that the GPL requires. But the second is not caused by the first, and therefore section 7 does not apply.
Specifically, as I understand, the hypothetical patent licenses would say something like, "this license permits you to practice patent P only for the purposes of implementing standard S". It would not say anything about the terms under which you may distribute your implementation. The fact that others will be restricted in how they may modify your software is due to their license from the patent holder (even if it happens to be the same license you have), not due to a "condition imposed on you".
The "detailed step-by-step example" makes the fallacy more plain:
I similarly know full well that C's patent licence prohibits folks from taking GNU Emacs and adding URL parsing code. By this logic, I am prohibited from redistributing Emacs.
The only difference between the two cases is that a large class of modifications (any that would remove the program from the scope of the patent license) is prohibited in the first, while a smaller class (any that would bring Emacs under the scope of the patent) is prohibited in the second. But this is immaterial to the GPL.
While millions of people want a decent browser. Yes, there are free alternatives and there are offshoots of mozilla, but people use mozilla. You're saying the developers are right to ignore them? That's inconsiderate and plain stupid.
As I said, I have no problem with this guy working on his research project. Someday, hopefully, it will have the benefits you're talking about. But people have been promising programs that learn about you for decades, so forgive me if I'm not wildly optimistic.
Finally, I don't understand the criticism of Mozilla's current autocomplete behaviour.
Ok, you got me started. Like I said, some of the problems are lack of simple features, some are UI bogosities, and they all add up to making the URL bar a miserable experience. (I'm using the unix version, in case it matters.)
- Can't scroll backwards to recently visited sites.
- Can't search, except on the first letters.
- Can't complete part of a URL. Ie, just the hostname part or just the
next path element. When I've visited large parts of a site, this would let
me navigate much mor efficiently. Funny, I thought the web was a
hierarchical namespace.
- Can't show only the next part of the path. So if I know the site I'm
looking for starts with an 's', I have to scroll through a million slashdot
entries to find it.
- Can't complete only the characters that are common to all entries. Ie,
if I've been to slashdot.org and slashnot.org, I should be able to type
"sl" and complete to "slash".
- Doesn't remember bookmark keywords. I search with "? foo" and I often
want to repeat searches.
- Only shows a small number of completions at once.
- Most of the information about a history entry is cut off. In
particular, I see only a few characters of the site's title, which is often
crucial to figuring out which entry I want. It will even show two entries
that are indistinguishable! They should use the full window width, and let
me scroll if not everything is showing, or something.
- If I quickly type "si<tab>", it completes to "http://slashdot.org". No,
that's not a typo. Mozilla can't even get keyboard input right!
- It grabs the keyboard and mouse while the list of completions is
showing, so I can't do anything else (even switch programs) without clicking
somewhere to stop autocomplete. (This is true even if there were no
completions!)
- No way to make it only come up if I hit a key.
- If I have some text copied that I want to paste into the URL bar, and I
first start editing the URL, then click the middle button to paste, it
doesn't paste. I first have to click to stop auto-complete, then paste.
- If I'm in the URL bar but autocomplete is not showing (eg, because I
used the arrow keys), there's no way to bring it up again without typing
more at the end of the URL.
Well, that's enough for now.<snip>
Damn straight. Leave it to the mozilla people to turn to machine learning when obvious heuristics and UI tweaks would have a much more immediate benefit, and when there are many time-tested examples to follow. It's clear that there aren't enough people in the project who just want a good browser. Autocomplete appears to be a case of copy whatever NS4/IE does, and who cares if it's actually useful?
I know the machine learning part is just one guy's pet project, and I'm not trying to stop him. It's just that the glaring deficiencies he points out shouldn't exist in the first place.
But heck, while I'm at it, here is a criticism of the machine learning approach: Part of the value of shell autocomplete is that it's predictable. I can type some letters, tab, more letters, tab, without pausing, because I know what the completions will be. Machine learning risks giving up this benefit. It may still be a win, though, especially for beginners. We'll see.
This is readily debunked. Start with bats and most birds.
See my reply to the other reply to my message. See also the AC followup.
Trust me, I don't. (In fact, I loathe SQL. And I didn't even mention SQL in the original message, although I believe it is often the lesser of evils.)
SQL needs indices because they're required to meet the relational model. If you're not relational, you don't need them.
Huh? The relational model does not include indices at all. And any sort of processing of large amounts of data benefits from indices. You just have to build them yourself without a database system.
we don't need trasactions because our commands are already atomic.
Which means you have to write all of the roll-back processing by-hand if you want any non-trivial commands. By the way, atomicity is only one aspect of a transaction.
We are disagreeing on terminology. Here is a reference to what I mean by serialization:
(SICP 3.4.2)In the same sense that assembly code is more powerful than Java. I'll take relational algebra (which, admittedly, is crappily implemented in SQL) over procedural Java any day, unless I have very particular needs.
transactions (for instance object synchronization in Java,
I hope I don't have to tell you that serialization is in a whole different ballpark from transactions.
In other words, "it doesn't have queries". What real project doesn't (eventually) need queries? And even if writing your queries "by hand" in Java is good enough for now, what real project doesn't eventually need indices, transactions, or other features of a real database system?
That's a bizarre thing to say. Do you think that Python code doesn't eventually execute real machine instructions on real ints, floats, and pointers? What evidence do you have that the programmer's view of "data" should match the hardware's view of data? For certain performance-critical or low-level code this is necessary, of course. But I'd much rather have a higher-level view of the world. It's simlpy more productive.
Since when is Java a "primitive" language?
Will you accept that C is a primitive language? What does Java has that C doesn't? Garbage collection, which is old hat (what languages in use today besides C and C++ don't have garbage collection?). A simplistic object system to which it does not even adhere faithfully (int et al). It doesn't have pointers, but it does have unsafe casts, so it's not type-safe. If you add generics and boxing, I'll probably take Java out of the primitive category.
Or is this just your bias that all strongly typed languages are primitive?
No!! Haskell, for example, is quite advanced.
p.s. I am not a Java fan.
I am neither a Java fan nor a Python fan.
That's why you only accept string input, and validate as a string, and only then convert it to your strong typed data.
I'm glad you do. But it will take you longer to process the text than it would in Python. Is there any chance that you would do more careful validation, or at least emit more meaningful error messages, if you were programming in Python? This is a perfect example of how "scripting" features may lead to greater robustness.
We all want code that we can see is logically correct without a compiler.
I still contend that it is much harder to produce such "obviously correct" code in a low-level language. You lose concision, mechanical details get in the way, and related pieces are in different parts of the code. All of these things make reading harder.
But compilers are also useful tools to catch those dumb mistakes that we all make.
I really don't deny that. I just don't think the sacrifice in productivity and expressivity are worth it, just to catch these errors. Have you tried a language like Haskell? One of the wonderful things about it is it catches type errors without imposing a burden on the programmer.
PS. Thanks for replying thoughtfully to an admittedly trollish message.
Those who say "why would I ever choose not to have certain errors detected at compile time" are missing the big picture. The errors that can be caught by static typing are only the beginning of the errors that can occur in a software system. And they are the ones that will be caught easily in testing. If the uncertainties of runtime typing encourage you to write more tests, so much the better! And have you noticed how much easier it is to whip up tests, and to add the extra code to deal with corner cases, in such languages? In my experience, strongly-typed code tends to be more susceptible to unexpected inputs, just because it's such a pain to handle and test them.
Further, runtime-typed languages are usually better at slaying the real dragons of software developments: the complex errors that are beyond the scope of typing. Guido said a wise thing:
As a maintainer, I would much rather have code that I can see is logically correct with my eyes, than code that a compiler can tell me type checks. High-level languages are much better at expressing complex ideas in clear code; in C and Java, the idea gets lost in the mechanical details.My experience has convinced me that a strong team can produce more robust code in a runtime-typed language than a similar team using a traditional strongly-typed language, given the same amount of time. The first team also has more leeway in trading robustness for speed of completion, when that counts.
Tell him that judges prefer plain language. Of course, your boss's boss probable uses terms like "monetize" and "action item", in which case this is a lost cause.