That's surprising. I went there recently, and you aren't permitted to bring any electronic devices whatsoever - you have to leave them in a locker and then take a ~30 minute bus ride to the telescope.
They're also very strict about checking: you have to go through two different x-ray machines to check you didn't sneak any electronics through.
Are those truly x-ray machines? Not just magnetic coils? Seems overkill and I'd object to being exposed to ionizing radiation just for the purpose of validating my claim that I don't carry any electronic communication devices.
It's actually a pretty standard setup in China anyway... Pretty much anytime you go onto an inter-city bus / train or into a crowded space (museum / exhibition centre) you will go through a metal detector and your bag through an x-ray machine. So it makes sense that they'd just use the standard setup that the local security company would be used to.
No, it wasn't there from the start. The no electronics policy only started within the last two years. I know someone who has been there and has the pictures on her phone.
This does seem very interesting! Because of your comment I started reading the architecture document for the GreenArrays[0] chip, and it's totally different to anything I've seen: a network of processing units, and the whole thing without a clock anywhere!
I am interested what makes you say it "provides computational grunt comparable to an i7 for a few milliwatts" though - could you elucidate? Do you mean in terms of performance-per-watt?
> I am interested what makes you say it "provides computational grunt comparable to an i7 for a few milliwatts"
I've been quite interested in Green Arrays, but I'm quite sure that's basically nonsense. The Ga144 can do lots of interesting stuff, but comparing it with an i7 is ill adviced. If for no other reason than that you have to provide your own dram interface, while the i7 typically comes with that in the form of chipset support.
In short, I think such a claim is misbranding the Green Array chip, setting potential users up for disappointment and at the same time selling the chip short.
Interesting, it reminds me a bit of the game TIS-100[0], similar idea of an array of very simple units interacting by I/O ports, blocking until a read/write to another unit can complete. I didn't know there was a real architecture like that!
edit: It seems the transputer[1] was similar, hadn't heard of that either.
The transputer actually has a successor called the XCore[0], which is produced by XMOS. They're founded by the same fellow that came up with the transputer (David May).
It's a similar concept again - it's a multi-core chip for embedded applications, and the cores communicate using an on-chip network. Each core is like a regular CPU with a clock though - the GreenArrays approach seems to be completely asynchronous.
I was lucky to get a mix of C, Java, and Haskell. Unfortunately (to my detriment) I totally ignored Haskell, and it didn't really click until I picked it up at the end of my degree out of curiosity- it really does help to clarify one's thinking.
I think teaching the motivation for learning it before beginning would have been better than just throwing it at freshmen, but I can't truly blame anyone other than myself.
My experience is that routes to UK and Europe (at least to budget VPS providers) have high latency and often have low throughput. Try servers in Singapore, Tokyo or the USA. Even these vary in performance, depending on the peering arrangements in place. Try to find an overseas host with direct peering with PCCW or China Unicom.
It means that to be portable you have to wrap symbols that represent functions in (function <the-symbol>) when passing them as arguments. Not doing so will work on some ports but not on others, and should be considered "undefined behaviour".
I chose between Go and Haskell for a project some time around 2012. I was a beginner to both, but came from a background of imperative languages (C, C++, Java, etc.)
Initially I felt the same as you: Go was much easier to get things done in, and I could be reasonably productive quite quickly (moreso than Haskell, which I found very difficult to learn).
However, after some time I found many of the same problems mentioned in this article. Particularly, in many cases I had to fall back to the kind of nasty unsafe code mentioned in this article (like using interface{}). Often, I felt that my code was needlessly verbose. I would frequently write code and feel that the language was preventing me from doing what I wanted directly. Ironically, this is exactly how I felt with Haskell at first (not anymore).
Ultimately, I ended up switching to Haskell, and although it was significantly harder to learn, I felt like it has a lot more flexibility, safety, and importantly lends a clarity to thinking when designing a program.
This sounds strikingly similar to my experience! Though my imperative language experience was mostly with dynamic and/or scripting languages aside from C#.
They're also very strict about checking: you have to go through two different x-ray machines to check you didn't sneak any electronics through.