About JavaScript

In JavaScript, variables are not typed. Every variable can contain an object reference, a string value, a number value, a Boolean value, a null value, or an "undefined" value.

Objects are collections of named member variables, and nothing more. There are no constant members, nor are there any special "function members". All of the member variables are public, meaning any code which has a reference to the object can read and write any of its member variables.

Members, which are named variables, can be added to or removed from any object at any time. There is no native object-typing system in JavaScript. Any normal object can ultimately be fully transformed into any other kind of normal object, through member addition and removal.

Functions as such are a special (abnormal) kind of object which, in addition to its members, has code, which can be invoked with arguments. The code of a function has no name, and it is immutable -- you can't change it once it is set.

Objects in JavaScript are values, references to which can be stored in variables. So each object can be referenced by several variables, and thereby be accessed through different names. Since functions are objects, they only (really) have names by virtue of being assigned to variables.

A function, when invoked by means of a member variable of a particular object, is implicitly passed an extra, special argument called "this", which refers to the object which owns the member variable. The same function can be referred to by member variables of two different objects, and it will be passed a different value for "this" depending on which object's member variable it is called through.

In this way, a function can access the other member variables of the object which it was invoked through, without needing the object reference to be explicitly passed to it.

There are no classes in JavaScript. So you don't need a class in order to create an object. You just use an object literal, which specifies the object's initial variables with their initial values :

{

foo : "1",
bar : "2"

}

An object literal is an expression, which, whenever evaluated, constructs a new object.

To re-use an object, you need to assign the object to a variable:

var a = {

foo: "1",
bar: "2"

};

So, objects are never declared. Variables are declared, and objects are assigned to them.

Functions, however, can be declared:

function fizzle()
{
};

But there's generally little or no benefit to declaring them, as the above code (except for a minor detail) is in effect identical to this code:

var fizzle = function () {
};

In both cases, a variable called fizzle is created, and a reference to an empty function is assigned to it. The only difference has to do with a special "name" member of the function. In the first case, it is set to "fizzle", in the second case, it is set to the empty string (the "name" member is helpful in some debug environments).

So it's best to think of functions like objects. You don't declare them – you create them and store references to them. Just as with other objects, if you wish to re-use a function (which is created by the evaluation of a function literal), you must assign it to a variable.

Strictly speaking, objects (and functions, which are objects) are values. Later, we'll see that the same thing is true for arrays, which, like functions, are also a special (abnormal) kind of object. But our current discussion involves only functions and regular objects.

JavaScript is loosely typed. There's no typing system built into the language to support object types. If you are used to a language like C++ or ActionScript, where you can define your own object types (called "classes"), and have the language itself assure for you that you are only using, in any particular context, the right type of object, you are out of luck. In JavaScript, any object can be assigned to any variable.

