If the cops show up and you are kicking the mugger while he is on the ground in a fetal position, you will be arrested.
Actually, I'm not sure that's true. A friend took a self-defense class. Their standard advice was to beat the hell out of the guy, then stomp on his head until you're confident he won't move without serious medical help. It definitely wasn't a class about fighting fair or doing the minimum amount of damage. It was a class about feeling safe without crossing legal lines, and they advised you to leave the guy unconscious and bleeding.
At the same time, they advised that if you disarm an attacker, you should never use the weapon. (I guess someone lost a court case due to that.) They also gave stuff like a script to use when calling the police. Weird class.
(Of course, please don't consider the above legal advice. It's third-hand; there may be more subtleties I'm not aware of.)
I'm wondering how long it'll be before we see the code to this feature submitted to the FireFox CVS. 2 hours from first post? 5 hours?
I'd bet much longer. Slashdotters are all talk. There are any number of people who could implement this feature, but probably very few who would.
Count me in the latter category. I like to think of myself as a decent C++ coder, but lately I don't have the time to learn the Mozilla codebase well enough to implement even a feature as simple as this.
It's not like the graphics cards are going to be pushed to the limit - I mean, the CPU wouldn't cope with them all playing ut2004 at the same time.:-)
I don't think there's any reason it couldn't, if UT2004 had been designed for this. The thing is, I bet a lot of the CPU's effort when playing that is just tracking where everything is. You need to do that whether one person is playing or four. The actual rendering is done by the graphics card; so you've got four times the hardware there. So if you wanted to design a game that one share one game instance across four people on the same machine, I think it would work. (After all, Playstation 2s and XBoxes do this...they just use a split a single display.) I'd think the biggest worry would be bandwidth to the video cards. Most motherboards come with 8X AGP slots now...but only one of them.
And that article is complete bullshit. It may make intuitive sense...but how did they make those graphs? How do you get a precise numerical value for "reaction" or "similarity to human" plotted by "movement", "appearance", or "overall"? And for that matter, how do you fit a curve like that with only three points?
I was just talking about this yesterday. Someone raised up the often-cited "fact" that on average, people swallow six spiders per year while sleeping. Here's her question: how do you measure that?
If you see information and can't possibly imagine how it could have been gathered, it probably wasn't. It's just bullshit.
Also remember, 83% of all statistics are made up on the spot.
I have no doubt that you would consider a situation that always generated bounces broken. I thought it was a situation worth pointing out, because it's not at all obvious to some administrators.
Yeah, maybe I'll write up a more complete description of my rules sometimes that makes this more explicit.
They can still send you an email that asks if their important document arrived. So long as that email doesn't contain the original virus payload, they will get through.
And if the original mail didn't contain a virus payload either? I'm worried about false positives, not sending potentially-infected files. Here's a good example. Since you mentioned MIMEDefang, this came up on their mailing lists:
Example: someone sends a business inquiry and attaches a vcard. With the
default filter, if the vCard filename includes the email address and the
domain is a.com - say "My Name (here at there.com).vcf" - it will trigger
filter_bad_filename. Your server discards the message, but they never get
a bounce notice, and of course they never hear back from you. If you're
lucky, they'll try to reach you by phone. If you're not lucky, they'll
figure "Well, these people have never responded to a single one of my
emails, I guess I'll take my business elsewhere." If they get a bounce
notice, at least they'll know you didn't get the message.
You probably never worked in a large institution. The relay server very often is not under your control, nor is it possible to use the relay for time-consuming tasks like content filtering. At our institute, the MX host simply decides to which mail servers the mail is forwarded, and the server itself is not under our control. Port 25 connections from outside to other hosts are blocked by the routers. I know several other institutions (university as well as corporate) that have this kind of setup.
Bureaucracy, then. Always fun. I do work in a large institution (a University-run hospital), but I don't have anything to do with the email here, thank God. We just play with our departmental Oracle server.
That's a requirement almost as illusionary as to require all Windows installations to be patched!:-)
Hey, it can be done. That's one thing the support staff here does right - they can pump out updates to everyone automatically. For a while they weren't really taking advantage of it, but after some embarrassing incidents, they started pushing recent updates. Now every machine is up-to-date, and it seems like they'll keep it that way.
Of course, where your organization's machines end, and the general Internet begins...that's another story. If they were patched, we wouldn't be getting these damned virus emails. Newer versions of Microsoft software will encourage users to patch more, but there's always someone who will turn it off, and it will be years before people upgrade anyway.
Virus scanning is becoming common, but is not at all universal. Many email servers scan for viruses only during local delivery, and not when relaying.
...and such systems are broken, not following my (now more explicit) rule #3. It would be really, really nice if there were a way to get your system to get them to do the Right Thing no matter how they're misconfigured, but there isn't. So when this happens, there's no right thing to do. But I say the more wrong thing would be to drop the email, since you can never be certain it's malware.
Additionally, some systems use a form of relaying to deliver all email. This is the case for AMaViS in Postfix and "Sendmail Relay" configurations. Someone spitting out 5xx error codes with such a setup will guarantee "MAIL DELIVERY FAILURE" for all. : )
Let me clarify: I mean sending a 5XX at the end of your sphere of influence. Thus, if you are sending a 5XX internally and bouncing from there, I still consider that broken.
So if you do use such a setup and follow my three rules (you should!), you're stuck with actually delivering the messages. Maybe in a quarantine system, like one of the other posters mentioned.
If what they sent is important, they will probably check to see if it arrived.
Bah. I have people who I communicate with only through email. How am I supposed to check if something arrived?
in many countries (e.g. Germany) you are actually obliged to deliver a message, regardless of whether its a Virus or not, or at least send the recepient a message that he received an email and can fetch it by some means.
I feel sorry for you. How much disk space do you have devoted to viruses?
your proposal is short-sighted: most viruses are already relayed via several systems before they reach my mail server, so a bounce would be generated in any case; I suspect that this is true for most other systems as well.
Most? Really? How does this happen? From everything I've seen, the malware directly connects to the MX-specified server for the destination address. So I'd think the server in question should generally be under your control.
At some point, though, there's only so much you can do. Those servers forwarding it really should be doing virus checking. (I just changed the wording of rule #3 to include this.) When people upstream are being stupid...it would be nice to handle that gracefully, but I think #1 is more important. There's no right answer here.
The approach that we take is the following: We mark virus messages with a special header and deliver them in a dedicated folder in the user's mailbox. Most users simply delete all messages in this folder, but then it is their choice, we abide to all laws and do not generate bounce messages.
You are meeting the rules I mentioned, then, provided you're not sending vacation messages and such in reply. But I don't envy you the wasted disk space.
All very interesting. However the vast majority of people don't run an SMTP server, but filter their e-mail on delivery (e.g. after a POP3 download), so cannot follow this suggestion. Sorry.
They're actually not breaking any of three rules, provided they:
don't delete something outright. Stuffing it into an infrequently-checked spam folder is okay.
It's indirect? What's a good way to transfer binary files that is both direct and secure?... and archived with a personal note. One handy thing I do for large attachments is to upload them to a http server and send the link. But this is a pain in the ass for anything other than the biggest files. What are the good options
First, the section you're referring to is not one of my hard rules. It's just an extra note about how I implement them. If you disagree, no big deal.
It's indirect in the sense that mail tends to go from your client to a SMTP server on your end to one on their end to their computer (two extra machines)...in the simplest case. There might be at least another couple machines involved, especially if there are infranets there.
I tend to do as you said (HTTP), but I have an easier time uploading. If you have WebDAV set up, you can just drag on Windows (Web Folders), OS X, and other systems. I also use SSH public keys, so uploading something from the commandline is as simple as typing an scp or rsync command.
Another option is an instant messaging client. File transfers in AIM, IRC, etc. are direct connections between the two machines. Not perfect, though: both machines have to be online simultaneously, and firewalls are sometimes a problem.
Permanant Failure (5xx SMTP) codes are not safe either.
There are many cases where email is relayed before being sent to a system that does virus scanning. (Consider what happens when you use sendmail aliases and virtual domain entries that contain somthing on the order of "user: user@someotherhost.com".)
They exist, but I do not agree that they are common. Not only do they have to have a rule like that, but they have to not be using virus scanning themselves.
So, yes, people can get bounces from virus emails from this method. But it's much, much rarer than the other way. And with the randomization these viruses do, no one in particular is targeted.
The proper way to deal with email worms is to quietly delete them.
That's a horrible idea. You will have false positives, and those will be important messages. This is why people think email software isn't reliable. It is...but administrators like you configure it in an unreliable way.
Emails containing viruses are replaced by a text message warning that a virus was sent to the email address.
And that warning is so useful. Who do you send it to?
The recipients? They don't care.
The "senders"? They don't care. (The From: address is forged!)
These messages are a waste of everyone's time. I get hundreds of worms daily...but I never see them, because they're easy to filter. What I do see are these damned "helpful" messages that "I" sent someone a virus. Those are much harder to filter.
Much better way: reject viruses in the SMTP transaction. The SMTP client is then responsible for notifying the sender. If that client is a virus or worm, it will do nothing; no one is bothered. If it's a false positive, the sender will get the bounce. Reliable, unobstrusive.
If you want to filter email politely, you must follow these rules. People who don't cause the rest of us constant headaches. The worst thing is that they don't even realize it.
I guess Sun deserves what it gets, but I think the reviewer was a bit irresponsible. Perhaps he had a deadline and couldn't wait around for replacement media (assuming that you still couldn't rule out defective media) or for Sun support to resolve the issue.
He did everything right.
First, he made a reasonable attempt to install it. He tried several computers; he tried both the graphical interface and the text one. If there had been a "check media" option (like RedHat's installer has), I'll assume he would have used it, given the other steps he took. Defective media is understandable. But we don't know that's the problem, because they didn't provide a way to check. Why not?
Then he called support. He didn't use any special reviewers-only support channel. He called the normal number like everyone else has to. He got the same horrible support experience. And he criticized them for it. Why do we just let large companies off for having horrible support? Why don't we yell and scream until they do better?
I'm starting to understand what you're saying with the module stuff. So:
one module interface, many module implementations
any functionality not given in a module interface is inaccessible to other modules
no inheritance of module interfaces
no inheritance of implementations, either. (As far as I saw.)
But I don't agree that it's superior to Java's way. Namely, that you can optionally implement an interface or share a superclass. public members of a class can be called without one, at the cost of tying yourself to a particular implementation. I like inheritance; I disagree that it complicates things.
There's also a "quote" function in the tk module, so:
My concern is that people will forget to do this (or your first way, which I omitted for brevity). They already regularly forget to do so when sending things to the shell, to an XML processor, to a web browser's HTML engine, to a SQL database, etc. It causes huge problems. So when you have to be continually careful, I get uneasy.
So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).
There is indeed a balance to be struck. Colors don't need to be first-class objects; they could be strings:
b = new Button(_("hello world"), color: "red")
Where I use keyword arguments for the optional stuff. The color is simply another string. More static than your way, less than Java's. From my perspective of a user of the language, this is about as simple as it gets. One place to look for a description of the API. One syntax to learn. Yet simple.
But in my understanding, the Erlang message passing is intended to transport messages transparently between machines. Limbo's channels don't try to do any such thing. Sending a value down a Limbo channel is exactly the same as passing it to a function, except that the value goes to another process on the same machine. No marshalling, no distributed objects.
Erlang's message-passing is also the only way to send messages between Erlang processes. And when it is on the same machine, I do not believe any marshalling happens. It's certainly fast. And there's no worry about distributed objects, either: Erlang is a pure functional language, so you can't send a mutable value. No need to keep two copies in sync as they change, since they won't.
You can actually build up quite sophisticated protocol descriptions this way - an example of an area where perhaps more static type checking is used in Limbo than in other languages (but maybe it's trivial to do these things in Erlang too, I dunno).
Erlang lets you send arbitrary messages to a process. It has a receive that matches one or more patterns and takes the associated action. So yes, Limbo does seem to be more static. But I think you'd lose something if you specified an allowed pattern beforehand; you'd end up keeping the receive patterns and that one in sync, which would be a pain. So here you are doing things more statically, and I still don't like it. You can't win.;)
Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML).
Cool! You should mention that in "A Descent into Limbo"; it's a nice feature. (I can see how it would indeed be useful for code transformation.)
When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component.
It is more than the redundant declarations/definitions of C/C++, then. That's cool. It'd still be nice if I didn't have to go through this for the "Hello world" module, though, or for other situations where the one implementation is enough. I prefer simple abstract classes or Java's interface. They're there but not mandatory.
Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).
I'm missing the advantage of having a smaller interface in the language proper, when you've just moved it to another language embedded in strings rather than simplifying it.
What I am seeing is the pain of dealing with two syntaxes. And the pain of escaping things if your interface is dynamic. For instance, localized strings. This is ugly:
and error-prone. What if the dynamically-generated string contained a }? You have escaping worries. Which is a continual problem for people in SQL. I always use bind variables to avoid it. I don't see an equivalent structure here.
None of that would be necessary with a Java-style interface:
Button b = new Button(_("hello world"));
Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing.
Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.
True. This is what attracted me to Erlang. I confess; I don't quite understand the distinction between the two that you are making.
Try using it. You'd be pleasantly surprised. It really is a beautiful language.
Maybe. But there are so many languages; I don't have time to try them all. I want to at least do more with OCaml and Erlang a while first.
So you're basically talking about a syntactical problem in C/C++ which forces you to declare (textuall) things in a topological order.
Yes. Limbo shares it, and I don't understand why. If it were like Java in this way, these declarations and forward definitions would not be necessary.
Besides, nobody said anything about forcing you to use separate interface/implementation. I just said to it could be a good thing to use it and have it be supported by the compiler.
Limbo is forcing me to use them, as near as I can tell from the tutorial.
By the way, since you brought them up, declaring a proper interface is much more important in type-inferencing languages, since even tiny
changes to code can cause completely different types to be inferred.
Good to know. I haven't yet built a system in OCaml large enough to run into that problem.
You call that intelligent? Instead of just having the compiler do it? It already knows all about type aliases, what types are compatible,
etc. etc. (i.e. all the stuff that makes checking such things using a postprocessor extremely error-prone).
More intelligent than just checking that the interface's text file hasn't changed. I see now that wasn't what you were describing, but when I wrote my reply, I thought it was.
You could "fix" this feature of C/C++ inside a single file by doing a two pass compilation, but since there is no mapping from function name to file name you cannot fix it in general without doing something very radical.
Right. I don't really expect anyone to change this about an existing language (or backward-compatible one like C++ or Objective-C). But here they made an entirely new language and did the same thing. I don't understand why; every other modern language I've seen has decided the #include system is inadequate. You can (through import or however) refer to an externally-defined class that in turn refers to the one you're about to define. Without worrying about forward definitions or paying attention to ordering at all.
Ummm, even in C/C++ you can change comments in an interface and it won't break its linkage.
Right, which is why it would be silly to completely lock down the file which defines the interface, as the original poster was advocating.
You cannot, of course, add methods to a class, change signatures, etc. without breaking the interface.
As you mentioned, the first of these (the "fragile base class" problem) does not apply to Java. I'd hope it doesn't apply to Limbo either, since it's also a VM system.
I tend to agree with the first poster that having the capability to define separate interfaces and implementations is a nice feature in a language. I don't know that it should be forced down your throat, but having the capability is nice.
Of course it's good to be able to define a separate interface and implementation. That's what Java's interface is for, or just completely-abstract classes in C++.
But that's distinct from the redundant declarations that C/C++/Objective-C and Limbo force you to do. Those declarations accomplish nothing - to achieve a meaningful separation, you need a separate class. They're just redundant, and painfully so.
Python actually has it easy in that it doesn't check stuff like this is valid until the function is called. I could made a() call c() (which is never declared) and I wouldn't get an error until I call a().
Wrong. Compilers do not need separate interface definitions. They might just as well use the source files and find all the definitions there.
Compilers do not need them if properly designed, as with the many modern languages I cited.
But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.
There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file.
Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)
For the remaining 99% of us, this is unwanted Bondage and Discipline.
Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and ensuring the old methods are there, with the same signatures as before. If they're this strict, that shouldn't be a problem - they already have checkin tests to ensure all unit tests pass. Adding another condition shouldn't be a problem.
Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").
I don't see the resemblance to Python. Limbo has:
explicit static typing to Python's dynamic typing. (I don't like either; I prefer ML-style type inference.)
declarations and definitions in separate files. This is an aid to the compiler, not the person; the compiler should be able to separate them as with Java, Python, C#, Ruby, Perl, and every other modern language. When editing, it's much more friendly to change these in one place. If you want to see the declarations only, you still can - through Javadoc-style tools or through a folding text editor.
graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language. With escaping hassles, because stuff like button names is right in the middle of the embedded control string.
curly braces to denote scope, rather than Python's whitespace. Like many languages, but I like the Python way better.
no functional programming features (lambda functions, tail recursion, etc). Or if it has them, they're not mentioned in this paper.
no support for keyword arguments, that I can see. (Like Python, PL/SQL, Ada, VHDL, etc. have. They make function calls much easier to interpret without flipping back and forth to a API manual.)
the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing.
Slashdot Mirror
Be sure to use the apostrophe correctly, as in:
Actually, I'm not sure that's true. A friend took a self-defense class. Their standard advice was to beat the hell out of the guy, then stomp on his head until you're confident he won't move without serious medical help. It definitely wasn't a class about fighting fair or doing the minimum amount of damage. It was a class about feeling safe without crossing legal lines, and they advised you to leave the guy unconscious and bleeding.
At the same time, they advised that if you disarm an attacker, you should never use the weapon. (I guess someone lost a court case due to that.) They also gave stuff like a script to use when calling the police. Weird class.
(Of course, please don't consider the above legal advice. It's third-hand; there may be more subtleties I'm not aware of.)
I'd bet much longer. Slashdotters are all talk. There are any number of people who could implement this feature, but probably very few who would.
Count me in the latter category. I like to think of myself as a decent C++ coder, but lately I don't have the time to learn the Mozilla codebase well enough to implement even a feature as simple as this.
That's a good idea, but it has nothing to do with machine learning. Maybe you could submit it as a feature request in bugzilla instead?
I don't think there's any reason it couldn't, if UT2004 had been designed for this. The thing is, I bet a lot of the CPU's effort when playing that is just tracking where everything is. You need to do that whether one person is playing or four. The actual rendering is done by the graphics card; so you've got four times the hardware there. So if you wanted to design a game that one share one game instance across four people on the same machine, I think it would work. (After all, Playstation 2s and XBoxes do this...they just use a split a single display.) I'd think the biggest worry would be bandwidth to the video cards. Most motherboards come with 8X AGP slots now...but only one of them.
I was just talking about this yesterday. Someone raised up the often-cited "fact" that on average, people swallow six spiders per year while sleeping. Here's her question: how do you measure that?
If you see information and can't possibly imagine how it could have been gathered, it probably wasn't. It's just bullshit.
Also remember, 83% of all statistics are made up on the spot.
Yeah, maybe I'll write up a more complete description of my rules sometimes that makes this more explicit.
They can still send you an email that asks if their important document arrived. So long as that email doesn't contain the original virus payload, they will get through.
And if the original mail didn't contain a virus payload either? I'm worried about false positives, not sending potentially-infected files. Here's a good example. Since you mentioned MIMEDefang, this came up on their mailing lists:
That's from this message.Bureaucracy, then. Always fun. I do work in a large institution (a University-run hospital), but I don't have anything to do with the email here, thank God. We just play with our departmental Oracle server.
That's a requirement almost as illusionary as to require all Windows installations to be patched! :-)
Hey, it can be done. That's one thing the support staff here does right - they can pump out updates to everyone automatically. For a while they weren't really taking advantage of it, but after some embarrassing incidents, they started pushing recent updates. Now every machine is up-to-date, and it seems like they'll keep it that way.
Of course, where your organization's machines end, and the general Internet begins...that's another story. If they were patched, we wouldn't be getting these damned virus emails. Newer versions of Microsoft software will encourage users to patch more, but there's always someone who will turn it off, and it will be years before people upgrade anyway.
...and such systems are broken, not following my (now more explicit) rule #3. It would be really, really nice if there were a way to get your system to get them to do the Right Thing no matter how they're misconfigured, but there isn't. So when this happens, there's no right thing to do. But I say the more wrong thing would be to drop the email, since you can never be certain it's malware.
Additionally, some systems use a form of relaying to deliver all email. This is the case for AMaViS in Postfix and "Sendmail Relay" configurations. Someone spitting out 5xx error codes with such a setup will guarantee "MAIL DELIVERY FAILURE" for all. : )
Let me clarify: I mean sending a 5XX at the end of your sphere of influence. Thus, if you are sending a 5XX internally and bouncing from there, I still consider that broken.
So if you do use such a setup and follow my three rules (you should!), you're stuck with actually delivering the messages. Maybe in a quarantine system, like one of the other posters mentioned.
If what they sent is important, they will probably check to see if it arrived.
Bah. I have people who I communicate with only through email. How am I supposed to check if something arrived?
I feel sorry for you. How much disk space do you have devoted to viruses?
your proposal is short-sighted: most viruses are already relayed via several systems before they reach my mail server, so a bounce would be generated in any case; I suspect that this is true for most other systems as well.
Most? Really? How does this happen? From everything I've seen, the malware directly connects to the MX-specified server for the destination address. So I'd think the server in question should generally be under your control.
At some point, though, there's only so much you can do. Those servers forwarding it really should be doing virus checking. (I just changed the wording of rule #3 to include this.) When people upstream are being stupid...it would be nice to handle that gracefully, but I think #1 is more important. There's no right answer here.
The approach that we take is the following: We mark virus messages with a special header and deliver them in a dedicated folder in the user's mailbox. Most users simply delete all messages in this folder, but then it is their choice, we abide to all laws and do not generate bounce messages.
You are meeting the rules I mentioned, then, provided you're not sending vacation messages and such in reply. But I don't envy you the wasted disk space.
They're actually not breaking any of three rules, provided they:
You're right; thanks for the correction.
That's not one of the rules. The rules are the things in bold. The bulleted stuff below is just how I do things.
First, the section you're referring to is not one of my hard rules. It's just an extra note about how I implement them. If you disagree, no big deal.
It's indirect in the sense that mail tends to go from your client to a SMTP server on your end to one on their end to their computer (two extra machines)...in the simplest case. There might be at least another couple machines involved, especially if there are infranets there.
I tend to do as you said (HTTP), but I have an easier time uploading. If you have WebDAV set up, you can just drag on Windows (Web Folders), OS X, and other systems. I also use SSH public keys, so uploading something from the commandline is as simple as typing an scp or rsync command.
Another option is an instant messaging client. File transfers in AIM, IRC, etc. are direct connections between the two machines. Not perfect, though: both machines have to be online simultaneously, and firewalls are sometimes a problem.
They exist, but I do not agree that they are common. Not only do they have to have a rule like that, but they have to not be using virus scanning themselves.
So, yes, people can get bounces from virus emails from this method. But it's much, much rarer than the other way. And with the randomization these viruses do, no one in particular is targeted.
The proper way to deal with email worms is to quietly delete them.
That's a horrible idea. You will have false positives, and those will be important messages. This is why people think email software isn't reliable. It is...but administrators like you configure it in an unreliable way.
And that warning is so useful. Who do you send it to?
These messages are a waste of everyone's time. I get hundreds of worms daily...but I never see them, because they're easy to filter. What I do see are these damned "helpful" messages that "I" sent someone a virus. Those are much harder to filter.
Much better way: reject viruses in the SMTP transaction. The SMTP client is then responsible for notifying the sender. If that client is a virus or worm, it will do nothing; no one is bothered. If it's a false positive, the sender will get the bounce. Reliable, unobstrusive.
If you want to filter email politely, you must follow these rules. People who don't cause the rest of us constant headaches. The worst thing is that they don't even realize it.
He did everything right.
First, he made a reasonable attempt to install it. He tried several computers; he tried both the graphical interface and the text one. If there had been a "check media" option (like RedHat's installer has), I'll assume he would have used it, given the other steps he took. Defective media is understandable. But we don't know that's the problem, because they didn't provide a way to check. Why not?
Then he called support. He didn't use any special reviewers-only support channel. He called the normal number like everyone else has to. He got the same horrible support experience. And he criticized them for it. Why do we just let large companies off for having horrible support? Why don't we yell and scream until they do better?
But I don't agree that it's superior to Java's way. Namely, that you can optionally implement an interface or share a superclass. public members of a class can be called without one, at the cost of tying yourself to a particular implementation. I like inheritance; I disagree that it complicates things.
My concern is that people will forget to do this (or your first way, which I omitted for brevity). They already regularly forget to do so when sending things to the shell, to an XML processor, to a web browser's HTML engine, to a SQL database, etc. It causes huge problems. So when you have to be continually careful, I get uneasy.
There is indeed a balance to be struck. Colors don't need to be first-class objects; they could be strings:
Where I use keyword arguments for the optional stuff. The color is simply another string. More static than your way, less than Java's. From my perspective of a user of the language, this is about as simple as it gets. One place to look for a description of the API. One syntax to learn. Yet simple.
Erlang's message-passing is also the only way to send messages between Erlang processes. And when it is on the same machine, I do not believe any marshalling happens. It's certainly fast. And there's no worry about distributed objects, either: Erlang is a pure functional language, so you can't send a mutable value. No need to keep two copies in sync as they change, since they won't.
Erlang lets you send arbitrary messages to a process. It has a receive that matches one or more patterns and takes the associated action. So yes, Limbo does seem to be more static. But I think you'd lose something if you specified an allowed pattern beforehand; you'd end up keeping the receive patterns and that one in sync, which would be a pain. So here you are doing things more statically, and I still don't like it. You can't win. ;)
Check out Concurrent Programming in Erlang, PDF page 100 / written page number 89. It has a good example.
Accepted gladly. An apology is a rare thing on slashdot.
Cool! You should mention that in "A Descent into Limbo"; it's a nice feature. (I can see how it would indeed be useful for code transformation.)
It is more than the redundant declarations/definitions of C/C++, then. That's cool. It'd still be nice if I didn't have to go through this for the "Hello world" module, though, or for other situations where the one implementation is enough. I prefer simple abstract classes or Java's interface. They're there but not mandatory.
I'm missing the advantage of having a smaller interface in the language proper, when you've just moved it to another language embedded in strings rather than simplifying it.
What I am seeing is the pain of dealing with two syntaxes. And the pain of escaping things if your interface is dynamic. For instance, localized strings. This is ugly:
and error-prone. What if the dynamically-generated string contained a }? You have escaping worries. Which is a continual problem for people in SQL. I always use bind variables to avoid it. I don't see an equivalent structure here.
None of that would be necessary with a Java-style interface:
Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing.
True. This is what attracted me to Erlang. I confess; I don't quite understand the distinction between the two that you are making.
Maybe. But there are so many languages; I don't have time to try them all. I want to at least do more with OCaml and Erlang a while first.
Yes. Limbo shares it, and I don't understand why. If it were like Java in this way, these declarations and forward definitions would not be necessary.
Limbo is forcing me to use them, as near as I can tell from the tutorial.
Good to know. I haven't yet built a system in OCaml large enough to run into that problem.
More intelligent than just checking that the interface's text file hasn't changed. I see now that wasn't what you were describing, but when I wrote my reply, I thought it was.
Right. I don't really expect anyone to change this about an existing language (or backward-compatible one like C++ or Objective-C). But here they made an entirely new language and did the same thing. I don't understand why; every other modern language I've seen has decided the #include system is inadequate. You can (through import or however) refer to an externally-defined class that in turn refers to the one you're about to define. Without worrying about forward definitions or paying attention to ordering at all.
Right, which is why it would be silly to completely lock down the file which defines the interface, as the original poster was advocating.
As you mentioned, the first of these (the "fragile base class" problem) does not apply to Java. I'd hope it doesn't apply to Limbo either, since it's also a VM system.
Of course it's good to be able to define a separate interface and implementation. That's what Java's interface is for, or just completely-abstract classes in C++.
But that's distinct from the redundant declarations that C/C++/Objective-C and Limbo force you to do. Those declarations accomplish nothing - to achieve a meaningful separation, you need a separate class. They're just redundant, and painfully so.
Python actually has it easy in that it doesn't check stuff like this is valid until the function is called. I could made a() call c() (which is never declared) and I wouldn't get an error until I call a().
Compilers do not need them if properly designed, as with the many modern languages I cited.
But C and C++ require this. Ever notice how in C and C++, you can't refer to an undeclared type, even if it is declared later in the file? You have to provide at least a forward definition. ("class Bob;") Likewise functions, data members, etc. This is most annoying in C++, with inline functions. You have to pay attention to ordering. In other languages, you do not.
There is actually a very good (programmer-centric) reason for doing having separate interface/implementation: If you want to remain completely (binary or source) interface-compatible you just lock down the interface file.
Okay...that's great for those 1% of people who want the interface file to remain absolutely static. And I mean absolutely static. No new methods. No changes to the comments. No nothing. (In fact, I doubt there are even 1% of people who want this, once they give it some thought.)
For the remaining 99% of us, this is unwanted Bondage and Discipline.
Maybe the people who want the interface to remain static can do so in a more intelligent way. Like comparing javap output on check-in and ensuring the old methods are there, with the same signatures as before. If they're this strict, that shouldn't be a problem - they already have checkin tests to ensure all unit tests pass. Adding another condition shouldn't be a problem.
I don't see the resemblance to Python. Limbo has:
I don't see any redeeming qualities.