Incremental compilation in the lisp sense has always been possible in Java, you're just slamming it because it's not done the same (learn how to use a classloader and maybe you'll understand.)
Okay, I'm quite willing to admit I wasn't aware Java could do incremental compilation of any kind - I thought you just had to compile a Java source file into a JVM bytecode file (or machine code via something like gcj) and that was it. But I guess it depends on what you define as "incremental compilation". Now I think about it, the term is pretty vague - I was thinking of an environment where you can have interpreted code and then arbitrarily decide to compile a function here or there. And that's a little too closely linked to the REPL concept as well as the amiable coexistence of interpreted and compiled code... so it's not really possible to evaluate Java on those terms.
I'll also cheerfully admit I don't know how to use a Java classloader - I haven't written anything serious in Java for about six years. But from what I remember, I thought the classloader was more of an incremental linker than a compiler.
REPL could be done in Java, but few people seem to care to; maybe because not everybody likes to develop in such an environment.
I suspect it's more that Java's just not very well suited to that kind of try-stuff-out-in-bits-and-pieces environment. You're right that it's not anything super-duper amazing, and it should be possible to have a Java REPL, but I think it'd be awkward and probably wouldn't be very effective/useful (as, for comparison, it is for Python).
Macros in the lisp sense seem like they would be difficult to add to Java,
As far as I understand it, it wouldn't even be possible. The whole power of the Lisp macro system is due to the s-expression syntax (regular and unambiguous structure, code is data is code, etc.).
I've heard that some non-sexp languages can approximate Lisp-style macros (eg. Dylan), but they don't compare to the real thing.
Engineering is about making tradeoffs--something that the designers of Lisp did not understand.
Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.
Java is also implementing lots of Lisp things, [...]
Lots of Lisp things??? Tell you what. How about you tell me just two. And you can use "garbage collection" if you can't think of anything else, but I'll think it pretty lame:).
The things I generally think of when I think of Lisp (Common Lisp or Scheme or other forms) includes REPLs, macros, functional-style programming, macros, incremental/optional compilation, macros, optional/dynamic typing, macros, closures and macros.
Oh, and (occasionally) continuations.
Java doesn't come close to having any of those, last I looked.
And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp.
Okay, try to name (or point to an article online that names) something wrong (or suboptimal, etc.) with the Common Lisp implementation of scoping, naming, reflection and code generation. Seriously, I'm really interested. I'm not an expert on Common Lisp myself, and all I'd read suggested that Common Lisp was actually far superior to any other programming language re: reflection and code generation (and I'd never heard of any problems in the way it handles scoping or naming).
Re: the standard library having some important omissions, well, you have more of a point there. Lacking a semi-standard free implementation of a GUI has been a bit of a problem for a while, but it's debateable whether such a thing belongs in a standard library in any case. Same with other practical issues like database connectivity.
Some languages (eg. Java, Python) define rather a lot of stuff in their "standard" library. Some (eg. Scheme) define very little. Common Lisp is somewhere between the two extremes. There are usually libraries to do most things you might want (especially for the more popular implementations), but they're not necessarily standardised.
Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".
Quite likely. No argument there. But I'd probably suggest that the average (serious) Common Lisp application is significantly more sophisticated and powerful than the average (serious) Python program - mainly because Common Lisp just has a lot more raw power than Python.
To borrow an apt quote from Kenny Tilton, one of the denizens of comp.lang.lisp: "Lisp supports meta-solutions which not only pay off more and more in the
long run, but which also require greater design effort up front. If
anything a Lisper tortoise seems to be going slower than the hare because
the tortoise is still at the starting line building a rocket sled."
No, C++ does
not support functional programming. Functions are not first-class concepts of C or C++. If they were, it would be possible for you to pass functions as arguments and return functions as output.
int main(int argc, char* argv[])
{
function< int (int& a, int b) > f = lambda::_1 += lambda::_2;
int a = 0;
function< int (int b) > g = bind(f, ref(a), _1);
function< int () > h = bind(g, 3);
Slashcode stuffs up the indentation of course, but there's only one level of indent so it's still fairly readable.
Anyway, bind is a function, it takes a function f (defined as an anonymous function and assigned to f at runtime) as a parameter and returns a function (assigned to g at runtime). Same with g and h. I guess it's up to you to decide whether you'll accept that g and h are defined at runtime - the functional structures (of f, g, h) are defined at compile-time, but the parameters they close over (a, 3) are supplied to them at runtime (and they're certainly assigned at runtime).
And yes, this does seem to be almost a solution to the task that Paul Graham said probably couldn't be done in C++ (see appendix A at the bottom) - with a bit of handwaving over the types issue. Note that you can change the above so that it closes over the value of a but doesn't change a - simply by replacing ref(a) with a.
Just to be clear, I'm really not claiming that C++ can match languages like Common Lisp or Scheme for this sort of programming. It just can't. But it does a bloody good job of covering enough that it can reasonably be considered a language that supports functional programming (and supports it quite well, at that).
Which is pretty impressive given the limitations of standard C++.
Erm... yeah, okay. Apparently my knowledge of the wide variety of Pascal-like implementations is woefully incomplete:).
My original point (that the first version of Pascal in 1970-ish didn't support OO-style programming) stands, but I'm happy to acknowledge that I was at least quite misleading with the statement you quoted - that there are lots of implementations of standard Pascal that do support object-oriented development now (most of which do have the word "Pascal" in their name).
Thanks for the correction re: Delphi, BTW. Obviously I paid too much (or perhaps not enough) attention to the ravings of the Delphi nut I used to work with.:)
Well - it's kind of difficult to defend against a criticism so vague and (going by context) inconsistent. I mean, if you're going to say that C++ smart pointers are all ugly kludges (as I can't see a way you'd think auto_ptr is an ugly kludge but shared_ptr isn't), then you should really be comparing it to the alternatives - umanaged raw pointers which (as you've pointed out) leave you fucked in the case of exceptions. And if you think that they're ugly kludges too, then you pretty much think all of C++ is an ugly kludge:). Which is fine with me, don't get me wrong - just that you shouldn't specifically point towards the smart pointer technique as being an ugly kludge of a solution (to the problem of exception-safe dynamic memory management without automatic garbage collection).
There's also the minor detail that writing auto_ptr<T> t; inside one block is much tidier (and, IMO, clearer) than writing T* t = new T(); in one block and then matching that pointer up with a corresponding delete somewhere else. It's also safer - even before you bring exceptions into the picture.
As a final point, C++ does have true garbage collection as an optional extra. I haven't used it myself, but apparently some people do, and it works fine.
ur comment Callbacks are everywhere in C++ although these days gives an impression as if, callbacks are part of standard C++ way.
Well, callbacks are a fairly straightforward concept. They're most commonly used in things like GUI programming, where you do a lot of (asynchronous) event handling.
But more generally, callbacks are just a very specific example of functional programming, which is just another style of programming that emphasises functions as first-class elements.
And because C++ supports several programming paradigms, you can do object-oriented programming, functional programming and/or generic programming - often all at the same time.
Just like in Perl, there's more than one way to do it. And there isn't any one "correct" way - whatever gets the job done is fine.
If u r aware, OOP was first implemented on pascal (rather than C).
No.
Object-oriented programming is widely recognised as first being implemented on a language called
Simula in the 1960s. 1962 to be precise - for Simula I - though Bjarne Stroustrup based C++ most closely on the OO concepts in Simula 67 (1967).
Pascal was first implemented in 1970, though the original Pascal didn't support object-oriented programming.
And Pascal had inherent capability, while C++ did not.
I'm not quite sure what you mean by that. Most implementations of Pascal don't support object-oriented programming at all, much less have "inherent capability". Those implementations that do support OO-style programming usually aren't called Pascal - eg. Delphi, Oberon, Modula-2.
I could go with the list of many things. For example: C++ did not provide any mechanism to identify whether this object is instance of *THAT CLASS*.
You're using your terminology confusingly here, so it's difficult to work out exactly what you're saying. But I can say that I've only seen a few occasions where it'd be useful to work out if Base* p is actually pointing at a Derived object, and usually those cases arise when you've started out with a bad design or bad logic. Usually the whole point of having a (pointer-to) Base is that you're supposed to rely on using Base functionality. You're not supposed to care if it might actually be a Derived, the only thing that should matter is that it is substitutable-for a Base. If you need to access Derived functionality, you should have a Derived.
But anyway, in those cases where you're dealing with someone else's badly designed code, a dynamic_cast should be enough to get around it. Take your Base* and try to dynamic_cast it to a Derived* - if that fails, you haven't got a valid pointer-to-Derived. Go find the person that built the code you're using and kick them. Hard.:-)
Gee, thanks AC. I'll have to tell my slender, athletic, karate-blackbelt-possessing, early-30s stepbrother to get off the couch and do something once in a while.
Only thing is, he'd probably kick my ass if I tried that:-).
Terms like "lard ass" diabetes are pretty damn misleading and not particularly helpful. It's about as useful as referring to AIDS as a "faggot disease" (which is to say - not at all).
Even at this stage, just getting off of their dead asses and taking a walk once in a while would help prevent their noninsulin-dependent type from turning into Type I.
I'm not sure what you're saying here, because this doesn't make sense even if you typoed and wrote "Type I" where you meant "Type II". Type IIs do not turn into Type I, they're completely different diseases that just happen to have very similar external symptoms.
Perhaps you were equating some type IIs injecting insulin with being a type I. If you were, I guess that displays your level of knowledge on the subject - the whole problem with Type IIs is that their body is still producing insulin, it just doesn't work properly. The reason that insulin injection is a last resort with Type IIs is because (a) it's just not very effective, and (b) it can cause complications.
With Type Is, your pancreas just stops producing insulin. Usually there's a "honeymoon period" of a couple of years which it's still producing some insulin, but then it's all gone.
But when you inject insulin, it works just fine, just as well as in normals.
Yeah, you're exactly correct except for the "just" word;-). Speaking as a type I diabetic, with a type I brother and a type II stepfather and a type II stepbrother - keeping control of the blood sugar levels can be a bitch. Regardless of whether you're injecting insulin or not.
I wouldn't consider a "treatment" involving immunosuppressant drugs unless my blood sugar levels were really severely out of control (and I'd tried a variety of alternatives). Anti-rejection drugs suck.
I was much more excited about the Glucowatch product (nice asynchronous, albeit approximate, blood sugar monitoring tool), but I first heard about it a couple of years ago and still haven't seen any sign of them being available in Australia. Motherfuckers.
In fact, the Glucowatch website doesn't seem to have been updated in about a year. Hmmm. I wonder what's happening with them. I hope they get their shit together at some time, as the Glucowatch could be a really really useful tool.
In this type the diet and weight are factors [...]
Yeah, and they're just factors. If you have a family history of Type 2 diabetes you can develop it while being a fit, slim, health-food nut.
Type 2 is by far the more common form (something like 90% of all diabetics), so it's not surprising that people tend to get the lines between the two slightly blurred.
Not right now, no, but when Trolltech release Qt4 (later this year I think) it will be available under the GPL for Windows too. So we should have KDE4 (including KOffice) for Windows soon afterwards.
Systrace
is the kind of thing you're looking for. As far as I can tell, it's available for NetBSD, OpenBSD and Linux. I'm not surely if it's actively maintained.
Actually, Tridge didn't violate any agreement. He didn't make any agreement with Bitmover. He never used their software or accepted their license terms.
You may now try to justify your (seemingly baseless) belief that his actions are or were unethical. Seriously, I'm interested if you can come up with something:).
I haven't heard Tridge's exact words on the subject, but what little I have heard suggests that he didn't particularly care about Bitkeeper's great features and he wasn't trying to write a replacement for the entire Bitkeeper system. He was just writing a replacement for the non-OSS Bitkeeper client - and purely so he and/or others could interact with other developers on Linux kernel development without being several technological steps behind.
The fact that the non-OSS Bitkeeper client had a morally repugnant license was probably a major reason that Tridge thought this a worthwhile project.
Everything I've heard so far indicates that Tridge was doing nothing more than the OpenOffice.org and/or Abiword developers do in reverse-engineering a closed file format, thus enabling people to access their own goddamn data if they cannot (for whatever reason) use the "usual" software. For example, if you're running Linux on PPC hardware, you can't run Microsoft Office and so you can't access information locked up in Microsoft Word documents from that platform - or at least you can't without the open-source applications that have (mostly) reverse-engineered that file format.
And if you're a Linux kernel hacker and you want to develop on an equal footing with other kernel developers, but you happen to occasionally hack on source-control software too - well, you're not allowed to use the free Bitkeeper client. A roughly equivalent opensource client is your only option.
Well, aside from convincing Linus to stop using Bitkeeper:). And as that's now happened (or is in the process of happening), I think you'll find that Tridge has absolutely no interest in continuing development of his OSS bitkeeper-ish client.
I personnaly don't have much respect for the reverse engineer...the should do something creative with their supposed talents.
I think you don't really understand why people do reverse engineering, nor what a slow and painful process it can be. People don't reverse-engineer stuff to get a cheap thrill. Writing software using your own file formats and/or your own networking protocols and/or accessing your own bits of hardware is much more fun and interesting (and productive) than reverse-engineering someone else's.
But often it can be of enormous benefit to the wider community to be able to open and modify that Microsoft Word document, or use that interesting piece of hardware, or view those Sorenson Quicktime videos, with free and open-source software. And the reverse engineers are the wonderful people who make it possible for us to do this.
Sorry, I take back the above. My edition of Firefox does get it wrong. My mistake, I got confused between this URL (the reference) and this URL (the test). D'oh.
Yeah, it seems to render fine in mine too (assuming it's meant to be a single smiling face with the text "Hello World" floating above). Well, at least there's nothing obviously askew (as there is in the broken Opera and Firefox 1.0 screenshots).
I'm running Firefox built from CVS of a couple of days ago (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050410 Firefox/1.0+).
It is a bit disturbing, isn't it? Almost as disturbing as these various people trying to claim that Tridge is immoral and/or evil for reverse-engineering Bitkeeper's file format(s) and/or network protocol(s). Bizarre.
I've lost a fair chunk of respect for Linus over this. Mind you, Linus has a hell of a lot of my respect he can easily afford to lose:), but the cheek of him slagging off Tridge (when Tridge almost certainly did nothing wrong) is pretty offensive.
I'm glad it's finally over and Larry has taken his bat and ball and gone home to sulk. Maybe he can buy himself a few new toys with that half a million per year (or whatever) he'll now be saving in free-bitkeeper-maintenance costs *roll of eyes*.
As an aside, (begin sarcasm) I've often wondered how it is that FreeBSD can possibly maintain a kernel even remotely comparable to the Linux kernel. After all, they use CVS, which is the crappiest source control system there is... right?:-)
In many (most? all?) cases they're not being slanderous or libellous. They're just saying "we block email from these IP addresses, you can too if you want."
In the case of sites like blackholes.us, they just say "these are the IP blocks for this country or major ISP, use this information as you see fit."
All I'm saying is that it'd be fairly difficult to prosecute a slander/libel (sorry, not sure of the distinction) case against blacklist maintainer(s). Especially in the USA. That's probably why you haven't seen too many people suggesting it.
We had the rights to our IPs and were not using them for spam.
"We had the rights to our IPs".... well, whatever that means, it probably doesn't translate to "we own these IPs".
If I ran "whois $THE_IP_IN_QUESTION", would it show your (or your company's) name and address?
No? Thought not. It'll probably show your ISP's (or your ISP's ISP's) name and address.
You don't own that IP address or addresses. You're leasing them. You don't control them.
Your ISP can (probably) shift you to another IP address if they feel they have to (depending on the specifics of your contract). If you want to own your own netblock that is totally yours, then you should be fairly safe from being listed on a (reputable) anti-spam blacklist (note: some lists are used to block entire countries, eg. South Korea)... as long as you're careful to not allow spammers on your block:). But as long as you're leasing IPs from someone else, you're vulnerable. You just have to find an ISP you can trust.
(Aside: the True Positive Fraction/False Positive Fraction is one of the standard numbers used by both the military and medical communities to evaluate the usefulness of a test. It's a good standard for measuring spam blocking as well.)
In that case, the true-positive/false-positive in your case would be 1/0. 100% true-positive, zero false-positive.
It was aimed at your ISP. The IP addresses you are using are considered part of your ISP. The
listing was completely accurate.
...and now I reread your third and fourth paragraphs:), yeah, you've got the basic idea. Although someone else already corrected you that the actual goal is not to damage ISP's financially - it's to stop them hosting spammers.
Damaging them financially (by giving customers a more concrete reason to leave) is just one legitimate (and fairly effective) way to achieve this goal.
Though it's sort of sad that the ISP in question couldn't have just responded to their abuse reports and terminated their spammers immediately. That'd be a much much better solution for all people concerned (note: I don't consider spammers to be people).
Not meaning it in a nasty way, but, well... your proposed solution has a lot of major flaws. For example, even if it were actually possible/plausible to implement (hint: it's not, not within the current SMTP), it'd rely on the sending mailserver implementing this limitation.
Large-scale spammers (hell, even small-scale spammers) run their own mailservers. Why would they use a mailserver program that implements such a restriction? Answer to rhetorical question: they wouldn't.
And when I mentioned that it wouldn't be possible/practical to implement - how could the server tell that the same message is being sent to ten people? Hint: spammers don't just put all their target email addresses in the To: header of one message, as an ordinary person might if they were sending a message to ten or twenty people.
High-profile people do have a higher chance of being modded up because moderators notice their name.
But the related side-effect is that high-profile opensource people are usually more likely to write lucid, intelligent, and possibly even well-informed posts. Usually because if they bother to post to slashdot at all, it's on an area of interest. And it appears patents, especially software patents, are interesting to Bruce.
But in regard to the geek-patent-examiner-AC's comment - well, he did put a smiley at the end of the sentence. Ha-ha only serious.
The only minor shot he was taking at Bruce's comment was that he thought it contained some FUD. And he (the AC) actually backed up that opinion with some actual evidence (rare on slashdot, I know).
Just because you disagree with someone doesn't mean you don't respect them. And conversely, just because you respect someone doesn't mean you must agree with them on everything.
I may not have been entirely clear. I think it's morally wrong for Bitmover (for example) to put such a clause in their license.
I'm not necessarily trying to justify someone agreeing to such a license and then violating it.
But if I was a judge on such a case, I'd probably rule something like "Yep, he violated that license totally and utterly" and then issue a fine of one dollar.:)
Yep, of course (though I'll presume you meant "violating a license to develop a copy of a competitor's software" where you said "copy a competitor's software").
So you sue the employee for a large amount of money with all your
impressive evidence of their license violation... and then try to cut a deal where the employee testifies against his employer about the deception.
It's going to be tricky and risky and take a lot of time and expensive lawyers, yes. But that's just the way things work.
As an aside, I doubt that most companies would try to disclaim responsibility (as a legal tactic) for a piece of software their employee's developing. I mean, what are they going to do after that if they actually want to do stuff with this software? "Buy" it from their employee? Well all right, maybe, but it just seems tangled.
Quite frankly, I just think it's wrong to have a clause like "thou shalt not attempt to reverse-engineer and/or develop your own implementation of this software." I think it's an unreasonable intrusion on your rights, and I'd like to think that such a clause wouldn't hold up in court.
Slashdot Mirror
Okay, I'm quite willing to admit I wasn't aware Java could do incremental compilation of any kind - I thought you just had to compile a Java source file into a JVM bytecode file (or machine code via something like gcj) and that was it. But I guess it depends on what you define as "incremental compilation". Now I think about it, the term is pretty vague - I was thinking of an environment where you can have interpreted code and then arbitrarily decide to compile a function here or there. And that's a little too closely linked to the REPL concept as well as the amiable coexistence of interpreted and compiled code... so it's not really possible to evaluate Java on those terms.
I'll also cheerfully admit I don't know how to use a Java classloader - I haven't written anything serious in Java for about six years. But from what I remember, I thought the classloader was more of an incremental linker than a compiler.
I suspect it's more that Java's just not very well suited to that kind of try-stuff-out-in-bits-and-pieces environment. You're right that it's not anything super-duper amazing, and it should be possible to have a Java REPL, but I think it'd be awkward and probably wouldn't be very effective/useful (as, for comparison, it is for Python).
As far as I understand it, it wouldn't even be possible. The whole power of the Lisp macro system is due to the s-expression syntax (regular and unambiguous structure, code is data is code, etc.).
I've heard that some non-sexp languages can approximate Lisp-style macros (eg. Dylan), but they don't compare to the real thing.
Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.
Lots of Lisp things??? Tell you what. How about you tell me just two. And you can use "garbage collection" if you can't think of anything else, but I'll think it pretty lame :).
The things I generally think of when I think of Lisp (Common Lisp or Scheme or other forms) includes REPLs, macros, functional-style programming, macros, incremental/optional compilation, macros, optional/dynamic typing, macros, closures and macros. Oh, and (occasionally) continuations. Java doesn't come close to having any of those, last I looked.
Okay, try to name (or point to an article online that names) something wrong (or suboptimal, etc.) with the Common Lisp implementation of scoping, naming, reflection and code generation. Seriously, I'm really interested. I'm not an expert on Common Lisp myself, and all I'd read suggested that Common Lisp was actually far superior to any other programming language re: reflection and code generation (and I'd never heard of any problems in the way it handles scoping or naming).
Re: the standard library having some important omissions, well, you have more of a point there. Lacking a semi-standard free implementation of a GUI has been a bit of a problem for a while, but it's debateable whether such a thing belongs in a standard library in any case. Same with other practical issues like database connectivity.
Some languages (eg. Java, Python) define rather a lot of stuff in their "standard" library. Some (eg. Scheme) define very little. Common Lisp is somewhere between the two extremes. There are usually libraries to do most things you might want (especially for the more popular implementations), but they're not necessarily standardised.
Quite likely. No argument there. But I'd probably suggest that the average (serious) Common Lisp application is significantly more sophisticated and powerful than the average (serious) Python program - mainly because Common Lisp just has a lot more raw power than Python.
To borrow an apt quote from Kenny Tilton, one of the denizens of comp.lang.lisp: "Lisp supports meta-solutions which not only pay off more and more in the long run, but which also require greater design effort up front. If anything a Lisper tortoise seems to be going slower than the hare because the tortoise is still at the starting line building a rocket sled."
You mean like this?
Slashcode stuffs up the indentation of course, but there's only one level of indent so it's still fairly readable.
Anyway, bind is a function, it takes a function f (defined as an anonymous function and assigned to f at runtime) as a parameter and returns a function (assigned to g at runtime). Same with g and h. I guess it's up to you to decide whether you'll accept that g and h are defined at runtime - the functional structures (of f, g, h) are defined at compile-time, but the parameters they close over (a, 3) are supplied to them at runtime (and they're certainly assigned at runtime).
And yes, this does seem to be almost a solution to the task that Paul Graham said probably couldn't be done in C++ (see appendix A at the bottom) - with a bit of handwaving over the types issue. Note that you can change the above so that it closes over the value of a but doesn't change a - simply by replacing ref(a) with a.
Just to be clear, I'm really not claiming that C++ can match languages like Common Lisp or Scheme for this sort of programming. It just can't. But it does a bloody good job of covering enough that it can reasonably be considered a language that supports functional programming (and supports it quite well, at that).
Which is pretty impressive given the limitations of standard C++.
Erm... yeah, okay. Apparently my knowledge of the wide variety of Pascal-like implementations is woefully incomplete :).
My original point (that the first version of Pascal in 1970-ish didn't support OO-style programming) stands, but I'm happy to acknowledge that I was at least quite misleading with the statement you quoted - that there are lots of implementations of standard Pascal that do support object-oriented development now (most of which do have the word "Pascal" in their name).
Thanks for the correction re: Delphi, BTW. Obviously I paid too much (or perhaps not enough) attention to the ravings of the Delphi nut I used to work with. :)
Because in the desktop PC market they're fighting against a little thing called the network effect.
Whether you think of them as ugly kludges or not and whether you think of them as an acceptable solution or not (and you certainly have the right to your opinion (informed or not) on both points), the conventional C++ solutions for exception-safe dynamic memory management do work.
And you don't have to "catch exceptions at every point to free stuff".
Well - it's kind of difficult to defend against a criticism so vague and (going by context) inconsistent. I mean, if you're going to say that C++ smart pointers are all ugly kludges (as I can't see a way you'd think auto_ptr is an ugly kludge but shared_ptr isn't), then you should really be comparing it to the alternatives - umanaged raw pointers which (as you've pointed out) leave you fucked in the case of exceptions. And if you think that they're ugly kludges too, then you pretty much think all of C++ is an ugly kludge :). Which is fine with me, don't get me wrong - just that you shouldn't specifically point towards the smart pointer technique as being an ugly kludge of a solution (to the problem of exception-safe dynamic memory management without automatic garbage collection).
There's also the minor detail that writing auto_ptr<T> t; inside one block is much tidier (and, IMO, clearer) than writing T* t = new T(); in one block and then matching that pointer up with a corresponding delete somewhere else. It's also safer - even before you bring exceptions into the picture.
As a final point, C++ does have true garbage collection as an optional extra. I haven't used it myself, but apparently some people do, and it works fine.
Well, callbacks are a fairly straightforward concept. They're most commonly used in things like GUI programming, where you do a lot of (asynchronous) event handling.
But more generally, callbacks are just a very specific example of functional programming, which is just another style of programming that emphasises functions as first-class elements. And because C++ supports several programming paradigms, you can do object-oriented programming, functional programming and/or generic programming - often all at the same time.
Just like in Perl, there's more than one way to do it. And there isn't any one "correct" way - whatever gets the job done is fine.
No.
Object-oriented programming is widely recognised as first being implemented on a language called Simula in the 1960s. 1962 to be precise - for Simula I - though Bjarne Stroustrup based C++ most closely on the OO concepts in Simula 67 (1967).
Pascal was first implemented in 1970, though the original Pascal didn't support object-oriented programming.
I'm not quite sure what you mean by that. Most implementations of Pascal don't support object-oriented programming at all, much less have "inherent capability". Those implementations that do support OO-style programming usually aren't called Pascal - eg. Delphi, Oberon, Modula-2.
You're using your terminology confusingly here, so it's difficult to work out exactly what you're saying. But I can say that I've only seen a few occasions where it'd be useful to work out if Base* p is actually pointing at a Derived object, and usually those cases arise when you've started out with a bad design or bad logic. Usually the whole point of having a (pointer-to) Base is that you're supposed to rely on using Base functionality. You're not supposed to care if it might actually be a Derived, the only thing that should matter is that it is substitutable-for a Base. If you need to access Derived functionality, you should have a Derived.
But anyway, in those cases where you're dealing with someone else's badly designed code, a dynamic_cast should be enough to get around it. Take your Base* and try to dynamic_cast it to a Derived* - if that fails, you haven't got a valid pointer-to-Derived. Go find the person that built the code you're using and kick them. Hard. :-)
Gee, thanks AC. I'll have to tell my slender, athletic, karate-blackbelt-possessing, early-30s stepbrother to get off the couch and do something once in a while.
Only thing is, he'd probably kick my ass if I tried that :-).
Terms like "lard ass" diabetes are pretty damn misleading and not particularly helpful. It's about as useful as referring to AIDS as a "faggot disease" (which is to say - not at all).
I'm not sure what you're saying here, because this doesn't make sense even if you typoed and wrote "Type I" where you meant "Type II". Type IIs do not turn into Type I, they're completely different diseases that just happen to have very similar external symptoms.
Perhaps you were equating some type IIs injecting insulin with being a type I. If you were, I guess that displays your level of knowledge on the subject - the whole problem with Type IIs is that their body is still producing insulin, it just doesn't work properly. The reason that insulin injection is a last resort with Type IIs is because (a) it's just not very effective, and (b) it can cause complications.
With Type Is, your pancreas just stops producing insulin. Usually there's a "honeymoon period" of a couple of years which it's still producing some insulin, but then it's all gone. But when you inject insulin, it works just fine, just as well as in normals.
(talking purely about type I diabetes here)
Yeah, you're exactly correct except for the "just" word ;-). Speaking as a type I diabetic, with a type I brother and a type II stepfather and a type II stepbrother - keeping control of the blood sugar levels can be a bitch. Regardless of whether you're injecting insulin or not.
I wouldn't consider a "treatment" involving immunosuppressant drugs unless my blood sugar levels were really severely out of control (and I'd tried a variety of alternatives). Anti-rejection drugs suck.
I was much more excited about the Glucowatch product (nice asynchronous, albeit approximate, blood sugar monitoring tool), but I first heard about it a couple of years ago and still haven't seen any sign of them being available in Australia. Motherfuckers.
In fact, the Glucowatch website doesn't seem to have been updated in about a year. Hmmm. I wonder what's happening with them. I hope they get their shit together at some time, as the Glucowatch could be a really really useful tool.
Yeah, and they're just factors. If you have a family history of Type 2 diabetes you can develop it while being a fit, slim, health-food nut.
Type 2 is by far the more common form (something like 90% of all diabetics), so it's not surprising that people tend to get the lines between the two slightly blurred.
Not right now, no, but when Trolltech release Qt4 (later this year I think) it will be available under the GPL for Windows too. So we should have KDE4 (including KOffice) for Windows soon afterwards.
Could be interesting. :)
Systrace is the kind of thing you're looking for. As far as I can tell, it's available for NetBSD, OpenBSD and Linux. I'm not surely if it's actively maintained.
Actually, Tridge didn't violate any agreement. He didn't make any agreement with Bitmover. He never used their software or accepted their license terms.
You may now try to justify your (seemingly baseless) belief that his actions are or were unethical. Seriously, I'm interested if you can come up with something :).
I haven't heard Tridge's exact words on the subject, but what little I have heard suggests that he didn't particularly care about Bitkeeper's great features and he wasn't trying to write a replacement for the entire Bitkeeper system. He was just writing a replacement for the non-OSS Bitkeeper client - and purely so he and/or others could interact with other developers on Linux kernel development without being several technological steps behind.
The fact that the non-OSS Bitkeeper client had a morally repugnant license was probably a major reason that Tridge thought this a worthwhile project.
Everything I've heard so far indicates that Tridge was doing nothing more than the OpenOffice.org and /or Abiword developers do in reverse-engineering a closed file format, thus enabling people to access their own goddamn data if they cannot (for whatever reason) use the "usual" software. For example, if you're running Linux on PPC hardware, you can't run Microsoft Office and so you can't access information locked up in Microsoft Word documents from that platform - or at least you can't without the open-source applications that have (mostly) reverse-engineered that file format.
And if you're a Linux kernel hacker and you want to develop on an equal footing with other kernel developers, but you happen to occasionally hack on source-control software too - well, you're not allowed to use the free Bitkeeper client. A roughly equivalent opensource client is your only option.
Well, aside from convincing Linus to stop using Bitkeeper :). And as that's now happened (or is in the process of happening), I think you'll find that Tridge has absolutely no interest in continuing development of his OSS bitkeeper-ish client.
I think you don't really understand why people do reverse engineering, nor what a slow and painful process it can be. People don't reverse-engineer stuff to get a cheap thrill. Writing software using your own file formats and/or your own networking protocols and/or accessing your own bits of hardware is much more fun and interesting (and productive) than reverse-engineering someone else's.
But often it can be of enormous benefit to the wider community to be able to open and modify that Microsoft Word document, or use that interesting piece of hardware, or view those Sorenson Quicktime videos, with free and open-source software. And the reverse engineers are the wonderful people who make it possible for us to do this.
Thanks for this post. You've said almost exactly what I'd want to say, except much more lucidly and concisely :). Well done.
Sorry, I take back the above. My edition of Firefox does get it wrong. My mistake, I got confused between this URL (the reference) and this URL (the test). D'oh.
Yeah, it seems to render fine in mine too (assuming it's meant to be a single smiling face with the text "Hello World" floating above). Well, at least there's nothing obviously askew (as there is in the broken Opera and Firefox 1.0 screenshots).
I'm running Firefox built from CVS of a couple of days ago (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050410 Firefox/1.0+).
It is a bit disturbing, isn't it? Almost as disturbing as these various people trying to claim that Tridge is immoral and/or evil for reverse-engineering Bitkeeper's file format(s) and/or network protocol(s). Bizarre.
I've lost a fair chunk of respect for Linus over this. Mind you, Linus has a hell of a lot of my respect he can easily afford to lose :), but the cheek of him slagging off Tridge (when Tridge almost certainly did nothing wrong) is pretty offensive.
I'm glad it's finally over and Larry has taken his bat and ball and gone home to sulk. Maybe he can buy himself a few new toys with that half a million per year (or whatever) he'll now be saving in free-bitkeeper-maintenance costs *roll of eyes*.
As an aside, (begin sarcasm) I've often wondered how it is that FreeBSD can possibly maintain a kernel even remotely comparable to the Linux kernel. After all, they use CVS, which is the crappiest source control system there is... right? :-)
In many (most? all?) cases they're not being slanderous or libellous. They're just saying "we block email from these IP addresses, you can too if you want."
In the case of sites like blackholes.us, they just say "these are the IP blocks for this country or major ISP, use this information as you see fit."
All I'm saying is that it'd be fairly difficult to prosecute a slander/libel (sorry, not sure of the distinction) case against blacklist maintainer(s). Especially in the USA. That's probably why you haven't seen too many people suggesting it.
"We had the rights to our IPs".... well, whatever that means, it probably doesn't translate to "we own these IPs".
If I ran "whois $THE_IP_IN_QUESTION", would it show your (or your company's) name and address? No? Thought not. It'll probably show your ISP's (or your ISP's ISP's) name and address.
You don't own that IP address or addresses. You're leasing them. You don't control them. Your ISP can (probably) shift you to another IP address if they feel they have to (depending on the specifics of your contract). If you want to own your own netblock that is totally yours, then you should be fairly safe from being listed on a (reputable) anti-spam blacklist (note: some lists are used to block entire countries, eg. South Korea)... as long as you're careful to not allow spammers on your block :). But as long as you're leasing IPs from someone else, you're vulnerable. You just have to find an ISP you can trust.
In that case, the true-positive/false-positive in your case would be 1/0. 100% true-positive, zero false-positive.
It was aimed at your ISP. The IP addresses you are using are considered part of your ISP. The listing was completely accurate.
Though it's sort of sad that the ISP in question couldn't have just responded to their abuse reports and terminated their spammers immediately. That'd be a much much better solution for all people concerned (note: I don't consider spammers to be people).
You Might Be An Anti-Spam Kook If....
Not meaning it in a nasty way, but, well... your proposed solution has a lot of major flaws. For example, even if it were actually possible/plausible to implement (hint: it's not, not within the current SMTP), it'd rely on the sending mailserver implementing this limitation.
Large-scale spammers (hell, even small-scale spammers) run their own mailservers. Why would they use a mailserver program that implements such a restriction? Answer to rhetorical question: they wouldn't.
And when I mentioned that it wouldn't be possible/practical to implement - how could the server tell that the same message is being sent to ten people? Hint: spammers don't just put all their target email addresses in the To: header of one message, as an ordinary person might if they were sending a message to ten or twenty people.
High-profile people do have a higher chance of being modded up because moderators notice their name.
But the related side-effect is that high-profile opensource people are usually more likely to write lucid, intelligent, and possibly even well-informed posts. Usually because if they bother to post to slashdot at all, it's on an area of interest. And it appears patents, especially software patents, are interesting to Bruce.
But in regard to the geek-patent-examiner-AC's comment - well, he did put a smiley at the end of the sentence. Ha-ha only serious. The only minor shot he was taking at Bruce's comment was that he thought it contained some FUD. And he (the AC) actually backed up that opinion with some actual evidence (rare on slashdot, I know).
Just because you disagree with someone doesn't mean you don't respect them. And conversely, just because you respect someone doesn't mean you must agree with them on everything.
Well yes, absolutely. :)
I may not have been entirely clear. I think it's morally wrong for Bitmover (for example) to put such a clause in their license. I'm not necessarily trying to justify someone agreeing to such a license and then violating it.
But if I was a judge on such a case, I'd probably rule something like "Yep, he violated that license totally and utterly" and then issue a fine of one dollar. :)
Yep, of course (though I'll presume you meant "violating a license to develop a copy of a competitor's software" where you said "copy a competitor's software").
So you sue the employee for a large amount of money with all your impressive evidence of their license violation... and then try to cut a deal where the employee testifies against his employer about the deception.
It's going to be tricky and risky and take a lot of time and expensive lawyers, yes. But that's just the way things work.
As an aside, I doubt that most companies would try to disclaim responsibility (as a legal tactic) for a piece of software their employee's developing. I mean, what are they going to do after that if they actually want to do stuff with this software? "Buy" it from their employee? Well all right, maybe, but it just seems tangled.
Quite frankly, I just think it's wrong to have a clause like "thou shalt not attempt to reverse-engineer and/or develop your own implementation of this software." I think it's an unreasonable intrusion on your rights, and I'd like to think that such a clause wouldn't hold up in court.