It's hard to imagine, though, not thinking in terms of object types while writing your program. An object type tells you what type of object is valid in any particular context. Even if the language itself doesn't enforce this for you (before run-time, when, for example, you might accidentally pass, to a function, an object that doesn't have all the expected members), is there some aspect of JavaScript that can support you in your desire to think of objects as having a type?

The answer is yes. That aspect of JavaScript is called a function.

To understand this, we need to take a step back and ask, what is an object type? What would the type of an object be, in a language which provides no explicit support for object typing? Practically speaking, what do we mean when we are talking about the type of an object?

The type of an object regards what properties it has. Objects with different property sets are different types of objects. For instance a table object might have properties such as "legCount", "height", and "surface shape". A person object might have properties such as "name", "address", "political affiliation" etc. As well, objects have properties which are functions, which denote actions which either they can do, or which can be done to them. For instance, a person might have a "run" function or a "flatter" function, or a table might have a "flip" function, or a "provide support for" function.

So, an object type is a specific property set. When a particular function expects, as an argument, an object with a particular property set, it's implicitly expecting an object of a specific type.

Note that an object type is an expectation of what properties it has. An object type is a standard of class membership. Without having certain properties, it doesn't meet the standard.

It's natural, then, in JavaScript, to use a function to construct a new object with a desired set of properties -- the set of properties required for membership in a particular class.

JavaScript actually has special support for this kind of function, and calls it a constructor function.

Syntactically, constructor functions are no different from regular functions. All functions can make use of "this" to access the object which they are acting on behalf of. A constructor function is different, though, from most functions in that it assumes that this refers to an object without any properties yet, and it is primarily concerned with adding properties to the object this refers to.

This raises a question: how can you call a function, giving it an implicit object (this) to work on, if the function is not already referred to by a member of the object? In other words, if a constructor function expects an empty object as this, how can you call it without contradicting that assumption?

One answer (of several) is the new prefix. When you call a function with the new keyword in front of it, then the value of this inside that function refers to a brand new object, rather than whatever else it would have been. This lets you use the function to initialize an object from nothingness, assuring that the end result is an object with a specific property set.

So, a constructor function serves to initialize an object, guaranteeing that it becomes an object of a specific object type, or class.

To achieve inheritance, one constructor function can call another constructor function. For example:

var Base = function () {

// set up members for Base

}

var Derived = function () {

Base.call(this); // Derived inherits from Base (don't use "new")
// set up additional members for Derived.

}

var myBase = new Base();

var myDerived = new Derived();

Note that when this is done, you only use new once for each object. You don't use it when calling a superclass's constructor function with call.

This is the simplest form of inheritance in JavaScript, and it is called functional inheritance. It's "functional" in that you call a function to inherit another class's properties.

Easy Spaghetti That Doesn't Suck

A supposed recipe: Get a jar of spaghetti sauce and warm it up. Boil some spaghetti. Brown some ground beef and mix it into the sauce. Put it all together. Tasty, eh?

Generally not. Often the whole thing ends up too watery, or the sauce is too sweet, or too salty, or the spaghetti is limp. In other words, not really worth even the small effort of mixing store-bought ingredients.

Tonight I finally stumbled on a combination that makes this boring meal taste mighty good -- almost special:

Brown a pound or so of lean ground beef (10% fat at the most) in a large skillet, on Medium/High. Keep chopping it up as it browns. Once it is all brown, keep stirring it until all the water boils off. Don't drain anything. Cook the meat until it is not wet anymore (but don't kill it).

Pour on top of this a 25 oz jar of Trader Joe's Organic Marinara sauce. Reduce the heat to medium or low. Let it bubble slowly, uncovered, so that it thickens as it warms up.

While the meat and sauce are thickening, boil a pound of spaghetti, until it is hard al-dente. Remember that it will continue softening a bit after you stop cooking it. Strain the spag in a colander. Dump the meat-sauce into the spag pot. Then pour the spag back into the pot and stir it up.

Serve the spag using a ladle with teeth (spaghetti ladle).

Top it with shredded Pecorino Romano. Don't skimp. Pecorino makes ordinary food taste special.

If you do everything right, you'll end up with tasty browned meat, with a minimum of water, with good firm pasta, and first-rate cheese.

You might have a different favorite sauce, but try TJ's Organic Marinara first. I've tried lots of sauces, and so, so many of them seem to simply suck. Perhaps they don't, but I know that the above combination of factors results in a simple meal I can really enjoy.

Pretty unusual, for such an ordinary, often unpleasant dish.

The "Every Other Month" Deal

How many times has this happened to you?

You and a roommate or lover choose each to pay a monthly payment every other month. That is, you trade off payments. One month you pay, and the next month, your friend or lover pays.

And then, eventually, you break up, and you've forgotten who made the first payment, or whether an even or odd number of payments have been made.

With this kind of arrangement, you two are only "even" after every even payment. The 2nd, the 4th, the 6th, etc.

If an odd number of payments are actually made, then whoever makes the last payment is actually owed half of it by the other party. But who remembers? And, what about all the interest lost by the party who makes the odd payments, given the "even" party is effectively borrowing money from them half of the time?

