exch

Having things be complex and messy is hardly ideal, but I think Neil deGrasse Tyson's sentiment is important to keep in mind: The universe is under no obligation to make sense to you.

But as cshimmin mentioned, we already unified electricity and magnetism. I am reasonably confident we'll find something equally nice and elegant for the rest. Maybe not tomorrow, or in a hundred years, but it'll happen. If only because we're too stubborn a species to let it be.

This talk by Hans Rosling may be what you are referring to.

https://www.youtube.com/watch?v=dymPP9RhPjw

https://www.youtube.com/watch?v=dymPP9RhPjw

A talk by Hans Rosling[1] on the subject.

[1] https://en.wikipedia.org/wiki/Hans_Rosling

What does 'post human' mean? Unless we go extinct, we will always be humans, regardless of what species we evolve into. Our current species is "Homo Sapiens Sapiens", not "Human". Ergo, if we evolve into amorphous blobs of space goo, we will still be Human but not "Homo Sapiens Sapiens". Which means it is physically impossible for us to ever reach a "post-human" stage.

As a fellow, certified autist (High Functioning Autism diagnosis since 2009), this article resonates with me on many points.

Since the diagnosis, my life has improved 100 fold. Not so much because I got go to some courses and group meetings about the subject, but because I was finally able to understand who I was and why. All the weird and inexplicable things I saw in my past, suddenly fit. Like a giant puzzle you've been trying to solve for 30 years and in a matter of weeks, every piece just falls into place.

And more importantly, being able to explain to others who I am and not feeling the need to try to 'fit in'. I learned it is perfectly OK to be me and this almost solely improved my mood, energy and ability to function in daily life.

For those interested, I've also written up a few articles on my experiences in various daily things:

- https://jteeuwen.nl/autism/hfa.html - https://jteeuwen.nl/autism/a_night_on_the_town.html - https://jteeuwen.nl/autism/phonecall.html

They do in my (marginal) experience. I have found it to be a very common idiom to keep word definitions in these languages as short as possible. Probably for this very reason.

You define new words for the sole purpose of keeping things short and to the point. This holds true for most languages (At least if you want readable and maintainable code), but a language like Factor, this becomes an absolute necessity.

I would not be surprised if this is the reason Factor is called Factor. Specifically when related to factoring in Algebra where you do much the same thing: "splitting" an expression into a multiplication of simpler expressions.

This is definitely one of my all time favourite games. The atmosphere and story are top notch. Good to see it being revitalized.

Not to mention the vastly better field of view and detail. Neither of which translate very well through a phone camera.

Not sure why you are getting down voted. These are all valid points.

Thank you! It seems my confusion arose from assuming this is a power generator, while it is a storage device.

As a completely non-technically-inclined person, can someone explain how this is intended to yield electricity as output?

From what little I do understand, the enormous surface area of the crushed gravel acts as a very efficient heat transfer mechanism, so it can cool(or heat) the Argon, depending on which chamber one is looking at.

The pistons are there to cycle the Argon between high and low pressure.. Presumably to keep the gas flow going. But can't this be done with just the pistons and without the pressure gradient? (edit: nvm this part; the heat energy is obviously generated by this pressure gradient).

Then comes the time to get the heat energy out for actual use. The article mentions that the gas flow can be reversed. So presumably the gravel that was previously being cooled, will now be heated. Isn't this just exchanging the heat between the gravel and gas? How does this yield net energy output?

Go would fit that definition quite nicely as well. It may be worth adding to your list of things to check out.

[unsubstantiated armchair physics ahead]

One benefit of this approach I can see is that you don't, in theory, need transmitters and receivers to be in line of sight for a clear signal. If you are doing standard radio transmissions, it helps if there isn't a planet between you and the transmitter. With entanglement equipment on both ends, this is irrelevant.

You will also not be bothered by signal degradation. The real head-scratcher of quantum entanglement lies in that it works over any distance. The 'transfer' of state between particles is identical, whether the twin is sitting 1 meter or a million light years away.

But as the other commenters mentioned, you are still very much bound by the speed of light. So propagating state changes between entangled particles separated by 1 light year, will still take 1 year.

Having congenital Glaucoma, I've always had to live with the possibility of one day being blind. My left eye is already pretty much there.

What has always fascinated me about sight is how our brains augment and outright invent things you think you see with your eyes. It's not at all about believing what you see, but about seeing what you believe.

The Glaucoma has steadily been eating away at my retina and optic nerves over the many years. Causing blind spots to form all over my visual field. In daily life, I can't see those spots. As in, there are not actually black holes in the images I perceive. The brain somehow manages to fill in those gaps with visual information directly surrounding those gaps and combine it with what my experiences/memories tell me should be there.

It's only when I start concentrating on really small details, that these holes become apparent. Particularly when looking at small LED lights in a dark environment. The LED keeps disappearing and reappearing as I slowly turn my head in various directions. Everybody has a single blind spot like this in the center of their visual field which behaves in the same way. Imagine this, but multiplied over 60 - 80% of your visual field.

Additionally, my almost-blind left eye has caused me to lose depth perception all together. This means those fancy stereoscopic 3D things are pointless to me and one would expect I would have a hard time in traffic. Not being able to judge the distance to an oncoming car can be deadly. But again, the brain seems to draw on its memories and years of experience and somehow manages to account for the lack of depth perception. It's not perfect, but enough to cope in daily life and safely move from A to B. At least on foot, that is. I am not allowed to drive a car for obvious reasons. A moped is technically permitted, but I don't. It moves too fast for me to accurately judge my surroundings in time. The same even goes for a bicycle. I only ride those in daylight. Not at night.

