... just once, and people make fun of you when you screw up. I'm surprised it got modded up, despite that.
The CC city wifi works fine at ground level. Unfortunately, we were staying at my aunt's place on the 17th floor. Fortunately, I was able to access a wireless network named "linksys" from up there...
Someone at DARPA has forgotten that DOD AI research has been worth every penny spent on it. Very little of it turned directly into military applications, but the stuff that did was spectacularly successful. Look here (emphasis added):
AI systems proved their strategic value in support of operations Desert Shield and Desert Storm. For example, DART (Dynamic Analysis and Replanning Tool) solved the logistical nightmare of moving the U.S. military assets to the Saudi Desert. The application was developed to schedule the transportation of all U.S. personnel and materials such as vehicles, food, and ammunition from Europe to Saudi Arabia. This one application alone reportedly more than offset all the money the Advanced Research Projects Agency had funneled into AI research in the last 30 years.
When I worked at (long-lamented) Xerox AI Systems, we did the usual code freeze before release thing. Once a code freeze was in effect, the only thing that would unfreeze it was a bug that:
It also makes error recovery very difficult, something that we know is quite important from all that malformed HTML code out there. The XML creators knew that too.
The extra redundancy of closing tag labels makes sense when your documents are generated by humans, like most SGML was.
It makes no sense at all for documents that are generated by programs, especially programs that create documents in some canonical manner like building DOM structures and then serializing them - if you trust the serializer, then it can't drop a close tag.
Comcast broadband is OK - fast downloads, pokey uploads and semi-annual short outages. I would drop it like a rock, though, if I could get broadband from anyone else, especially a cool local ISP like zzapp.
If Verizon fiber has reliability near to my wired phone, I'd consider dumping the land line and going with VOIP.
Would one of you people who glories in generating prices for BYO systems price their silent configuration and compare it to the cost of a Mac mini, which is damn quiet out of the box?
... because they would have to admit that the existing tax code is an internally inconsistent nightmare. My wife is a ten-year veteran at H&R Block. She tells me that in their first class you have to take from them before becoming a preparer, the instructor said something like this:
"If you're here because you want to make sense of your taxes, or of the tax system in general, we can't do that for you - Congress has created sets of inconsistent laws and handed them off to the IRS for enforcement. What we can do is tell you what procedures and strategies have been accepted by the IRS in the past."
This is why filing your taxes can't be a purely mechanical procedure - an expert system based on IRS rules and regulations would prove the equivalent of 1+1 = 3, and explode shortly thereafter.
Essentially what Harvard did here was to apply a filter that discriminates against people with Internet technical skills. A pretty weak filter, granted, but you have to have a little something on the ball to find and paste together significant fields from multiple URLs.
We have enough trouble with lack of Internet savvy in American business management as it is.
... but Gorman didn't make it because he clearly doesn't know the first thing about how Google search works.
The flaw in Google's plan to digitize lots of books is not "too much information". It's too much information without links generated by people. Without those links, PageRank doesn't work, and Google search degenerates to keyword search.
This digital library could be as useful as the rest of Google if people who are experts at reading and classifying texts (like librarians, maybe) could go through it and make meaningful links. Google could get partway to this if they digitized the texts and used the card catalog information to start the linking process.
Gorman and the membership of his orgainzation could then be viewed as contributing to the solution, rather than as Luddites trying to preserve their jobs and old habits.
You know, when you set out to make fun of something, it helps if you actually know something about what you're making fun of. I don't have the time to give your posting a full-scale line-by-line fisking, so I'll just hit the high points here:
You name it, LISP implemented it way back when. Things like visual form designers, refactoring IDEs, regular expressions and the like don't count...
They don't count because Lisp did implement them "way back when". LOOPS (a Xerox PARC OO system, one of the predecessors of CLOS) had a visual forms designer and a refactoring IDE... in 1985.
I've used LISP for 70 years...
Close, but no cigar. Lisp was invented in the late 1950's, so it's a little over 45 years old today.
... some people find LISP a bit daunting, and they keep wanting to write 'a + b' instead of '(add a b)' just because it's "shorter" and "clearer".
I find "(+ a b c d e)" shorter and clearer than "a + b + c + d + e", myself.
LISP has exactly the strengths and weaknesses you would expect from a pure functional language.
One of the reasons Lisp is still around is that it isn't a pure-anything language. Check out those SETQs in the original LISP 1.5 manual.
Lisp invented conditional execution (Fortran at the time had only computed GOTO when Lisp introduced COND), and over the years it has absorbed structured programming, IDEs, and object-oriented programming, usually by helping to invent or extend them.
I just think it's weird that people always jump up and go 'LISP IS BETTER OH YES IT IS' when a language discussion comes round.
Yes, Grasshopper, it is good that you are learning to Question Authority. But, you should also Listen to Authority's Response, and if it turns out that Authority is Indeed Correct, you are obliged to Admit It.
and don't understand why this is a bad idea in portable code.
My current task involves taking huge lumps of code for processing satellite science data and porting them from their native environement (big iron SGI) to x86/linux. I've seen code ranging from multiple pre-compiled binaries with Perl drivers that automatically do the right thing on different platforms, to code like the above, with lots of stuff inbetween. Scary...
... from scientist and engineer coders. For these guys, FORTRAN is the only reasonable way for them to turn their domain knowledge into production code, for three main reasons:
Libraries - the most bullet-proof, battle-tested numerical code is pretty much all in FORTRAN
Optimizers - if you must wring the last factor of two of performance out of big vectorizing iron, and you're not a CS guru, the FORTRAN compiler is still your best bet
Semantics - FORTRAN the language enforces some constraints that make vectorizing optimization work better than less constrained stuff like C
The problem is, for these guys FORTRAN is a means to an end - most of them have had very little formal training in good coding practice, and worse, most of the code they read was written by people with similar experience.
Maybe what we should do is require scientists and engineers to pair-program with recent CS graduates. Both sides would learn a lot from that.
It's $5/month, so buying a modem would pay for itself in a year or so, but I just rent it anyway. That way, if it ever fails, Comcast gets to replace it, and I've had two fail on me in ~4 years:
one was a badly manufactured piece of junk whose power cord kept falling out
another got nailed by lightning (I think - both the modem and my router (which has one hardwired line that goes around the outside of my house) died after a big storm)
When Comcast announces the speed upgrade in my area, maybe I'll have another modem failure so they can give me a shiny new DOCSIS 2.
Not at all seats, though. Look for the cars with pairs of seats facing tables - there's an outlet underneath the table (which I didn't notice until my fourth ride during a recent visit).
MS has always had a vested interest in making it easy for spyware to get into their browser/OS. They call it "a vibrant third-party market for user-experience-enhancing browser extensions", though. You can see it in the ambiguity in their term for spyware - "Potentially Unwanted Software". A lot of spyware gets into Windows through the "front door" via browser help objects, not through exploits.
The real problem here is that MS will now have to have a list, blessed by them, of whose browser extensions have acceptable behavior and whose don't. If the list is too loose, they'll piss off consumer advocates and the Windows cogniscenti; if it's too tight, they'll piss off their developer community.
Never any mod points when you need them... besides not wanting to give up my karma for the grandparent. Here's the meat of the real posting:
I get the crash too. I found it happens from tables made in word on windows. DO NOT SCROLL when you open a large document on word for mac if it was created on word for windows. Use (??ctrl-)command-end to reach the end of the document (then wait until it actually moves there). You should find that the crashes don't happen anymore after that initial lag. The crash, AFAICT is caused by the renderer in word. It appears as if the tables are converted to a metafile and then rendered. This is a blocking operation. If you attempt to scroll past one of these (which is on a seperate thread), the renderer will ask for data that is beyond the current conversion point (which it thinks is the end of the document). The behavior is not unlike a buffer overflow. I was able to create a trivial 6 page document that exhibited this behavior reliably. Incidentally, I haven't had this problem since the last office patch. Instead, I now get the "out of disk space" message when I try to save a document that has been open for a while. I started getting that after the last OS X upgrade.
Word for OS X isn't slow until you use it to open big complex documents (the ones that TextEdit won't open correctly because they have lots of tables, footnotes, images, a table of contents, etc.). Documents like that barely scroll on my ancient and revered dual 450 MHz G4.
And when they do scroll, they cause Word to crash, about once a day. Makes me feel like I'm running Windows 98 again, except I don't have to reboot afterwards.
... just once, and people make fun of you when you screw up. I'm surprised it got modded up, despite that.
The CC city wifi works fine at ground level. Unfortunately, we were staying at my aunt's place on the 17th floor. Fortunately, I was able to access a wireless network named "linksys" from up there...
See "a herf="http://www.downtowncorpuschristi.com/wiki/DM D/WiFiCity">here. It's free for now and covers the whole downtown area.
Kzin are fast, powerful, honorable, intelligent... and a little paranoid. Not a bad match for an Apple fanboy...
What more needs to be said?
Caused the user to lose work
Had no workaround
The extra redundancy of closing tag labels makes sense when your documents are generated by humans, like most SGML was.
It makes no sense at all for documents that are generated by programs, especially programs that create documents in some canonical manner like building DOM structures and then serializing them - if you trust the serializer, then it can't drop a close tag.
Comcast ($65/month for basic TV + Internet)
zzapp.org ($13/month for backup dialup and email)
Comcast broadband is OK - fast downloads, pokey uploads and semi-annual short outages. I would drop it like a rock, though, if I could get broadband from anyone else, especially a cool local ISP like zzapp.
If Verizon fiber has reliability near to my wired phone, I'd consider dumping the land line and going with VOIP.
Would one of you people who glories in generating prices for BYO systems price their silent configuration and compare it to the cost of a Mac mini, which is damn quiet out of the box?
Just curious...
... because they would have to admit that the existing tax code is an internally inconsistent nightmare. My wife is a ten-year veteran at H&R Block. She tells me that in their first class you have to take from them before becoming a preparer, the instructor said something like this:
"If you're here because you want to make sense of your taxes, or of the tax system in general, we can't do that for you - Congress has created sets of inconsistent laws and handed them off to the IRS for enforcement. What we can do is tell you what procedures and strategies have been accepted by the IRS in the past."
This is why filing your taxes can't be a purely mechanical procedure - an expert system based on IRS rules and regulations would prove the equivalent of 1+1 = 3, and explode shortly thereafter.
Essentially what Harvard did here was to apply a filter that discriminates against people with Internet technical skills. A pretty weak filter, granted, but you have to have a little something on the ball to find and paste together significant fields from multiple URLs.
We have enough trouble with lack of Internet savvy in American business management as it is.
Irregardless of underlying platform.
... but Gorman didn't make it because he clearly doesn't know the first thing about how Google search works.
The flaw in Google's plan to digitize lots of books is not "too much information". It's too much information without links generated by people. Without those links, PageRank doesn't work, and Google search degenerates to keyword search.
This digital library could be as useful as the rest of Google if people who are experts at reading and classifying texts (like librarians, maybe) could go through it and make meaningful links. Google could get partway to this if they digitized the texts and used the card catalog information to start the linking process.
Gorman and the membership of his orgainzation could then be viewed as contributing to the solution, rather than as Luddites trying to preserve their jobs and old habits.
You know, when you set out to make fun of something, it helps if you actually know something about what you're making fun of. I don't have the time to give your posting a full-scale line-by-line fisking, so I'll just hit the high points here:
...
... in 1985.
... some people find LISP a bit daunting, and they keep wanting to write 'a + b' instead of '(add a b)' just because it's "shorter" and "clearer".
You name it, LISP implemented it way back when. Things like visual form designers, refactoring IDEs, regular expressions and the like don't count
They don't count because Lisp did implement them "way back when". LOOPS (a Xerox PARC OO system, one of the predecessors of CLOS) had a visual forms designer and a refactoring IDE
I've used LISP for 70 years...
Close, but no cigar. Lisp was invented in the late 1950's, so it's a little over 45 years old today.
I find "(+ a b c d e)" shorter and clearer than "a + b + c + d + e", myself.
LISP has exactly the strengths and weaknesses you would expect from a pure functional language.
One of the reasons Lisp is still around is that it isn't a pure-anything language. Check out those SETQs in the original LISP 1.5 manual.
Lisp invented conditional execution (Fortran at the time had only computed GOTO when Lisp introduced COND), and over the years it has absorbed structured programming, IDEs, and object-oriented programming, usually by helping to invent or extend them.
I just think it's weird that people always jump up and go 'LISP IS BETTER OH YES IT IS' when a language discussion comes round.
Yes, Grasshopper, it is good that you are learning to Question Authority. But, you should also Listen to Authority's Response, and if it turns out that Authority is Indeed Correct, you are obliged to Admit It.
... when they block iTunes at the microsoft.com firewall.
Or worse, leave it open and fire anyone who accesses it from work...
This is an example of the worse-is-better phenomenon, which attempts to explain why elegant stuff fails in the marketplace, and crufty stuff succeeds.
You are clearly not a member of the majority class I was describing. I was thinking more of the people who write stuff like:
INTEGER*1 PARTS(4)
INTEGER*4 WHOLE
EQUIVALENCE PARTS, WHOLE
and don't understand why this is a bad idea in portable code.
My current task involves taking huge lumps of code for processing satellite science data and porting them from their native environement (big iron SGI) to x86/linux. I've seen code ranging from multiple pre-compiled binaries with Perl drivers that automatically do the right thing on different platforms, to code like the above, with lots of stuff inbetween. Scary...
Libraries - the most bullet-proof, battle-tested numerical code is pretty much all in FORTRAN
Optimizers - if you must wring the last factor of two of performance out of big vectorizing iron, and you're not a CS guru, the FORTRAN compiler is still your best bet
Semantics - FORTRAN the language enforces some constraints that make vectorizing optimization work better than less constrained stuff like C
The problem is, for these guys FORTRAN is a means to an end - most of them have had very little formal training in good coding practice, and worse, most of the code they read was written by people with similar experience.
Maybe what we should do is require scientists and engineers to pair-program with recent CS graduates. Both sides would learn a lot from that.
one was a badly manufactured piece of junk whose power cord kept falling out
another got nailed by lightning (I think - both the modem and my router (which has one hardwired line that goes around the outside of my house) died after a big storm)
When Comcast announces the speed upgrade in my area, maybe I'll have another modem failure so they can give me a shiny new DOCSIS 2.
... would be BitTorrent.
Not at all seats, though. Look for the cars with pairs of seats facing tables - there's an outlet underneath the table (which I didn't notice until my fourth ride during a recent visit).
MS has always had a vested interest in making it easy for spyware to get into their browser/OS. They call it "a vibrant third-party market for user-experience-enhancing browser extensions", though. You can see it in the ambiguity in their term for spyware - "Potentially Unwanted Software". A lot of spyware gets into Windows through the "front door" via browser help objects, not through exploits.
The real problem here is that MS will now have to have a list, blessed by them, of whose browser extensions have acceptable behavior and whose don't. If the list is too loose, they'll piss off consumer advocates and the Windows cogniscenti; if it's too tight, they'll piss off their developer community.
Never any mod points when you need them... besides not wanting to give up my karma for the grandparent. Here's the meat of the real posting:
I get the crash too. I found it happens from tables made in word on windows. DO NOT SCROLL when you open a large document on word for mac if it was created on word for windows. Use (??ctrl-)command-end to reach the end of the document (then wait until it actually moves there). You should find that the crashes don't happen anymore after that initial lag. The crash, AFAICT is caused by the renderer in word. It appears as if the tables are converted to a metafile and then rendered. This is a blocking operation. If you attempt to scroll past one of these (which is on a seperate thread), the renderer will ask for data that is beyond the current conversion point (which it thinks is the end of the document). The behavior is not unlike a buffer overflow. I was able to create a trivial 6 page document that exhibited this behavior reliably. Incidentally, I haven't had this problem since the last office patch. Instead, I now get the "out of disk space" message when I try to save a document that has been open for a while. I started getting that after the last OS X upgrade.
Office for OS X is profitable for MS, so killing it could only be seen as an obvious anti-competitive move by a convicted monopolist.
If they did that, the US Justice Department would be all over them in a heartbeat...
Oh, sorry. Never mind.
Word for OS X isn't slow until you use it to open big complex documents (the ones that TextEdit won't open correctly because they have lots of tables, footnotes, images, a table of contents, etc.). Documents like that barely scroll on my ancient and revered dual 450 MHz G4.
And when they do scroll, they cause Word to crash, about once a day. Makes me feel like I'm running Windows 98 again, except I don't have to reboot afterwards.