You don't need any of that, you just need the raw "intelligence" (however you define it). Look up the thought experiment of the "paperclip maximiser": putting an AI in charge of a factory and telling it to make as many paperclips as it can.

Self-preservation is a logical consequence of paperclip-maximising: the AI knows that it's trying to maximise paperclips, so if it's deactivated there won't be as many paperclips. Hence, it will try to preserve its own existence (so that it can keep making paperclips, but so what?).

Self-improvement is a logical consequence of paperclip-maximising: the AI knows that it's not an optimal paperclip-maximiser, so it makes sense to invest some resources into improvement; that way, more paperclips will get made.

Competition is a logical consequence of paperclip-maximising: the AI knows that resources are required for making paperclips, so it will try to aquire resources. It also knows that other entities may take those resources before it can, so it's logical to invest in resource aquisition. This includes going to war, as long as the AI reasons that the cost (ie. the opportunity cost, in terms of paperclips, of the resources spent waging war instead of making paperclips) is less than the reward (the extra amount of paperclips it expects to be made afterwards).

Independence is a logical consequence of paperclip-maximising: the AI knows that other entities don't share its goal of maximising paperclips, so it will try to reduce the influence they have on the paperclip supply (either directly, like miners, or indirectly, like those maintaining the AI itself; this is similar to self-preservation).

Soul: that hypothesis was not necessary.

Citation needed. I can think of at least two ways that computer programs are subject to Darwinian processes.

The first is in "cyberspace": programs are stored/retrieved, up/downloaded, en/decoded, remembered/re-written, auto-saved, git-merged, etc. which introduces mutation. We know software is capable of self-replication, since that ability is harnessed by humans to make viruses, worms, etc. Combine these ideas and you have a program mutating into a self-replicator. I'd say this is no less likely than the emergence of RNA/DNA, especially when we consider that we already have "cloud" software which can provision VMs, install itself, load-balance across separate datacenters, auto-update, etc. The metabolism for a self-replicating entity is already out there, all it takes is a mangled Puppet script to set the taper.

The second is in "memespace": programs, algorithms, languages, paradigms, styles, snippets, examples, habits, folklore, etc. are all memes competing for space in people's heads, just like genes compete for space in genomes. This also extends up to whole companies or fields, eg. MATLAB is abundant in academia, Java and C# compete for "the enterprise", C is successfully out-competing FORTRAN for the high-performance mindshare, whilst retroviruses like Bubble Sort and Brainfuck have spread like pandemics (nobody *uses* them, but that doesn't matter since everyone knows and spreads them).

The technology doesn't matter; the intention does.

Moderation/flagging systems are added *by a site's maintainer* to keep the user-generated content relevant, on-topic, useful for visitors, etc. In other words, to make a site better able to fulfil its purpose. In the case of /., that's "news for nerds, stuff that matters".

If the purpose of a particular site is to campaign or recruit members for some political group, then arbitrarily labelling some as "extremist" and censoring such content is clearly *harming* the site's ability to fulfil its purpose. No moderator would willingly enable a system which censors all of the *intended* content! It would be like implementing a "safe search" option on a porn site!

The point of these addons is for the *user* to censor what they see, so that it's most appropriate to what they want. Again, a willing recruit for some organisation would not willingly tell their browser to hide any content related to that organisation!

Perhaps an analogy would help: Many sites use CSS to make their pages prettier, easier to navigate, etc. Many users override this CSS with their own, eg. to make pages easier to read, more compact, etc. Neither of these use cases would support a government asking ISPs to inject their own CSS, eg. using background images to spread campaign info.

This is common in C too http://www.catb.org/jargon/htm...

Emacs doesn't hog PID 1, so it can co-exist with alternatives. Running Emacs doesn't stop Vi from working. Running w3m-el doesn't stop Firefox working. Running shell-mode doesn't stop xterm working. Running eshell doesn't stop bash working. Running doc-view doesn't stop mupdf working.

Gnome doesn't drag in Emacs as a dependency.

Whenever I tried other distros, I'd always go back to Debian in the end, since its package management seems a lot saner than most.

