But logic programming gets called a paradigm because it's a Turing-complete computational model that's dramatically different from the more familiar ones (Turing machines, lambda calculus). I'm not aware that dynamic dispatch is like that.
Though by that criterion, functional programming is a paradigm, imperative is a paradigm, an OOP isn't. To me that just goes to show that the notion of a "programming paradigm" is vague; there are a bunch of different reasons that somebody refers to something as a "programming paradigm," and the criterion by which logic programming makes the cut is not the same as the ones by which OOP makes it in.
I'm pretty sure dynamic dispatch is the key element.
I just don't think dynamic dispatch is a big enough idea to merit the name "paradigm." I realize that there can be no principled rule to distinguish between "paradigms" and mere "techniques," but I'd say the following:
Functional programming is a paradigm.
Object-oriented programming is a vague family of paradigms.
Dynamic dispatch isn't a paradigm; it's a feature.
I'd say a Scheme that had been extended in the manner you describe is an object-oriented Scheme. (This is the great thing about LISPs in general: you can implement almost any paradigm you want in them, as long as you don't mind using peculiar syntax for it).
What's peculiar to the syntax for invoking a generic function in a CLOS-type system? It's the same syntax as for applying any other function in Lisp. The fact that the function does a dynamic dispatch is an internal detail of the function.
There is likely some special syntax for defining the generic functions and the methods, sure; how is that peculiar, also? Stereotypical OOP languages have separate syntaxes for class definition, method definition and method invocation.
Certainly, dynamic dispatch seems to have been central in Alan Kay's mind when he invented the term.
What does "central" mean in this context? He certainly had a lot of other stuff in mind at the same time. Were any of these other things "central" too? If so, were any of them more "central" than dynamic dispatch? Again, there's no principled rule here, but I just don't think dynamic dispatch by itself reasonably counts as a "paradigm."
I must say that I find some of the Smalltalk core ideas pretty bad for software engineering, particularly the emphasis on subclassing and adding methods to base classes. And a lot of OOP folks would wholeheartedly agree with this...
Choose a simple 8-bit micro such as an AVR first, or an ARM. Something with a RISC architecture is nice and clean.
Um, why pick a real processor at all? I think a much better choice would be to use very simple VMs tailored toward the task of teaching programming. The VMs can abstract away detail that only gets in the way, and provide a lot more debugging information for the students.
What should such a VM provide? My suggestion would be the following:
Stack based, no registers. Make all operations pop their arguments off the stack, and push their results into it. There would be two stacks: an explicit one for operands and results, and an implicit one for subroutines.
Five primitive data types: character, int, float, memory pointer and instruction pointer.
Heap memory allocation and deallocation. You'd have an instruction/syscall that would allocate a memory frame of the desired size for you, returning a pointer to the frame.
All memory accesses would be based off a frame pointer plus an int offset into the frame. The VM implementation would catch when you tried to access memory outside the frame, and basically tell you that your program doesn't work. Beyond that, pointer arithmetic would not be allowed.
The instruction set should allow the VM implementation to keep track of the type of the value at every stack and memory location. Unless it can be proven safe otherwise, every instruction would be coded for the types of the values that it uses or produces. This allows the VM to catch type errors.
A garbage collector that can be turned on and off as a startup option. If you run the VM in GC mode, it can analyze the stack and memory to find all the pointers, and use that to automatically free frames that the program can no longer refer to.
Flow control would be unconditional goto to an instruction pointer, conditional goto to an instruction pointer, and branch to subroutine at instruction pointer.
Simple, instructive compilers from a simple high-level language into the VM. The obvious candidate: a Scheme compiler. (This is the whole reason for including optional GC into the VM!)
Basically, a VM like this could be used as an introduction to the basics of machine code programming, and then later reused to teach compilers.
Nobody's every offered a usable definition of "object-oriented" that really allows you to distinguish OOP from non-OOP in any reliable manner. Classes don't do it (because of prototype-based languages that are said to be OO); "sending messages to objects" doesn't do it either (counterexamples: CLOS, Dylan); object.operation syntax doesn't do it either (CLOS and Dylan, again). Dynamic dispatch seems the closest thing to a deciding criterion, but that alone seems like an unsatisfying answer, because it describes a technique that can be easily built into a random impure functional language (you can probably implement simple dynamic dispatch in two pages of Scheme code).
"Pure functional" does have a good demarcation criterion (the language has referential integrity in all contexts with no exception), but "impure functional" is also impossible to demarcate precisely (Is Ruby an impure functional language? Is Python so? C#?)
Ultimately, I think all this talk about "object-oriented" vs. "functional" isn't very useful. It would be better to enumerate specific features or properties that one would like a language to support. So, for example, I like PLT Scheme because it has first-class functions, closures, macros, dynamic types, mutable state, record types and a module system. I can use these fairly straightforwardly to implement nearly any programming technique or feature out there, from dynamic dispatch to monads, logic programming, or what have you.
I wouldn't say it was created to save money, because the initial costs to get the FOSS ball running are often higher than buying something.
However, the adoption of large FOSS projects like Linux or Apache certainly is because they save money. Large corporations pay a lot of money for Linux development work that they give away, because the alternative would be for each of them to independently duplicate the work that the others do. This alternative would be more expensive, and provide little clear competitive advantage.
An interpreter compiles each instruction every time it gets executed.
Um, a pure interpreter never "compiles" its program, in the sense of transforming the code into equivalent code in an object language. A pure interpreter usually works this way:
Parse source code and produce an abstract syntax tree representation of the program.
Traverse that AST according to the interpretation rules of the language, keeping track of the program state at each point.
A compiler, on the other hand, translates the AST into equivalent object code in a different language, which can then be run in an implementation of that second language (which can be either a real machine, a virtual machine, a language interpreter, ). For a pure interpreter to "compile each instruction every time it gets executed," there would have to be a program in the object language involved somewhere... and there isn't one, only an model of the successive states of a computation.
Here the evaluation order is not defined. We could evaluate the end sqrt calculation first, or assign the first 5 sqrt calculations to one thread, the next 5 to another thread and so on. Which sqrt is calculated first is entirely up to the compiler.
I think your example is very flawed. The compiler can't easily make the kind of analysis to drastically reorder or regroup this computation.
Let's simplify your example for a minute by dropping the roots bit. So we just have a sum function:
sum [] = 0 sum (x:xs) = x + (sum xs)
Now, when the system has to compute the value of sum [1..5], it basically has to compute the value of the following expression: (1 + (2 + (3 + (4 + 5)))). Unless the compiler recognizes that addition is commutative and associative, there is only one order in which it can reduce that expression to the final answer: from the inside to the outside. This is because your claim that "the evaluation order is not defined" isn't quite true. There is a well-defined partial order of value dependencies in a functional program, and any execution of the program must respect that partial order.
Sure, in the case of that one example, you could write a compiler that recognizes that + is commutative and associative. The problem now is that doesn't help you when you're dealing with other functions.
The correct solution here, IMO: you want to have a higher-order function, let's call it reduce, over lists that takes three arguments: a two-argument function (like +), an identity element for that function, and a list of values that are accepted by that function. The contract of reduce is that it will order and group the elements of the list in an undefined, implementation-dependent order, and then combine them with the function given. So here are three valid implementations of reduce:
reduce1 fn id [] = id reduce1 fn id (x:xs) = fn x (reduce1 fn id xs)
-- this one has identical order to reduce1 reduce2 = foldr
-- this one uses the opposite order to reduce1 and reduce2 reduce3 = foldl
Now, since the contract of reduce says that the order and grouping is undefined, that means that the only way to guarantee that you'll get the same answer with different implementations of reduce is to pass it an associative and commutative function, like +. It also means that if you write a bunch of code today using a sequential version of reduce, and you take care to respect the contract of the function, tomorrow you can replace any one of those uses with another function with the same contract, but which parallelizes the work.
Short version: no, the compiler can't figure out what to parallelize very well at all.
Functional language compilers and runtime systems don't have the ability to magically guess how to parallelize your computations in a way that actually helps performance. Yes, in principle it could construct a dependency graph of the subcomputations that the program has to perform, and execute as much of that in parallel, but that in practice would mean more time spent in thread synchronization than on computation.
You still have to write your programs to specify where you need parallelism, and choose those places wisely. Where functional programming wins for parallelism is on two areas:
In a parallel world, immutable data structures are way easier than mutable ones.
Functional programming has a big emphasis on using functional combinators to transform data structures, instead of using loops like imperative programmers often do. This means that in the places where an imperative program usually has a loop, a functional program has functions like map, filter, reduce, and so on, that specify what to do instead of how to do it. Because of this, when you identify a place in your functional program where parallelism would help, it's comparatively easy to write similar functional combinators that do their work in parallel.
The idea to get rid of "save" is, basically, the idea that the user should not have to do any action to prevent the document they're working on from disappearing. Basically, you can stop working on the document instantaneously and come back to it in exactly the same state, without having to perform a "save" action.
The idea is not to eliminate versioning and content archiving operations. There would be versioning and filing operations available to the user, which would work very much like "save" does. The point is that their use would be, strictly speaking, optional. If the user doesn't use those features, then the only thing that the system does is to guarantee that the most recent state of the document is preserved between sessions. So when you shut down your computer with Notepad open, you are not prompted for anything, and the most that you lose is undo.
The problem is the default "Untitled" document. If you started without an open document, and created the file when you wanted to start working on it, then you'd know where to find it (particularly if the app or the OS or both has a recent documents list.
Why so complicated? As I said in another comment: just put newly created files on the desktop, and make names optional. The question of where a newly created document went then always has the same answer (the desktop). When the user decides that the desktop has become too cluttered, then they can "file" the items (with multiple tools, like tags, hierarchical folders, version control tools, etc.).
Might not be a bad idea, except that when you wanted to find it again you wouldnt have a clue.
So put it on the desktop, and make the desktop capable of showing you the contents of your files. When your desktop gets cluttered, then you set aside 15 minutes to file away or discard the items in it.
You might answer that many users' desktops would then get insanely cluttered; my reply to that is that many people's desks are insanely cluttered, so that's ok. The UI doesn't have to solve the user's character flaws.
There's a problem you're not seeing: the logic for swapping out cold memory pages assumes that the goal is to maximize application throughput, at the potential cost of latency when doing large context or workload switches. The approach makes the applications that are currently running optimally fast, at the cost of making it costly for an idle application to become active again.
This is excellent for some kinds of workloads, but bad for user interaction, where latency of task switching is more important than maximum throughput. When I click on a minimized application window, I want that application to be ready to run instantly. That's more important to most users than having an occasional computationally intensive task take 3 minutes instead of 5--I can find something to do during those 5 minutes.
Whether or not it works (and I'm not sure how well it does), there's something odd about swapping out RAM contents to disk so that you can mirror disk contents in RAM.
Assume all disk reads and writes are the same cost, one unit. The cost of swapping a page out, and then later swapping it back in, would then be two units. Basically, the throughput cost of swapping a page out and later back in breaks even if you otherwise save two disk reads--for example, by getting two hits on the disk cache.
There's nothing odd about this. Basically, RAM is faster than disk, so you want the data that's used most often in RAM, and the data that's used less often on disk. Which pieces of data are process memory pages and which are file block data is irrelevant.
The big questionable assumption here, however, is that the goal is to maximize throughput of a constant workload. If you're seeking to minimize latency in a highly-variable, interactive workload, then things can easily change. This is why swapping is often perceived to be bad for desktop systems: the user will often switch over to a completely different program from what she's using, and doesn't want to wait for the UI to respond. This translates into a requirement for low latency of frequent workload changes.
Capitalism requires the public to have as much information as possible about products and organizations.
Not really, because a free market also requires competition, which often requires that organizations keep trade secrets. In a free market economy, the cost of developing new techniques to bring superior goods or services to the market, or reducing the cost of existing ones, can only be justified if the resulting information can either be kept from would-be competitors (trade secrets), or the competitors barred from using it (patents, copyrights).
Basically, for a given good or service, there is a lot of information that's not relevant to the potential buyer's choice, and a lot of this information is of enormous value to the producer.
If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.
Yes, if the encodings of all the strings have a precisely defined mapping into Unicode code points, then this is true. Abstractly, they're all just sequences of Unicode code points. However, there's no point in allowing different string objects to use different encodings in that case; you might as well use the Java/Python model, where all text strings are stored in some internal Unicode representation that's hidden from the clients, and encoding translation is done for byte I/O.
The issue with Ruby 2.0, however, is that their planned string type will support encodings that don't have a precise mapping to Unicode codepoints--and even harder, were defined to not have any such mapping. So basically, you can have two strings in separate encodings where what you describe does not hold.
Because if it has happened since perhaps part of the original problem was that there weren't enough resources to begin with. If its continuing to happen perhaps its time to invest in more resources?
I think you are confusing two issues here:
Whether a 10 Mbit/s line from an ISP should provide a guaranteed 10Mbit/s throughput 24/7.
Whether the ISPs are investing in enough infrastructure.
Basically, GP is arguing that the answer to (1) is "no." You're responding that the answer to (2) is "no." Well, (2) is a different issue than (1).
Yes, ISPs are acting like weasels, and we should press them to build more infrastructure, to price their offerings better, to market them honestly, etc. But the endless Slashdot choir that "when I pay for a 10 Mbit/s line I should get a guaranteed 10 Mbit/s every time" is completely wrong, and doesn't help the issue at all. The shared resource model that the ISPs (and all other utlities) are using is really the correct one.
I was thinking the same thing but from a moral viewpoint rather than a legal one. If you sign a non-compete clause you should be respecting it rather than trying to find a loophole in it.
No, you were not thinking the same thing. Note that GP doesn't talk about non-compete clauses at all. Your obligation to protect your employers' trade secrets is separate from whether you have a non-compete clause. A non-compete clause forbids you from working at a competitor for a certain period of time, period, even if, hypothetically, you actually knew no trade secrets. But even if you are not subject to any non-compete terms, you can't just leave your company and blab on all of its trade secrets to somebody else, or exploit them for your own gain.
The unfortunate bastard who came after Copernicus, Galileo, was the one who received the ire of the church. Not just because he was contradicting church doctrine, but because he was also using evidence to support his claims.
Galileo's theory wasn't predictively superior to contemporary geocentrism, by his own admission. However, it was worse off in comparison, because it required a major revision of mechanics; it contradicted Aristotelian mechanics, which was as firmly entrenched as today's physics is for us. Galileo didn't have anything near a worked out theory of mechanics that rejected the idea of an absolute reference frame, and therefore, the idea of the relativity of all motion. This objection, if you note, was not biblical: it's a technical physical objection. (A modern day analogy would be if somebody proposed a theory that blatantly violated the law of inertia.)
The most important new kind of evidence Galileo brought into the picture were telescopic observations, and those weren't straightforward to interpret. The telescopes of the day were pretty awful devices, and more importantly, he didn't have a theory of optics that allowed him to justify his interpretations of what he did observe. Again, this is a technical objection, not a biblical one.
There were also other serious problems posed by other, very good astronomers of the day (by their and our standards), for which Galileo didn't have satisfactory answers. Things like the relative brightness of the planets at various points of their trajectories. These were not cosmological or biblical objections: they were technical, astronomical objections.
The church wasn't a biblical fundamentalist institution. It can be easily demonstrated that in many places, it accepted the scientific theories of the ancient Greeks in spite of apparent contradiction to the bible. There are biblical verses that the church read as seemingly implying that the Earth is flat; but the arguments for the Earth being a sphere were firmly accepted. In a sense, the world was seen as the work of God just as the bible was the word of God, so solid scientific arguments about the world had serious theological standing, and could not be shot down by appeal to the bible.
The church judged Galileo's astronomical theory, which seemingly contradicted the bible, on the basis of the professional opinions of astronomers of the day. The theory was found wanting on those grounds, so therefore, because it contradicted the word of God as interpreted by the Church, Galileo was forbidden from teaching it as a truth, while still being allowed to teach it "as a hypothesis." And in actual fact, many figures in the church, including the pope himself and some cardinals, encouraged Galileo in his studies.
At the end, you just can't conclude that Galileo's trial was as simple of an affair as people normally describe it. Yes, the church held too strong of a leash on science back then, but it wasn't nearly as reactionary as people like to portray it. In the actual facts of what happened, the political, interpersonal, scientific and biblical aspects of the Galileo affair were all very important. Galileo proposed an interesting but still very incomplete theory that contradicted the bible, and then went and publically humiliated the powerful sponsors that were shielding him from his biggest critics.
It's always comforting to be reminded that some people are stupid enough to still think playing WoW somehow prevents you from going outside and having fun with friends.
Of course it doesn't prevent them from doing that. The problem then is that when they meet their friends outside, all they do is talk about WoW and nothing else. I've had many a lunch ruined at work when my WoW-playing coworkers decide to all sit down at my table.
Do you really mean that Chinese people do not commit a crime by talking about "taboo topics" as long as they do that on US-based Blogspot?
That doesn't follow from what GP said. The question of where an alleged crime occurred, and therefore of which courts have jurisdiction over it, is a very complicated, subtle issue that doesn't allow for simple generalizations like that.
Basically, if you apply the heuristic that the crime occurs where the damage is done, then you get the following: (a) the German guy's crime occurs in the USA, because the effect was to deny somebody in the USA their right to control the use of their own copyrighted materials; (b) the Chinese folk who post to Blogspot commit their "crime" in China, because the "damage" their "crime" "inflicts" is to Chinese society.
Yes, it's fucked up, but as somebody said in another thread, the problem is not how jurisdiction works; the problem is China's government.
So, what is supposed to follow from "fault," in cases where there is no question of moral or legal wrong? In cases where it does it not play a role in either the moral or the legal calculus of the situation, what role does it play?
I think you'll find falsifiability to be a cornerstone of science, and one of the best tools keeping science separate from metaphysics.
I think I've read plenty about this topic, and you have clearly not. For example, the Wikipedia article you linked about falsifiability plainly fails to support your claim. The article gives a detailed discussion of the problem of ad hoc hypotheses in science. It attributes the whole idea of falsifiability as a demarcation criterion specificallt to Popper, and then goes on to offer this choice quote: "Among the professional philosophers of science, the Popperian view has never been seriously preferred to probabilistic induction, which is the mainstream account of scientific reasoning."
So, if we go by the article you first cited to support your claim, your proposed cornerstone of science is actually not the mainstream account of scientific reasoning. Good job there.
Let's assume we both have. Exactly what do you take issue with? Don't just pull the "read your own link" argument - it's the internet equivalent of "I'm rubber and you're glue." If you wish to debate, then debate. Point out what I've posted, and a clip from the article, and state your notion on how they disagree.
You're in no position to preach when the sources that you cite contradict what you claim. This isn't a give-and-take of opinions, as you're trying to paint it. You are making claims that are contradicted by the sources you cite. I'm suggesting that if you do not want to look like an ignorant fool, you might want to try and read the sources you cite. Otherwise, one of these days a creationist who actually has studied the philosophy of science is going to pwn you, simply by pointing at the vast philosophical, scientific and history of science literature that's critical of falsificationism.
But I think if someone had me beat in all three they would have a hard time also arguing creationism as science, what with all that raw intelligence and education. They would understand even better than I do what science is, and what it isn't. Such a person would be able to make a better argument than I could about why creationism doesn't belong in a science class.
So basically, you think that smart, educated people, by virtue of their intelligence and education, should necessarily agree with you? Have you considered the possibility that how smart and educated you are may be largely unrelated to what beliefs you have?
Creationists believe the bible literally... 6k years. If they believe otherwise, they're not a creationist.
You're supporting this claim with two dictionary definitions and a Wikipedia article. Setting aside the question of how the hell a lexicographer's description of the meaning of the word can possible settle this point, let me just point out that: (a) the first dictionary entry you cite starts with a non-Bible literalist aception of the term; even worse, (b) the Wikipedia article you cite explicitly contradicts your point.
But the earth being 6000 years old is a possible conclusion of creationism. That's why it attracts ridicule as a theory. If it leads you down that road, it just might be the road that's silly, not just the house at the end of the road that says "6000 years and not one day more."
Um, you're doing exactly what GP objects to: you're taking a minority view among creationists (the idea that the Old Testament literally tells us the age of the Earth), and judging all of them by that standard. The claim that life is the result of divine design does not entail the claim that the Old Testament tells us a literal creation story, period.
FWIW, creationism could still be exactly true and it still would never be science. It makes no predictions, and is not falsifiable. It may be a theory, but it's not a scientific theory. A scientific theory has certain criteria that creationism does not meet.
Falsifiability fails as a demarcation criterion for science. I agree with you that creationism isn't a scientific theory, but your argument sucks, and you shouldn't be making it. (And, BTW, read your own fricking link.)
And that is why it attracts scorn here. This is a place for science-types. You'd probably have better luck on some board devoted to theology rather than Slashdot.
As a fellow non-creationist, let me tell you two things: (a) you supposed "science-types" make a really bad showing of yourselves, (b) actual theologists, on the aggregate, don't spend a lot of time on creationism, so don't tar them with the brush that you tar creationists. (Which, incidentally, means you're doing to theologists exactly the same thing that GP complained is done to creationists.)
Anyway, what's commonly referred to as "creationism" these days has two main ingredients:
Strong skepticism about claims of evolutionary biologists, specially claims that are intended to apply over a long time scale (e.g., claims that people and apes have a common ancestor).
A political and cultural agenda to have a certain religious cosmology promoted by the state, by controlling what the state teaches children as "science."
The first of these ingredients is perfectly scientific, taken on its own. The second one is the nasty one. So of course, creationists spend all their time playing up the first one, and distracting us from the second one. And you "science-types," instead of focusing on the political agendas, just love to sit down and play into their hands by going on and on about scientific and philosophical topics you don't quite understand. With the effect that you'll just get eaten for lunch by any creationist who just happens to be smarter than you, better educated on these topics, and more eloquent.
Don't play their game. Just tell them that the scientific merits of theories, and therefore, the content of science courses, should be decided by the scientific community, period. Even if the scientific community is wrong, science is what the community says it is, and if we are going to teach biology to children, then the actual truth or falsity of evolutionary theory isn't even relevant. What matters is if we're teaching biology correctly--and creationists basically want biology to be taught incorrectly.
and you can still show an argument to be invalid by disproving its premise.
You don't seem to understand the concept of a logically valid argument. An argument is valid if and only if the truth of the premises guarantees the truth of the conclusion. A valid argument's premises can be false.
There's another problem with what you said: logic cannot offer proofs or disproofs of contingent statements. If the pundit's premise is a contingent statement, then logic doesn't suffice to deal with it.
and if people are accustomed to rational thought they'd be less likely to believe in false premises.
How? Again, if premises are contingent statements, logic is completely silent about whether they're true or false. A perfectly logical thinker would have perfectly consistent beliefs, but nothing would guarantee that those beliefs were all true.
Slashdot Mirror
But logic programming gets called a paradigm because it's a Turing-complete computational model that's dramatically different from the more familiar ones (Turing machines, lambda calculus). I'm not aware that dynamic dispatch is like that.
Though by that criterion, functional programming is a paradigm, imperative is a paradigm, an OOP isn't. To me that just goes to show that the notion of a "programming paradigm" is vague; there are a bunch of different reasons that somebody refers to something as a "programming paradigm," and the criterion by which logic programming makes the cut is not the same as the ones by which OOP makes it in.
I just don't think dynamic dispatch is a big enough idea to merit the name "paradigm." I realize that there can be no principled rule to distinguish between "paradigms" and mere "techniques," but I'd say the following:
What's peculiar to the syntax for invoking a generic function in a CLOS-type system? It's the same syntax as for applying any other function in Lisp. The fact that the function does a dynamic dispatch is an internal detail of the function.
There is likely some special syntax for defining the generic functions and the methods, sure; how is that peculiar, also? Stereotypical OOP languages have separate syntaxes for class definition, method definition and method invocation.
What does "central" mean in this context? He certainly had a lot of other stuff in mind at the same time. Were any of these other things "central" too? If so, were any of them more "central" than dynamic dispatch? Again, there's no principled rule here, but I just don't think dynamic dispatch by itself reasonably counts as a "paradigm."
I must say that I find some of the Smalltalk core ideas pretty bad for software engineering, particularly the emphasis on subclassing and adding methods to base classes. And a lot of OOP folks would wholeheartedly agree with this...
Um, why pick a real processor at all? I think a much better choice would be to use very simple VMs tailored toward the task of teaching programming. The VMs can abstract away detail that only gets in the way, and provide a lot more debugging information for the students.
What should such a VM provide? My suggestion would be the following:
Basically, a VM like this could be used as an introduction to the basics of machine code programming, and then later reused to teach compilers.
Nobody's every offered a usable definition of "object-oriented" that really allows you to distinguish OOP from non-OOP in any reliable manner. Classes don't do it (because of prototype-based languages that are said to be OO); "sending messages to objects" doesn't do it either (counterexamples: CLOS, Dylan); object.operation syntax doesn't do it either (CLOS and Dylan, again). Dynamic dispatch seems the closest thing to a deciding criterion, but that alone seems like an unsatisfying answer, because it describes a technique that can be easily built into a random impure functional language (you can probably implement simple dynamic dispatch in two pages of Scheme code).
"Pure functional" does have a good demarcation criterion (the language has referential integrity in all contexts with no exception), but "impure functional" is also impossible to demarcate precisely (Is Ruby an impure functional language? Is Python so? C#?)
Ultimately, I think all this talk about "object-oriented" vs. "functional" isn't very useful. It would be better to enumerate specific features or properties that one would like a language to support. So, for example, I like PLT Scheme because it has first-class functions, closures, macros, dynamic types, mutable state, record types and a module system. I can use these fairly straightforwardly to implement nearly any programming technique or feature out there, from dynamic dispatch to monads, logic programming, or what have you.
I wouldn't say it was created to save money, because the initial costs to get the FOSS ball running are often higher than buying something.
However, the adoption of large FOSS projects like Linux or Apache certainly is because they save money. Large corporations pay a lot of money for Linux development work that they give away, because the alternative would be for each of them to independently duplicate the work that the others do. This alternative would be more expensive, and provide little clear competitive advantage.
Um, a pure interpreter never "compiles" its program, in the sense of transforming the code into equivalent code in an object language. A pure interpreter usually works this way:
The easiest example to learn here would be a typical Lisp meta-circular evaulator.
A compiler, on the other hand, translates the AST into equivalent object code in a different language, which can then be run in an implementation of that second language (which can be either a real machine, a virtual machine, a language interpreter, ). For a pure interpreter to "compile each instruction every time it gets executed," there would have to be a program in the object language involved somewhere... and there isn't one, only an model of the successive states of a computation.
I think your example is very flawed. The compiler can't easily make the kind of analysis to drastically reorder or regroup this computation.
Let's simplify your example for a minute by dropping the roots bit. So we just have a sum function:
Now, when the system has to compute the value of sum [1..5], it basically has to compute the value of the following expression: (1 + (2 + (3 + (4 + 5)))). Unless the compiler recognizes that addition is commutative and associative, there is only one order in which it can reduce that expression to the final answer: from the inside to the outside. This is because your claim that "the evaluation order is not defined" isn't quite true. There is a well-defined partial order of value dependencies in a functional program, and any execution of the program must respect that partial order.
Sure, in the case of that one example, you could write a compiler that recognizes that + is commutative and associative. The problem now is that doesn't help you when you're dealing with other functions.
The correct solution here, IMO: you want to have a higher-order function, let's call it reduce, over lists that takes three arguments: a two-argument function (like +), an identity element for that function, and a list of values that are accepted by that function. The contract of reduce is that it will order and group the elements of the list in an undefined, implementation-dependent order, and then combine them with the function given. So here are three valid implementations of reduce:
Now, since the contract of reduce says that the order and grouping is undefined, that means that the only way to guarantee that you'll get the same answer with different implementations of reduce is to pass it an associative and commutative function, like +. It also means that if you write a bunch of code today using a sequential version of reduce, and you take care to respect the contract of the function, tomorrow you can replace any one of those uses with another function with the same contract, but which parallelizes the work.
Short version: no, the compiler can't figure out what to parallelize very well at all.
GP is talking out of the wrong orifice.
Functional language compilers and runtime systems don't have the ability to magically guess how to parallelize your computations in a way that actually helps performance. Yes, in principle it could construct a dependency graph of the subcomputations that the program has to perform, and execute as much of that in parallel, but that in practice would mean more time spent in thread synchronization than on computation.
You still have to write your programs to specify where you need parallelism, and choose those places wisely. Where functional programming wins for parallelism is on two areas:
The idea to get rid of "save" is, basically, the idea that the user should not have to do any action to prevent the document they're working on from disappearing. Basically, you can stop working on the document instantaneously and come back to it in exactly the same state, without having to perform a "save" action.
The idea is not to eliminate versioning and content archiving operations. There would be versioning and filing operations available to the user, which would work very much like "save" does. The point is that their use would be, strictly speaking, optional. If the user doesn't use those features, then the only thing that the system does is to guarantee that the most recent state of the document is preserved between sessions. So when you shut down your computer with Notepad open, you are not prompted for anything, and the most that you lose is undo.
Why so complicated? As I said in another comment: just put newly created files on the desktop, and make names optional. The question of where a newly created document went then always has the same answer (the desktop). When the user decides that the desktop has become too cluttered, then they can "file" the items (with multiple tools, like tags, hierarchical folders, version control tools, etc.).
So put it on the desktop, and make the desktop capable of showing you the contents of your files. When your desktop gets cluttered, then you set aside 15 minutes to file away or discard the items in it.
You might answer that many users' desktops would then get insanely cluttered; my reply to that is that many people's desks are insanely cluttered, so that's ok. The UI doesn't have to solve the user's character flaws.
There's a problem you're not seeing: the logic for swapping out cold memory pages assumes that the goal is to maximize application throughput, at the potential cost of latency when doing large context or workload switches. The approach makes the applications that are currently running optimally fast, at the cost of making it costly for an idle application to become active again.
This is excellent for some kinds of workloads, but bad for user interaction, where latency of task switching is more important than maximum throughput. When I click on a minimized application window, I want that application to be ready to run instantly. That's more important to most users than having an occasional computationally intensive task take 3 minutes instead of 5--I can find something to do during those 5 minutes.
Assume all disk reads and writes are the same cost, one unit. The cost of swapping a page out, and then later swapping it back in, would then be two units. Basically, the throughput cost of swapping a page out and later back in breaks even if you otherwise save two disk reads--for example, by getting two hits on the disk cache.
There's nothing odd about this. Basically, RAM is faster than disk, so you want the data that's used most often in RAM, and the data that's used less often on disk. Which pieces of data are process memory pages and which are file block data is irrelevant.
The big questionable assumption here, however, is that the goal is to maximize throughput of a constant workload. If you're seeking to minimize latency in a highly-variable, interactive workload, then things can easily change. This is why swapping is often perceived to be bad for desktop systems: the user will often switch over to a completely different program from what she's using, and doesn't want to wait for the UI to respond. This translates into a requirement for low latency of frequent workload changes.
Not really, because a free market also requires competition, which often requires that organizations keep trade secrets. In a free market economy, the cost of developing new techniques to bring superior goods or services to the market, or reducing the cost of existing ones, can only be justified if the resulting information can either be kept from would-be competitors (trade secrets), or the competitors barred from using it (patents, copyrights).
Basically, for a given good or service, there is a lot of information that's not relevant to the potential buyer's choice, and a lot of this information is of enormous value to the producer.
Yes, if the encodings of all the strings have a precisely defined mapping into Unicode code points, then this is true. Abstractly, they're all just sequences of Unicode code points. However, there's no point in allowing different string objects to use different encodings in that case; you might as well use the Java/Python model, where all text strings are stored in some internal Unicode representation that's hidden from the clients, and encoding translation is done for byte I/O.
The issue with Ruby 2.0, however, is that their planned string type will support encodings that don't have a precise mapping to Unicode codepoints--and even harder, were defined to not have any such mapping. So basically, you can have two strings in separate encodings where what you describe does not hold.
I think you are confusing two issues here:
Basically, GP is arguing that the answer to (1) is "no." You're responding that the answer to (2) is "no." Well, (2) is a different issue than (1).
Yes, ISPs are acting like weasels, and we should press them to build more infrastructure, to price their offerings better, to market them honestly, etc. But the endless Slashdot choir that "when I pay for a 10 Mbit/s line I should get a guaranteed 10 Mbit/s every time" is completely wrong, and doesn't help the issue at all. The shared resource model that the ISPs (and all other utlities) are using is really the correct one.
No, you were not thinking the same thing. Note that GP doesn't talk about non-compete clauses at all. Your obligation to protect your employers' trade secrets is separate from whether you have a non-compete clause. A non-compete clause forbids you from working at a competitor for a certain period of time, period, even if, hypothetically, you actually knew no trade secrets. But even if you are not subject to any non-compete terms, you can't just leave your company and blab on all of its trade secrets to somebody else, or exploit them for your own gain.
Galileo's theory wasn't predictively superior to contemporary geocentrism, by his own admission. However, it was worse off in comparison, because it required a major revision of mechanics; it contradicted Aristotelian mechanics, which was as firmly entrenched as today's physics is for us. Galileo didn't have anything near a worked out theory of mechanics that rejected the idea of an absolute reference frame, and therefore, the idea of the relativity of all motion. This objection, if you note, was not biblical: it's a technical physical objection. (A modern day analogy would be if somebody proposed a theory that blatantly violated the law of inertia.)
The most important new kind of evidence Galileo brought into the picture were telescopic observations, and those weren't straightforward to interpret. The telescopes of the day were pretty awful devices, and more importantly, he didn't have a theory of optics that allowed him to justify his interpretations of what he did observe. Again, this is a technical objection, not a biblical one.
There were also other serious problems posed by other, very good astronomers of the day (by their and our standards), for which Galileo didn't have satisfactory answers. Things like the relative brightness of the planets at various points of their trajectories. These were not cosmological or biblical objections: they were technical, astronomical objections.
The church wasn't a biblical fundamentalist institution. It can be easily demonstrated that in many places, it accepted the scientific theories of the ancient Greeks in spite of apparent contradiction to the bible. There are biblical verses that the church read as seemingly implying that the Earth is flat; but the arguments for the Earth being a sphere were firmly accepted. In a sense, the world was seen as the work of God just as the bible was the word of God, so solid scientific arguments about the world had serious theological standing, and could not be shot down by appeal to the bible.
The church judged Galileo's astronomical theory, which seemingly contradicted the bible, on the basis of the professional opinions of astronomers of the day. The theory was found wanting on those grounds, so therefore, because it contradicted the word of God as interpreted by the Church, Galileo was forbidden from teaching it as a truth, while still being allowed to teach it "as a hypothesis." And in actual fact, many figures in the church, including the pope himself and some cardinals, encouraged Galileo in his studies.
At the end, you just can't conclude that Galileo's trial was as simple of an affair as people normally describe it. Yes, the church held too strong of a leash on science back then, but it wasn't nearly as reactionary as people like to portray it. In the actual facts of what happened, the political, interpersonal, scientific and biblical aspects of the Galileo affair were all very important. Galileo proposed an interesting but still very incomplete theory that contradicted the bible, and then went and publically humiliated the powerful sponsors that were shielding him from his biggest critics.
Of course it doesn't prevent them from doing that. The problem then is that when they meet their friends outside, all they do is talk about WoW and nothing else. I've had many a lunch ruined at work when my WoW-playing coworkers decide to all sit down at my table.
That doesn't follow from what GP said. The question of where an alleged crime occurred, and therefore of which courts have jurisdiction over it, is a very complicated, subtle issue that doesn't allow for simple generalizations like that.
Basically, if you apply the heuristic that the crime occurs where the damage is done, then you get the following: (a) the German guy's crime occurs in the USA, because the effect was to deny somebody in the USA their right to control the use of their own copyrighted materials; (b) the Chinese folk who post to Blogspot commit their "crime" in China, because the "damage" their "crime" "inflicts" is to Chinese society.
Yes, it's fucked up, but as somebody said in another thread, the problem is not how jurisdiction works; the problem is China's government.
So, what is supposed to follow from "fault," in cases where there is no question of moral or legal wrong? In cases where it does it not play a role in either the moral or the legal calculus of the situation, what role does it play?
I think I've read plenty about this topic, and you have clearly not. For example, the Wikipedia article you linked about falsifiability plainly fails to support your claim. The article gives a detailed discussion of the problem of ad hoc hypotheses in science. It attributes the whole idea of falsifiability as a demarcation criterion specificallt to Popper, and then goes on to offer this choice quote: "Among the professional philosophers of science, the Popperian view has never been seriously preferred to probabilistic induction, which is the mainstream account of scientific reasoning."
So, if we go by the article you first cited to support your claim, your proposed cornerstone of science is actually not the mainstream account of scientific reasoning. Good job there.
You're in no position to preach when the sources that you cite contradict what you claim. This isn't a give-and-take of opinions, as you're trying to paint it. You are making claims that are contradicted by the sources you cite. I'm suggesting that if you do not want to look like an ignorant fool, you might want to try and read the sources you cite. Otherwise, one of these days a creationist who actually has studied the philosophy of science is going to pwn you, simply by pointing at the vast philosophical, scientific and history of science literature that's critical of falsificationism.
So basically, you think that smart, educated people, by virtue of their intelligence and education, should necessarily agree with you? Have you considered the possibility that how smart and educated you are may be largely unrelated to what beliefs you have?
You're supporting this claim with two dictionary definitions and a Wikipedia article. Setting aside the question of how the hell a lexicographer's description of the meaning of the word can possible settle this point, let me just point out that: (a) the first dictionary entry you cite starts with a non-Bible literalist aception of the term; even worse, (b) the Wikipedia article you cite explicitly contradicts your point.
Did you even read what you cited?
Um, you're doing exactly what GP objects to: you're taking a minority view among creationists (the idea that the Old Testament literally tells us the age of the Earth), and judging all of them by that standard. The claim that life is the result of divine design does not entail the claim that the Old Testament tells us a literal creation story, period.
Falsifiability fails as a demarcation criterion for science. I agree with you that creationism isn't a scientific theory, but your argument sucks, and you shouldn't be making it. (And, BTW, read your own fricking link.)
As a fellow non-creationist, let me tell you two things: (a) you supposed "science-types" make a really bad showing of yourselves, (b) actual theologists, on the aggregate, don't spend a lot of time on creationism, so don't tar them with the brush that you tar creationists. (Which, incidentally, means you're doing to theologists exactly the same thing that GP complained is done to creationists.)
Anyway, what's commonly referred to as "creationism" these days has two main ingredients:
The first of these ingredients is perfectly scientific, taken on its own. The second one is the nasty one. So of course, creationists spend all their time playing up the first one, and distracting us from the second one. And you "science-types," instead of focusing on the political agendas, just love to sit down and play into their hands by going on and on about scientific and philosophical topics you don't quite understand. With the effect that you'll just get eaten for lunch by any creationist who just happens to be smarter than you, better educated on these topics, and more eloquent.
Don't play their game. Just tell them that the scientific merits of theories, and therefore, the content of science courses, should be decided by the scientific community, period. Even if the scientific community is wrong, science is what the community says it is, and if we are going to teach biology to children, then the actual truth or falsity of evolutionary theory isn't even relevant. What matters is if we're teaching biology correctly--and creationists basically want biology to be taught incorrectly.
You don't seem to understand the concept of a logically valid argument. An argument is valid if and only if the truth of the premises guarantees the truth of the conclusion. A valid argument's premises can be false.
There's another problem with what you said: logic cannot offer proofs or disproofs of contingent statements. If the pundit's premise is a contingent statement, then logic doesn't suffice to deal with it.
How? Again, if premises are contingent statements, logic is completely silent about whether they're true or false. A perfectly logical thinker would have perfectly consistent beliefs, but nothing would guarantee that those beliefs were all true.