Several of my friends worked on the bid for south africa and the volume of data they they were talking about is astounding.
Another friend of mine is working on the forked nix os that they are building to run all this, very very interesting,lots of interesting computing. Lots of phd and post doc CS and EE work being done around this in South Africa.
Interestingly the algo which they use to process the data is very simple, several nested loops (trying to find the paper now one of my friends on the project sent me yielded no results), but this algo obivously has to run on masses of data and massively parallel.
I know that one of the teams at my work has deployed a few tools on mono written in F#.
I play with mono and f# (nix) and I was surprised with how mature mono develop was (I had very low expectations)- I have not used it in anger however, so things like profiling and such I have not even taken a peak at.
I have been playing with F# a fair bit and I am totally in love with the language. I wish it was a jvm language given that is what I ply my trade on (and no scala is not as elegant imo)
F# is indeed very interesting! For the JVM, one alternative (based on Haskell 2010, so it has philosophical similarities to F#) is Frege (https://github.com/Frege/frege). Frege is probably even less mainstream than F#, though. I don't use it because I'd rather code in Haskell using GHC.
While it's not an ML-style language, I've found that I enjoy Clojure the most when it comes to JVM alternatives. The lack of F#-style pattern matching makes a few things feel less elegant, but the general structure of my code is extremely similar.
There is core.match[1], and between the restructuring bind, multimethods, and the ability to create polymorphic functions like hello in this example[2], you can replicate a lot of common FP idioms reasonably well. It's not pretty, but Clojure generally isn't.
The trouble with Scala is that developer A writes elegant mostly-functional code while developer B uses global state modified in nested while-loops with everything as type Any. I think more of a bondage language approach would be better.
Agreed this is a problem. For example, I had to educate my boss about Option vs null, and I'm still not sure he gets it (he's an old school C-and-then-Java programmer).
On the other hand, it's possible to "not get it" and write messy code in even the most bondage-oriented languages.
Interesting! Didn't know that. But note two things:
1- In the more general case, you cannot enforce a rule to disallows clumsy/inelegant code. You cannot force proper use of the language.
2- In the Option/null case, this is an education problem. My boss is an old-school programmer with lots of experience (and I've seen him successfully solve and/or prevent real problems at work that bit every other team, so by no means I want to sound disrespectful of his experience), but he simply doesn't understand why Option is needed. He claims "defensive programming should be enough" (i.e. checking for null at every turn). He claims "academia is not good for anything", and I guess he sort of believes Scala is an academic language full of fancy but not really useful constructs. He is not completely sold on functional programming, pattern matching, etc. So I cannot simply have the language complain about nulls, because I must justify the enforcement of this rule to my boss, and he isn't convinced. (Note: this isn't limited to Option values; think of almost every feature/coding style from Scala that might sound unfamiliar to Java programmers, and it's the same problem with my boss).
As someone who frequently travels all over Africa, I would want a secure password on this. If this card gets stolen without such a password it would mean the thieves can empty out several of my cc accounts.
If they don't mess up the implementation then it would appear to be more secure than traditional cards. Especially in places like Africa (I assume) and the US where Chip and Pin has yet to be rolled out.
I appreciate the point you're making in that stealing this one card is equivalent to stealing a whole wallet-full. But isn't it usually the case that you lose the whole wallet in one go?
Actually, according to this worldwide map of card and terminal EMV deployment, Africa/ME had chip & pin tech, as of Q4 2013, in 38.9% of cards and 86.3% of terminals.
The difference is when I travel I don't take all my cards out with me, I would leave at least 2 backups in the hotel safe and another at home which can get sent to me in an emergency. Realistically imitating this behaviour on such a device probably won't happen.
on the jvm i would say groovy is probably one of the better languages for dsl's. Gradle is a dsl and groovy has inbuilt Builder classes to help you in the creation of dsl's
Clojure being a lisp is extremely powerful in this regard as well, but if you are programming in any lisp I would expect a fair amount of meta programming.
we have been running an indoor aquaponic system as an expriment for a year now and you are right, it is a pipe dream mostly. Lots of fun to be had, but its not a cheap hobby.
Running an aquaponic system is not easy. We have been running one for a year now inside our house under growlights (as an experiment - no way it is economical). a lot is automated with the arduino, but if my wife was not a microbiologist we would have failed totally. Super interesting however.
Interestingly the algo which they use to process the data is very simple, several nested loops (trying to find the paper now one of my friends on the project sent me yielded no results), but this algo obivously has to run on masses of data and massively parallel.