In fact, as the lack of god is the null hypothesis, atheism is the default scientific proposition.
This is the part I don't understand. If there is no evidence either way, why does atheism win by default? Isn't this like saying we should abandon string theory because it doesn't explain anything better than the standard model?
Atheism wins because it is the existential claim that requires proof, not its negation.
If you claim that something exists, you have to show that it exists. The burden of proof is not on others to show that it does not exist.
You either have to demonstrate that something directly, or else prove that the negation (that it doesn't exist) leads to some kind of problem, making it impossible for that thing not to exist.
The human mind can invent all kinds of things that can't be proven not to exist.
Are you familiar with Russel's teapot? This is the whimsical proposition that there is a china teapot orbiting the Sun in an elliptical orbit. Can you prove that it is false? Yet should that proposition "win by default"?
Though we cannot prove it false, there are several strikes against Russel's teapot: 1) it's an obvious human fabrication and any number of such fabrications can be invented on the spot, with similar difficulties of proving their non-existence. For instance, a herd of pink elephants roaming Antarctica, etc. 2) Russel's teapot has never been observed and 3) The proposition that "Russel's teapot does not exist", if true, has no catastrophic consequences in our understanding of the world. We cannot show that Russel's teapot is necessary for anything. In fact, "Russel's teapot does not exist", if true, only has a devastating effect on the statement "Russel's teapot exists" and on nothing else!!!
You don't answer why there is a color in the first place. What is this quality that our brain superimposes onto surfaces that we call color, and if it is all just nerve impulses why doesn't it resemble the sensation of hot versus cold, or high pitch versus low pitch?
If the brain can demonstrate so much flexibility in learning new things, why can't it teach itself to hear a color or feel it like a temperature?
People agree on which things are green and which are not (except for people who are understood to be color blind). Yet when you and I see a green thing, do we feel green-ness the same way?
How do you explain "green" to someone who is congenitally blind? Since he's a descendant of a race of visual beings who can generally see color, can he imagine colors, even if he has no way to know which ones of those colors match what grass looks like?:)
Religions have an answer for "why", just not one that is adequate and consistent with the facts.
I do think that the answers for "why" do ultimately involve faith; it just doesn't have to be a faith with all the poor quality, highly random and improbable content of religion.
You don't know if there is some omni-potent being who decided exactly how the universe would operate.
This idea simply divides the universe into two parts. One part is a being, which decides how the other part, namely everything else, operates. Now what you need is yet another being which decides the workings of that universe, and in general you now need an infinite chain of beings, in which each successor is beleived to have caused the predecessor.
A far simpler explanation is that we are in a large mathematical object whose behavior is the consequence of rules.
That might lead to the suspicion that someone created the rules, but that is wrong. Nobody creates mathematical objects; they just are. Moreover, all possible such rules exist, giving rise to an infinity of universes. Every mathematical object we can find and describe is just as real as any other.
We exist in the same sense that the number PI exists, or the Pythagorean Theorem exists.
This is the least ridiculous form of faith, and is the simplest explanation which is compatible with all observation, and free of hidden variables.
Perhaps a more common view among physicists today is the idea that there is a multiverse with a wide range of values for the constants of physics, and by the selection principle of observership (the weak anthropic principle), we find ourselves in the part of the multiverse where life is possible and/or relatively common (at least compared to other parts of the multiverse) [7]. However, there is still considerable controversy over whether such a multiverse that would be necessary for this explanation really exists.
This way of stating the controversy is inherently biased. The multiverse view is actually simple; it consists of the non-denial that multiple universes exist.
I.e. we can also formulate the controversy as being "over the existence of hidden rules which prevent the existence of multiple universes."
This is similar to, say, imaginary numbers. Algebra without the imaginary number i is more complicated. This number is not some extra ingredient whose existence is added; rather it is the consequence of the denying the existence of a superfluous and inconvenient rule against finding the roots of negative numbers. Mathematicians who denied i as repugnant were simply defending the faith-based existence of such a rule, which just "had to be". Now we take it for granted that investigation of rules can give rise to discoveries of new kinds of numbers.
Currently, we cannot show by observation (and probably never will be able to) whether there is just the one universe or whether there is an infinite number of universes. Neither view is falsifiable, and both are consistent with observation.
However, the multiverse view is simpler and less astonishing.
The claim that there is only one universe (or, say, some finite number of them) requires an explanation of why the remaining universes do not exist, why are the constants tweaked this way and not that, etc. The believer in the multiverse view is liberated from believing in arbitrary hidden processes and variables, and sidesteps the problem of infinite causality (essentially by embracing it in a different way).
The observation that constants in our universe are not tweaked to be optimized for life (at least as we know it) may be falsifiable, but it does not give us a hypothesis for the existence of everything, so it is not fair to compare it to TOE hypotheses, especially given that it's actually compatible with all these hypotheses (since they are consistent with observations).
I can "disprove" something by demonstrating that it relies on unprovable hidden variables which are not necessary.
If there are two equally unprovable hypotheses that explain something, the superior one is the one which relies on fewer hidden variables (ultimately, none at all).
Those who cling to an inferior hypothesis are irrational.
It may be impossible to determine the origin of the world (which necessarily will have to be the case if, for instance, it doesn't actually have an origin!).
It is possible that the best we will ever be able to do to explain the world is via an unprovable hypothesis. What is left then is to choose the best one.
A hypothesis which appeals to hidden variables, like a creator, is obviously inferior because it invokes recursion: it requires us to solve a problem which is equally as large: what created the the creator?
Any universe U with a creator C understood to be outside of U can be reified as a larger universe U+C which consists of the union of U and C. We know where U came from (it was created by C), but we cannot explain where U+C came from.
Religions get around this problem by asserting things like C didn't come from anywhere; C is infinite outside of time and space.
But these properties of C can simply be applied to U, eliminating the need for C. U itself encompasses infinities.
Asking where the universe began might be as silly as asking how far do we have to go to the left off the blackboard to find the spot where the function y = sin(x) begins its undulations.
But, in fact, the statement "we are not here" holds, when you define "here" as many of the infinite possible universes, which do not contain anything like us.
We only know the one "here" in which we find ourselves, our observations of what exists are biased by the lack of access to the infinite reams of universes.
If all possible universes exist, there is no need for creation, because creation would mean that only a few universes exist which are deliberately tuned.
Nobody creates mathematical axioms and the objects that spring forth from those axioms. The set of sets of axioms is infinite.
There is an obvious bias in the empirical observation of universes in that only the universes that contain conscious life get observed.
Conscious life is the means of which by a universe introspects. The universe gazes at itself through us.
Any universe which is sophisticated enough to give rise to conscious, thinking life will appear to that life as if it were created, until that life further improves the quality of its thought.
C++ exceptions are broken. An exception in computing is some event out of the normal flow of the program's execution which requires handling. For instance, a not-present page of virtual memory, upon a memory access to that memory.
During an exception, meticulous care must be taken to preserve the program state, for two reasons. One is so that the maximum information is available about what the processor was doing (in case the exception was caused by code). The other reason is to allow the program to be resumed where it left off, as one of the options for recovering from the exception.
The point of departure for C++ exceptions is the erasure of information. Once a C++ exception is thrown, a search for the handler begins. As the search progresses, information is thrown away (unwinding). All call frames between the handling site and the exception throw site are thrown away.
C++ exceptions are not really an exception mechanism but a dynamic non-local control transfer mechanism, which provides a way to escape from deep within some context without any intent to recover and continue.
C++ exceptions are debugger-hostile. If you stop the program where an exception is caught, there is no meaningful backtrace for investigating what happened; it's already gone. To catch the exception where it occurs, you have to put a breakpoint on every throw which might be causing it.
These dumb exceptions are suitable for writing system utilities which can follow the mentality of simply bailing when something goes wrong, so that some higher-level metaprogram (script) can notice the failed termination status and do the real handling.
I once wrote an exception library for C which is similar. It ended up being used in projects like Ethereal/Wireshark. I no longer endorse that library. Today, I would not design it that way.
The search for an exception handler must be done in a new execution frame, without discarding any frames. When a suitable handler is found among the call frames, that handler can then search the call frames for a restart point, as determined by that handler's recovery strategy. Once a restart point is chosen, only then does unwinding take place and a non-local transfer to that restart point.
This design allows the module where an exception is raised to provide ways to recover and continue.
The most recent (open source) project I have worked on is Txr (http://www.nongnu.org/txr/).
Even though I have tons of C++ experience, this is written in a dialect which compiles with either a C or C++ compiler, and does the same thing.
This dialect more portable than either C++-incompatible C or C-incompatible C++.
The main paradigm within the program is ideologically and esthetically incompatible with most of the extensions that C++ brings to C.
Wide portability isn't the only benefit. You get access to a wider range of diagnostics. There are things the C++ compiler might tell you that the C compiler won't, and even vice versa.
Many things that are banned in C++ are bad features in C or bad style of C coding. For instance, skipping variable initializations with a goto. Or lack of type safety in the handling of enum constants.
Programs in the "C/C++ dialect" benefit from these things being diagnosed without losing compatibility with C.
Here is another one: C++'s enforcement of type-safe linkage, the one-definition rule, and its banishment of obsolescent features, like calling undeclared C functions.
I get approximately the same code from GCC's C++ or C's front end. Benchmarks have differed between the two as much as between different versions of GCC.
These days, performance concerns are no longer valid as a reason for eschewing C++ in favor of C (except in provable circumstances with particular toolchains and platforms). However, the C/C++ dialect will let you port your code anywhere, choosing the best possible compiler. If some embedded target has a great C++ compiler, but a so-so C compiler, you can use the C++ compiler and vice versa. Even if you don't ship with the C++ compiler, you can use it for diagnostics.
"void *" is a stupid misfeature, which I avoid in all new C code that is written by me.
C++ never took away the automatic conversion from "void *"; it never had such a conversion. C perverted the "void *" idea by adding that conversion. As recently as last week, I ran into a void * bug. Some stupidly defined third party API defined an important handle type like this:
typedef void *handle_t;
A typedef for void * usually spells trouble. Anyway, one of the functions of this API is like this:
int api_init(handle_t *phandle);
the cleanup is:
int api_cleanup(handle_t handle);
The buggy program called both of them as api_init(&handle); and api_cleanup(&handle). Compiled without a peep, of course. C++ wouldn't help with this because this is a conversion to void *, not from void *.
In all new C code that I develop for my own projects, I now use some character type as a generic pointer-to-anything, and have explicit casts everywhere there is an unsafe conversion, in either direction.
The conversion from any pointer to object type to void * (allowed in C and C++) is itself braindamaged, because it gets you halfway to reinterpreting some memory without requiring you to confirm it or leave behind a piece of documentation in the code that can be easily spotted later (the cast).
C was better off before "void *", when malloc returned "char *".
In the Txr project (http://www.nongnu.org/txr/) I developed last year, I introduced "typedef unsigned char mem_t". After that, all generic pointers are "mem_t *". An allocator returns "mem_t *": All pointers other than unsigned char * have to be converted to and from mem_t * with a cast.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation,
Great! That lets you combine the poor libraries of CommonLisp with the syntactic limitations of Python.
The performance is comparable to using C libraries,
It is possible to get C-like performance out of a CommonLisp compiler, but you have to jump through hoops to do it, and the necessary declarations are different from compiler to compiler (and sometimes even between versions).
Common Lisp has great libraries, and can easily call foreign API's. Lisp can call C functions, pass Lisp functions to C as callbacks. Lisp compilers have extensions that let you manage argument data right on the stack. Recently I needed to call some Win32 functions from Clozure, and found all the goodies there to do the job with minimal overhead.
Common Lisp declarations for type and optimization are part of the ANSI standard, and generally do the same thing across different compilers.
"possible to get C-like performance" (Lisp) is a heck of a lot better than "impossible to get C-like performance" (CPython, Ruby,...). To get "C like performance" from C, you also have to jump through hoops sometimes.
Of course, I would like "same from compiler to compiler", but when that is not available, my next choice will be "different from compiler to compiler". My third choice after that would be "only one compiler", and an unfortunate fourth would be "no compiler" (CPython, Ruby).
Committees should standardize what is out there. Once that is done, they have achieved their purpose and it's time to disband.
The problem with the C++ committee is that their egos prevent them from going their separate ways.
Once a committee thinks that it is so important that it can start inventing new features and dictating them to the programmers and implementors, it is the beginning of a disaster.
Almost never should a draft language contain features that no compiler has. This should only happen very early in the standardization, when there is no other way to solve some conflict between dialects.
If you aren't aware of this debate, then I suggest you research the history of LISP. I've already covered this on another post. I'm not even sure where I stand on the debate as I can see points on both sides, but I'm not idiotic enough to pretend that there is no debate.
It's not about whether there is a lot of LISP code out there - there certainly is - emacs is full of lisp macros. AI research and mathematics use it heavily.
The debate is more about whether it fits the classic definition of a computer language.
Classically, computer languages are defined by a specific, usually fairly extensive grammar, whereas the LISP grammar is basically
expr: ID | STR | NUM | list
list: ( seq )
seq: | expr seq
Again, this is not to say that it's not powerful or to deride it's significance, but to try and explain why there is legitimate debate over what constitutes a programming language.
You are confusing formal languages and programming languages.
Programming languages are not simply syntax.
Programming languages have multiple layers of syntax. For instance, on one level, a C language program is a sequence of various kinds of preprocessor tokens.
Lisp has a lexical syntax (quite a bit more rich than the grammar you have given) and then it has a syntax within the forms produced by the lexical syntax.
For instance (defclass derived (base1 base1) (slot...))) is syntax for defininig a class and (loop for x from 1 to 10 summing (* x x)) is the syntax of an expression which sums the squares from 1 to 10.
There is a lot of syntax you have left out. For instance #(1 2 3) is Lisp syntax for a vector. #c(1 2) is the complex number 1 + 2i. Then there is backquote syntax, which can nest arbitrarily. E.g. `(1,a,b) is a quasiliteral which denotes the three element list consisting of 1, and the value of A and the value of B.
The legitimate debate you are alluding to does not exist. I've never seen anyone claim that Lisp isn't a programming language.
Common Lisp has an ANSI standard (look for it on the ANSI web store). The title is "Information Technology - Programming Language - Common Lisp".
Unlike Python (the principal implementation of it, rather) and Ruby, Lisp (which has not been spelled LISP since 1980) is a compiled language. Lisp implementations produce native code. Lisp libraries for cryptography, regular expressions, etc, are written in Lisp and are comparable to C libraries. Lisp is fast enough to be used as a systems programming language, and has been, including as an operating systems programming language. The system running on the Lisp machines was written in Lisp: OS, drivers,... Yet it is also suitable for making a web application.
Can you provide a URL to this "considerate debate" about whether "LISP" is a programming language?
Are you sure you couldn't live without static typing? Or could it be that you could not live with Ruby's immature, crappy dynamic typing?
Real dynamic languages have compilers that help discover type errors in your code, and also provide optional type declarations so that you can optimize.
C++'s declare-everything type system is 1960's technology. But at least it is mature. Don't compare mature type systems to toys; it's not fair!
Lisp is a compiled language, so you don't need C extensions so much, other than to call a foreign API. When you use CPU-intensive routines like cryptography, regular expressions, etc, in a Lisp program, those things are also written in Lisp. The performance is comparable to using C libraries, though Lisp programs can call C libraries easily, and Lisp routines can be passed as callbacks to C code.
Lisp supports the business model of writing a tamper-resistant proprietary application, distributed to users in binary form, just like C++.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation, which works by compiling the Python code to Lisp forms, which are then compiled by your Lisp compiler. Since Lisp is an extensible language, CLPython appears to you as a library that you add to your program, which then lets parts of your program to be written in Python.
Induction (not the mathematical kind, but generalization from particulars) and deduction are completely different beasts.
Induction works because the universe has been fairly kind to us so far by exhibiting regularity.
There is no/logical/ reason why anything should remain the same tomorrow as it is today: the charge of an electron, Planck's constant, etc.
Just our assumption that such things don't change has worked out so far.
Science is in fact logical (deductive) in its predictions in the sense that we can we add the regularity of the universe as a premise to the inductive argument to make it deductive:
"IF the universe will continue to permit us, as it has in the past, these generalizations from particulars, both in the direction of the (future behavior will be as past behavior) and space (the laws far away are as they are nearby), and IF we have such and such initial conditions, and such and such laws generalized from past observations of behavior, then the following shall happen..."
If the universe suddenly does not permit the generalization, then the argument is still logically valid because of its deductive form.
One regularity of the universe is that rules derived from observing some situation tend to apply to similar situations: i.e involving events on a similar scale of time and space, energies on a similar scale, particle or other object sizes and masses of a similar scale, energy levels or field strengths of similar scales, and so on.
If you observe the motions of ordinary objects on Earth, you can make laws that apply very well to the motions of such objects, though perhaps not to sub-atomic particles, or bodies moving at relativistic speeds and so on.
We have been burned enough by generalizing to be suspicious of all generalizations. Are the fundamental constants the same everywhere in space? Etc.
But all such uncertainties can be stuffed in as assumptions to make the resulting claims deductive.
A great piece of tech, introduced just four years later in 1979, was the Motorola 68000.
This is probably the only processor worth studying, from that era.
Let's look at the 6502: eight bit registers only, and just three of them. 256 byte stack. 16 bit address space. Invalid opcodes execute strange actions instead of vectoring to an exception. Synchronous interfacing with no recovery: if a peripheral doesn't produce data within the clock period, the processor simply reads garbage!
By contrast, the 68000 gave us 32 bit data and address registers (well not all address lines useable in the first generation). Wonderful instruction set. Decent interrupt and exception handling for operating system development. Terrific interfacing with handshaking protocols for slower peripherals.
The only thing that's amazing is some of the cool software that was produced for computers based around chips like these.
What's also amazing is how long that 6502 lasted: how a processor introduced in1975, it continued to be used right up to the mid 80's for home computers. Unthinkable today.
What's amazing is the incredibly retarded follow ups too, like the 65C816 with its segmented memory model, well into the era of decent microprocessors.
The 6502 belongs in the same historic trash bin as the Intel 8086/88 and its progeny.
Censorship is a state-imposed publication ban, or requirement for alteration.
This is just some publishing company making a modified version of something in the public domain.
They are not interfering with anyone's ability to read the original.
Thanks to Project Gutenberg, anyone can download The Adventures of Huckleberry Finn and publish their own version.
If you don't like what some obscure publisher in Alabama is doing, make a HTML version in which racial slurs are in large, colored font, and put it on your web site in protest.
Slashdot Mirror
People using an open source program spend resources to adopt it to work with something else.
And they do that just to waste money; making a program work with something else never helps their bottom line.
Therefore, open source is more expensive.
This is the part I don't understand. If there is no evidence either way, why does atheism win by default?
Isn't this like saying we should abandon string theory because it doesn't explain anything better than the standard model?
Atheism wins because it is the existential claim that requires proof, not its negation.
If you claim that something exists, you have to show that it exists. The burden of proof is not on others to show that it does not exist.
You either have to demonstrate that something directly, or else prove that the negation (that it doesn't exist) leads to some kind of problem, making it impossible for that thing not to exist.
The human mind can invent all kinds of things that can't be proven not to exist.
Are you familiar with Russel's teapot? This is the whimsical proposition that there is a china teapot orbiting the Sun in an elliptical orbit. Can you prove that it is false? Yet should that proposition "win by default"?
Though we cannot prove it false, there are several strikes against Russel's teapot: 1) it's an obvious human fabrication and any number of such fabrications can be invented on the spot, with similar difficulties of proving their non-existence. For instance, a herd of pink elephants roaming Antarctica, etc. 2) Russel's teapot has never been observed and 3) The proposition that "Russel's teapot does not exist", if true, has no catastrophic consequences in our understanding of the world. We cannot show that Russel's teapot is necessary for anything. In fact, "Russel's teapot does not exist", if true, only has a devastating effect on the statement "Russel's teapot exists" and on nothing else!!!
You don't answer why there is a color in the first place. What is this quality that our brain superimposes onto surfaces that we call color, and if it is all just nerve impulses why doesn't it resemble the sensation of hot versus cold, or high pitch versus low pitch?
If the brain can demonstrate so much flexibility in learning new things, why can't it teach itself to hear a color or feel it like a temperature?
People agree on which things are green and which are not (except for people who are understood to be color blind). Yet when you and I see a green thing, do we feel green-ness the same way?
How do you explain "green" to someone who is congenitally blind? Since he's a descendant of a race of visual beings who can generally see color, can he imagine colors, even if he has no way to know which ones of those colors match what grass looks like? :)
Religions have an answer for "why", just not one that is adequate and consistent with the facts.
I do think that the answers for "why" do ultimately involve faith; it just doesn't have to be a faith with all the poor quality, highly random and improbable content of religion.
You don't know if there is some omni-potent being who decided exactly how the universe would operate.
This idea simply divides the universe into two parts. One part is a being, which decides how the other part, namely everything else, operates. Now what you need is yet another being which decides the workings of that universe, and in general you now need an infinite chain of beings, in which each successor is beleived to have caused the predecessor.
A far simpler explanation is that we are in a large mathematical object whose behavior is the consequence of rules.
That might lead to the suspicion that someone created the rules, but that is wrong. Nobody creates mathematical objects; they just are. Moreover, all possible such rules exist, giving rise to an infinity of universes. Every mathematical object we can find and describe is just as real as any other.
We exist in the same sense that the number PI exists, or the Pythagorean Theorem exists.
This is the least ridiculous form of faith, and is the simplest explanation which is compatible with all observation, and free of hidden variables.
Perhaps a more common view among physicists today is the idea that there is a multiverse with a wide range of values for the constants of physics, and by the selection principle of observership (the weak anthropic principle), we find ourselves in the part of the multiverse where life is possible and/or relatively common (at least compared to other parts of the multiverse) [7]. However, there is still considerable controversy over whether such a multiverse that would be necessary for this explanation really exists.
This way of stating the controversy is inherently biased. The multiverse view is actually simple; it consists of the non-denial that multiple universes exist.
I.e. we can also formulate the controversy as being "over the existence of hidden rules which prevent the existence of multiple universes."
This is similar to, say, imaginary numbers. Algebra without the imaginary number i is more complicated. This number is not some extra ingredient whose existence is added; rather it is the consequence of the denying the existence of a superfluous and inconvenient rule against finding the roots of negative numbers. Mathematicians who denied i as repugnant were simply defending the faith-based existence of such a rule, which just "had to be". Now we take it for granted that investigation of rules can give rise to discoveries of new kinds of numbers.
Currently, we cannot show by observation (and probably never will be able to) whether there is just the one universe or whether there is an infinite number of universes. Neither view is falsifiable, and both are consistent with observation.
However, the multiverse view is simpler and less astonishing.
The claim that there is only one universe (or, say, some finite number of them) requires an explanation of why the remaining universes do not exist, why are the constants tweaked this way and not that, etc. The believer in the multiverse view is liberated from believing in arbitrary hidden processes and variables, and sidesteps the problem of infinite causality (essentially by embracing it in a different way).
The observation that constants in our universe are not tweaked to be optimized for life (at least as we know it) may be falsifiable, but it does not give us a hypothesis for the existence of everything, so it is not fair to compare it to TOE hypotheses, especially given that it's actually compatible with all these hypotheses (since they are consistent with observations).
If you try to watch it all the way through, you'll get diarrhea.
Why, do they play the brown note at the end?
http://en.wikipedia.org/wiki/Brown_note
I can "disprove" something by demonstrating that it relies on unprovable hidden variables which are not necessary.
If there are two equally unprovable hypotheses that explain something, the superior one is the one which relies on fewer hidden variables (ultimately, none at all).
Those who cling to an inferior hypothesis are irrational.
It may be impossible to determine the origin of the world (which necessarily will have to be the case if, for instance, it doesn't actually have an origin!).
It is possible that the best we will ever be able to do to explain the world is via an unprovable hypothesis. What is left then is to choose the best one.
A hypothesis which appeals to hidden variables, like a creator, is obviously inferior because it invokes recursion: it requires us to solve a problem which is equally as large: what created the the creator?
Any universe U with a creator C understood to be outside of U can be reified as a larger universe U+C which consists of the union of U and C. We know where U came from (it was created by C), but we cannot explain where U+C came from.
Religions get around this problem by asserting things like C didn't come from anywhere; C is infinite outside of time and space.
But these properties of C can simply be applied to U, eliminating the need for C. U itself encompasses infinities.
Asking where the universe began might be as silly as asking how far do we have to go to the left off the blackboard to find the spot where the function y = sin(x) begins its undulations.
But, in fact, the statement "we are not here" holds, when you define "here" as many of the infinite possible universes, which do not contain anything like us.
We only know the one "here" in which we find ourselves, our observations of what exists are biased by the lack of access to the infinite reams of universes.
If all possible universes exist, there is no need for creation, because creation would mean that only a few universes exist which are deliberately tuned.
Nobody creates mathematical axioms and the objects that spring forth from those axioms. The set of sets of axioms is infinite.
There is an obvious bias in the empirical observation of universes in that only the universes that contain conscious life get observed.
Conscious life is the means of which by a universe introspects. The universe gazes at itself through us.
Any universe which is sophisticated enough to give rise to conscious, thinking life will appear to that life as if it were created, until that life further improves the quality of its thought.
No, you misunderstand.
I want transparent aluminum which I can beat into a thin foil, and then wrap a potato in and pop in the oven!
Then I want to be able to crumple this aluminum into a ball, and use it as substitute fuse. :)
Just like Outlook, Explorer, ... :)
C++ exceptions are broken. An exception in computing is some event out of the normal flow of the program's execution which requires handling. For instance, a not-present page of virtual memory, upon a memory access to that memory.
During an exception, meticulous care must be taken to preserve the program state, for two reasons. One is so that the maximum information is available about what the processor was doing (in case the exception was caused by code). The other reason is to allow the program to be resumed where it left off, as one of the options for recovering from the exception.
The point of departure for C++ exceptions is the erasure of information. Once a C++ exception is thrown, a search for the handler begins. As the search progresses, information is thrown away (unwinding). All call frames between the handling site and the exception throw site are thrown away.
C++ exceptions are not really an exception mechanism but a dynamic non-local control transfer mechanism, which provides a way to escape from deep within some context without any intent to recover and continue.
C++ exceptions are debugger-hostile. If you stop the program where an exception is caught, there is no meaningful backtrace for investigating what happened; it's already gone. To catch the exception where it occurs, you have to put a breakpoint on every throw which might be causing it.
These dumb exceptions are suitable for writing system utilities which can follow the mentality of simply bailing when something goes wrong, so that some higher-level metaprogram (script) can notice the failed termination status and do the real handling.
I once wrote an exception library for C which is similar. It ended up being used in projects like Ethereal/Wireshark. I no longer endorse that library. Today, I would not design it that way.
The search for an exception handler must be done in a new execution frame, without discarding any frames. When a suitable handler is found among the call frames, that handler can then search the call frames for a restart point, as determined by that handler's recovery strategy. Once a restart point is chosen, only then does unwinding take place and a non-local transfer to that restart point.
This design allows the module where an exception is raised to provide ways to recover and continue.
The most recent (open source) project I have worked on is Txr (http://www.nongnu.org/txr/).
Even though I have tons of C++ experience, this is written in a dialect which compiles with either a C or C++ compiler, and does the same thing.
This dialect more portable than either C++-incompatible C or C-incompatible C++.
The main paradigm within the program is ideologically and esthetically incompatible with most of the extensions that C++ brings to C.
Wide portability isn't the only benefit. You get access to a wider range of diagnostics. There are things the C++ compiler might tell you that the C compiler won't, and even vice versa.
Many things that are banned in C++ are bad features in C or bad style of C coding. For instance, skipping variable initializations with a goto. Or lack of type safety in the handling of enum constants.
Programs in the "C/C++ dialect" benefit from these things being diagnosed without losing compatibility with C.
Here is another one: C++'s enforcement of type-safe linkage, the one-definition rule, and its banishment of obsolescent features, like calling undeclared C functions.
I get approximately the same code from GCC's C++ or C's front end. Benchmarks have differed between the two as much as between different versions of GCC.
These days, performance concerns are no longer valid as a reason for eschewing C++ in favor of C (except in provable circumstances with particular toolchains and platforms). However, the C/C++ dialect will let you port your code anywhere, choosing the best possible compiler. If some embedded target has a great C++ compiler, but a so-so C compiler, you can use the C++ compiler and vice versa. Even if you don't ship with the C++ compiler, you can use it for diagnostics.
"void *" is a stupid misfeature, which I avoid in all new C code that is written by me.
C++ never took away the automatic conversion from "void *"; it never had such a conversion. C perverted the "void *" idea by adding that conversion. As recently as last week, I ran into a void * bug. Some stupidly defined third party API defined an important handle type like this:
typedef void *handle_t;
A typedef for void * usually spells trouble. Anyway, one of the functions of this API is like this:
int api_init(handle_t *phandle);
the cleanup is:
int api_cleanup(handle_t handle);
The buggy program called both of them as api_init(&handle); and api_cleanup(&handle). Compiled without a peep, of course. C++ wouldn't help with this because this is a conversion to void *, not from void *.
In all new C code that I develop for my own projects, I now use some character type as a generic pointer-to-anything, and have explicit casts everywhere there is an unsafe conversion, in either direction.
The conversion from any pointer to object type to void * (allowed in C and C++) is itself braindamaged, because it gets you halfway to reinterpreting some memory without requiring you to confirm it or leave behind a piece of documentation in the code that can be easily spotted later (the cast).
C was better off before "void *", when malloc returned "char *".
In the Txr project (http://www.nongnu.org/txr/) I developed last year, I introduced "typedef unsigned char mem_t". After that, all generic pointers are "mem_t *". An allocator returns "mem_t *": All pointers other than unsigned char * have to be converted to and from mem_t * with a cast.
This works out beautifully.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation,
Great! That lets you combine the poor libraries of CommonLisp with the syntactic limitations of Python.
The performance is comparable to using C libraries,
It is possible to get C-like performance out of a CommonLisp compiler, but you have to jump through hoops to do it, and the necessary declarations are different from compiler to compiler (and sometimes even between versions).
Common Lisp has great libraries, and can easily call foreign API's. Lisp can call C functions, pass Lisp functions to C as callbacks. Lisp compilers have extensions that let you manage argument data right on the stack. Recently I needed to call some Win32 functions from Clozure, and found all the goodies there to do the job with minimal overhead.
Common Lisp declarations for type and optimization are part of the ANSI standard, and generally do the same thing across different compilers.
"possible to get C-like performance" (Lisp) is a heck of a lot better than "impossible to get C-like performance" (CPython, Ruby, ...). To get "C like performance" from C, you also have to jump through hoops sometimes.
Of course, I would like "same from compiler to compiler", but when that is not available, my next choice will be "different from compiler to compiler". My third choice after that would be "only one compiler", and an unfortunate fourth would be "no compiler" (CPython, Ruby).
Committees should standardize what is out there. Once that is done, they have achieved their purpose and it's time to disband.
The problem with the C++ committee is that their egos prevent them from going their separate ways.
Once a committee thinks that it is so important that it can start inventing new features and dictating them to the programmers and implementors, it is the beginning of a disaster.
Almost never should a draft language contain features that no compiler has. This should only happen very early in the standardization, when there is no other way to solve some conflict between dialects.
If you aren't aware of this debate, then I suggest you research the history of LISP. I've already covered this on another post. I'm not even sure where I stand on the debate as I can see points on both sides, but I'm not idiotic enough to pretend that there is no debate.
It's not about whether there is a lot of LISP code out there - there certainly is - emacs is full of lisp macros. AI research and mathematics use it heavily.
The debate is more about whether it fits the classic definition of a computer language.
Classically, computer languages are defined by a specific, usually fairly extensive grammar, whereas the LISP grammar is basically
expr: ID | STR | NUM | list
list: ( seq )
seq: | expr seq
Again, this is not to say that it's not powerful or to deride it's significance, but to try and explain why there is legitimate debate over what constitutes a programming language.
You are confusing formal languages and programming languages.
Programming languages are not simply syntax.
Programming languages have multiple layers of syntax. For instance, on one level, a C language program is a sequence of various kinds of preprocessor tokens.
Lisp has a lexical syntax (quite a bit more rich than the grammar you have given) and then it has a syntax within the forms produced by the lexical syntax.
For instance (defclass derived (base1 base1) (slot ...))) is syntax for defininig a class and (loop for x from 1 to 10 summing (* x x)) is the syntax of an expression which sums the squares from 1 to 10.
There is a lot of syntax you have left out. For instance #(1 2 3) is Lisp syntax for a vector. #c(1 2) is the complex number 1 + 2i. Then there is backquote syntax, which can nest arbitrarily. E.g. `(1 ,a ,b) is a quasiliteral which denotes the three element list consisting of 1, and the value of A and the value of B.
The legitimate debate you are alluding to does not exist. I've never seen anyone claim that Lisp isn't a programming language.
Common Lisp has an ANSI standard (look for it on the ANSI web store). The title is "Information Technology - Programming Language - Common Lisp".
You are hopefully now better informed.
Unlike Python (the principal implementation of it, rather) and Ruby, Lisp (which has not been spelled LISP since 1980) is a compiled language. Lisp implementations produce native code. Lisp libraries for cryptography, regular expressions, etc, are written in Lisp and are comparable to C libraries. Lisp is fast enough to be used as a systems programming language, and has been, including as an operating systems programming language. The system running on the Lisp machines was written in Lisp: OS, drivers, ...
Yet it is also suitable for making a web application.
Can you provide a URL to this "considerate debate" about whether "LISP" is a programming language?
Are you sure you couldn't live without static typing? Or could it be that you could not live with Ruby's immature, crappy dynamic typing?
Real dynamic languages have compilers that help discover type errors in your code, and also provide optional type declarations so that you can optimize.
C++'s declare-everything type system is 1960's technology. But at least it is mature. Don't compare mature type systems to toys; it's not fair!
Lisp is a compiled language, so you don't need C extensions so much, other than to call a foreign API. When you use CPU-intensive routines like cryptography, regular expressions, etc, in a Lisp program, those things are also written in Lisp. The performance is comparable to using C libraries, though Lisp programs can call C libraries easily, and Lisp routines can be passed as callbacks to C code.
Lisp supports the business model of writing a tamper-resistant proprietary application, distributed to users in binary form, just like C++.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation, which works by compiling the Python code to Lisp forms, which are then compiled by your Lisp compiler. Since Lisp is an extensible language, CLPython appears to you as a library that you add to your program, which then lets parts of your program to be written in Python.
How exactly does MySpace make money?
Does it really have a path to profitabillity?
Induction (not the mathematical kind, but generalization from particulars) and deduction are completely different beasts.
Induction works because the universe has been fairly kind to us so far by exhibiting regularity.
There is no /logical/ reason why anything should remain the same tomorrow as it is today: the charge of an electron, Planck's constant, etc.
Just our assumption that such things don't change has worked out so far.
Science is in fact logical (deductive) in its predictions in the sense that we can we add the regularity of the universe as a premise to the inductive argument to make it deductive:
"IF the universe will continue to permit us, as it has in the past, these generalizations from particulars, both in the direction of the (future behavior will be as past behavior) and space (the laws far away are as they are nearby), and IF we have such and such initial conditions, and such and such laws generalized from past observations of behavior, then the following shall happen ..."
If the universe suddenly does not permit the generalization, then the argument is still logically valid because of its deductive form.
One regularity of the universe is that rules derived from observing some situation tend to apply to similar situations: i.e involving events on a similar scale of time and space, energies on a similar scale, particle or other object sizes and masses of a similar scale, energy levels or field strengths of similar scales, and so on.
If you observe the motions of ordinary objects on Earth, you can make laws that apply very well to the motions of such objects, though perhaps not to sub-atomic particles, or bodies moving at relativistic speeds and so on.
We have been burned enough by generalizing to be suspicious of all generalizations. Are the fundamental constants the same everywhere in space? Etc.
But all such uncertainties can be stuffed in as assumptions to make the resulting claims deductive.
You could run this on a couple of Intel servers and a big RAID.
The 6502 was a piece of crap.
A great piece of tech, introduced just four years later in 1979, was the Motorola 68000.
This is probably the only processor worth studying, from that era.
Let's look at the 6502: eight bit registers only, and just three of them. 256 byte stack. 16 bit address space. Invalid opcodes execute strange actions instead of vectoring to an exception. Synchronous interfacing with no recovery: if a peripheral doesn't produce data within the clock period, the processor simply reads garbage!
By contrast, the 68000 gave us 32 bit data and address registers (well not all address lines useable in the first generation). Wonderful instruction set. Decent interrupt and exception handling for operating system development. Terrific interfacing with handshaking protocols for slower peripherals.
The only thing that's amazing is some of the cool software that was produced for computers based around chips like these.
What's also amazing is how long that 6502 lasted: how a processor introduced in1975, it continued to be used right up to the mid 80's for home computers. Unthinkable today.
What's amazing is the incredibly retarded follow ups too, like the 65C816 with its segmented memory model, well into the era of decent microprocessors.
The 6502 belongs in the same historic trash bin as the Intel 8086/88 and its progeny.
Censorship is a state-imposed publication ban, or requirement for alteration.
This is just some publishing company making a modified version of something in the public domain.
They are not interfering with anyone's ability to read the original.
Thanks to Project Gutenberg, anyone can download The Adventures of Huckleberry Finn and publish their own version.
If you don't like what some obscure publisher in Alabama is doing, make a HTML version in which racial slurs are in large, colored font, and put it on your web site in protest.