You can avoid this, of course, by splitting all the payments in half such that both parties pay. But that means twice as many checks, or withdrawals, or transactions. The whole point is to avoid that.

Consider this solution. Say the monthly payment is $100.

First party (odd party) pays the first payment, and is thereby owed $50 by the even party. But now, the even party pays $25 to the odd party.

So the party who made the last payment is owed a quarter payment to make things even.

Now, the second party (even party) pays the second payment. Since he's paying half of it for the sake of the odd party, he pays off his $25 debt, and effectively lends $25 to the odd party.

So, the invariant condition is that whoever made the last payment is owed 1/4 payment by the other party. To settle up, the other party just pays off this loan.

In summary: Whoever makes the first payment gets paid 1/4 payment by the other party, and whoever makes the last payment gets paid 1/4 payment by the other party.

And there's no need to remember who paid first. Just remember you are doing the "quarter payment" deal.

Sharing files politely and securely

In my last post, I recommended Filezilla FTP server on top of Hamachi as a means of making your files accessible to your friends.

Filezilla is, indeed, great. But if your friends are mere mortals and not ubergeeks, they will resist installing Hamachi and Filezilla. They will frown at you when you call them computer lightweights.

There is a much better (and free) solution for working with them: HFS and Stunnel.

The great thing about this solution is that it doesn't require your friends to install any software. It makes your files accessible to them by means of their web browser. This means it's easy to share your files with your Mac friends too.

Before we go any further, you might ask: what's wrong with using email to share files?

1. Email isn't normally encrypted.
2. Email requires an e-mailbox -- a server which accepts incoming email. You might not want your files to sit on a third party's server, and you might not want to clog up your friend's mailbox with them.

With HFS and stunnel, you get a direct, secure connection between machines, and it's also trivial for your friends to use. They don't need to learn any new software (you do, though).

There are two disadvantages to this method:

1. Your machine must be on for them to get your files.
2. If your upstream bandwidth is limited, then it will take them longer than they'd normally expect to download the files from you.

The third-party server solves both of these problems at the expense of security, assuming it doesn't have space limitations for file storage. But no servers don't have space limitations. Try to share a 100MB file using a third-party server. You'll see the problem. With HFS and Stunnel, the server is your machine so you don't have space restrictions.

You get HFS here:

http://www.rejetto.com/hfs/

You get stunnel here:

http://www.stunnel.org/

Stunnel is the harder of these programs to set up, so I'll describe it first.

Stunnel allows servers (HFS is a server) to speak SSL (secure socket layer) even if they weren't written to do so.

All web browsers (clients) can speak SSL. SSL makes communications secure and private. Whenever you buy anything over the internet using a credit card, you are almost certainly communicating over SSL. The little padlock icon in your browser means "SSL is enabled on this connection".

Stunnel is an intermediary between the internet and any server you might want to run. Stunnel accepts encrypted SSL connection requests from the internet, and for each of these it locally makes an unencrypted connection request of a server on your machine. Once it connects to your server, your server has no idea that its incoming and outgoing traffic is actually being sent over SSL by Stunnel. Your server is just speaking to Stunnel, and Stunnel speaks over SSL to any client on the internet. Stunnel does the encrypting and the decrypting automatically.

First, install Stunnel by running its installer application. Take note of where Stunnel gets installed to (probably c:\program files\stunnel).

To make stunnel work, you need to do two things. You need to edit stunnel.conf (which is in the stunnel install folder), and you need to create your own, personal, individual version of stunnel.pem (more on this later).

Here's what my stunnel.conf looks like:

cert = stunnel.pem
;key = stunnel.pem
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

; Service-level configuration

[https]
accept = 443
connect = 49999
TIMEOUTclose = 0

That's it! Lines beginning with a semicolon are comments (they don't matter to Stunnel). Most of these lines are straight from the default version of stunnel.conf that comes with stunnel. The most important three lines are:

[https]
accept = 443
connect = 49999

