My default position for most business tasks would be to do this with Haskell. You asked for the three criteria:
1. Haskell as around for longer time than the other two options. It will enable new people to quickly grasp your code base, so even if some core members leave the team the system will support them actively.
2. A true winner. Haskell allows for using very abstract and generic code. If this works then it can be used in many contexts. In Go and Python your devs will write more low-level code that is less reusable. Just think about writing a function that adds 10 to its argument. In Haskell:
add10 = (+10)
You can easily call this to add 10 to a number. You can never make a type error with this. But now: what happens if you are reading numbers from some incoming bad data? You may have been able to read a number or not. In Python you may have a value `x = None` and in Haskell x would be `Nothing`.
In Haskell you can make your `add10` into a very reusable component which we call f: `f = pure . add10` and you can use it like this:
x >>= f
And it will work fine.
In Python you need to write a new function which first checks if its argument is None and if yes it will return None, otherwise it calls add10() on it.
Or you have a list of numbers and we call it again `x`.
To add 10 to each element in Haskell you do:
x >>= f
In Python (and Go) you would have to write a function which will map over x and apply add10 to each element.
What if you now have a function which may either return a number or an error message? In Haskell such a value can be used like this:
x >>= f
In Go or Python you would have to write a function which first checks if x is an error message and if yes returns it or otherwise calls add10() on its argument.
What if you wrote a function `x` which reads a number from the keyboard and returns it? In Haskell you would use it like this:
x >>= f
In Python you will first have write a function which calls x and then makes use of the return value.
In Go and Python you would have to write several different implementations to handle different contexts (absense of values, error handling, IO, DB requests, non-deterministic values, etc) and every single time they would look different. In Haskell this function will always have this body:
x >>= f
And this is only the beginning. Haskell allows you to write less code than dynamically typed languages. But your code will run very fast and have way less errors. In Python every function call needs to be looked up at runtime first. In Haskell you go to the function definition and save much overhead.
From my experience in 2017 with our production system was that nearly every bigger problem was due to some type error. Nearly always! This is what we get from a dyanmically typed language. The initial development time may be a tiny bit shorter, but then you will pay this many times with more debugging time and with time to write more tests.
Only tonight one colleague had to stay some extra hours in the office because there was some strange bug in the Python code.
To outperform the competition you need to write ultra stable code that runs fast. Neither Go and certainly not Python can give you this. For scripting this is of course different. Our data scientists use R and this works fine for them.
But with Haskell you can write very generic code, but without magic involved. In every single case you will know _perfectly_ what situation you are in thanks to the type system.
Your point 3:
If you’ve got such a nice budget go visit some headhunter and try to find out what they have to offer.
I can only say that I know people who are willing to move to get a Haskell job. You may want to consider to have some remote positions. But you may also need fewer Haskell devs because they will be more productive.
One other thing: nowadays Python and Go are pretty common. People learn it because those are popular languages and because the market has a demand. The days when Python was considered an esoteric language are long over. Haskell is learned because people are deeply interested in programming and not out of some necessity to earn money. Those might be the guys you are after.
I put a tiny Truecrypt container on my file hoster (HiDrive, Skydrive, Dropbox, etc.) in which I store the KeePass keystore. The keystore itself can't get decrypted, but in case AES has weaknesses one first needs to crack the triple encryption of AES+Serpent+Twofish of the Truecrypt container.
It is GPL and you have the control over your keyfile(s). A browser plugin for the commercial services could any time sneak evil bits in, so you might feel less safe with them (they could upload your masterkey or your decrypted keyfile, when asked by the NSA).
Yes, it’s strange. My idea here is: for distances both things are typical: meters and kilometers. Every day we need to handle both unites. It would be impractical to give longer distances in meters (“Hey Jeff, it’s still around 100000000000000000 picometers to your home, will be there in roughly 4200000000000 nanoseconds…”).
But even huge distances on Earth can be measured in km, and we don’t need megameters.
With calories however for all practical purposes we have a number range in which it is okay to use kcal. So here people just forgot that the k actually has a meaning. It makes not much sense to go down to the level of cal.
Both numbers are totally wrong. Because both should be closer to a quarter million, and not 200. Even one gram of sugar already has over 4000 calories.
But besides that, and this is probably your question:
you only need a tiny amount of artificial sweetener, to get the same sweetness that you would get with sugar. For example Aspartam is about 200x as sweet as sugar, but it contains a very similar amount of energy. Sugar has ca. 16.8 kJ/g and Aspartam more like 17 kJ/g.
Guys, also don’t forget: what we currently see is a snapshot in time. Right now Mathics offers the features X and Y and lacks Z. But this may change over the next years.
“we already have nearly unlimited computing power at our disposal”
I have to disagree. To tackle hard problems I would be glad to have a billion times more computational power.
We are doing semantic processing of texts. For one customer we have a million texts, and processing one takes about one second. To have the computer automatically generate rules (Genetic Programming) we would like to have this:
the computer generates a rule, processes the million texts, and checks if that rule improved the overall understanding. Currently one million processing seconds are required.
But if we could do this on one million cores, we could generate one rule per second. The thing is: an evolutionary system will generate millions and millions of rules. So, even if we had a million times more computational power, it would still require several months to finish a run. Renting such capacity from Amazon & Co. would cost easily 5-10 millions.
With a billion times more computational power however this would fall in the range of perhaps a few thousand dollars.
Also, it would be useful, if mobile phones would feature such a computational power, so that strong AI software with above human intelligence could run on it. Such software could technically run on a C64 if enough memory were available, but answers would take quite a long time.
So, I really hope that we will see maaany trillion times more computational power in this century.
Even when we directly say “We’ll copy it!”, it could still come out as having the classifier outputting a small confidence value. So, in my opinion this should not count. There should be a confidence value of a neural network involved.
In the case of a real copy, the classifier should have a confidence of 1.0, or be enormously close to it.
This whole thing is a difficult issue. Who is to decide what devices look similar enough, to deserve calling it a “copy”? In principle what we do here is: we implement a neural network for object recognition, and train it to recognize a certain device. Now we run this classifier on other devices and need to settle for a confidence value which says if a device is a copy or not. But who should decide what exactly this confidence value should be?
For example, what if we decide to say that a 0.921 value means a device is a copy, and we find out that Samsungs older devices get a 0.884 confidence?
Often “why”-questions are interpreted as criticism. I would like to ask one, just because I am curious:
why are people interested in this for communication?
With current technology we can communicate with within the limits of the speed of light. We can also encrypt communication. So, what makes this technology so interesting, that people may want to use it in the future?
Will it be cheaper? Faster? More secure/better encrypted?
Yes, Clojure 1.4 defaults to static. However, a Var still needs to do an extra lookup at runtime. A Var does not directly point to the object that I want. And Vars have to be that way, this is their core feature. Clojure is a dynamic language, so they need to stay dynamic too.
All code constantly assumes that the objects behind Vars will change. Let’s say we have `(defn foo [] 1)`. The caller of (foo) will first lookup the address in RAM of the compiled function, and then jump to it.
Because of this dynamicy we can redefine foo at runtime: `(defn foo [] 2)`.
All callers still function, and will now get the result `2`. In statically compiled languages this would not happen, because `foo` is translated to the direct address of the first function. The concept of replacing functions at runtime doesn’t exist in that way.
But I would like to see an optional “static” programming feature: I want to be able to mark functions as final. This would be nice after major development has happened. A function object that Clojure created could then not be changed any longer, without restarting the JVM. But such functions can be called directly, without any overhead.
`defonce` unfortunately doesn’t help. Without restarting the JVM I can overwrite that var. And that is okay, because defonce is just a protection mechanism, to not delete data when a namespace is repeatedly reloaded. This reloading occurs 99% at development time. Useful tool.
But I would like to have real constants. A final class with a static final field (and potentially type information), or something like that. This would give the optimal lookup time, as the JVM would have the direct address.
When I (defonce x 1) I can still (def x 2), without restarting the JVM. I want this to not be possible with a defconstant.
The posting is about JavaFX, but in reality it will be a general mechanism for JVM apps. Oracle is doing this preparation, so that your JVM apps (Java, Clojure, Scala, etc.) can run under Android and iOS.
2. A true winner. Haskell allows for using very abstract and generic code. If this works then it can be used in many contexts. In Go and Python your devs will write more low-level code that is less reusable. Just think about writing a function that adds 10 to its argument. In Haskell: add10 = (+10)
You can easily call this to add 10 to a number. You can never make a type error with this. But now: what happens if you are reading numbers from some incoming bad data? You may have been able to read a number or not. In Python you may have a value `x = None` and in Haskell x would be `Nothing`. In Haskell you can make your `add10` into a very reusable component which we call f: `f = pure . add10` and you can use it like this:
x >>= f
And it will work fine. In Python you need to write a new function which first checks if its argument is None and if yes it will return None, otherwise it calls add10() on it.
Or you have a list of numbers and we call it again `x`. To add 10 to each element in Haskell you do:
x >>= f
In Python (and Go) you would have to write a function which will map over x and apply add10 to each element.
What if you now have a function which may either return a number or an error message? In Haskell such a value can be used like this:
x >>= f
In Go or Python you would have to write a function which first checks if x is an error message and if yes returns it or otherwise calls add10() on its argument.
What if you wrote a function `x` which reads a number from the keyboard and returns it? In Haskell you would use it like this:
x >>= f
In Python you will first have write a function which calls x and then makes use of the return value.
In Go and Python you would have to write several different implementations to handle different contexts (absense of values, error handling, IO, DB requests, non-deterministic values, etc) and every single time they would look different. In Haskell this function will always have this body:
x >>= f
And this is only the beginning. Haskell allows you to write less code than dynamically typed languages. But your code will run very fast and have way less errors. In Python every function call needs to be looked up at runtime first. In Haskell you go to the function definition and save much overhead.
From my experience in 2017 with our production system was that nearly every bigger problem was due to some type error. Nearly always! This is what we get from a dyanmically typed language. The initial development time may be a tiny bit shorter, but then you will pay this many times with more debugging time and with time to write more tests. Only tonight one colleague had to stay some extra hours in the office because there was some strange bug in the Python code.
To outperform the competition you need to write ultra stable code that runs fast. Neither Go and certainly not Python can give you this. For scripting this is of course different. Our data scientists use R and this works fine for them. But with Haskell you can write very generic code, but without magic involved. In every single case you will know _perfectly_ what situation you are in thanks to the type system.
Your point 3: If you’ve got such a nice budget go visit some headhunter and try to find out what they have to offer. I can only say that I know people who are willing to move to get a Haskell job. You may want to consider to have some remote positions. But you may also need fewer Haskell devs because they will be more productive.
One other thing: nowadays Python and Go are pretty common. People learn it because those are popular languages and because the market has a demand. The days when Python was considered an esoteric language are long over. Haskell is learned because people are deeply interested in programming and not out of some necessity to earn money. Those might be the guys you are after.