Hold on there! I'll have you know I was once a totally 1337 Intercal coder! (this was before "1337", but anyway...) Though it was rough, I once even sucessfully implemented addition. So there. To this day, I can read large numbers in Roman Numerals faster than most...
In any case, your comparisons significantly overstate Intercals expressiveness, readability, etc. When compared based on their worst features, it is much much worse than any of those languages. But I can still stand by my original statement, because for Intercal, that's not an indictment; it's a compliment.
I don't recall a bear-oriented language. Is it a variant of COW, the language for bovine developers? (All keywords are variants of "Moo")
Lest anyone suspect I just don't like functional programming at all, I'll note that the coolest language of all time is UnLambda, which you ought to google if the other languages on your list interest you.
The date is not arbitrary. LISP was invented in 1958. Hence it's user base at that time was handful of academics. It's user base today is more or less a handful of academics. LISP is arguably a bigger success than Pascal, maybe even arguably in the same league as FORTRAN. In the world of languages used outside academia, all three are minor footnotes.
I clearly haven't written much LISP? Thanks for letting me know. I must have just imagined it. Too bad, I seem to recall having enjoyed it quite a bit. I didn't mean to imply LISP was "no good"; for talking about programming languages; for examining the concepts other languages take for granted, it's excellent. For a CompSci grad student, LISP is the perfect language. For a comercial software engineer, not so much.
C++ (for example) is much more popular than LISP pretty much everywhere except possibly academia; LISP is vastly more popular in academia than anywhere else. I suggest this is not merely an accident of history.
I don't worry that LISP zealots might be right. For the most part, they are right. But like other zealots, they fail to understand that there is more than one question.
"Javascript has been called Lisp in C's clothing."
So the ways Javascript differs from C are due to being LISP like? I find it hard to imagine a more damning indictment of a language.
"All things being equal, you should generally choose the most powerful language you can all the time"
But all things are not equal. Being able to use that power is important too. Sure, LISP is powerful, in theory. But writing it makes me yearn for the straightforward simplicity of C++!
LISP fanatics bug me. If everyone just acnowledges that LISP had every language feature possible way before any thing else, can you give it a rest? Or at least stick to explaining why a language that is the greatest one ever, and has been since the 50s still has about as many users as it did in the 50s.
All the "new" features of today's languages have been available for decades in LISP, as well as in every other turing-complete language; it's a matter of how easy it is to use those features.
I've written code in a bunch of languages, including quite a bit of LISP. LISP is great if you want to do a mental puzzle resulting in aesthetically beautiful code. If you want to get stuff done, LISP blows big hairy chunks.
Out of curiosity, what industry/job are you in? Different jobs tend to have different start times, but in every office job I've run across with a required start time that time was 9:00am. Most retail places seem to be 9:00 or 10:00.
In any case, that's the reason for the "most" and "almost never" in my statement. "Business hours" are set collectively by society, but in a very messy fassion; obviously some peoples hours need to be earlier than others (so they can sell things to people before work for example). But if a lot of people have to get up in the dark very much, they don't like it, and hours tend to move later. But once most people have hours that don't bother them, those on the very early side of the average are out of luck.
While it escaped me for quite some time, I've come to realize DST actually makes sense; not for computers, but for us humans who like light better than dark, particularly when getting out of bed.
Regardless of how much sense it would make, people and businesses don't do what the GP poster suggests. That is, they do not, for the most part, adjust their hours seasonally (in the absense of DST). They pick an hour to open in the morning, and they stick with that time on the clock year round. Which would be fine, except that they tend to pick that hour such that most people almost never need to get up before sunrise, even in the winter. While their are certainly exceptions, more people seem more willing to stay up after sunset than to get up before sunrise. But this means that in the summer, people would still be staying up past dark (and using energy) even though there is quite a bit of daylight before they get up in the morning. Hence DST, which allows us to all adjust our hours seasonally in a coordinated manner.
"The problem with the situation in your second paragraph is that without appealing to an absolute cause of 'right and wrong' all you can appeal to is common perception."
While it might be a very nice thing if there was an absolute cause of right and wrong, that does not make it so.
"If i don't share your perception then you no longer have any case and the result is that if I am stronger then you, you lose."
If we diasagree, and I cannot convince you by argument, and you are stronger, I lose; regardless of why either of us claim to beleive what we do. If you recognize that you yourself are responsible for your moral judgements, you are more likely to be swayed by my arguments than if you think they are imutable truth handed down from on high.
"I am sure that time had a beginning" Why? Were you there? What was it like before that? How could time possibly have a beginning? "Beginning" is only meaningful in reference to time. Yeah, it's equally weird to think of time not having a begining as to think of it having one. But just because something defies your understanding doesn't mean you get to pick one of the nonsensical alternatives at random and start resoning as if it were true. Not if you expect me to treat your conclusions as anything but the random BS that "resonated" with you on one particular day.
"atheist say time was caused by random chance."
No, we do not. Atheists say that they do not believe that God exists. That's all. As a group, atheists don't say anything at all about whether time required causing; whether it might have been caused by random chance if it did. Personaly, I say "random chance" is a concept(redundantly described), not a thing that can cause anything=. I also say that the reason you're having trouble describing what it means to "cause time", is because it's not really a meaningful phrase. Causing something implies time.
In any case, this unchanging God you posit... Well, I'm having a hard time seeing how a universe where that God existed would be any different from one where he did not. To get right to the point: why should I care if such a God exists or not? Why should I not conclude he is a perfectly undetectable and superfulous addition to my model of the world, whip out occams razor and hack him off?
I do beleive in absolute truth. i.e. I believe that some statements are not matters of opinion, but are literally true or false. I don't know of anyone who claims to disagree with this. I do know of quite a few rather annoying people who claim to agree with this, then go on to claim they have certain knowledge of things they clearly beleive only because they resonate with them; and they want everyone else to accept these things as true, despite a lack of any evidence, and in many cases the logical impossibility of their beleifs.
"if there is not god what is 'wrong' with me forcing you to believe whatever I like, assuming I were capable of something so asinine?"
It would be asinine. I guess you mean, what inarguable authority beyond you, me, or any other human opinion would declare it objectively wrong? And the answer is: None, so what? It's still wrong, according to me, so I'll tell you so. Just because I take responsibility for my own moral judgements doesn't make them inferior to those of people who ascribe their own moral judgements to some imaginary higher authority. Quite the oposite if you ask me.
"The theology I adhere to teaches that God is unchanging in state, but is in a state of constant motion."
I can't manage to interpret this as anything but meaningless or contradictory. Nor do I understand what existing 'outside' time would mean. If one who did not create time must have been created by the creator of time, why doesn't that creator need a creator? Uh-oh, talking about the creation of time means I'd better stop, I've already started trying to apply logic to nonsensical concepts. What could it possibly mean to "create time"? There wasn't time before is was created? Woops, that "before" doesn't work...
"The truest cause of anti-intellectualism is the anti-religion movement"
I was going to take issue with that, but reading the rest of your post perhaps I agree, though I'd phrase it differently: "The truest cause of the fiction-is-better-than-truth movement is the truth-is-better-than-fiction movement." Religious people who insist they are "under attack" and must fight back (by making everyone else live by their beleifs) piss me off. But in a larger sense, much of religion is about not trying to actually understand the world, and so has indeed been under attack for the last few centuries. Why truth? Because I think the world today is a better place to live than it was in the middle ages, and the difference is down to people with a prefernce for truth.
How exactly does it require a made-up evidence-free beleif in order to value evidence-based attempts to actually understand the world?
"If there is no God/gods no absolute truth..." The lack of God/gods does not imply the lack of absolute truth. In fact, a God (who can change his mind) would seem an impediment to absolute truth.
"So what if you happen to be able to "PROVE" something is a fact? What if that 'fact' doesn't 'resonate' with me and it feels better for me to believe something else. why shouldn't I ?"
Well, in that case, I'll be right, and you'll be wrong. If "resonance" is more important to you than accuracy, feel free to beleive whatever you want. Just don't be offended if I fail to take your beleif seriously.
I'll give you my take on it, no twisting. (I tend to think of myself as a liberal, but only because I tend to disagree with those who are quickest to call themselves conservatives):
The government should stay out of my life as much as possible both socially and financially. Government can pretty much just stay entirely out of my life socially period. So they should.
Government cannot exist without funds, and since I do think there are legitimate purposes for government, I must concede it cannot stay entirely out of my life financially. So it should stay out as much as possible. Once upon a time this might have led to a dillema as to which party to support. But I'm not so incredibly naive as to think that it's better to take less money from me while borrowing several times as much on my behalf. So I realize that for the last 25 years, the Republicans have been the party of socialy conservate and fiscally super-ultra-liberal to the point of entirely losing touch with reality. Easy call.
I'd say "X exists" is not a scientific theory. Depending on the value of X, it might be an observation. Theoretical falsifiability is certainly my favorite acid test for being a scientific theory, but "X exists" fails at related things I'd expect of a scientific theory too. It doesn't explain anything or predict anything beyond itself. Based on evidence, scientific theories posit additional information (the explanation for that evidence). "Water exists" states some evidence I have observed, but adds nothing to it. "Unicorns exist" is not based on evidence. Neither is a scientific theory.
His use of "orthogonal", while not endorsed by any dictionary I know of, is fairly common, at least amongst the sorts of people likely to be familiar with the strict matematical definition you quote. It means that the two concepts are independent; the logic being that were they the sorts of things that could be axes on a graph, those axes would be at right angles.
Being an infidel or not means nothing about whether you are a civilian or not, and vice-versa.
"The practicality is that, at least right now, it's much harder to wipe out life on two planets than it is two countries"
That's the practical side of things? Hate to see the impractical. Right now, and for a very long forseeable future, wiping out life on two planets is exactly as hard as wiping out life on one. A Mars colony that could continue to survive if life on Earth had been wiped out is no where close. And before you say it, no, I don't think going there now is very helpful in brining it closer. If you're trying to prevent the extinction of humanity, asteroid defense is probably a much better use of your money. For that matter, foreign aid to support the spread of secular democracy is probably better than both...
According to your link, someone who wasn't in a position to decide, or even know, says she wasn't a covert agent.
Yet she was according to the people responsible for making the decision. It's not a matter of opinion; the fact that she worked for the CIA was classified. If Karl didn't know that, he should have. Anyone with even passing familiar with the inteligence community knows you don't mention that someone works at a particular agency just passingly, even if they aren't covert; let alone to a reporter if you're not sure of their status. Did he do anything criminal? Maybe not; certainly nothing provably so. Did he give classified information to a reporter? Yup, sure did. Did Bush promise to fire anyone who did that? Yup, repeatedly. Is he going to fire Karl? HaHaHa, the Bush administration punish dishonesty... that's a good one.
Frankly, if Karl Rove didn't think he did anything wrong, why has he lied about it for two years? Funny how the story was strictly "didn't do it, absolutely not" through special counsel investigations, supreme court appeals, reporters on the verge of going to jail, etc. Then on the very day Time announced it was going to give him up, it's officialy "can't comment on an ongoing investigation", and unofficialy, "didn't do anything wrong, what's the fuss?". Seems a little late to switch to claiming it was all perfectly innnocent.
Bah. IBM killed OS/2. I went to Comdex "back in the day". At the IBM booth, you could fill out an application and they'd consider whether you were a sufficiently worthy developer that they should deign to let you to pay for a copy of the OS/2 SDK.
Meanwhile, how to get the Windows SDK? Walk within throwing distance of the MS booth looking vaguely geeky (then try to catch one of the first ones, so they'll quit pelting you)
IBM failed to make the expected profits on SDK sales, and lots more apps got developed for Windows. Shocking.
I find the argument in your first paragraph uncompelling. Fix the library, use a different one, or work around it in a maintainable way. If the implementer didn't expose the functionality you need, that library doesn't provide the functionality you need. It doesn't mean you just can't do anything; you do whatever you would if the library didn't provide the function at all. The fact that you know what private members do the thing you want implies you've got source, so you're hardly completely out of luck.
"Lisp gives you the ability to make an end-run around the encapsulation, but it also makes it obvious"
It's obvious in the calling code. It's not obvious if all I look at is the library code.
"Also, since development is so fast, fixing code which did depend on internal knowledge is generally not a problem if it does come to that."
There is no such thig as development that fast. I once accidentally broke backward compatibility in the public part of a library I wrote. The compatibility break was somewhat obscure, so it didn't cause problems imediately. But a couple years previously, someone had written some code using that behavior. A couple years after I made the change, a major clients server-based app goes down for an unrelated reason. The bug that brought them down was easy to find and the fix was simple: they needed the updated version of this one library; I recompiled; and now it's broken in a totally different way. Now I'm trying to find a subtle bug in a large amount of four year old code I've never seen before, while dozens of users are sitting on their hands. That sucked incredibly. In that case, I should have known I was causing a problem. Without working encapsulation, I couldn't know, and this would be happening constantly.
"And since it's been used for some very large systems, I think that it works." Well, assuming you're defining "large" the same way I am (number of developers and amount of time in development) I can only assume that they enforced encapsulation externally to the language. i.e. they turned on the warning you mention, and didn't allow code that generated it. I'd just prefer the compiler do the enforcing, rather than the boss.
"Really, C++ does the same, since members are just slots in a struct, and with a pointer to the struct one can pull anything out one wants *grin*"
Well, that will only work for data members. I don't think you're going to be able to deduce the address of a member function, and it's obviously impossible if that member gets inlined, or for that matter, never generated. While it's probably a data member you want to get at, anyone who has the knowledge to do that probably has the wisdom not to.
I'm dealing with code written by maybe 30 people over 8 years. Many are not the sorts where I want to rely on their having been wise. Quite a bit of this code is in the category where if I have to do much of anything to it maintenance-wise, I'll probably need to rewrite it, but if I don't break it, I don't have to.
I don't know, people get by and get stuff done in coding environments I can't imagine working in. I'm sure Lisp is great for many people, and you're more than welcome to go with it. I'm just saying that for me to use a language, a lack of hard encapsulation is a deal-killer.
"I thought that in C++ the owning class had to declare its friends and that any random class or function couldn't declare itself a friend"
Exactly.
"Lisp lets one use encapsulation, but also lets one get around it if necessary"
Ack! If you can get around it, it's not encapsulation. I write a class, and carefully expose a few member functions for others to use, sealing away the implementation. A couple years go by, during which a dozen other developers might have writen code that uses my class. Now I want to change part of the implementation. Can I do so without breaking any code? Note that I can't ask everyone who might have used my class because some of them have been fired for being the sorts that would unnecessarily ignore encapsulation if they could. This is not a hypothetical situation; I'm faced with this regularly.
In C++, I know that if the public members retain the same behavior, nothing using this class can break. (Unless it's a friend, but you almost never use friends, and as noted, you declare them in the class whose internals are being exposed, so you know about it) This is what I mean by large-scale development: I can work on one part of the code and have garauntees that I won't break anything in a code base containing code I know nothing about.
If developers decide to take the risk of relying on private stuff in a library I wrote, it sounds fine to say, well it's their problem if I change the library and their code breaks. But it's not fine, because they don't work here anymore, and I'm responsible for maintaining their code. And in my case, they outnumber me twenty to one! (Yes, I've been here too long; well, not really, only in the sense of being the most qualified to fight fires in far too much code)
Note that one of those scientificly conducted studies found that for certain disorders the success rate of psychotherapists was equivalent to that of voodoo practitioners.
Which is not to say that I have any problem with psychologists or consider them frauds. They are trying to aproach the problem scientifically, but as the previous poster says, that problem is inordinately complex and resistant to exacting analysis.
They are in basically the same boat as economists or meteorologists. They understand many of the details around the edges quite well, and they've got some good broad outlines of how the system works on a large scale. But there is a vast gulf in between that means they can't come close to telling you where a stock will be a month from now, or whether it will rain the saturday after next.
Persons such as your father are in a tough boat. We really don't know the answers to the problems they are dealing with with any certainty. But their patients need help, so they've got to try anyway.
Psychologists try to figure stuff out scientifically; the fact they are only marginally successful indicates the problem is really hard. It certainly doesn't indicate any support for Scientology, or anyone else who's just making shit up without even any attempt at the scientific method.
Actually, in college, Lisp was presented to me as the ultimate language that would eventually take over the world:)
It seems to me that all the things you describe multi-methods doing are pretty directly achievable in C++. Functions can be specialized on any and all of their arguments, and can be members of particular classes or not. (You say "without using method overloading", but I'm not clear why one shouldn't).
But note that foo.bar(baz) is not just syntactic sugar for bar(foo,baz). If bar is a member of foo, it has special status; it can access private members of foo and other objects of its type; it does not just operate on foo, but is part of it. The "friend" keyword you mention allows methods that are not part of an object to access its private members, but that's a pretty rare case for tightly-coupled types. Definitely one of those things you should, as a rule, not do, but C++ will give you a way to do it, because sometimes it's best to bend the rules.
If Lisp methods aren't owned by particular classes, does it (or how does it ) provide a mechanism for enforcing abstraction barriers? The ability to present an interface, and prevent any aceess to implementation is certainly something I'd consider basic to large-scale development. I don't see how to do it without the "member" concept.
kscguru pretty much wrote my reply to most of your points, so uh, what he said. But I can't help piling on a bit too.
"You really have no clue that '::' is a horrible choice of name separator"
No, I really had no clue about that. Here I had been thinking it was a perfectly fine choice, easy to type, readable, I don't know, how many things can you say about a choice of a couple charachters? it always seemed fine to me. Thanks for setting me straight with your blind assertion though. Um, you do realize "." is already used for something quite different?
C++ gives you all the power it can. This is more than enough power to let you do stupid things and create entirely impossible to understand code if you want. But I'm sure that even in Java a skilled programmer could write obfuscated hard to fathom code if they tried.
"you assume 'cin' must be an io stream because no competent developer would use that name otherwise"
Yes, that is exactly why I assume 'cin' must be an io stream: no competent developer would use that name otherwise. In fact, no incompetent developer would use that name otherwise. The only developer who would use that name otherwise is one bent on deception.
"Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops."
That's not an "oops". It's an "aha! gotcha!". C++ will indeed let you do what you want, even if what you want is to define intentionally deceptive conversions. It's not like someone accidentally made that conversion automatic; they wrote a whole extra function on top of what was needed for an explicit conversion whose sole purpose was making sure it would happen without specifying. They really wanted to make it work that way, and you want the language to forbid it? Even though forbiding that will forbid vast swaths of things that do make sense, and have teremendous expressive power in the hands of a skilled developer? Stay away from my language please.
"You can nest templates like this: 'outer<inner<type> >' but not like this: 'outer<inner<type>>'. That's not an annoyance, it's absolutely moronic from a human design POV"
I'd phrase that differently: From a design POV, it's absolutely moronic. In practice, it's not an annoyance. Seriously, I've devoted more thought to that in the course of this post than in my last decade of coding. Practicality-wise, it's a non-issue. Theory-wise, I'm glad they're fixing it.
I haven't used any Lisp in the last 10 years, so I'm not really qualified to comment on its simplicity/power vs. C++. When I did use Lisp those many moons ago, I thought it was neato, and very cool from a theoretical standpoint, but not something I'd want to do major development in; and that was before I even knew what major development was. Anyway, I don't really know squat about Lisp these days, except that its fans think its the greatest thing since sliced bread, yet still almost nobody uses it outside academia. But anyway, I'll bite, what's a multi-method and why would I want one?
Actually, I set out to write this post in a somewhat confrontational mood, so I went to your website to see if I could rag on you for being an academic. Sadly, not only are you apparently not an academic, you sound like an interesting guy, and to top it off, you're a fellow Boulder Cruzer. Now who am I going to be obnoxious to? Oh well, Happy Thursday.
"I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files"
You mention these as if we are supposed to automatically know what you think is wrong with them. I'm not sure what you find objectionable about these, but from the rest of your criticisms, it's pretty clear you don't know much about C++.
"can't nest templates because >> is a token"
Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.
"references *and* pointers" Which are different, and both useful. Which really goes to the philosphical difference between Java and C++. If there are two ways to do something, Java gives one (the one that's usually best); C++ gives you three. (The one that's usually best, the one that you might sometimes want instead, and the one that really shouldn't count because it's invariably a bad idea.)
"no garbage collector (even optional)?" There are several libraries that provide garbage collectors, which are hence obviously optional. Programmers rarely opt for them. You can either take this as an argument for making them required, or against GC in general.
"cin >> s, shift right or method call?" Method call. I guess I can see the theoretical problem there, but in practice, I've never run across a case where it was even close to being an issue. You'd have to be trying pretty hard to intentionally obfuscate your code for me to mistake it. (e.g. if 'cin' in your example isn't a stream.)
I think Java is successful because it makes things simpler for the programmer by reducing the available complexity. You only have to worry about learning one way to do it because there is only one way to do it. Frequently, that's an excellent trade-off. Java is quite expressive, so if you don't need the additional expressive ability of C++ there is certainly no need to deal with the complexity. (I'm not trying to insult any one here, but if someone has difficulty handling the complexity of C++, they may be more productive in Java. This is a genuinely useful feature of the language; for a businessperson thinking in terms of programmer pay scales, it may be huge.)
But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.
Even "mission" statements can be OK if they are clear and consise.
I work for a small company that once came out with a mission statement a page long all about leveraging stuff, and enhancing customers other stuff, and so forth. Layoffs followed shortly thereafter. Though we don't use it officially anymore, we've now returned to the spirit of our very first mission statement, which guided us to great successes: "Make shit happen."
"Then you've never used Intercal..."
Hold on there! I'll have you know I was once a totally 1337 Intercal coder! (this was before "1337", but anyway...) Though it was rough, I once even sucessfully implemented addition. So there. To this day, I can read large numbers in Roman Numerals faster than most...
In any case, your comparisons significantly overstate Intercals expressiveness, readability, etc. When compared based on their worst features, it is much much worse than any of those languages. But I can still stand by my original statement, because for Intercal, that's not an indictment; it's a compliment.
I don't recall a bear-oriented language. Is it a variant of COW, the language for bovine developers? (All keywords are variants of "Moo")
Lest anyone suspect I just don't like functional programming at all, I'll note that the coolest language of all time is UnLambda, which you ought to google if the other languages on your list interest you.
The date is not arbitrary. LISP was invented in 1958. Hence it's user base at that time was handful of academics. It's user base today is more or less a handful of academics. LISP is arguably a bigger success than Pascal, maybe even arguably in the same league as FORTRAN. In the world of languages used outside academia, all three are minor footnotes.
I clearly haven't written much LISP? Thanks for letting me know. I must have just imagined it. Too bad, I seem to recall having enjoyed it quite a bit. I didn't mean to imply LISP was "no good"; for talking about programming languages; for examining the concepts other languages take for granted, it's excellent. For a CompSci grad student, LISP is the perfect language. For a comercial software engineer, not so much.
C++ (for example) is much more popular than LISP pretty much everywhere except possibly academia; LISP is vastly more popular in academia than anywhere else. I suggest this is not merely an accident of history.
I don't worry that LISP zealots might be right. For the most part, they are right. But like other zealots, they fail to understand that there is more than one question.
Yeah, we should build on the sucesses of the past, like LISP! You know it's a success, because it still has just as many users as it did in 1958!
"Javascript has been called Lisp in C's clothing."
So the ways Javascript differs from C are due to being LISP like? I find it hard to imagine a more damning indictment of a language.
"All things being equal, you should generally choose the most powerful language you can all the time"
But all things are not equal. Being able to use that power is important too. Sure, LISP is powerful, in theory. But writing it makes me yearn for the straightforward simplicity of C++!
LISP fanatics bug me. If everyone just acnowledges that LISP had every language feature possible way before any thing else, can you give it a rest? Or at least stick to explaining why a language that is the greatest one ever, and has been since the 50s still has about as many users as it did in the 50s.
All the "new" features of today's languages have been available for decades in LISP, as well as in every other turing-complete language; it's a matter of how easy it is to use those features.
I've written code in a bunch of languages, including quite a bit of LISP. LISP is great if you want to do a mental puzzle resulting in aesthetically beautiful code. If you want to get stuff done, LISP blows big hairy chunks.
Out of curiosity, what industry/job are you in? Different jobs tend to have different start times, but in every office job I've run across with a required start time that time was 9:00am. Most retail places seem to be 9:00 or 10:00.
In any case, that's the reason for the "most" and "almost never" in my statement. "Business hours" are set collectively by society, but in a very messy fassion; obviously some peoples hours need to be earlier than others (so they can sell things to people before work for example). But if a lot of people have to get up in the dark very much, they don't like it, and hours tend to move later. But once most people have hours that don't bother them, those on the very early side of the average are out of luck.
While it escaped me for quite some time, I've come to realize DST actually makes sense; not for computers, but for us humans who like light better than dark, particularly when getting out of bed.
Regardless of how much sense it would make, people and businesses don't do what the GP poster suggests. That is, they do not, for the most part, adjust their hours seasonally (in the absense of DST). They pick an hour to open in the morning, and they stick with that time on the clock year round. Which would be fine, except that they tend to pick that hour such that most people almost never need to get up before sunrise, even in the winter. While their are certainly exceptions, more people seem more willing to stay up after sunset than to get up before sunrise. But this means that in the summer, people would still be staying up past dark (and using energy) even though there is quite a bit of daylight before they get up in the morning. Hence DST, which allows us to all adjust our hours seasonally in a coordinated manner.
"The problem with the situation in your second paragraph is that without appealing to an absolute cause of 'right and wrong' all you can appeal to is common perception."
While it might be a very nice thing if there was an absolute cause of right and wrong, that does not make it so.
"If i don't share your perception then you no longer have any case and the result is that if I am stronger then you, you lose."
If we diasagree, and I cannot convince you by argument, and you are stronger, I lose; regardless of why either of us claim to beleive what we do. If you recognize that you yourself are responsible for your moral judgements, you are more likely to be swayed by my arguments than if you think they are imutable truth handed down from on high.
"I am sure that time had a beginning"
Why? Were you there? What was it like before that? How could time possibly have a beginning? "Beginning" is only meaningful in reference to time. Yeah, it's equally weird to think of time not having a begining as to think of it having one. But just because something defies your understanding doesn't mean you get to pick one of the nonsensical alternatives at random and start resoning as if it were true. Not if you expect me to treat your conclusions as anything but the random BS that "resonated" with you on one particular day.
"atheist say time was caused by random chance."
No, we do not. Atheists say that they do not believe that God exists. That's all. As a group, atheists don't say anything at all about whether time required causing; whether it might have been caused by random chance if it did. Personaly, I say "random chance" is a concept(redundantly described), not a thing that can cause anything=. I also say that the reason you're having trouble describing what it means to "cause time", is because it's not really a meaningful phrase. Causing something implies time.
In any case, this unchanging God you posit... Well, I'm having a hard time seeing how a universe where that God existed would be any different from one where he did not. To get right to the point: why should I care if such a God exists or not? Why should I not conclude he is a perfectly undetectable and superfulous addition to my model of the world, whip out occams razor and hack him off?
I do beleive in absolute truth. i.e. I believe that some statements are not matters of opinion, but are literally true or false. I don't know of anyone who claims to disagree with this. I do know of quite a few rather annoying people who claim to agree with this, then go on to claim they have certain knowledge of things they clearly beleive only because they resonate with them; and they want everyone else to accept these things as true, despite a lack of any evidence, and in many cases the logical impossibility of their beleifs.
"if there is not god what is 'wrong' with me forcing you to believe whatever I like, assuming I were capable of something so asinine?"
It would be asinine. I guess you mean, what inarguable authority beyond you, me, or any other human opinion would declare it objectively wrong? And the answer is: None, so what? It's still wrong, according to me, so I'll tell you so. Just because I take responsibility for my own moral judgements doesn't make them inferior to those of people who ascribe their own moral judgements to some imaginary higher authority. Quite the oposite if you ask me.
"The theology I adhere to teaches that God is unchanging in state, but is in a state of constant motion."
I can't manage to interpret this as anything but meaningless or contradictory. Nor do I understand what existing 'outside' time would mean. If one who did not create time must have been created by the creator of time, why doesn't that creator need a creator? Uh-oh, talking about the creation of time means I'd better stop, I've already started trying to apply logic to nonsensical concepts. What could it possibly mean to "create time"? There wasn't time before is was created? Woops, that "before" doesn't work...
"The truest cause of anti-intellectualism is the anti-religion movement"
I was going to take issue with that, but reading the rest of your post perhaps I agree, though I'd phrase it differently: "The truest cause of the fiction-is-better-than-truth movement is the truth-is-better-than-fiction movement." Religious people who insist they are "under attack" and must fight back (by making everyone else live by their beleifs) piss me off. But in a larger sense, much of religion is about not trying to actually understand the world, and so has indeed been under attack for the last few centuries. Why truth? Because I think the world today is a better place to live than it was in the middle ages, and the difference is down to people with a prefernce for truth.
How exactly does it require a made-up evidence-free beleif in order to value evidence-based attempts to actually understand the world?
"If there is no God/gods no absolute truth..."
The lack of God/gods does not imply the lack of absolute truth. In fact, a God (who can change his mind) would seem an impediment to absolute truth.
"So what if you happen to be able to "PROVE" something is a fact? What if that 'fact' doesn't 'resonate' with me and it feels better for me to believe something else. why shouldn't I ?"
Well, in that case, I'll be right, and you'll be wrong. If "resonance" is more important to you than accuracy, feel free to beleive whatever you want. Just don't be offended if I fail to take your beleif seriously.
I'll give you my take on it, no twisting. (I tend to think of myself as a liberal, but only because I tend to disagree with those who are quickest to call themselves conservatives):
The government should stay out of my life as much as possible both socially and financially. Government can pretty much just stay entirely out of my life socially period. So they should.
Government cannot exist without funds, and since I do think there are legitimate purposes for government, I must concede it cannot stay entirely out of my life financially. So it should stay out as much as possible. Once upon a time this might have led to a dillema as to which party to support. But I'm not so incredibly naive as to think that it's better to take less money from me while borrowing several times as much on my behalf. So I realize that for the last 25 years, the Republicans have been the party of socialy conservate and fiscally super-ultra-liberal to the point of entirely losing touch with reality. Easy call.
I'd say "X exists" is not a scientific theory. Depending on the value of X, it might be an observation. Theoretical falsifiability is certainly my favorite acid test for being a scientific theory, but "X exists" fails at related things I'd expect of a scientific theory too. It doesn't explain anything or predict anything beyond itself. Based on evidence, scientific theories posit additional information (the explanation for that evidence). "Water exists" states some evidence I have observed, but adds nothing to it. "Unicorns exist" is not based on evidence. Neither is a scientific theory.
His use of "orthogonal", while not endorsed by any dictionary I know of, is fairly common, at least amongst the sorts of people likely to be familiar with the strict matematical definition you quote. It means that the two concepts are independent; the logic being that were they the sorts of things that could be axes on a graph, those axes would be at right angles.
Being an infidel or not means nothing about whether you are a civilian or not, and vice-versa.
"The practicality is that, at least right now, it's much harder to wipe out life on two planets than it is two countries"
That's the practical side of things? Hate to see the impractical. Right now, and for a very long forseeable future, wiping out life on two planets is exactly as hard as wiping out life on one. A Mars colony that could continue to survive if life on Earth had been wiped out is no where close. And before you say it, no, I don't think going there now is very helpful in brining it closer. If you're trying to prevent the extinction of humanity, asteroid defense is probably a much better use of your money. For that matter, foreign aid to support the spread of secular democracy is probably better than both...
According to your link, someone who wasn't in a position to decide, or even know, says she wasn't a covert agent.
Yet she was according to the people responsible for making the decision. It's not a matter of opinion; the fact that she worked for the CIA was classified. If Karl didn't know that, he should have. Anyone with even passing familiar with the inteligence community knows you don't mention that someone works at a particular agency just passingly, even if they aren't covert; let alone to a reporter if you're not sure of their status.
Did he do anything criminal? Maybe not; certainly nothing provably so. Did he give classified information to a reporter? Yup, sure did. Did Bush promise to fire anyone who did that? Yup, repeatedly. Is he going to fire Karl? HaHaHa, the Bush administration punish dishonesty... that's a good one.
Frankly, if Karl Rove didn't think he did anything wrong, why has he lied about it for two years? Funny how the story was strictly "didn't do it, absolutely not" through special counsel investigations, supreme court appeals, reporters on the verge of going to jail, etc. Then on the very day Time announced it was going to give him up, it's officialy "can't comment on an ongoing investigation", and unofficialy, "didn't do anything wrong, what's the fuss?". Seems a little late to switch to claiming it was all perfectly innnocent.
Bah. IBM killed OS/2. I went to Comdex "back in the day". At the IBM booth, you could fill out an application and they'd consider whether you were a sufficiently worthy developer that they should deign to let you to pay for a copy of the OS/2 SDK.
Meanwhile, how to get the Windows SDK? Walk within throwing distance of the MS booth looking vaguely geeky (then try to catch one of the first ones, so they'll quit pelting you)
IBM failed to make the expected profits on SDK sales, and lots more apps got developed for Windows. Shocking.
"They have implicit permission due to their community based goals and not-for-profit nature."
I think it's more due to their fair use right to lend their books to whoever they feel like, regardless of goals or nature. Just like you or I can.
I find the argument in your first paragraph uncompelling. Fix the library, use a different one, or work around it in a maintainable way. If the implementer didn't expose the functionality you need, that library doesn't provide the functionality you need. It doesn't mean you just can't do anything; you do whatever you would if the library didn't provide the function at all. The fact that you know what private members do the thing you want implies you've got source, so you're hardly completely out of luck.
"Lisp gives you the ability to make an end-run around the encapsulation, but it also makes it obvious"
It's obvious in the calling code. It's not obvious if all I look at is the library code.
"Also, since development is so fast, fixing code which did depend on internal knowledge is generally not a problem if it does come to that."
There is no such thig as development that fast. I once accidentally broke backward compatibility in the public part of a library I wrote. The compatibility break was somewhat obscure, so it didn't cause problems imediately. But a couple years previously, someone had written some code using that behavior. A couple years after I made the change, a major clients server-based app goes down for an unrelated reason. The bug that brought them down was easy to find and the fix was simple: they needed the updated version of this one library; I recompiled; and now it's broken in a totally different way. Now I'm trying to find a subtle bug in a large amount of four year old code I've never seen before, while dozens of users are sitting on their hands. That sucked incredibly. In that case, I should have known I was causing a problem. Without working encapsulation, I couldn't know, and this would be happening constantly.
"And since it's been used for some very large systems, I think that it works."
Well, assuming you're defining "large" the same way I am (number of developers and amount of time in development) I can only assume that they enforced encapsulation externally to the language. i.e. they turned on the warning you mention, and didn't allow code that generated it. I'd just prefer the compiler do the enforcing, rather than the boss.
"Really, C++ does the same, since members are just slots in a struct, and with a pointer to the struct one can pull anything out one wants *grin*"
Well, that will only work for data members. I don't think you're going to be able to deduce the address of a member function, and it's obviously impossible if that member gets inlined, or for that matter, never generated. While it's probably a data member you want to get at, anyone who has the knowledge to do that probably has the wisdom not to.
I'm dealing with code written by maybe 30 people over 8 years. Many are not the sorts where I want to rely on their having been wise. Quite a bit of this code is in the category where if I have to do much of anything to it maintenance-wise, I'll probably need to rewrite it, but if I don't break it, I don't have to.
I don't know, people get by and get stuff done in coding environments I can't imagine working in. I'm sure Lisp is great for many people, and you're more than welcome to go with it. I'm just saying that for me to use a language, a lack of hard encapsulation is a deal-killer.
"I thought that in C++ the owning class had to declare its friends and that any random class or function couldn't declare itself a friend"
Exactly.
"Lisp lets one use encapsulation, but also lets one get around it if necessary"
Ack! If you can get around it, it's not encapsulation. I write a class, and carefully expose a few member functions for others to use, sealing away the implementation. A couple years go by, during which a dozen other developers might have writen code that uses my class. Now I want to change part of the implementation. Can I do so without breaking any code? Note that I can't ask everyone who might have used my class because some of them have been fired for being the sorts that would unnecessarily ignore encapsulation if they could. This is not a hypothetical situation; I'm faced with this regularly.
In C++, I know that if the public members retain the same behavior, nothing using this class can break. (Unless it's a friend, but you almost never use friends, and as noted, you declare them in the class whose internals are being exposed, so you know about it) This is what I mean by large-scale development: I can work on one part of the code and have garauntees that I won't break anything in a code base containing code I know nothing about.
If developers decide to take the risk of relying on private stuff in a library I wrote, it sounds fine to say, well it's their problem if I change the library and their code breaks. But it's not fine, because they don't work here anymore, and I'm responsible for maintaining their code. And in my case, they outnumber me twenty to one! (Yes, I've been here too long; well, not really, only in the sense of being the most qualified to fight fires in far too much code)
Note that one of those scientificly conducted studies found that for certain disorders the success rate of psychotherapists was equivalent to that of voodoo practitioners.
Which is not to say that I have any problem with psychologists or consider them frauds. They are trying to aproach the problem scientifically, but as the previous poster says, that problem is inordinately complex and resistant to exacting analysis.
They are in basically the same boat as economists or meteorologists. They understand many of the details around the edges quite well, and they've got some good broad outlines of how the system works on a large scale. But there is a vast gulf in between that means they can't come close to telling you where a stock will be a month from now, or whether it will rain the saturday after next.
Persons such as your father are in a tough boat. We really don't know the answers to the problems they are dealing with with any certainty. But their patients need help, so they've got to try anyway.
Psychologists try to figure stuff out scientifically; the fact they are only marginally successful indicates the problem is really hard. It certainly doesn't indicate any support for Scientology, or anyone else who's just making shit up without even any attempt at the scientific method.
Actually, in college, Lisp was presented to me as the ultimate language that would eventually take over the world :)
It seems to me that all the things you describe multi-methods doing are pretty directly achievable in C++. Functions can be specialized on any and all of their arguments, and can be members of particular classes or not. (You say "without using method overloading", but I'm not clear why one shouldn't).
But note that foo.bar(baz) is not just syntactic sugar for bar(foo,baz). If bar is a member of foo, it has special status; it can access private members of foo and other objects of its type; it does not just operate on foo, but is part of it. The "friend" keyword you mention allows methods that are not part of an object to access its private members, but that's a pretty rare case for tightly-coupled types. Definitely one of those things you should, as a rule, not do, but C++ will give you a way to do it, because sometimes it's best to bend the rules.
If Lisp methods aren't owned by particular classes, does it (or how does it ) provide a mechanism for enforcing abstraction barriers? The ability to present an interface, and prevent any aceess to implementation is certainly something I'd consider basic to large-scale development. I don't see how to do it without the "member" concept.
kscguru pretty much wrote my reply to most of your points, so uh, what he said. But I can't help piling on a bit too.
"You really have no clue that '::' is a horrible choice of name separator"
No, I really had no clue about that. Here I had been thinking it was a perfectly fine choice, easy to type, readable, I don't know, how many things can you say about a choice of a couple charachters? it always seemed fine to me. Thanks for setting me straight with your blind assertion though. Um, you do realize "." is already used for something quite different?
C++ gives you all the power it can. This is more than enough power to let you do stupid things and create entirely impossible to understand code if you want. But I'm sure that even in Java a skilled programmer could write obfuscated hard to fathom code if they tried.
"you assume 'cin' must be an io stream because no competent developer would use that name otherwise"
Yes, that is exactly why I assume 'cin' must be an io stream: no competent developer would use that name otherwise. In fact, no incompetent developer would use that name otherwise. The only developer who would use that name otherwise is one bent on deception.
"Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops."
That's not an "oops". It's an "aha! gotcha!". C++ will indeed let you do what you want, even if what you want is to define intentionally deceptive conversions. It's not like someone accidentally made that conversion automatic; they wrote a whole extra function on top of what was needed for an explicit conversion whose sole purpose was making sure it would happen without specifying. They really wanted to make it work that way, and you want the language to forbid it? Even though forbiding that will forbid vast swaths of things that do make sense, and have teremendous expressive power in the hands of a skilled developer? Stay away from my language please.
"You can nest templates like this: 'outer<inner<type> >' but not like this: 'outer<inner<type>>'. That's not an annoyance, it's absolutely moronic from a human design POV"
I'd phrase that differently: From a design POV, it's absolutely moronic. In practice, it's not an annoyance. Seriously, I've devoted more thought to that in the course of this post than in my last decade of coding. Practicality-wise, it's a non-issue. Theory-wise, I'm glad they're fixing it.
I haven't used any Lisp in the last 10 years, so I'm not really qualified to comment on its simplicity/power vs. C++. When I did use Lisp those many moons ago, I thought it was neato, and very cool from a theoretical standpoint, but not something I'd want to do major development in; and that was before I even knew what major development was. Anyway, I don't really know squat about Lisp these days, except that its fans think its the greatest thing since sliced bread, yet still almost nobody uses it outside academia. But anyway, I'll bite, what's a multi-method and why would I want one?
Actually, I set out to write this post in a somewhat confrontational mood, so I went to your website to see if I could rag on you for being an academic. Sadly, not only are you apparently not an academic, you sound like an interesting guy, and to top it off, you're a fellow Boulder Cruzer. Now who am I going to be obnoxious to? Oh well, Happy Thursday.
"I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files"
You mention these as if we are supposed to automatically know what you think is wrong with them. I'm not sure what you find objectionable about these, but from the rest of your criticisms, it's pretty clear you don't know much about C++.
"can't nest templates because >> is a token"
Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.
"references *and* pointers"
Which are different, and both useful. Which really goes to the philosphical difference between Java and C++. If there are two ways to do something, Java gives one (the one that's usually best); C++ gives you three. (The one that's usually best, the one that you might sometimes want instead, and the one that really shouldn't count because it's invariably a bad idea.)
"no garbage collector (even optional)?"
There are several libraries that provide garbage collectors, which are hence obviously optional. Programmers rarely opt for them. You can either take this as an argument for making them required, or against GC in general.
"cin >> s, shift right or method call?"
Method call. I guess I can see the theoretical problem there, but in practice, I've never run across a case where it was even close to being an issue. You'd have to be trying pretty hard to intentionally obfuscate your code for me to mistake it. (e.g. if 'cin' in your example isn't a stream.)
I think Java is successful because it makes things simpler for the programmer by reducing the available complexity. You only have to worry about learning one way to do it because there is only one way to do it. Frequently, that's an excellent trade-off. Java is quite expressive, so if you don't need the additional expressive ability of C++ there is certainly no need to deal with the complexity. (I'm not trying to insult any one here, but if someone has difficulty handling the complexity of C++, they may be more productive in Java. This is a genuinely useful feature of the language; for a businessperson thinking in terms of programmer pay scales, it may be huge.)
But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.
Even "mission" statements can be OK if they are clear and consise.
I work for a small company that once came out with a mission statement a page long all about leveraging stuff, and enhancing customers other stuff, and so forth. Layoffs followed shortly thereafter. Though we don't use it officially anymore, we've now returned to the spirit of our very first mission statement, which guided us to great successes: "Make shit happen."