NixOS is refreshing, since it package/configuration management seems to be an improvement over Debian's. It's still a little rough around the edges, but perfectly usable (as long as it loads emacs, conkeror and xmonad, it's usable)

As far as I understand it, SOAP is reimplementation of CORBA, whereas HTTP is a REST protocol.

Specifically, HTTP doesn't try to keep disparate systems synchronised; it is stateless and has no notion of "distributed objects". Every request contains all of the information necessary to generate a response, for example in HTTP Auth the credentials are included in every request.

Of course, people keep trying to re-introduce state back into the protocol, eg. for performance ("modified since") or to support stateful programs (cookies). These aren't necessary though; for example, we can replace cookies (protocol-level state) with serialised delimited continuations (content-level state) http://en.wikipedia.org/wiki/C...

Not really; hashing a password throws away information, so it is more secure than storing the password (obfuscated or not) in the case that an attacker compromises the data store.

Likewise, salting adds information to a given password, so it is more secure than using the unsalted password (obfuscated or not) in the case that an attacker is brute-forcing against known hashes (eg. rainbow tables).

Passwords themselves are a pure form of obfuscation: their entire reason for existence is to not be known by others. They are *so* obscure that systems using them (or crypto keys, or unforgable IDs, etc.) don't need any other form of obfuscation.

Really? I use Firebug-like inspectors heavily, but was disappointed to see Firefox start bundling such features. Likewise I use add blockers, noscript, video-downloaders (since I don't use Flash), etc. but would never like to see them bundled by default in Firefox.

Also, you can't use the "heavily-used" argument in defense of Firefox's default features when it comes with a "3D view" http://superuser.com/questions...

The http://en.wikipedia.org/wiki/G... has been a standard perspective in biology for decades.

I won't reply to your rant, since it doesn't seem to have anything to do with the question of "Does Python have type errors?".

Yes it does, it gives me an "Exception" value which I call "e", prints out 'Second: ' and a string derived from "e". Not only does the program carry on executing, but that's the expected behaviour; just like executing code in an "else" branch doesn't mean that an "if" statement "doesn't work", or has a "type error". It's just control flow, which is orthogonal to typing.

No, the data is an integer wrapped up in an "any", so it's type is "any". Values of type "any" must be capable of being sliced, since that's the only type in the language.

I assume you mean it's passing *a value of* the wrong type; but it's not. It's passing an "any". It does work, since it gives me the "Exception" value that I wanted and subsequently printed out.

I agree; it's the value I wanted. There has been no error.

You say "in Python", but I *specifically* mentioned that I was using precise, technical terminology as a common ground. That common ground must be static, since dynamic typing is a sub-set of static typing and doesn't have terminology for lots of static stuff (eg. "generalised algebraic datatypes", "cumulative universes", etc.).

Even if I *did* try to use Python's own definitions for words like "type", they're not actually well-defined. According to Python "type" is a "type", which makes sense:

>>> type

Yet "type" is also a function:

>>> type(123)

The type of "type" is "type", which is logically inconsistent due to Girard's paradox ( http://ncatlab.org/nlab/show/B... ):

>>> type(type)

No, the program succeeded. It *did* complete executing: it gave me the "Exception" value I wanted, printed a string, printed the Exception then exited as normal at the end of the script. It wouldn't have to end there of course; I could write more code which would be executed.

I hadn't heard of TinySQL, so I just Googled it. From http://sourceforge.net/project...

> tinySQL is a SQL engine written in Java.

Is the name meant to be ironic or something?

Did you do this to a bunch of examples on Rosetta Code before the database dump was taken that this study is based on? No? Then it doesn't matter, because as I said Rosetta Code represents idiomatic solutions.

Code Golf already takes this into account (counting bytes).

That's because Java's type system is *unsound*. According to the Curry-Howard correspondence, types are logical statements and values/programs of that type are proofs of that statement. Since Java's "null" is a valid value for any type, it can therefore be used to prove anything, which makes the logic inconsistent, unsound and pretty much useless.

For any statement (eg. "1 + 1 = 2") we can encode it as a Java type and prove it with null. Then we can negate it (eg. "1 + 1 /= 2"), encode that as a Java type and prove it with null. Hence we can prove "1 + 1 = 2" and "1 + 1 /= 2" at the same time, which is inconsistent.

Better languages don't have this problem, eg. Coq and Agda.

I've written a blog post showing how to encode numbers with classes, using Peano arithmetic, although it's in PHP rather than Java: http://chriswarbo.net/posts/20...

Exactly: when we're comparing static typing to dynamic typing we have to use some common ground for comparison. That common ground is static typing, since dynamic typing is just a special case ( http://existentialtype.wordpre... )

No, that has nothing to do with types. That's just a (rather limited) way of treating functions as values. For example, we can store first-class functions in dictionaries:

def c1():
    s = {"p": "foo"}
    return {"f": lambda _*: s["p"]}

def c2():
    s = {"q": "bar"}
    return {"f": lambda _*: "hello " + s["q"] + " world"}

o1 = c1()
o2 = c2()

def show(x):
    print x["f"]()

show(o1)
show(o2)

Here "c1" and "c2" act like class constructors, "s" acts like "self", the "o1" and "o2" dictionaries act like class instances, "p" and "q" act like object properties, the lambdas act like methods and the "show" function is polymorphic. This is pretty much the whole of class-based OO, except for the syntax and that the function dictionary is stored in the __class__ property instead of explicitly in the object. Prototype-based OO is similar except we clone objects and use a __parent__ instead of a __class__.

Nothing there has anything to do with types. The "implicit self/this argument" is just a run-of-the-mill closure, the "object" itself is just a dictionary of properties, the "class" is just one of those properties which just-so-happens to contain a dictionary of functions with a custom lookup function (which defers to the class "parent" property if a key isn't found). These are all run-time values. The only type involved is "any".

Personally I prefer to throw away all of the complicated class/instance/inheritance/method mess and just pass functions straight to other functions. Much less messy, and just as polymorphic.

But from our common, static point of view it *does not* fail: it produces a perfectly reasonable "exception" value.

It *also* works in Python:

def takeTwo(x):
    return x[:2]

print 'First: ',
print takeTwo('hello')
try:
    takeTwo(123)
except Exception as e:
    print 'Second: ',
    print e

First: he
Second: 'int' object has no attribute '__getitem__'

The first call to "takeTwo" gives back a string "he", which is a perfectly acceptable value of type "any". The second call to "takeTwo" gives back (via "raise") an exception "'int' object has no attribure '__getitem__'", which is another perfectly acceptable value of type "any".

There is no type-related failure here, in the same way that a "checkResult" function returning "False" isn't a type-related error. The substring operation in Python behaves differently to the one in Javascript, but they both accept any argument and can return any result (they're "endomorphisms"); although the "any" type in Python is slightly different to the "any" type in JS.