As far as blindness goes, I've had this once. As a kid, I fell out of a tree and landed flat on my back. For the following 45 minutes I was completely blind. It freaked me out to no end, as I was terrified it would not go away. Luckily it did. Not looking forward to that again!

I am guessing OP is referring to the ability to reliably orbit and land on comets (and asteroids). We can use them for manned way stations or construction platforms. Not to mention mining them for whatever useful stuff may be in there.

I'm thinking he means registering an account on the formspree site. So your form's `action` attribute doesn't require the inclusion of a plain e-mail address. Instead it gets some encrypted string, which is uniquely tied to your formspree account.

Given the current exchange rate, those 600 BTC would still net him $628,932.00. That seems like a pretty good deal. Granted, it could have been nearly $260 million, but I guess one can never have it all.

I think this whole thing sits in the same boat with error handling and unit tests. Many folks tend to see these as something separate from programming. Some kind of side effect that isn't a lot of fun and is therefore best ignored. "Hey, I can write me some code.. and oh yea.. there's also this bit of stuff I should do, but I'm busy writing the next big thing."

It helps to start thinking of all this as one and the same. No single part of it is more or less important. If you are writing code, you are writing documentation, you are doing correct and thorough error handling and you are producing consistent and relevant tests. There is no difference.

The README is mentioned is more or less a lightweight specification of the public parts. Sometimes it warrants more detail and I add an actual SPEC document which goes into great detail.

I have not had much trouble with the comments diverging from the final implementation of a piece of code. But I have forced myself into a habit of re-reading through the documentation regularly once I've committed a chunk of new code. Just to ensure it all still does what it says on the tin. This takes extra time, but together with learning how to write decent commit messages, this has helped me keep things sane and organized.

I think the article hits on the wrong conclusion. Don't write less documentation because you're going to assume it will all suck anyway. Insist on writing better documentation instead.

Having said that, I find it helpful to write documentation before writing the actual code. Specifically for more complex code pieces for which the behaviour is not immediately obvious.

For me, writing documentation serves as a form of 'rubber duck debugging'[1] before the actual bugs occur. Explicitly writing out the intention of a piece of code in plain English often makes the concept much clearer in my brain and immediately brings out possible problems with my initial design. Problems I can fix before wasting time iterating through code implementations.

This is also the reason I very much enjoy writing thorough READMEs for each library I produce. These explain in abstract concepts what the entire library API is intended to accomplish. Additionally, I try to include actual usage examples. As with code-level documentation, this brings up possible problems before they occur.

The fact that it makes it clear what the code does, months after I last worked on it, is entirely bonus.

[1] http://en.wikipedia.org/wiki/Rubber_duck_debugging

I'll add that the reason for using `struct{}` over `bool`, is that an empty struct occupies 0 bytes, whereas a boolean occupies 1.

(assuming, of course, that Go accepts Reader as a valid subtype of ReaderCloser (i would hope so!)).

Yes it does: http://play.golang.org/p/OnBotL9zfF

I've looked at this sort of stuff as utter voodoo for a long time. Then I ran into this book[1], and everything just kind of 'clicked' into place in my head. I can't recommend this book often enough.

[1] http://www.nand2tetris.org/book.php

In short: It gives you a hands-on approach in designing and building your own computer and programming language, to end up writing and running your own games on the system.

    * It starts with simple boolean algebra to explain and create logic gates (NAND, AND, OR, XOR, etc).
    * Use these to build an ALU, memory banks and eventually a full CPU.
    * Design an assembly language and assembler for this system.
    * Use the assembler to create a higher level OOP language, compiler and code base.
    * Use this language to write a rudimentary operating system.
    * Write a game to run on the OS.

Edit: For some reason, this site has started showing malware warnings in chrome and firefox since today. Even though Google's advisory[1] makes no mention of any actual malware being detected. I've visited this site safely for a long time. Still, if you don't trust it, then wait until Google clears up the issue. I've already contacted one of the authors about it.

[1] http://safebrowsing.clients.google.com/safebrowsing/diagnost...

Even shorter:

    package main
    
    import "io/ioutil"
    
    func main() {
        data, err := ioutil.ReadFile("/etc/ttys")
        ...

        println(string(data))
    }

I'd have to agree here. There is no difference between Go's way of managing external dependencies, compared to any other language/platform where you use external packages. Whether they are manually downloaded and built, or pulled from some kind of source-control repo. The `go get ...` approach is just a convenience tool you can use /IF/ you want to.

I get the impression that much of the complaints stem from not really understanding what is actually happening. It's a shame really. People taking a first look at Go, and running into these kind of rants will get an entirely incorrect impression of the Go tool chain.

It seems it doesn't go into a lot of detail as to the call-chain for each running goroutine, but this example may just not be very suitable to properly test it. Either way, here is the same deal with a bunch of running goroutines.

http://play.golang.org/p/GQxdXpWdZD

As a practical example to 4ad's answer, here is the result of NULL-pointer dereference on the C code on my system (Arch Linux 3.9.2-1-ARCH). It does yield a SEGFAULT:

http://play.golang.org/p/uoBKsRIJB7

Go is completely open source. The primary devs just happen to work at Google. That is all.

If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.

He is referring to the `go` command, which is a front end to all of go's build tools.

http://golang.org/cmd/go/

To get a good overview of third party libraries 'out there', you can browse the index at http://godoc.org/-/index

These are by no means all the 3rd party stuff out there, but it's a good starting point.

Incidentally, this website is intended to automatically generate and serve the documentation for all those projects in a centralized place. You don't even have to submit your projects. Just type the import path in the search box, and the site fetches the code by itself.

Edit: And here's anther community-built site to do continuous integration testing for your projects. It too, has an index of registered projects: http://goci.me/