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.
54 karma · joined June 26, 2014
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.
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.
[0] http://xmos.com/
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?
[0]: http://www.greenarraychips.com/home/documents/greg/PB002-100...
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.
> Note that if Shen is not running on a Lisp platform, then function may be needed to disambiguate those symbol arguments that denote functions.
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.
http://english.stackexchange.com/questions/38741/use-of-and-...
I would restate this as: "In Haskell you write a description of a stateful computation." The "State Monad" is really just the illusion of mutable state, provided by passing the underlying state to each described computation. Actually-mutable state is possible with things like IORef, but these are impure.