You must be thinking of J++, since J# appeared much later with.NET,
long after the contract lawsuit.
J++ wasn't java. Byte code from J++ included new non-optional
instructions, violated the specification, and thus
could not run on any VM but Microsoft's. Microsoft's VM did not support
1.1 features for handling native code. How would Sun have benefited
from a non-java VM pretending to be java?
Just keep some cotton balls and a bottle of rubbing alcohol
on the desk. Swab off the keyboard and mouse once a week.
Q-tips are handy for the spaces between keys.
This Jon Katz article describing slashdot as a "weblog" was the first place I ever saw the term:
http://slashdot.org/features/99/05/13/1832251.shtm l
(Yes, that's from 1999, back when two-digit dates were popular.)
I remember because I found the term confusing and thought it should be the log of a webserver. Thankfully, the abbreviation "blog" came along eventually and prevented further confusion.
If your goal is to elicit information and insight,
you might have better luck not putting your guest on the defensive. Partisan attacks illuminate nothing. Make the guy feel at home, without fear that you will take a cheap shot. On the Daily Show, arch-neocon Bill Kristol was amazingly frank about how disastrous the Iraq war had become. There's no way he would have shown so much self-doubt if confronted by a shouting head on Crossfire.
The headline also incorrectly substitutes
the word "web" for the word "Net" used in
the article. The Web is limited to the
HTTP protocol, so 75% non-browsers would be
a lot of bots.
The Denver Public Library began to use
Amazon recently. According to library
volunteers, only books with ISBN numbers
go online. Older books end up in the dumpster,
and many more besides. A third
party must be hired to store and cull the
books. That intermediary does the dirty
work of tossing all but the easiest sales.
Through a partnership with the firm bLogistics, Amazon receives a 15 percent commission on each book sold, while bLogistics -- which stores the books in a Boulder warehouse -- and the library each receive 42.5 percent of the revenues. Last year the library made $37,265 from the deal over ten months, and the DPL is projecting that it will earn $50,000 this year. The Friends raised $100,000 through two used-book sales last year.
...
Fans of old books are especially troubled by the new arrangement, because bLogistics only sells books that have an International Standard Book Number (ISBN), a ten digit ID that has been assigned to almost all books published in the last thirty years. They fear the old books will all wind up in the trash.
"Older, rarer books, what happens to them?" asks Linda Lebsack, who sells used books with an emphasis on Colorado history at her small shop on Broadway. "Do they throw them away or sell them out the back door? Every year I go to the sale and see a book by some old geezer who lived in a small Colorado town and wrote his memoirs. You'll see dozens of books like that go through the sale. I've bought signed editions of poets from the 1920s. I sold a library discard the other day for $45."
And even though Jackson says those books will be sold at the used-book sale in October or at the annual rare-books auction in January, the Friends volunteers have seen what really happens to many of the volumes. While preparing for what would be their last summer extravaganza, they heard rumors that they no longer had full access to the stock because much of the year's discards were simply being tossed in the dumpster.
So Monley and the volunteers went down to the library's dock to investigate. What they found appalled them: box after box of books heading to the dump.
"We thought it was a mistake and went down and took them out of the trash," Monley says. "They went on throwing the books away, even though they were good books for the book sale. We always sold them; they were $18 or $19 books. They were throwing away art books -- they sell beautifully; some were in perfect shape inside. We'd sell them for $7 or $8, and they'd go in minutes."
"Those of us who sort the books see what's coming through and are appalled by it," Silverman adds. "They were saying they needed to raise money for Spanish-language materials, and we would be seeing Spanish materials for children in mint condition being discarded. We were getting stuff that had never been opened, and it was being discarded."
My favorite reference book on Linux
is the "Linux
Administration Handbook" by by Evi Nemeth,
Garth Snyder, and Trent Hein, from
Prentice Hall. (See http://www.admin.com/ )
The material will not age nearly as
fast as a book only for Red Hat.
I've got a directory archive of mail going back
well into the 80's. The only detail about
a given message I can usually count on remembering
is the sender or recipient. I give each
correspondent a separate subdirectory with the
name of email alias (last name,
sometimes with initials). I have a few
special folders for "receipts," "strangers,"
and corporate spam. Special folders for
specific topics have never worked out, mostly
because topics overlap too heavily.
Grep works fine for the rare cases where
I remember the content but forget the correspondent.
Here's something I wrote in 1999 that
still seems to apply.
If you are a monopoly, then
everyone is a competitor. The key technology
is the written contract, not software.
Any contract worth signing must have a
booby-trap for the other guys.
Identify a hole in your market. Find a
hungry company attempting to fill this hole,
and let them have your exclusive endorsement
for a few years. In return, they will sign a
contract with a suicide clause. When you are
ready to absorb this market into your own
product line, you exploit the clause and they
die.
If new technology moves too fast, then you
must form a strategic alliance. Find other
competitors with no interest in the new
technology and get them to sign contracts
endorsing your incompatible, vapor-ware
alternative. You kill the new technology and
burn the other competitors at the same time.
If a competing technology succeeds anyway,
then remember that a monopoly has its
privileges. Distribution channels must sell
your weak products if they want the strong
ones. Prevent the distribution of competing
products. Such contracts are always
confidential.
Non-disclosure agreements are an end in
themselves. Anyone who asks about your
long-term plans is a potential threat. Get
such parties to sign agreements not to
discuss the issue with anyone else. Tell
them how you will vaporize all competing
technologies they may have considered. They
can't check your story with anyone else.
They can't complain if they base decisions on
misinformation.
Amazingly, you can usually find companies to
agree to these contracts for nothing.
They'll sign just to be your friend.
Here are some comments on pair programming
I put together for coworkers.
What are the basic mechanics? Usually, one
programmer is typing and thinking out loud
about what needs to be done. The other sits
and offers suggestions. Sometimes, the
keyboard changes hands.
The first few times are not typical. You
will spend time discovering tricks with
editors and discussing personal work habits.
You will find it exhausting, and neither will
be unable to type for more than half a day
each. Remember to pass the keyboard back and
forth, and keep your paired days short.
After the novelty has worn off, you find that
every partner is different. Nevertheless,
the benefits seem not to depend very much on
whom you work with.
What is one guaranteed benefit? All code
written by two people is at least
understandable to two people. Two people can
maintain it, so others are more likely the
find the code maintainable as well. Upgrades
and bug fixing will always consume more of
your time than the negligible first draft of
a program. If your code can't be maintained,
then you really cannot afford to ship it, no
matter how useful the functionality.
Better, the two of you are thinking about the
code in different ways. While the typer is
thinking about one screenful of code, the
companion is thinking about the effects on
other code. Maybe this bit of functionality
belongs elsewhere. Maybe this information
can be encapsulated. Maybe we're making a
bad assumption here. You catch many
opportunities to simplify your code and
improve flexibility.
It's hard to think about the big picture and
the details at exactly the same moment.
While you're thinking about one, you mess up
the other. With twice the brain capacity,
one of you can focus on the details, while
the other checks the context and adjusts
priorities.
I also find that we get more than twice the
work done of either of us working alone. A
speed-up isn't guaranteed, or even necessary,
but there are good reasons why it happens.
Much of the time you spend in front of a
terminal is wasted by context switching.
"OK. Where was I?" You decide something
must be fixed or refactored before you can
make any progress. You spend twenty minutes
making the extra change and you lose the
thread. Your original idea goes cold. Or
you postpone and never get back to the
necessary refactoring. Worse, you may spend
an hour restructuring code, then realize it
was not necessary after all. There was a
simpler way to solve the same problem, or you
misunderstood the problem. Two people will
stop each other from wasting many hours this
way. One or two such insights can justify
the entire session.
Pair programming is also constant code
review. You get to discuss and and explain
the design at the most optimum moment, when
it is being written. Alone, you might get
ninety-five percent of a design perfect, so
that no one could possibly improve on it.
But that stupid five percent could have been
avoided by almost anyone you pull in from the
hallway. You could have avoided it yourself
on Tuesday, but today is Thursday, and you
were using a different part of your brain.
Two people are less likely to have the same
blind spots.
Each programmer has a high tolerance for
complexity in certain types of code. Certain
strange idioms are second nature to you, but
to no one else. You won't know for sure,
unless someone is sitting next to you asking
"What the heck is that?" Then you'll break
the one clever line into several readable
lines, and move on.
You'll like your work better, others will
like your work better, and you'll get more
done. That should be enough reason to give
pair programming a try. Maybe it won't work
for everyone, or everyday. Don't force
yourself or others to participate. You must
be relaxed and receptive. As with any new
skill, it works better with practice. Try
with different partners and different
problems. If you find yourself staring
blankly at the screen, then surely you can't
do any worse with someone else in the room.
Try it right then.
What if your programmers work in different
cities? Try using an instant messenger,
such as IRC, Jabber, or Yahoo's.
These allow you to pass files and
snippets of code back and forth.
You can archive your conversations.
Most AI programmers prefer languages that are strong in symbolic manipulation, such as Lisp or Prolog. When did the computational speed of a particular implementation become the most important criterion for every problem? Implementations of languages are fast or slow, not languages.
Your statement that C++ will always run faster than Java clearly is based on hearsay, not experience. Ignorant coding will make any language slow. I've seen unoptimized java code run faster than C++ equivalents. Why? Because the VM can profile the code while running and recompile on the fly, unlike statically compiled C++. A statically compiled program will never know if loops are long or short and cannot unroll them to greatest advantage.
Slashdot Mirror
J++ wasn't java. Byte code from J++ included new non-optional instructions, violated the specification, and thus could not run on any VM but Microsoft's. Microsoft's VM did not support 1.1 features for handling native code. How would Sun have benefited from a non-java VM pretending to be java?
Just keep some cotton balls and a bottle of rubbing alcohol on the desk. Swab off the keyboard and mouse once a week. Q-tips are handy for the spaces between keys.
This Jon Katz article describing slashdot as a "weblog" was the first place I ever saw the term: http://slashdot.org/features/99/05/13/1832251.shtm l
(Yes, that's from 1999, back when two-digit dates were popular.)
I remember because I found the term confusing and thought it should be the log of a webserver. Thankfully, the abbreviation "blog" came along eventually and prevented further confusion.
Javascript and Java have nothing in common but four letters in their name, from a silly marketing decision by Netscape and Sun long ago.
Unfortunately, the alternative name that could have cleared up the confusion is impossible to pronounce: ECMAScript.
The patent office is a moving target. You should at least know who claims to own your partners' brains.
You read the article, right? :)
Hmm, I wonder if those bloggers might have posted any response to this story? After all, they've only had 12 hours so far today. http://www.dailykos.com/story/2005/1/14/02014/6287 ,
http://www.mydd.com/story/2005/1/13/231623/665 , and
http://www.pandagon.net/mtarchives/004427.html
Funny, I thought slashdot was a blog too.
Aren't most stories just a topic for discussion? Even unoriginal observations are worth revisting occasionally.
When an anecdote is a little too perfect (and this one is way over the top), then you need to google for it at site:snopes.com. http://www.snopes.com/college/exam/barometer.asp
If your goal is to elicit information and insight, you might have better luck not putting your guest on the defensive. Partisan attacks illuminate nothing. Make the guy feel at home, without fear that you will take a cheap shot. On the Daily Show, arch-neocon Bill Kristol was amazingly frank about how disastrous the Iraq war had become. There's no way he would have shown so much self-doubt if confronted by a shouting head on Crossfire.
Yes, you can use /etc/ld.so.conf
for common shared objects. You can equivalently
use $JAVA_HOME/jre/lib/ext for common jars.
Using a path is the single most common way to find dynamically loaded code.
The headline also incorrectly substitutes the word "web" for the word "Net" used in the article. The Web is limited to the HTTP protocol, so 75% non-browsers would be a lot of bots.
I have a feeling Darl's brother was responsible for that open letter of legal gibberish. Only a true believer could written such a thing.
From: http://www.westword.com/issues/2003-08-07/feature. html/1/index.html
The material will not age nearly as fast as a book only for Red Hat.
I've got a directory archive of mail going back well into the 80's. The only detail about a given message I can usually count on remembering is the sender or recipient. I give each correspondent a separate subdirectory with the name of email alias (last name, sometimes with initials). I have a few special folders for "receipts," "strangers," and corporate spam. Special folders for specific topics have never worked out, mostly because topics overlap too heavily. Grep works fine for the rare cases where I remember the content but forget the correspondent.
It is exasperating that the article emphasizes "copying" DVD's when Jon needed his decrypting program simply to VIEW his DVDs.
If you are a monopoly, then everyone is a competitor. The key technology is the written contract, not software.
Amazingly, you can usually find companies to agree to these contracts for nothing. They'll sign just to be your friend.
What are the basic mechanics? Usually, one programmer is typing and thinking out loud about what needs to be done. The other sits and offers suggestions. Sometimes, the keyboard changes hands.
The first few times are not typical. You will spend time discovering tricks with editors and discussing personal work habits. You will find it exhausting, and neither will be unable to type for more than half a day each. Remember to pass the keyboard back and forth, and keep your paired days short.
After the novelty has worn off, you find that every partner is different. Nevertheless, the benefits seem not to depend very much on whom you work with.
What is one guaranteed benefit? All code written by two people is at least understandable to two people. Two people can maintain it, so others are more likely the find the code maintainable as well. Upgrades and bug fixing will always consume more of your time than the negligible first draft of a program. If your code can't be maintained, then you really cannot afford to ship it, no matter how useful the functionality.
Better, the two of you are thinking about the code in different ways. While the typer is thinking about one screenful of code, the companion is thinking about the effects on other code. Maybe this bit of functionality belongs elsewhere. Maybe this information can be encapsulated. Maybe we're making a bad assumption here. You catch many opportunities to simplify your code and improve flexibility.
It's hard to think about the big picture and the details at exactly the same moment. While you're thinking about one, you mess up the other. With twice the brain capacity, one of you can focus on the details, while the other checks the context and adjusts priorities.
I also find that we get more than twice the work done of either of us working alone. A speed-up isn't guaranteed, or even necessary, but there are good reasons why it happens.
Much of the time you spend in front of a terminal is wasted by context switching. "OK. Where was I?" You decide something must be fixed or refactored before you can make any progress. You spend twenty minutes making the extra change and you lose the thread. Your original idea goes cold. Or you postpone and never get back to the necessary refactoring. Worse, you may spend an hour restructuring code, then realize it was not necessary after all. There was a simpler way to solve the same problem, or you misunderstood the problem. Two people will stop each other from wasting many hours this way. One or two such insights can justify the entire session.
Pair programming is also constant code review. You get to discuss and and explain the design at the most optimum moment, when it is being written. Alone, you might get ninety-five percent of a design perfect, so that no one could possibly improve on it. But that stupid five percent could have been avoided by almost anyone you pull in from the hallway. You could have avoided it yourself on Tuesday, but today is Thursday, and you were using a different part of your brain. Two people are less likely to have the same blind spots.
Each programmer has a high tolerance for complexity in certain types of code. Certain strange idioms are second nature to you, but to no one else. You won't know for sure, unless someone is sitting next to you asking "What the heck is that?" Then you'll break the one clever line into several readable lines, and move on.
You'll like your work better, others will like your work better, and you'll get more done. That should be enough reason to give pair programming a try. Maybe it won't work for everyone, or everyday. Don't force yourself or others to participate. You must be relaxed and receptive. As with any new skill, it works better with practice. Try with different partners and different problems. If you find yourself staring blankly at the screen, then surely you can't do any worse with someone else in the room. Try it right then.
What if your programmers work in different cities? Try using an instant messenger, such as IRC, Jabber, or Yahoo's. These allow you to pass files and snippets of code back and forth. You can archive your conversations.
Here's the best substitute for a ternary I have seen so far:
>>> (falseResult, trueResult)[bool(condition)]
Don't forget what Richard Belluzzo did for SGI with his NT server strategy. I wonder if anyone remembers Fahrenheit.
Microsoft has been convicted of abusing monopoly power under the Sherman Antitrust Act. Of course they are playing by different rules.
Your statement that C++ will always run faster than Java clearly is based on hearsay, not experience. Ignorant coding will make any language slow. I've seen unoptimized java code run faster than C++ equivalents. Why? Because the VM can profile the code while running and recompile on the fly, unlike statically compiled C++. A statically compiled program will never know if loops are long or short and cannot unroll them to greatest advantage.
Redhat has not been convicted of violating
the Sherman Antitrust Act.
I found AS perl to be much faster than the one that comes with cygwin.
Any exploration of the filesystem seemed an order of magnitude faster.