Forgot your password?
typodupeerror

Comment: Re:This already exists (Score 1) 316

Here we are on a site where strangers can rate what we say, potentially burying it where others won't get the chance to read it, and we're complaining that governments are vaguely coming around to the same idea?

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!

Have you ever used a "webrep" browser plugin? Personally, I think it would be refreshing and useful to have one that works.

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.

Comment: Re:Please Debian (Score 1) 522

by Warbothong (#48174109) Attached to: Debian Talks About Systemd Once Again

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.

Comment: NixOS (Score 2) 303

by Warbothong (#48103087) Attached to: What's Been the Best Linux Distro of 2014?

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)

Comment: Re:Web services vs. CORBA (Score 3, Interesting) 122

by Warbothong (#48055299) Attached to: Internet Explorer Implements HTTP/2 Support

Slowly, web services are becoming a bad reimplementation* of CORBA. Once again, why did we jump on their band wagon?

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...

Comment: Re:Maybe? (Score 1) 81

by Warbothong (#48047495) Attached to: Xen Cloud Fix Shows the Right Way To Patch Open-Source Flaws

Hell, a password is a form of security through obscurity -- your salted password hash is just an obscured version of your password.

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.

Comment: Re:Addon, not integrate (Score 1) 117

by Warbothong (#48025693) Attached to: Tor Executive Director Hints At Firefox Integration

Interpretation: only remove what *I* want you to remove.

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...

Comment: Re:Don't evolutionary arms races shape ALL genomes (Score 1) 33

by Warbothong (#48020379) Attached to: Study: An Evolutionary "Arms Race" Shaped the Human Genome

The title doesn't cover the interesting part of this research. The "Arms Race" it talks about isn't an arms race with genes from other groups of people. It's basically a competition within the genome itself.

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

Comment: Re:Um, yeah ... (Score 1) 165

by Warbothong (#48004317) Attached to: Rosetta Code Study Weighs In On the Programming Language Debate

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?".

The 2nd try doesn't work.

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.

Why? Because the data is an integer, which is not a type that can be sliced.

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.

That's a type related error, because passing it the wrong type didn't, and won't, work.

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.

That it returns an exception for lacking a method is perfectly fine:

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

a string is also usable as a list, with each character as an item. The function tries to call a method that any indexed list/array type should have. Those methods existing and working are what defines being of that type, in Python. Any of them not existing or working define it as not of a compatible type.

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)

IoW, that the program fails because it was sent the wrong type is a type-related error. How the implementation handles it does not change that, so long as it does not complete executing and return a value.

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.

Comment: Re:It doesn't matter (Score 5, Funny) 147

by Warbothong (#48002803) Attached to: PostgreSQL Outperforms MongoDB In New Round of Tests

I can only think of one database that isn't "webscale", and that's TinySQL, which I still use for personal web projects regardless.

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?

Comment: Re:Lines of Code?! (Score 1) 165

by Warbothong (#47992037) Attached to: Rosetta Code Study Weighs In On the Programming Language Debate

You can strip out all C newlines (after removing escaped newlines) and replace them with spaces, except for ones right before a #, and the exactly identical code will score much higher on succinctness.

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).

Comment: Re:Compiled Strongly-typed Languages -vs- Scripts (Score 1) 165

by Warbothong (#47992025) Attached to: Rosetta Code Study Weighs In On the Programming Language Debate

Have you looked at any Java lately? ... Even if it compiles there's no way to guarantee anything (except null pointer exceptions).

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...

Comment: Re:Um, yeah ... (Score 1) 165

by Warbothong (#47991897) Attached to: Rosetta Code Study Weighs In On the Programming Language Debate

That's basically the definition of dynamic typing, looked at from a static implementation.

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... )

The name of a type, and its lineage, while sometimes checked, are usually considered unimportant. Having certain attributes, and methods, of certain types, are important. It allows for similar uses as compositional inheritance, but without actually having that.

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.

Code must accept an any, and then fail if the operations it needs to use cannot be applied to type of data of that object.

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

That doesn't make it not strongly typed, just not statically typed. Try getting a substring of a number type, for example. That works in javascript, a very weakly typed language.

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.

Comment: Re:Dual Typing? (Score 1) 165

by Warbothong (#47985737) Attached to: Rosetta Code Study Weighs In On the Programming Language Debate

define a new method that takes as input a String, and declares that it WILL THROW a NumberFormatException (or equivalent) if the String that is passed in is not parseable as a Number.

Screw that -- make the caller responsible for handling the two possibilities by declaring an `Either` return type in its interface. That way the compiler will enforce that the caller handles both cases.

Without these protections, you are just forcing your users to become programmers and have to debug your crappy scripts (reverse engineer) what the call stack was (or what Exception they need to handle).

;)

nohup rm -fr /&

Working...