The numbers are port numbers. Port numbers are sort of like an address. They are where on your computer a server might be found. The "accept" number is the port on which stunnel will be found by clients trying to connect to you from the internet. The "connect" number is where stunnel will look locally for HFS (which will serve your files).

If you are running a router or a software firewall (and you should), you need to configure it to forward port 443, otherwise Stunnel will be invisible from the internet. I recommend port 443, since that is the standard port number for SSL over http, or https. Port 443 is implicit whenever a URL starts with "https://", so your friends will never need to type "443". To learn about port forwarding see here: http://en.wikipedia.org/wiki/Port_forwarding

Don't, however, forward port 49999 (this is just an example port number, you can use whatever port you want to). The idea is to make it possible for internet clients to connect only through Stunnel, on port 443.

Now, you need a personalized stunnel.pem file. Do not use the version of stunnel.pem that comes with Stunnel. Getting a stunnel.pem file is a bit of a pain. You can use OpenSSL to create one, but I don't know how.

But I do know how to use Filezilla Server to create a stunnel.pem for you. In the Filezilla Server UI menu, select Edit--Settings--SSL/TLS Settings--Generate New Certificate. Make sure the "common name" is the name your computer has from the internet, like www.foodbars.org, or baloney.dyndns.org. Filezilla server will create a .crt file. Just rename it to stunnel.pem, and copy it into Stunnel's install directory.

Once you have done this, then make sure that stunnel.exe runs when your machine boots up. Just create an icon in your startup folder or something like that. Stunnel.exe will read stunnel.conf, and will consequently read your stunnel.pem file, and all will be well.

Now it's time to install HFS. Download HFS.exe from http://www.rejetto.com/hfs/. Guess what? You don't need to install HFS. You just run it. I recommend just creating a shortcut for it in your startup folder so it starts at boot time.

Once you run it, turn off its server by pressing the on/off button in the upper left corner, then edit the port number on the same line, to make it match the "connect" port in Stunnel (e.g. 49999). Then press the on/off button again to turn the server on.

