Hemospectrum

If you know that every subfield of your state object is immutable, and you're using references instead of "local" copies (inconvenient unless you have garbage collection) then your copying costs are limited to the size of the overall state object plus whichever field changed.

Obviously this makes no sense for C++, but Clojure and OCaml get away with it and in Haskell it's the standard way of implementing almost every stateful computation.

> If you think Python was a significant influence in Go's design you probably have not worked with much with Go or its ancestors.

You're correct. I haven't used Go particularly much and I've only heard third-party descriptions of Limbo et al. Regardless, a number of the semantic and syntactic differences between Limbo and Go strike me as Python-influenced (obviously not goroutines or the defer statement) but if you have evidence to the contrary I'd love to see it.

> Yes, Go is not a 'purely functional' language, or 'purely' anything

Whoa buddy. That's not what I meant at all. There's no technical value in being able to say your language "purely" implements some programming style or other. Now, it would be nice if higher-order functions became a little easier to work with in Go; it is also unlikely that this will happen, because that's not one of the design goals. I can't fault them for that, but is there really any harm in pointing out a true fact such as this one?

And anyway, a "purely functional" language is just one where there's no built-in support for mutable state. Obviously this does not describe either Go or OCaml.

Call me crazy but it seems like Go is really just a munging-together of C and Limbo with a bunch of ideas from Python, and literally every feature that "supports functional programming" is only there as a result of being in Python. And obviously Python is not really designed to be a functional language....

Haskell is designed to quarantine side effects, not remove them altogether. There's a special monad for building data structures that are mutable at creation time but appear immutable outside that block of code. In normal circumstances, you'd probably still have to copy the contents of the input into a new array before sorting it, though. So, it would still be less memory efficient on large inputs.

By Asian standards, particularly Chinese, Americans are outrageously selfish. But it's true that Europeans (and perhaps most cultures) would find nothing unusual in Americans' value of self vs. family.

Ever been unable to think of a word for what you wanted to say? Strictly speaking, linguistic determinism claims that this is impossible.

If you talk to people in the Go community you'll see that they interpret "systems programming" to mean both OS-level development and applications-level development.

From the descriptions, Clean is lazy and pure, whereas Disciple is neither.

Yes.

Unicode is a superset of numerous other encodings, usually the national standards of the countries whose written languages they want to encode. For example, the sections for the Greek and Cyrillic alphabets have identical layouts to existing Greek-only and Russian-only encodings.

The exceptions to this policy are usually writing systems that didn't have standardized encodings at the time they were incorporated into Unicode. Also, the rather notorious CJK unification project resulted in several new overlapping layouts as Unicode policy changed over time with respect to Chinese characters.

GCC has always been a centerpiece in the plan for the "viralization" of the GPL, and support for its role in this plan has always driven design decisions in GCC. This policy has caused a lot of headaches even just within the free software community (eg. http://lwn.net/Articles/343608/).

I can't find a citation for this at the moment, but RMS has said on several occasions that GCC has to be difficult to integrate into other tools just for the sake of pushing the GPL. For example, this was his explanation for why improvements to GCC's intermediate representation formats (GIMPLE and friends) were refused for a long time.

In fact, at one time it was usable, but it has gotten less so, assuming it even still compiles.

If it helps, "quine" here sounds like "wine," not "queen."

Arguably, it already has: http://wiki.github.com/bjpop/berp/

Get a launcher app. Quicksilver has long been a favorite of Mac users, but I'm much more fond of a newcomer called Alfred (http://www.alfredapp.com/). There are a few others, as well.

The idea is to extend the command-line metaphor to parts of OS X where a regular shell isn't useful, and most such tools provide a whole lot of functionality besides just launching apps.

Then why bother with OOP to begin with?

A lot of people don't seem to understand the difference between closures and lambdas, and a lot of people get it backwards as soon as someone points it out to them. Good to know there's one clear demonstration out there.

Actually, if you could pass this on to people when you hear them refer to lambdas as closures, that would be pretty awesome.

At the assembly/bytecode level, you still have to save the return value of the recursive call and then do something to it, whereas a tail call wouldn't need to save any intermediate value because it would immediately return it as soon as it got it.

I guess Java's infix notation kind of obscures this. This is one of the reasons why functional programmers prefer to consider everything a function. It's also why some languages (like Clojure) have special syntax for tail calls, with special error messages if you goof up the semantics.