FYI, in Russia even buying anything resembling *hidden* camera may easily get you into jail. There were several cases of guys buying stuff like a camera hidden inside pen and getting several years of jailtime for it. As of dashcams, which are legal because they don't qualify as hidden cameras, while far from eliminating police corruption, they DO help in some cases against corrupt policement, and that's one of the reasons why they're so popular.
While there is an extensive (yet old) specification for the core language, the CLisp folks just didn't consider that standardizing a 'standard library' would be a good idea, and as a result each and every implementation features it's very own implementation of threads, networking, GUI,... completely incompatible with the implementation next door (and sometimes within an implementation from one platform to the other).
[BTW: CLISP is just an implementation of Common Lisp, please don't confuse it with the language itself] Yes, this is a problem, but it isn't as bad as it may seem. Do we have standard threads/networking/GUI in C? C++? (POSIX doesn't count - a lot of C/C++ code is written for Win32) What about 'standard' threads/GUI in Perl? Yet these languages are quite widespread.
And the worst, I think, is that the Lisp community doesn't seem to see how some kind of standard library (as in, including the batteries in Clisp) would be useful to bring people new to the language in, or keep them there.
Then again, actually reading comp.lang.lisp (or -- god forbid -- asking a question there) is sadly more than enough to drive you very far from trying to code in lisp ever again.
cll does indeed attract some number of strange trolls. Also, Lisp newbies in initial stages of their enlightenment do post some strange stuff sometimes. (When one begins to 'get it', things may seem much more cool than they are in reality for some time. It's important to learn the language a bit instead of inventing 'perpetuum mobiles' after learning a few nice features). But overall I was never insulted by anyone there though I did post some thoughts. And I don't think anyone will get flamed by cll old-timers unless he/she posts something implying that everyone else on the newsgroup is an idiot.
Let me know when the world comes to their senses and starts using Scheme instead, or some future or past dialect that has not a thousand page standard and a marginal packaging system.
Well, thousand page standard may not be always a good thing, but IMO it's better than having to rewrite your program from scratch every time you switch implementations. Different Schemes have different OO/package/whatever system, so porting between them is, well, something quite like complete rewrite. Concerning marginal packaging system -- would you
please be more specific?
Plus call/cc is cool.
Agreed, but life is hard without unwind-protect (aka try... finally). And it's possible to have continuations in CL when they are really necessary.
I have been thinking that 'Lisp is not accessible' for years. I regret all these years beyond expression. Don't believe it. It's horrible lie. Here's the proof.
It is funny that you should mention Python as a replacement for LISP in the context of Reddit: they indeed recently switched from Python to LISP, rewriting their whole application in about a week.
(correction: they switched from Lisp to Python) It's exactly the reason why I mentioned Reddit. A perfect example of a situation where most of the job is done by existing libraries/frameworks/etc.
The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well.
CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or.NET bytecode actually AFAIK. Later Open Genera was released that allows one to run the Lisp OS on Alphas. Using high-level opcodes is
not critical for Lisp (most modern CL compilers save CLisp produce native machine instructions for their target architectures).
Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!
Yes, it's rather hard to do so, just because Linux kernel and X.org are written in C. If they were written in Lisp, it would be hard to write drivers in C unless authors cared to
provide proper FFI-based "foreign" driver loading mechanism. There's nothing wrong with
Lisp itself concerning low level stuff. For example, take a look at this beast (Lisp on bare metal).
As a matter of fact, I agree that C/C++ is safer bet in our world, but not because C and C++ are more general languages than Lisp is. It's just because most of stuff in use is written in these languages. Lisp machines failed (mostly due to management & political reasons), Lisp itself became the scapegoat for failed AI promises, so now curly braces are almost inevitable for serious programmers.
But nevertheless Lisp is worth learning as it can be the best tool for complex problems in many cases, and also due to the fact that it makes programmers more broad-minded. It's actually much more general than C++ in the sense that it easily supports almost any paradigm one can imagine. For instance, it's possible to seamlessly embed SQL, Prolog, HTML, etc. rewritten using S-expressions in Lisp programs.
I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really:-)
But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.
A lot of stuff that is implementation-specific or DIY in Scheme (packages, classes, structs, "non-hygienic" macros, useful higher order functions, conditions (exceptions), pretty printing and many other things) is standard in CL.
CL's problems actually stem from the lack of Open Source libraries (as there are just too few Lispers). There are two approaches to solving these problems:
(a) use commercial implementation which has everything included. An example of such implementation is Allegro CL which includes hardly much less functionality than.NET Framework; they also provide mind-blowing CL OODB and a lot of other useful stuff. It's quite expensive though.
(b) use existing open-source CL implementations & libraries, improving them as you need, and maybe contributing some your code.
Approach (b) is feasible when most functionality of your product resides in your code and not in libraries. E.g. reddit.com code is mostly a rather thin wrapper around database + Web server, so free Common Lisp implementation may not be a best tool for the job. It may be better to use a commercial CL implementation or some other language (such as Python)
in such cases, depending on how much money & spare time you have.
Another example - I'm writing an online store now as a semi-holiday project, I don't have too strict time constraints there, so I'm using CMUCL+CLSQL+TBNL to implement it. With severe time constraints it would be better to use Python in my case, as I don't want to pay $$$ for commercial Lisps.
But there are plenty of cases where Lisp proves to be just the ideal tool for the job.
Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.
Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/">Boost C++ libraries.
At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.
Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to
"emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL.
After playing with Scheme for a while, I've found out (to my surprise) that the
language can be used for many other purposes besides list (tree) processing and simple
scripting (as in Gimp). As an example, there are wonderful things like Scsh. It's possible to write Web applications, many Schemes
can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.
So I've begun to try to do some real things in Scheme. Disillusionment has come rather
quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is
not standardized and thus is 100% non-portable between implementations. Moreover, every
implementation has its bugs and limitations, and when you come to the point when you need
to change your implementation you discover that most of your code needs to be rewritten
from scratch.
I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.
What quickly became apparent to me from my CL experience is that most of problems
Boost guys are fighting against are just plain nonexistent for Lispers.
Look at this, for example:
variant.hpp. A good workaround for C++ typing model. What do we have in Common Lisp?
(let ((x 5)) .... (setf x "abc");; no problems with types! ....)
(sorry for mangled indentation)
Now look at this beauty: boost::lambda.
Don't forget error messages it produces when you mistype something or stumble across a bug.
CL example?
(mapcar #'(lambda (x) ;; any code you want ...) my-list)
Not to mention Lisp's GC versus boost::shared_ptr.
OK, these are areas where dynamic languages like Perl, Python and Ruby, and even
statically typed like C# or Java are catching up to some degree. Now let's look at some
CL's more-or-less unique features.
Just got this from my/usr/bin/fortune:
LETTERS TO THE EDITOR (The Times of London)
Dear Sir,
I am firmly opposed to the spread of microchips either to the home or
to the office. We have more than enough of them foisted upon us in
public places. They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.
Yours faithfully,
Capt. Quinton D'Arcy, J. P.
Sevenoaks
We have plenty of snake oil here, including homeopathy, various "supplements" and so on. But such stuff isn't recommended by Ministry of Health. Also, it's also usually rather hard to find actual manufacturers of snake oil products, and they usually don't bother with scientific explanations of underlying principles, referring to various mystery "energies" and so on.
Arbidol is actually recommended by Russian Ministry of Health as profylaxys of flu. Its manufactures don't try to hide themselves from general public. They also do provide rather detailed information concerning its biochemical principles. The drug did undergo clinical testing. It isn't advertised as a panacea. So there seems to be no 'mystery' or 'wonder' about it.
Arbidol (in Russian) is virtually unknown outside Russia, while it seems that it was shown to be able to defeat bird flu virus. For some
discussions in English, look e.g. here.
I've heard that Tamiflu is preferred for political reasons. Maybe there's actually
something wrong with Arbidol, but here in Moscow they claim that Arbidol can cure
bird flu in their rather widespread advertisements and aren't driven to court for that.
There was an inaccuracy in my original post - GMail doesn't just kill attachments, it kills the whole messages containing anything suspicious.
GMail has selective policy on rejecting messages that have some file types attached to them (it judges by extension). It doesn't accept executable files or anything that looks like them or contains them. It rejects ZIP files containing anything suspicious. What's more unpleasant, it seems to reject all RAR attachments regardless of their content. Unfortunatelly I have to work with VB.NET in a somewhat distributed team, and despite the fact that Subversion solves code storage/exchange/etc. problems, there still can be situations when someone sends you several little source files in ZIP - they also get rejected (suspicious.vb extension). As of now, the common solution is renaming files to change their extension to something meaningless before sending them.
I understand that if Google didn't do anything about filtering out virus attachments,
unattended accounts would quickly be overflown despite great mailbox size. But I think
they could use some antivirus (e.g. an adapted version of ClamAV) instead of rejecting
e-mails.
Among my friends/colleagues the attachment problem is the greatest complaint (and the most
often cited reason for not using GMail). Some of them actually contacted Google, and the
answer was something like that this is going to be fixed somehow when they're out of Beta, but something tells me that it's not going to happen too soon).
I hope that Yahoo releases something competitive, maybe this will finally make GMail team add an option to GMail preferences so that I can receive these attachments... Well, I'm not a big fan of sending stuff as e-mail attachments, but a lot of people prefer this way, and not everyone is aware of GMail's attachment killing habits...
First something quite like originalBabel fish, then these singing mice, and now tracking down anonymous fathers. Well, what Arthur Dent donated was just his DNA, but similiarity is striking, isn't it?
As an experienced.NET programmer with some Common Lisp knowledge, I'd say that it will take C# another ten years before it reaches the level of CL. Well, at that point it will probably become just another Lisp dialect, differing from CL as much as modern.NET differs from Java. Then it will take them another ten years to match Genera development environment capabilities.
Eugene H. Spafford Department of Computer Sciences Purdue University West Lafayette, IN 47907-2004
spaf@cs.purdue.edu
ABSTRACT On the evening of 2 November 1988, someone infected the Internet with a worm program. That program exploited flaws in utility programs in systems based on BSD-derived versions of UNIX. The flaws allowed the program to break into those machines and copy itself, thus infecting those systems. This infection eventually spread to thousands of machines, and disrupted normal activities and Internet connectivity for many days. This report gives a detailed description of the components of the worm program\320data and functions. It is based on study of two completely independent reverse-compilations of the worm and a version disassembled to VAX assembly language. Almost no source code is given in the paper because of current concerns about the state of the ``immune system'' of Internet hosts, but the description should be detailed enough to allow the reader to understand the behavior of the program. The paper contains a review of the security flaws exploited by the worm program, and gives some recommendations on how to eliminate or mitigate their future use. The report also includes an analysis of the coding style and methods used by the author\(s\) of the worm, and draws some conclusions about his abilities and intent.
Copyright 1988 by Eugene H. Spafford. All rights reserved.
Permission is hereby granted to make copies of this work, without charge, solely for the purposes of instruction and research. Any such copies must include a copy of this title page and copyright notice. Any other reproduction, publication, or use is strictly prohibited without express written permission. November 29, 1988
The Internet Worm Program: An Analysis Purdue Technical Report CSD-TR-823 Eugene H. Spafford Department of Computer Sciences Purdue University West Lafayette, IN 47907-2004
The finger program is a utility that allows users to obtain information about other users. It is usually used to identify the full name or login name of a user, whether or not a user is currently logged in, and possibly other information about the person such as telephone numbers where he or she can be reached. The fingerd program is intended to run as a daemon, or background process, to service remote requests using the finger protocol. [Harr77] The bug exploited to break fingerd involved overrunning the buffer the daemon used for input. The standard C library has a few routines that read input without checking for bounds on the buffer involved. In particular, the gets call takes input to a buffer without doing any bounds checking; this was the call exploited by the worm. The gets routine is not the only routine with this flaw. The family of routines scanf/fscanf/sscanf may also overrun buffers when decoding input unless the user explicitly specifies limits on the number of characters to be converted. Incautious use of the sprintf routine can overrun buffers. Use of the strcat/strcpy calls instead of the strncat/strncpy routines may also overflow their buffers. Although experienced C programmers are aware of the problems with these routines, they continue to use them. Worse, their format is in some sense codified not only by historical inclusion in UNIX and the C language, but more formally in the forthcoming ANSI language standard for C. The hazard with these calls is that any network server or privileged program using them may possibly be compromised by careful precalculation of the inappropriate input. An important step in removing this hazard would be first to develop a set of replacement calls that accept values for bounds on their program-supplied buffer arguments. Next, all system servers and privileged applications should be examined for unchecked uses of the original calls, with those calls then being replaced by the new bounded versions. Note that this audit has already been performed by the group at Berkeley; only the fingerd and timed servers used the gets call, and patches to fingerd have already been posted. Appendix C contains a new version of fingerd written specifically for this report that may be used to replace the original version. This version makes no calls to gets.
So I think "... because people didn't really understand buffer overruns and port 80 and I/O issues 10 years ago" in the article should actually read as "... because people HERE AT MICROSOFT didn't really understand buffer overruns and port 80 and I/O issues 10 years ago".
Slashdot Mirror
FYI, in Russia even buying anything resembling *hidden* camera may easily get you into jail. There were several cases of guys buying stuff like a camera hidden inside pen and getting several years of jailtime for it. As of dashcams, which are legal because they don't qualify as hidden cameras, while far from eliminating police corruption, they DO help in some cases against corrupt policement, and that's one of the reasons why they're so popular.
There was very advanced and expensive Lisp OS once http://en.wikipedia.org/wiki/Genera_(operating_system)
While there is an extensive (yet old) specification for the core language, the CLisp folks just didn't consider that standardizing a 'standard library' would be a good idea, and as a result each and every implementation features it's very own implementation of threads, networking, GUI, ... completely incompatible with the implementation next door (and sometimes within an implementation from one platform to the other).
[BTW: CLISP is just an implementation of Common Lisp, please don't confuse it with the language itself] Yes, this is a problem, but it isn't as bad as it may seem. Do we have standard threads/networking/GUI in C? C++? (POSIX doesn't count - a lot of C/C++ code is written for Win32) What about 'standard' threads/GUI in Perl? Yet these languages are quite widespread.
And the worst, I think, is that the Lisp community doesn't seem to see how some kind of standard library (as in, including the batteries in Clisp) would be useful to bring people new to the language in, or keep them there.
Not true. Look here.
Then again, actually reading comp.lang.lisp (or -- god forbid -- asking a question there) is sadly more than enough to drive you very far from trying to code in lisp ever again.
cll does indeed attract some number of strange trolls. Also, Lisp newbies in initial stages of their enlightenment do post some strange stuff sometimes. (When one begins to 'get it', things may seem much more cool than they are in reality for some time. It's important to learn the language a bit instead of inventing 'perpetuum mobiles' after learning a few nice features). But overall I was never insulted by anyone there though I did post some thoughts. And I don't think anyone will get flamed by cll old-timers unless he/she posts something implying that everyone else on the newsgroup is an idiot.
Let me know when the world comes to their senses and starts using Scheme instead, or some future or past dialect that has not a thousand page standard and a marginal packaging system.
Well, thousand page standard may not be always a good thing, but IMO it's better than having to rewrite your program from scratch every time you switch implementations. Different Schemes have different OO/package/whatever system, so porting between them is, well, something quite like complete rewrite. Concerning marginal packaging system -- would you please be more specific?
Plus call/cc is cool.
Agreed, but life is hard without unwind-protect (aka try ... finally). And it's possible to have continuations in CL when they are really necessary.
I have been thinking that 'Lisp is not accessible' for years. I regret all these years beyond expression. Don't believe it. It's horrible lie. Here's the proof.
Making Windows Usable for Old Linux Farts
Still shows that making Windows workable is rather hard task.
"Do not meddle in the affairs of wizards, for you are crunchy and good with ketchup."
It is funny that you should mention Python as a replacement for LISP in the context of Reddit: they indeed recently switched from Python to LISP, rewriting their whole application in about a week.
(correction: they switched from Lisp to Python) It's exactly the reason why I mentioned Reddit. A perfect example of a situation where most of the job is done by existing libraries/frameworks/etc.
The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well.
CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or .NET bytecode actually AFAIK. Later Open Genera was released that allows one to run the Lisp OS on Alphas. Using high-level opcodes is
not critical for Lisp (most modern CL compilers save CLisp produce native machine instructions for their target architectures).
Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!
Yes, it's rather hard to do so, just because Linux kernel and X.org are written in C. If they were written in Lisp, it would be hard to write drivers in C unless authors cared to provide proper FFI-based "foreign" driver loading mechanism. There's nothing wrong with Lisp itself concerning low level stuff. For example, take a look at this beast (Lisp on bare metal).
As a matter of fact, I agree that C/C++ is safer bet in our world, but not because C and C++ are more general languages than Lisp is. It's just because most of stuff in use is written in these languages. Lisp machines failed (mostly due to management & political reasons), Lisp itself became the scapegoat for failed AI promises, so now curly braces are almost inevitable for serious programmers.
But nevertheless Lisp is worth learning as it can be the best tool for complex problems in many cases, and also due to the fact that it makes programmers more broad-minded. It's actually much more general than C++ in the sense that it easily supports almost any paradigm one can imagine. For instance, it's possible to seamlessly embed SQL, Prolog, HTML, etc. rewritten using S-expressions in Lisp programs.
Look here.
I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really :-)
But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.
CL's problems actually stem from the lack of Open Source libraries (as there are just too few Lispers). There are two approaches to solving these problems:
Approach (b) is feasible when most functionality of your product resides in your code and not in libraries. E.g. reddit.com code is mostly a rather thin wrapper around database + Web server, so free Common Lisp implementation may not be a best tool for the job. It may be better to use a commercial CL implementation or some other language (such as Python) in such cases, depending on how much money & spare time you have.
Another example - I'm writing an online store now as a semi-holiday project, I don't have too strict time constraints there, so I'm using CMUCL+CLSQL+TBNL to implement it. With severe time constraints it would be better to use Python in my case, as I don't want to pay $$$ for commercial Lisps.
But there are plenty of cases where Lisp proves to be just the ideal tool for the job.
Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.
Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/">Boost C++ libraries.
At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.
Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to "emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL.
After playing with Scheme for a while, I've found out (to my surprise) that the language can be used for many other purposes besides list (tree) processing and simple scripting (as in Gimp). As an example, there are wonderful things like Scsh. It's possible to write Web applications, many Schemes can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.
So I've begun to try to do some real things in Scheme. Disillusionment has come rather quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is not standardized and thus is 100% non-portable between implementations. Moreover, every implementation has its bugs and limitations, and when you come to the point when you need to change your implementation you discover that most of your code needs to be rewritten from scratch.
I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.
What quickly became apparent to me from my CL experience is that most of problems Boost guys are fighting against are just plain nonexistent for Lispers. Look at this, for example: variant.hpp. A good workaround for C++ typing model. What do we have in Common Lisp?
(sorry for mangled indentation)
Now look at this beauty: boost::lambda. Don't forget error messages it produces when you mistype something or stumble across a bug. CL example?
Not to mention Lisp's GC versus boost::shared_ptr.
OK, these are areas where dynamic languages like Perl, Python and Ruby, and even statically typed like C# or Java are catching up to some degree. Now let's look at some CL's more-or-less unique features.
(sorry for bad formatting...)
Just got this from my /usr/bin/fortune:
LETTERS TO THE EDITOR (The Times of London)
Dear Sir,
I am firmly opposed to the spread of microchips either to the home or
to the office. We have more than enough of them foisted upon us in
public places. They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.
Yours faithfully,
Capt. Quinton D'Arcy, J. P.
Sevenoaks
Why do you think that Marvin's brain was running NetBSD? Otherwise, what use could he make of a laptop, with his "brain the size of a planet" ?
Arbidol is actually recommended by Russian Ministry of Health as profylaxys of flu. Its manufactures don't try to hide themselves from general public. They also do provide rather detailed information concerning its biochemical principles. The drug did undergo clinical testing. It isn't advertised as a panacea. So there seems to be no 'mystery' or 'wonder' about it.
I've heard that Tamiflu is preferred for political reasons. Maybe there's actually something wrong with Arbidol, but here in Moscow they claim that Arbidol can cure bird flu in their rather widespread advertisements and aren't driven to court for that.
There was an inaccuracy in my original post - GMail doesn't just kill attachments, it kills the whole messages containing anything suspicious.
GMail has selective policy on rejecting messages that have some file types attached to them (it judges by extension). It doesn't accept executable files or anything that looks like them or contains them. It rejects ZIP files containing anything suspicious. What's more unpleasant, it seems to reject all RAR attachments regardless of their content. Unfortunatelly I have to work with VB.NET in a somewhat distributed team, and despite the fact that Subversion solves code storage/exchange/etc. problems, there still can be situations when someone sends you several little source files in ZIP - they also get rejected (suspicious .vb extension). As of now, the common solution is renaming files to change their extension to something meaningless before sending them.
I understand that if Google didn't do anything about filtering out virus attachments, unattended accounts would quickly be overflown despite great mailbox size. But I think they could use some antivirus (e.g. an adapted version of ClamAV) instead of rejecting e-mails.
Among my friends/colleagues the attachment problem is the greatest complaint (and the most often cited reason for not using GMail). Some of them actually contacted Google, and the answer was something like that this is going to be fixed somehow when they're out of Beta, but something tells me that it's not going to happen too soon).
I hope that Yahoo releases something competitive, maybe this will finally make GMail team add an option to GMail preferences so that I can receive these attachments... Well, I'm not a big fan of sending stuff as e-mail attachments, but a lot of people prefer this way, and not everyone is aware of GMail's attachment killing habits...
First something quite like original Babel fish, then these singing mice, and now tracking down anonymous fathers. Well, what Arthur Dent donated was just his DNA, but similiarity is striking, isn't it?
As an experienced .NET programmer with some Common Lisp knowledge, I'd say that it will take C# another ten years before it reaches the level of CL. Well, at that point it will probably become just another Lisp dialect, differing from CL as much as modern .NET differs from Java. Then it will take them another ten years to match Genera development environment capabilities.
Well, someone mentioned this in one of the comments - buffer overrun was utilized by rather well-known 1988 UNIX worm.
http://en.wikipedia.org/wiki/Morris_worm
BTW, that worm was written by the guy who later founded Viaweb (now Yahoo! Store) together with Paul Graham.
http://en.wikipedia.org/wiki/Robert_Tappan_Morris, _Jr.