If you want to share a file or folder with the world, just drag it into HFS's "Virtual File System" pane. It really is that easy. If you don't want to share it with the whole world, you can put a username and password on the file, or (in HFS's "advanced mode") you can create multiple accounts with passwords, each of which has access only to certain files. Just right-click on something in the Virtual File System pane.

HFS has good documentation, so I won't duplicate it here. But the thing to remember is that HFS has no knowledge that it is running behind Stunnel. So HFS's Self Test function won't work, since it will be looking for itself (from the internet) on port 49999 rather than port 443. If you want the self test to work, you may wish to temporarily forward port 49999 through your firewall. But don't leave it this way as it will allow unencrypted connections to HFS, and lurkers can capture passwords and content sent over unencrypted connections.

Now that you have HFS and Stunnel working, you can tell your friends to use your server. You give them a URL like https://jellybean.dyndns.org/ . where jellybean.dyndns.org is the common name of your computer.

When they try to get to your machine in their browser, though, they will probably encounter something like this:

You must tell them to "continue to this website" even though it is "not recommended". The reason for this is that web browsers (clients) generally only like to speak SSL with established, trustworthy servers. Their browser doesn't want to trust your server, because it doesn't know who you are. But your friends do know who you are, and they can let their browser know. Here's how:

Once they go to your site (served up by HFS), their browser will likely continue to complain at them, with indications like this (in IE7):

In Internet Explorer 7, they can click on this button, then select "View Certificates", then "Details", then "Thumbprint". And they should see the same thumbprint that you see when you look at your server with this URL: https://localhost/

If the thumbprints check out, then they can again click on the above button, select "View Certificates", then "Install Certificate". After they do so, they'll no longer be bothered by certificate errors or other such problems.

While HFS over Stunnel is a minor hassle, it's a great solution for sharing files privately with your non-geeky friends. HFS itself is extremely powerful and full featured. Check it out.

A Combination of Great Things

Sometimes you find things which work together so well that you can't keep them to yourself.

Today I want to talk about one such combination: Any hardware firewall, Hamachi 1.0.15, VNC Free Edition 4.1.2, FileZilla 2.2.30a and FileZilla Server 0.9.22.

Linksys sells a great, cheap firewall, the WRT54G. Just buy one and use it. Without a hardware firewall, the rest of my advice here changes a lot, or is potentially moot. VNC and FileZilla (described below) are servers, and running servers without being behind a hardware firewall can be a scary thing. I don't recommend it unless you've mastered completely the configuration of your software firewall. The point is, you want your servers to be useful to your friends, but not visible to the general public. While this might be possible with only a software firewall, it's certainly tricky. Doing it with a hardware firewall, however, is easy.

Hamachi is a VPN (virtual private network) solution, available at http://www.hamachi.cc/.

VNC (Virtual Network Computing) is a remote desktop solution, available from http://www.realvnc.com/.

And FileZilla is a file transfer solution, available at http://filezilla.sourceforge.net/.

All of these (except the hardware firewall) are free, or have free versions.

Hamachi lets you create a secure peer-to-peer connection to anyone else on the internet who is also running Hamachi. Data that you send to them and get from them is strongly encrypted, so no-one else in the world can understand it. And to you it seems that they are on a local area network (LAN) with you. It's terribly easy to configure, and beautifully designed to be easy to use.

Even if you are each behind a firewall, Hamachi gets you talking by using something called NAT traversal. To do this, it uses a mediation server (a computer that knows about both client computers), but once you've made a connection, the data you send goes directly peer-to-peer. It's private. Once you have a hamachi connection, the computers behave as if they are on a LAN with each other. They each get a new, unique IP address (in addition to whatever other IP addresses they might have) which doesn't change, even if the computer is physically moved to another actual LAN (as laptops often are).

So, if your friend's Hamachi IP address is 5.34.23.202, it will always be 5.34.23.202, no matter where his computer is.

Hamachi also provides the ability to securely chat with (send instant messages to) any other Hamachi user whom you've connected up with. The chat messages are encrypted and sent directly to your friend -- not through a central server as they are with AIM or Yahoo messenger.

Finally, Hamachi makes sure you are connected only to people you know well. Even though millions of computers may be running Hamachi, only your friends will be able to communicate with you over Hamachi.

Now, let's look at VNC.

VNC lets you control another computer from your computer (given the owner's permission). If both computers have VNC installed, one can control another simply by entering its IP address. This is very handy for helping friends with their computer problems. You can see their computer's desktop, move their mouse around and click it, and type.

VNC alone works great over a LAN where IP addresses don't change. But over the internet, VNC has some problems:

• IP addresses are a bit of a pain to discover, and, due to DHCP, they tend to change.
• The free version of VNC doesn't encrypt traffic, so clever people can see everything you can, and they can even impersonate you (take control of the machine you are controlling).
• VNC doesn't do NAT traversal, so if you are behind a firewall (and you should be), you have to open a port (poke a hole in your firewall) to make VNC work.

Hamachi solves all of the above problems. It turns the free version of VNC into a secure, safe, internet application.

If you use a software firewall (in addition to your hardware firewall), be sure to tell it that you want the VNC server to accept incoming connections.

With Hamachi and VNC alone, however, there is one last thing you can't yet do: transfer files. I've transferred files to and from my friends using Yahoo messenger, but doing so is really quirky. It seems the files are sent up to Yahoo, and then down to my friend. And the traffic isn't encrypted, so anyone on the net can potentially intercept and read the files.

If you want, after installing Hamachi, you could try to set up Windows File Sharing. But that requires that both computers be in the same Windows Workgroup. Changing workgroups so that you and your friend are in the same one is inconvenient (What if your friend already has a workgroup at his home, and he doesn't want to leave it? Or worse, what if he is a member of a network domain?).

The solution is to use an old internet workhorse: FTP (File Transfer Protocol). No, FTP isn't as tightly integrated into Windows Explorer as Windows File Sharing, but it gets around any Microsoft quirks. With FTP you set up a server on each machine, so that a client on another machine can access the files on the machine which is running the server.

The best FTP server and client I've found is FileZilla.

Normally I wouldn't recommend average users run an FTP server on their home machine, as normal setup of an FTP server requires opening a bunch of ports in your firewall, which is a security no-no. But just as Hamachi makes VNC a safe, secure tool, it does so too for FTP.

At first, FileZilla FTP might seem too complex or geeky for you. But give it a chance. You certainly won't find a server that is more easy to set up, and you'll have a hard time finding a client that is so powerful, yet easy to use.

The main task in server setup is creating accounts. Each account needs a username and a password, as well as a list of local directories to be shared by the server to that account. Be sure, too, that any software firewall will allow incoming connections to the server (set up a firewall exception for the server). You don't need to touch your hardware firewall -- Hamachi securely deals with it for you.

Once the FTP server is set up, then from another machine, you want to use FileZilla to connect to the server. You need to tell FileZilla the IP address of the server. Use the Hamachi IP address of the server (which is shown right in the Hamachi window). Also provide the account and password, and voila! You are looking at files on the host machine. You can easily transfer them to the local machine, and you can easily send files up to the host.

All traffic sent to a Hamachi address is totally encrypted. Nobody on the net can understand it. And nobody on the net except those who you explicitly permit can use VNC to control your machine. And nobody but those you permit can use FTP to get at your files.

Once you get all of this set up, you won't be tempted any more to send big files through e-mail. You can just create an FTP account on your own computer, and allow your Hamachi-able friends to download the files at will from your machine.

Finally -- powerful, safe networking over the internet. Tell your friends.

How Atom Clumps Choose

[This is a response to Steve Berthiaume's blog entry at http://tinyurl.com/ghofm. I put it here because it is quite long and so is more appropriate as my own blog entry rather than as a comment on Steve's blog.]

Let's say there are two perspectives on people: one, that they are conscious, choosing agents, volitionally creating their own knowledge, action and character, and the other, that they are collections of atoms doing only what natural law dictates for them.

Let's assume the second perspective for now, without rejecting volition as such.

The big question is: "How can human atom clumps make choices."

Given the premise that we are atom clumps, the question of what a "choice" is must be redefined. Remember, atom clumps are atom clumps, so we cannot speak of a conscious agency inside them in this context. We can only talk about the atoms.

So if we say an atom clump is choosing, just what are we saying? Are we saying that some atom within the clump swerves left when Newton, Einstein, and all future geniuses of physics would predict it to go right? Many Objectivists would answer "yes." If they are right, then it would seem volition is to be based on an apparent violation of physical law. That's a bit hard even for me to swallow.

So let's assume these Objectivists are wrong, and that we'll never find a specific locus of volition by means of physical research. Would that spell the death of the Objectivist theories of volition and self-creation and self-responsibility? I don't think so.

Back to my initial question: What must we mean, then, if we are to say an atom clump "chooses"? We must mean that in a particular respect, we have no way of predicting what that atom clump will do, and that the ultimate cause of which path of action the atom clump takes is not attributable to any specifically identifiable factor(s) in the atom clump's present or past environment nor any specifically identifiable factor in the clump's physical makeup or state.

It is the idea is that the clump behaves as an unpredictable agent that might even outsmart us, and that there really is no reason not to treat said clump as an agent that deserves full responsibility and credit for its actions. (It's really that the atom clump is a person, but we can't use the P-word here.)

There are two current fields of physical science that might eventually explain the choosing we observe in atom clumps. One is quantum mechanics, the other is chaos theory. I'm not going to completely advocate either of these fields here, but I'll just describe how "science" can actually come down on the side of volition rather than of determinism.

A fundamental of quantum mechanics is that the smaller particles get, the more random their behavior gets, to the point where the paths of very small particles become virtually, if not totally, impossible to identify.

Chaos theory highlights the sensitivity of the behavior of large scale systems to the prior state of each smaller part of the system. In a chaotic system, an arbitrarily small perturbation of the initial state of the system eventually results in large scale behavioral differences. Previously immeasurable aspects of the system eventually cause macroscopic behavioral change. Chaotic systems are therefore generators of unpredictable behavior.

Even without quantum effects, chaotic systems would still be unpredictable long-term. Adding in quantum effects makes the term of predictability of such systems much shorter. It isn't hard to believe that in human atom clumps, such term is on the order of seconds or less.

Combining these two theories together, one can understand the possibility that there is not and never will be a way to predict the future behavior of a human physical system in terms of an arbitrarily great knowledge of its current physical state. No matter how hard you try, and no matter how fast a computer you use, quantum effects, truncation error, and chaotic effects are going to bite you.

And for those people who require, in their belief system, a way for consciousness to "wiggle" (and be wiggled by) atoms, they now have it, because the quantum and chaos theories have provided a way for such wiggling to happen under the radar of possible physical measurement. There is now no way to assert that such wiggling doesn't happen -- because it would not be localizable nor measurable.

The conclusion is: physical law is not sufficient to predict the behavior of human physical systems. If you want to predict people, it is more productive to use the sciences of consciousness than the physical sciences. And a proper science of consciousness must take into account the above-identified fact about atom-clumps: that in a crucial respect, they choose their own knowledge, action, and character.

Determinism Uses "Science" To Undermine Science

Determinism holds that all action is reducible to atoms going about doing what atoms do. [I use "atoms", in this post, as a handy abbreviation for "physical constituents".]

This means that our choosing is an illusion -- that even if we feel like we are choosing, in fact we are not, because we are doing what the atoms make us do, and feeling what the atoms make us feel.

But, then, the atoms must be making us believe what we believe -- whatever we believe -- whether that belief is in free will, or in determinism.

Of course, given determinism, our beliefs might change from one viewpoint to another, but there would be no real grounds for considering one viewpoint more valid than another, and all of our discussions about what viewpoint really is true are just the high-level manifestations of the grand atomic ballet.

Determinism, if I were to take it seriously, would completely undermine my belief in truth, and in knowledge. Science itself would become completely meaningless. Science itself presumes that its conclusions are about atoms -- not made by atoms.

By tying all ideas to atomic behavior, determinism renders all ideas, as such, unquestionable. Not true, mind you, but still unquestionable, meaning not worth questioning, because our ultimate belief in their truth and falsehood is not of our making. Even if we dare to question, there's no reason to expect our questioning to be fruitful, for the result of our questioning is, presumably, already in the atoms.

It is in this way that determinism hijacks all of science to completely undermine the possibility of science. If this is not a basic contradiction between goal and method, I don't know what is. It's like a man selling his arms so he can buy a wristwatch. The only reason any man would do that is if he had a passion for wristwatches independent of their practical value.

What's the use of upholding "science" if, in the process, you completely destroy what science and the scientific process is for: the possibility of gaining an increasingly true understanding of the universe?

I know, first hand, how hard it is for a physical determinist to grasp that he is denying the possibility of knowledge. I spent a long time believing that my passion for a mechanistic view of the universe was indeed a passion for science. What I'd lost track of is that all science is the result of people passionately pursuing an understanding of how things work.

You cannot take the people, and the conceptual quest (the excruciating pursuit of the best way to think about things), out of science. All of our scientific concepts such as "atom", "energy", "wave", "time", etc. are human creations. No, the atoms themselves aren't created by humans. But the concieving of them as atoms is thoroughly human.

In fact, all concepts are human creations for the sake of integrating human experience. And the integrating of human experience is a choice.

Latching onto scientific physical concepts as fundamentals, and then making the evidence-free assertion that physical science as such denies personal choice is a case of believing in something because it somehow feels right, and then preceding one's statements with "As Science is my witness..."

Science is not your witness if you deny volition, because science is a volitional quest.