11ren

    fat:   "tall is Life"
    small: "tall is Death"
    tall:  "tall is Dungeon"

Now, one of the other two must be Life (because tall isn't), and so one of them must be telling the truth about tall. He's called Death and Life, so he must be one of them. We know he can't be Life, so tall is definitely Death.

Whoever called him Death was telling the truth, and must be Life. Only small called him Death, so small is Life. (edit I should have said: Life must be telling the truth about him, so if only one of them does that, that one is Life).

And the remaining guy - fat - must be the remaining knight - Dungeon. Dungeon can lie or truth, so it doesn't matter what he said (in fact, he was lying: he said tall was Life, when tall was Death). It only mattered what he said so we could distinguish between him and small.

    fat   is Dungeon
    small is Life
    tall  is Death

That said, I kind of like the weird names, esp grep. (Wasn't that in Stranger in a Strange Land or something?)

But I do object to inconsistent options. One example is: mkdir -p a/b/c This will make all three nested directories, if needed; but there is no equivalent: mv -p x a/b/c/y There also isn't: cp -p a/b/c [1]. You have to create the nested destination directories (a/b/c) first.

[1] cp has a -p option, but with a different meaning...

BTW: It would be nice if HackerNews had the `` markdown of Reddit for inline code. There's been a bit of code sharing recently, and I like that in a "hacker" site.

A danger I've found with patenting is that it encourages a competitor-focus (attack and defend), instead of a customer-focus (making a difference, creating something needed).

Patenting has similarities to a research thesis - articulating the idea helps you understand it; researching prior art contributes to your store of ideas.

http://www.paulgraham.com/softwarepatents.html

Don't get me wrong: I like the intellectual challenge, and I especially like the Haskell community - they are nice people, excited about what they're doing, very helpful, and just not interested in putting down other languages - and I think there is real beauty in Haskell. It's like a branch of mathematics.

Disclosure: I'm terrible at Haskell's intellectual challenge. It makes me feel stupid. I hate that.

Or can Haskell's laziness help with this? Can it somehow avoid actually creating the new copy, but instead just return the correct value when you reach the end of the list? So that the new copy is never actually made, but it just behaves as if it was?

The "Java of FP" could be C# or F# (although Microsoft isn't willing to go multi-platform, so that might stop it becoming "successful", by many definitions).

But honestly, I don't think there is a powerful enough vector available to carry FP. C had Unix. Java had the net. A novel way to think about the next "Java of FP" is to think of what vector could matter, and then what FP language is well-placed to be carried by it.

Mobile phones are all I can think of at the moment, but no FP has come of it; the netbooks (which are becoming phones) are plain ol' PCs; and the iPhone runs Objective-C (doesn't it?). What's the next IT revolution?

Actually, time_management is right: the next IT revolution is clearly multi-core.

EDIT: I keep hearing about Intel's CUDA for multicore on GPU's, but it's pretty much the anti-FP, being "recursion free" http://en.wikipedia.org/wiki/CUDA#Limitations

The usual claim is that the immutability of FP will avoid the problems of different processes writing to shared memory, because they only read it.

But Erlang is famous for its concurrency, and this is not due to it being a FP; it is due to its shared-nothing pure-message passing (from Smalltalk). It's another solution.

If you have multi-cores, the problem is not what you do within one core (we can already manage that); it's that you have many cores. If [1] they have their own local memory, then pure-message passing is the inevitable solution.

Anyway, that's my reasoning - I'm interested to hear your reasoning.

[1] At the moment, the on-chip memory is (very small) cache, and so shared memory is an option... but I think it's also inevitable that we'll get sufficient local memory for each core to execute code independently.

I wonder, is the emotional part really about something else, as this article suggests? It often seems out of place to me.

For example, xmlrpclib.ServerProxy takes an URI - is that a string or a special URI object? I guess it's most convenient if it's just a string, but if you had just constructed the URI by concatenating the separate parts, it's inefficient to immediately parse them apart - and so Java has URI objects. Maybe it's just that Python admits it's a scripting language, and uses machine cycles to serve you - instead of the other way round. That's a nice idea.

Python documentation, in contrast, seems to downplay (read: hide) the return type! It's not helpful to me (maybe I'm doing it wrong, or just not used to it). For example: http://docs.python.org/library/httplib.html#httplib.HTTPConn...

