1,405 karma · joined November 17, 2010
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.
A talk by Hans Rosling[1] on the subject.
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
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.
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?
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.
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!
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.
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.
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.
Yes it does: http://play.golang.org/p/OnBotL9zfF
[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...
package main
import "io/ioutil"
func main() {
data, err := ioutil.ReadFile("/etc/ttys")
...
println(string(data))
}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.
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.
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/