I couldn't care less what your meatspace name is or is not. This forum is an electronic one, and handles are perfectly acceptable. But an identity is, in fact required, not 'Anonymous Coward'. Register, and you can be heard; or continue crying ad hominums in the wilderness.
He can keep the karma, who needs it? Yes, I was flaming. And why not? this is slashdot...
as for the content of the thread, I was just throwing noise around, around the subject of the original poster insinuating that NT was first on the scene with tasking/threading, quote "years and years", which annoyed me. The operating system problem is an old one, and although some advancement is happening in modern commercial OS'es, NT is hardly a shining example. But I disgress.
I was pointing at how old those two things are, so a single, closed-source vendor could hardly claim 'first' on either. Since I hardly have read access to the NT source tree, I can't tell you when they were added, so that's hardly a defensible position. But I should have jumped him on pthreads, since with them Linux has been threadable since 1.2...
shouldn't read slashdot with a cold; it might kill me.
That'll be because your mind is shut. I find it easy to believe that WindowsNT, that has been a multitasking _multithreaded_ operating system for years and years is now smoking the hell out of Linux that barely supported threads at a until not too long ago.
Um.. yeah. And it shows, too, don't it? I mean, all that stability and all? Boy, all this time I thought NT was a munged knock-off of VMS, with implementation details following the latest breeze (remember when they said it was going to be Mach-based? that was a good one).
But it looks like I was wrong, and you are right. Threading wasn't invented in universities, and MIT didn't write the most-promogulated implementation; Microsoft did, and first!
Moreover, I'm glad you cleared up everyone's misconceptions about multitasking - I'll never look at pre-emption the same way again! Damn those researchers for lying to us, and damn those vendors for selling us multitasking systems since the mid 70's!
being with tons of other pale looking geeks at 4am is not exactly called being *social*. i mean...come on. do you really expect/. readers to swallow that one ?
Yes, he expects us to swallow that one. In the same way that staggering home, often with someone who's name you can't remember, at 3 am can be considered *social*. Pull your head out of your ass and remember that different social groups prosecute their social rituals differently.
personally i see most girls being to scared off/repelled by geeks & technology to really call themselves geeks.
Geeks love technology, that's one of the pillars of the definition. If you don't love technology, how can you call yourself a geek? There are lots of job opportunities in tech fields where you go home at 5 pm. You are welcome to take them.
My complaint with Dr. Spafford's position is this: Most present work in the web world now, where the standards are often implemented & written simultaneously. Laying aside complaints of poor design for a moment, I have to point out the problem here; Dr. Spafford defines trusted (ie, secure) systems as ones that pass "a formal testing and standards process". But are the attacks against web systems laid out before the system is built? Often, NO! So we have a conflict between how we're writing systems, and how Dr. Spafford defines trust.
Addressing more specifically open source, I want to point out the overwhelming portion of the web that runs on open-source. A primary reason behind that is that closed-source, desktop developers are very good at cloning systems, but don't do so well writing innovative products. The best stuff we have for web services are open, primarily written or extended in order to fulfill a specific need.(yesterday an interview with Brian Behlendorf was posted - a fine example) Fanning the flames here, often the standards developers either contribute or write these systems -- which definitely garners my trust. These systems are going to continue to evolve rapidly. No one here can or will wait 2 years for: freeze the standards, theorize attacks, design the system, write the system, test the system, release-and-now-keep-that-system-until-we-release- the-next-one-2-years-later. So under the circumstances, I trust open-source systems collecting contributions from standards developers rather than closed-source developers with unseen and possibly out-of-date code, lagging behind.
Point 2: Spafford has a faulty argument. He criticizes all open-source development on the grounds of how several well-known projects are managed. Let us remember that the sets are not equal. The definition of open-source is a hell of a lot larger than, eg "how Linus runs things". I hope he recognizes that; I for one never again care to work with, extend, or support a system I cannot see the source to. You may trust your vendor, but more options are never a bad thing.
Cryptonomicon had a great ending. The others I'm not so sold on, but they aren't as bad as the majority of drivel that makes its way into a hard binding.
The ending to Cryptonomicon was subtle.. moreover, it emphasized the continuation of the characters life, rather than the standard "and everyone lived either happily ever after, or in an appropriately fitting physio-emotional state congruent to the moral lesson of this text; thank you for reading, and for your $24.99". (As a humorous bonus, Randy throws in a few lines about how he doesn't really like the looks of his future; and he'd prefer a 'happy-ever-after' himself)
Doug's resolution was great too, what with his fragmented tale of his father being appropriately broken up by helicopter noise; and I sort of got the point that he never knew his dad, and he followed his own path, but just the same he's going to try to tie the lessons from his father into his own great achievements, eg, Golgotha.
The book was great, and how would you have ended it? It felt kind of like reading a history book, what with the hordes of people dying and information lost, for usually no good reason. So I dug the quiet moment at the end, where Randy sees the stream of gold; it made me sort of subjective to all the characters who were involved in Golgotha, whose stories we read, but IRL, no one would.
I dunno, you can read the ending several ways; which these days is how I define good fiction. (of course, you can read most tech documentation several ways; that is obviously a Bad Thing.)
I've ranted enough for now, but it seems most readers have something against non-conclusive fiction. So I draw from the film library to give a memorable example:
It's too bad she won't live -- but then again, who does...
> I totally agree - Neal, if you're listening, > please explain why your novels are great down to > the last chapter or two. The endings are always > kind of non-conclusive/too formulaic. ^^^^^^^^^^^^^^^^^^^^ Blasphemy!!
I think you may need to recognize what datatypes have a one-to-one mapping with language standard types, and write an obcenely complex regex to convert them all. (only Perl can handle this easily{Tcl has some hard-core ugliness, haven't tried Python}).
I've done this a couple times -- it's a little unnerving, but it definitely works quickly. (If you really want to get hard-core, like a having to convert some text in ~10k lines of Perl, try tying directly into the interpreter, to identify scope, quoting, context, fxn calls, etc).
Lisp programmers forced to look at Perl code would usually say "if there were any justice in this world, the guys who wrote this would go to jail." -- philg Yowsers!! Didn't see that! (And yet, people who wrote in APL, COBOL, and PL/1 somehow are innocent? why is Perl the beast?)
OKay, I didn't see that one. Partially that's b/c these web boards have poor threading, even worse than usenet, and bad grouping. (This is a peeve, and I'm working on it.) Had I seen that statement at the beginning, I wouldn't have stepped in here. He says LISP is awesome, and yes, I have to agree. But the old 'justice in the world' tantrum has no backup; I'm sorry I flamed. (In my moderate way)
Funnily enough, the resources on LISP are meager compared to the resources on Perl, Python, C, Tcl, etc. Read Structure and Interpretation of Computer Programming, 2nd edition. The down side to that is it's usually used as a class text, so you get interaction with other learners&teachers.
Plus I'm fond of things like iteration and variables. Yeah, it's a different way of thinking. Rather than loops, you have to sit and think about how you can set up the entire function as one cascading recursive element. Its quite fun, and an excellent way to learn program structure (which is why Lisp is great for teaching.)
Lot of Idiotic, Stupid Parentheses Or idiotic WhiteSpace in Python and Haskell. The idea here is that it makes writing parsers an order of magnitude simpler; and no complex, often stupid, operator precedence rules. It also increases readability, if you contrain your mind to follow said rules.
That said, I think Perl has the coolest parser known to god or man. Do I need to back up this statement? nah.. I think you already know.
and there must be a reason why the vast majority of them choose not to use LISP Managers, time issues, and salesmen(your company buys some middleware.. ugh..). Also, a lot of programmers I've worked with in the past aren't motivated to learn new tools&languages (maybe its just perception of language learning being difficult). I mean, are we engineers or programmers?
Is my impression wrong? Your impression is not wrong; your impression is the hard lesson LISPers had to learn after in-fighting through most of the 80's.
Your previous argument only goes to show how LISP can be a good educational tool, but does not show any uses of LISP. My point was you can do any kind of production code in any language (go PL/1!), so a generally excellent language is a generally excellent tool for production. I work in Perl for production work, mostly because of existing code, and the world's finest regex package. I probably won't have any good reasons to go back to Lisp, but I like to pay homage.
Regarding the.sig, thanks It looks like Terry Prachett.
I'll just respond to one small ad-hominium before moving on, hopefully ne'er to return. I must also add that you are taking the tone of the whining, pissed-off LISP bigot, not the tone of an effective defender of LISP. For example, "But to humor the remainder of your post..." Honestly, you don't need to humor me. You would find that your words are much more effective if you provide me with compelling evidence.
Well, you're asking a lot in that I need to convince you. comp.religion.flamewars suck. They ruin computer science, and keep 'software engineering' an oxymoron. Nonetheless, I stupidly waded into one...
So, I'm not trying to convince you to use LISP. Or even like it. But you came on the scene telling philg off, saying that LISP and other MIT tools are bad news, and demanding refutation. SO that's why I think you have the burden of proof, not I.
I asked specifically what would convince me that LISP is useful outside of academic snobbery I told you some reasons why LISP is a good language, and several of those reasons were implemented first in LISP. So I told you why LISP is a good language. If you think good language has no correlation to usefulness, you need to remember that you can do damn near anything in computers in any language. Focus on the app, not the flamewar.
So you want to know what LISP sucks at? Well, it doesn't have Taint checking like Perl, and that's a biggie for me, but not for everyone. Modern CS profs are getting obsessed about referencial integrity, so recent FP languages are crippled for IO, but that doesn't apply to good ol' Common Lisp. If you _really_ need speed, you're going to write in C & assembly, so I don't suggest writing graphics drivers in LISP. And I use Perl more b/c of vast size of CPAN; I can usually find solutions to most of my problems already there. If you want to know some reasons why there isn't more LISP in your desktop environment, you should read some history, in particular Symbolics and the death of the MIT AI Lab(and SAIL). Ironically, that gave us GNU, proving the idiom about the silver lining...
All I ask is that someone show my why LISP is more than just the snobbery of some elitist MIT bigots I told you some reasons already. It's a excellent language. I've never been to MIT, yet I like it. I don't see why you're so obsessed with this point. Maybe it's this: It is up to the LISP people to prove that LISP is everything that they claim it to be.
Well, the language is out there. You can play with it, and find out if they're right or wrong. Put your code where your mouth is; you might like it.
Firstly, you have yet to prove that LISP is worthless; your lack of knowledge of apps is not proof. But to humor the remainder of your post, here are a few reasons that LISP, and any other functional language, is/are cool:
1: base support for complex types. How many times can you write a linked list before puking? Run-time type checking on dynamic tuples? Can you even do that in C? And for the record, 'strings'. Amen. C? No. (I don't know why you've grouped C, Tcl, and Perl together; I use Perl, elisp, Haskell, and a little Java).
2: Functions are data, vice versa & lambda calculus. Where do you think this came from?
3: A real, honest to god object system. I spit on your C++ structures-with-inherited-functions.
4: GC.
5: Correctness. Fucks' sake, all I ask for is an overflow should degrade to bignum. Not even Java does this. LISP's philosophy seems to demand that operations should not fail due to hardware design.
6: Simplicity. You can write a Scheme interpreter in one page; moreover, the concepts are all simple.
7: Ease-of-use. The interpreter doesn't have to be baby-sat through strong typing. It infers necessary types via what operations happen to a piece of data.
Sounds fun to me. Better than running down memory leaks, writing complex list eval fxns in C, bizarre type casts, and no lambda calculus.
I hope you can see the point that Greenspun tries to make, which is drawing attention to how a language should really be written. Languages evolve, and if we shout, maybe our voices will be heard.
Now, I use Perl, because Perl uses many of the above concepts (some poorly, like GC). Everyone else in my company uses C++; I'm slowly bringing them around. Where LISP comes into this is: I _really_wish they had been taught LISP in school, just to train them to think in the higher patterns that LISP allows. Working on C/C++/Java is too low-level and too inconsistent; people get lost and programs get buggy.
My complaint with functional programming circa 2000 AD is that the 'referential integrity' whores have crippled new FP languages for IO. Good-bye scripting...
So, you've reiterated your position; which we've heard like 4-5 times now. Your contention that LISP has no functional value is hopefully negated by the above. (and the polysemous use of 'functional'{think FP}) But you have failed to inform us why your preferred languages are better, other than that they are popular (which we already knew).
I refrain from defending Emacs, in that others have spoken far fairer and clearer than I. But xemacs-mule is much easier to work with than any other multi-language editor I've found.
That's fantastic to hear. _And_ the son of Minsky; doubly impressive. As for me: I read wtr/thebook/ in the fall of '98; it really impressed me, but I had school to finish. I'm afraid I don't have the rep to impress yet, but I've been toying with a new message system (bastard son of NNTP, one might call it), so perhaps I can impress soon.
Thanks for responding; a look at your User Info indicates you've been busy today, not to mention more pressing issues than random/. nerds.
Slashdot Mirror
I couldn't care less what your meatspace name is or is not. This forum is an electronic one, and handles are perfectly acceptable. But an identity is, in fact required, not 'Anonymous Coward'. Register, and you can be heard; or continue crying ad hominums in the wilderness.
He can keep the karma, who needs it?
Yes, I was flaming. And why not? this is slashdot...
as for the content of the thread, I was just throwing noise around, around the subject of the original poster insinuating that NT was first on the scene with tasking/threading, quote "years and years", which annoyed me. The operating system problem is an old one, and although some advancement is happening in modern commercial OS'es, NT is hardly a shining example. But I disgress.
I was pointing at how old those two things are, so a single, closed-source vendor could hardly claim 'first' on either. Since I hardly have read access to the NT source tree, I can't tell you when they were added, so that's hardly a defensible position. But I should have jumped him on pthreads, since with them Linux has been threadable since 1.2...
...and you can take part in discussion
moreover, not once did I mention Linux, nor allude to it. Learn to read.
Um.. yeah. And it shows, too, don't it? I mean, all that stability and all? Boy, all this time I thought NT was a munged knock-off of VMS, with implementation details following the latest breeze (remember when they said it was going to be Mach-based? that was a good one).
But it looks like I was wrong, and you are right. Threading wasn't invented in universities, and MIT didn't write the most-promogulated implementation; Microsoft did, and first!
Moreover, I'm glad you cleared up everyone's misconceptions about multitasking - I'll never look at pre-emption the same way again! Damn those researchers for lying to us, and damn those vendors for selling us multitasking systems since the mid 70's!
please! Enlighten us more!
a router sends packets in Doriath...
Re: [SQL] locked my keys in the car
accursed database!
My complaint with Dr. Spafford's position is this:
- the-next-one-2-years-later. So under the circumstances, I trust open-source systems collecting contributions from standards developers rather than closed-source developers with unseen and possibly out-of-date code, lagging behind.
Most present work in the web world now, where the standards are often implemented & written simultaneously. Laying aside complaints of poor design for a moment, I have to point out the problem here; Dr. Spafford defines trusted (ie, secure) systems as ones that pass "a formal testing and standards process". But are the attacks against web systems laid out before the system is built? Often, NO! So we have a conflict between how we're writing systems, and how Dr. Spafford defines trust.
Addressing more specifically open source, I want to point out the overwhelming portion of the web that runs on open-source. A primary reason behind that is that closed-source, desktop developers are very good at cloning systems, but don't do so well writing innovative products. The best stuff we have for web services are open, primarily written or extended in order to fulfill a specific need.(yesterday an interview with Brian Behlendorf was posted - a fine example) Fanning the flames here, often the standards developers either contribute or write these systems -- which definitely garners my trust. These systems are going to continue to evolve rapidly. No one here can or will wait 2 years for: freeze the standards, theorize attacks, design the system, write the system, test the system, release-and-now-keep-that-system-until-we-release
Point 2:
Spafford has a faulty argument. He criticizes all open-source development on the grounds of how several well-known projects are managed. Let us remember that the sets are not equal. The definition of open-source is a hell of a lot larger than, eg "how Linus runs things". I hope he recognizes that; I for one never again care to work with, extend, or support a system I cannot see the source to. You may trust your vendor, but more options are never a bad thing.
Cryptonomicon had a great ending. The others I'm not so sold on, but they aren't as bad as the majority of drivel that makes its way into a hard binding.
The ending to Cryptonomicon was subtle.. moreover, it emphasized the continuation of the characters life, rather than the standard "and everyone lived either happily ever after, or in an appropriately fitting physio-emotional state congruent to the moral lesson of this text; thank you for reading, and for your $24.99". (As a humorous bonus, Randy throws in a few lines about how he doesn't really like the looks of his future; and he'd prefer a 'happy-ever-after' himself)
Doug's resolution was great too, what with his fragmented tale of his father being appropriately broken up by helicopter noise; and I sort of got the point that he never knew his dad, and he followed his own path, but just the same he's going to try to tie the lessons from his father into his own great achievements, eg, Golgotha.
The book was great, and how would you have ended it? It felt kind of like reading a history book, what with the hordes of people dying and information lost, for usually no good reason.
So I dug the quiet moment at the end, where Randy sees the stream of gold; it made me sort of subjective to all the characters who were involved in Golgotha, whose stories we read, but IRL, no one would.
I dunno, you can read the ending several ways; which these days is how I define good fiction. (of course, you can read most tech documentation several ways; that is obviously a Bad Thing.)
I've ranted enough for now, but it seems most readers have something against non-conclusive fiction. So I draw from the film library to give a memorable example:
It's too bad she won't live -- but then again, who does...
> I totally agree - Neal, if you're listening,
> please explain why your novels are great down to > the last chapter or two. The endings are always
> kind of non-conclusive/too formulaic.
^^^^^^^^^^^^^^^^^^^^
Blasphemy!!
I think you may need to recognize what datatypes have a one-to-one mapping with language standard types, and write an obcenely complex regex to convert them all. (only Perl can handle this easily{Tcl has some hard-core ugliness, haven't tried Python}).
I've done this a couple times -- it's a little unnerving, but it definitely works quickly. (If you really want to get hard-core, like a having to convert some text in ~10k lines of Perl, try tying directly into the interpreter, to identify scope, quoting, context, fxn calls, etc).
have fun!
Is there some reason tags aren't working?
Lisp programmers forced to look at Perl code would usually say "if there were any justice in this world, the guys who wrote this would go to jail." -- philg
.sig, thanks
Yowsers!! Didn't see that!
(And yet, people who wrote in APL, COBOL, and PL/1 somehow are innocent? why is Perl the beast?)
OKay, I didn't see that one. Partially that's b/c these web boards have poor threading, even worse than usenet, and bad grouping. (This is a peeve, and I'm working on it.) Had I seen that statement at the beginning, I wouldn't have stepped in here. He says LISP is awesome, and yes, I have to agree. But the old 'justice in the world' tantrum has no backup; I'm sorry I flamed. (In my moderate way)
Funnily enough, the resources on LISP are meager compared to the resources on Perl, Python, C, Tcl, etc.
Read Structure and Interpretation of Computer Programming, 2nd edition. The down side to that is it's usually used as a class text, so you get interaction with other learners&teachers.
Plus I'm fond of things like iteration and variables.
Yeah, it's a different way of thinking. Rather than loops, you have to sit and think about how you can set up the entire function as one cascading recursive element. Its quite fun, and an excellent way to learn program structure (which is why Lisp is great for teaching.)
Lot of Idiotic, Stupid Parentheses
Or idiotic WhiteSpace in Python and Haskell. The idea here is that it makes writing parsers an order of magnitude simpler; and no complex, often stupid, operator precedence rules. It also increases readability, if you contrain your mind to follow said rules.
That said, I think Perl has the coolest parser known to god or man. Do I need to back up this statement? nah.. I think you already know.
and there must be a reason why the vast majority of them choose not to use LISP
Managers, time issues, and salesmen(your company buys some middleware.. ugh..). Also, a lot of programmers I've worked with in the past aren't motivated to learn new tools&languages (maybe its just perception of language learning being difficult). I mean, are we engineers or programmers?
Is my impression wrong?
Your impression is not wrong; your impression is the hard lesson LISPers had to learn after in-fighting through most of the 80's.
Your previous argument only goes to show how LISP can be a good educational tool, but does not show any uses of LISP.
My point was you can do any kind of production code in any language (go PL/1!), so a generally excellent language is a generally excellent tool for production. I work in Perl for production work, mostly because of existing code, and the world's finest regex package. I probably won't have any good reasons to go back to Lisp, but I like to pay homage.
Regarding the
It looks like Terry Prachett.
I'll just respond to one small ad-hominium before moving on, hopefully ne'er to return.
.sig, tho. Where is it from?
I must also add that you are taking the tone of the whining, pissed-off LISP bigot, not the tone of an effective defender of LISP. For example, "But to humor the remainder of your post..." Honestly, you don't need to humor me. You would find that your words are much more effective if you provide me with compelling evidence.
Well, you're asking a lot in that I need to convince you. comp.religion.flamewars suck. They ruin computer science, and keep 'software engineering' an oxymoron. Nonetheless, I stupidly waded into one...
So, I'm not trying to convince you to use LISP. Or even like it. But you came on the scene telling philg off, saying that LISP and other MIT tools are bad news, and demanding refutation. SO that's why I think you have the burden of proof, not I.
I asked specifically what would convince me that LISP is useful outside of academic snobbery
I told you some reasons why LISP is a good language, and several of those reasons were implemented first in LISP. So I told you why LISP is a good language. If you think good language has no correlation to usefulness, you need to remember that you can do damn near anything in computers in any language. Focus on the app, not the flamewar.
So you want to know what LISP sucks at? Well, it doesn't have Taint checking like Perl, and that's a biggie for me, but not for everyone. Modern CS profs are getting obsessed about referencial integrity, so recent FP languages are crippled for IO, but that doesn't apply to good ol' Common Lisp. If you _really_ need speed, you're going to write in C & assembly, so I don't suggest writing graphics drivers in LISP. And I use Perl more b/c of vast size of CPAN; I can usually find solutions to most of my problems already there.
If you want to know some reasons why there isn't more LISP in your desktop environment, you should read some history, in particular Symbolics and the death of the MIT AI Lab(and SAIL). Ironically, that gave us GNU, proving the idiom about the silver lining...
All I ask is that someone show my why LISP is more than just the snobbery of some elitist MIT bigots
I told you some reasons already. It's a excellent language. I've never been to MIT, yet I like it. I don't see why you're so obsessed with this point. Maybe it's this:
It is up to the LISP people to prove that LISP is everything that they claim it to be.
Well, the language is out there. You can play with it, and find out if they're right or wrong. Put your code where your mouth is; you might like it.
Cute
Firstly, you have yet to prove that LISP is worthless; your lack of knowledge of apps is not proof. But to humor the remainder of your post, here are a few reasons that LISP, and any other functional language, is/are cool:
1: base support for complex types. How many times can you write a linked list before puking? Run-time type checking on dynamic tuples? Can you even do that in C? And for the record, 'strings'. Amen. C? No. (I don't know why you've grouped C, Tcl, and Perl together; I use Perl, elisp, Haskell, and a little Java).
2: Functions are data, vice versa & lambda calculus. Where do you think this came from?
3: A real, honest to god object system. I spit on your C++ structures-with-inherited-functions.
4: GC.
5: Correctness. Fucks' sake, all I ask for is an overflow should degrade to bignum. Not even Java does this. LISP's philosophy seems to demand that operations should not fail due to hardware design.
6: Simplicity. You can write a Scheme interpreter in one page; moreover, the concepts are all simple.
7: Ease-of-use. The interpreter doesn't have to be baby-sat through strong typing. It infers necessary types via what operations happen to a piece of data.
Sounds fun to me. Better than running down memory leaks, writing complex list eval fxns in C, bizarre type casts, and no lambda calculus.
I hope you can see the point that Greenspun tries to make, which is drawing attention to how a language should really be written. Languages evolve, and if we shout, maybe our voices will be heard.
Now, I use Perl, because Perl uses many of the above concepts (some poorly, like GC). Everyone else in my company uses C++; I'm slowly bringing them around. Where LISP comes into this is: I _really_wish they had been taught LISP in school, just to train them to think in the higher patterns that LISP allows. Working on C/C++/Java is too low-level and too inconsistent; people get lost and programs get buggy.
My complaint with functional programming circa 2000 AD is that the 'referential integrity' whores have crippled new FP languages for IO. Good-bye scripting...
So, you've reiterated your position; which we've heard like 4-5 times now. Your contention that LISP has no functional value is hopefully negated by the above. (and the polysemous use of 'functional'{think FP}) But you have failed to inform us why your preferred languages are better, other than that they are popular (which we already knew).
I refrain from defending Emacs, in that others have spoken far fairer and clearer than I. But xemacs-mule is much easier to work with than any other multi-language editor I've found.
That's fantastic to hear. _And_ the son of Minsky; doubly impressive. As for me: I read wtr/thebook/ in the fall of '98; it really impressed me, but I had school to finish. I'm afraid I don't have the rep to impress yet, but I've been toying with a new message system (bastard son of NNTP, one might call it), so perhaps I can impress soon.
/. nerds.
Thanks for responding; a look at your User Info indicates you've been busy today, not to mention more pressing issues than random
Not to be rude, but how big is your Tokyo office?
And is it staffed locally like your Caltech offices??
Just the idle questions of someone who would love the opportunity to work for AD.