BTW: I meant that specific problem you mentioned (which was a non-conforming xml document) - how would JSON/sexps make that specific one easier to solve?

I was mainly addressing your comment elsewhere about people who like to lock things down, and specify them upfront. For interfaces, you really do need to agree on some things, and be strict (within those tolerances). Someone changing an interface on you can be pretty frustrating.

For a grammar specification language (like XML Schema) to do a really good job, it really should also formalize how to specify error messages for that particular grammar. I'm not sure how hard it would be to do this, and I haven't seen any research on it.

An odd thing about XML Schema is that it's not very resilient - when this was supposed to be one of the cool thing about "extensible" XML. The next version is a little better at this. But it sounds like in your case, you wanted to get an error (because there was a real problem), it's just that you couldn't trace where it came from, or what its meaning was in terms of the system. It sounds like a hard problem. BTW: would using JSON or sexps have made this problem any easier? I think it's much deeper than that.

There's a range of people in any industry - I doubt that many fit the black-and-white stereotype that you paint. There are also real advantages of standardization (such as being able to swap different items in and out), which comes at a cost of inefficiency. The interfaces to those standards must be rigid (within tolerances), or you can't reliably swap the modules. It's a trade-off.

Some kind of threaded comments might help. e.g. on reddit, you can compress the joke-thread and the pun-thread, to get to the on-topic commentary. A "typo thread"? Or an explicit "typo" tag (which you could hide from the public, and so disable captcha, if you wanted).

But I haven't seen threaded comments on blogs - maybe they aren't needed? It seems an obvious idea to try.

> If S-expressions were easier to edit, it would be most logical to edit the document in S-expressions and then write a small Scheme program to convert S-expressions into a formatting language like LaTeX. This is, what XML and SGML people have done for decades [...]

  {
    "function": {
       "signature": {
         "name": "byId",
         "args": ["id"]
       }
       "body": {
         "return": {
           "call": {
             "target": "document",
             "method": "getElementById",
             "args": ["id"]
        }}}
  }}

The nice thing I see in XML is that it abstracts out grammars (using XML Schema / DTD). For JSON, a grammar isn't used - it's a nested tuple transmission format - sort of a dynamic type systems, but without, er, types - just tuples that can contain anything. It's agile, and all you need in many cases. And JSON is a natural for web-client stuff.

BTW: who said SOA is dead? SOA doesn't solve any pressing problem, but all the vendors switched to it.

By Google, XML is winning 50 to 1 - but declining, and JSON is growing: http://www.google.com/trends?q=xml%2C+json&ctab=0

However, a factor is that people already know about XML and don't need to search for it. e.g. HTML is declining even faster: http://www.google.com/trends?q=xml%2C+json%2C+HTML&ctab=...

There's an intriguing view that text can't be used by hand either - you have to use a "text shell". Wouldn't a fair comparison use an "XML shell"? If it knew the schema, it could even autocomplete/intellisense for you, showing you the available choices at that point... it's pretty cool how XML has factored out the grammar of a language, in a reusable way.

I don't know the Jabber protocol, but the difficulty I've experienced with web-based XML protocols (web services) is that the http header needs the length of the message, which is hard to do by hand - it's not due to XML (and a "http shell" would fix that...)

I think there'll be another chance when SOA/web services are superseded; but there's still huge scope for improvement within their present architecture/ecosystem (e.g. REST vs. SOAP vs. ?).

For programming languages, sexps are competing against all the other language syntaxes out there, not just XML. I agree that it seems odd that ant uses XML though... perhaps the extensibility of ant is easier with some kind of generic format (like XML/sexp/JSON)? yet other languages manage to be extensible via functions/classes/modules etc.

Thank goodness no one uses JSON to encode a language (in the way that ant uses XML).

I'm not sure if the "10,000" reports would happen; have to try it and see. It's probably more like bug-reports, or 37signal's "feature requests" (that they read and throw out). And, if you fix the typo, the reports stop. :-) It's hard to judge, but I think you'd have to be massively popular to get even one or two typo reports. But I don't know: need to do the experiment.

Maybe a lower-cost solution would be just to add "prompting" text next to the comment box, something like: "typo corrections are welcome", to encourage people.

Typo reports (bug reports?) aren't that common: for example, I made a comment on a typo to Tim O'Reilly's recent blog - but no one else had.