Is there a good, terse primer on the features and coding idioms/best practices of C++17 for someone who was proficient in C++98 but hasn't touched the language in years?
It's kind of strange that massive layoffs like these result in a stock uptick. At least for me it's a sign that the company is probably unhealthy and that its value is going to go down in the future.
The creator of toki pona seems to be a fan of the Finnish language. Several of the words are loaned directly (although without umlauts) and keep their original Finnish meaning.
At a glance: älä, kala, -kin, nenä, nimi, sama, sinä are exact Finnish words and "pimeja" is a slight alteration of "pimeä". Kiwen, lipu, linja and walo are probably Finnish inspired as well.
Another common trend seems to be using a simplified and shortened forms of the phonetic spelling of English words such as "ale" (all), "en" (and), "insa" (inside), "jaki" (yucky), "jelo" (yellow), "kama" (come), "ken" (can), "kule" (color), "lukin" (looking), "mani" (money), "mi" (me), "mun" (moon), "nanpa" (number), "pata" (brother), "suwi" (sweet), "tawa" (towards), "toki" (talking), "tu" (two), "wan" (one) and "wile" (will).
Slightly distorted, but still close: "anpa" (under), "kulupu" (sounds like a Japanese transliteration of group, グループ), "pilin" (feeling), "sewi" (ceiling) and "sike" (circle).
This actually helps a lot in memorizing the vocabulary. :)
Yeah, the online REPL is definitely not very useful or intuitive yet.
As it says, you can evaluate a single line Haskell "expression" and top-level declarations (like the sieve example) are not expressions. In addition, the sieve example declares an infinite list so there's no sensible way to print it.
You can fix all the above by using a let-expression on single line and only evaluating a finite part of the list using the 'take' function.
let { primes = sieve [2..]; sieve (p:xs) = p : sieve [x | x <- xs, x `mod` p /= 0] } in take 10 primes
At least here in Finland it is much, much easier from a regulations perspective for a company to fire a bunch of people all at once rather than just few at a time.
I fold each pair of socks into each other when I put them into the washing machine and then unfold them when hanging up to dry. All pairs stay together, no sorting necessary.
Vista (at least after the first service pack) is a solid OS. I still run it on my gaming PC (which also dual boots to Ubuntu) and I don't see any reason whatsoever to "upgrade" to W7 or W8.
While "Order of War: Challenge" might have been sold separately at some point (I'm not sure), I think that most players (like me) were those who bought the original "Order of War" and got "Order of War: Challenge" as a free add-on.
The article claims incorrectly that the game had 18 single-player missions. The FAQ linked from the article is for the game "Order of War". "Order of War: Challenge" is a completely separate, multi-player-only game that had its servers shut down and was removed from Steam. The original "Order of War" is still available (http://store.steampowered.com/app/34600/).
In addition, the "Challenge" add-on was given free to those who bought the original game.
This is a complete non-issue as far as Steam is concerned (the complaint about publishers shutting down multi-player servers is certainly valid). There is nothing that you could do with the game even if you still had it in your Steam library.
Yes, but the effect of ecosystem lock-down is huge compared to 5-6 years ago. It's not about who makes the best phones or phone-OS anymore. People are invested in their respective app ecosystems and all their photos, contacts, documents etc. are in Apple's or Google's cloud.
I'm not saying that Microsoft doesn't have a chance at all but I think the odds are against Windows phones ever reaching a significant market share no matter how much capital and R&D they stack behind it.
The important bit isn't the Maybe-types, but all types that are _not_ Maybe.
If types aren't non-nullable by default then any function parameter or return value can potentially be null and a robust program practically needs to have null checks _everywhere_. Otherwise, when your program throws a NullPointerException you'll have no way to know where that null originated from.
In Haskell, the types guarantee that you never ever have to check for null (in fact, you can't even) unless the function's type explicitly allows for the possibility of having a null. In addition, you have several ways to compose function calls that might return null in such a way that you don't have to check for each null case separately.
Scala doesn't really provide much of what is mentioned in the article.
It still has nullable types, side-effects aren't tracked in the type-system (so any function can potentially do anything) and the presence of sub-typing has several unpleasant consequences, for example: lack of full type-inference, generally more complex type signatures than in Haskell and having to deal with covariance vs contravariance.
I would also argue that you can get the benefits of a static type system with hardly any cost. Usually when people talk about dynamic vs static typing they imagine something like Ruby or Python vs Java, but there's no reason why you can't have a high-level, expressive language with static types.
All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be able to be just as productive as with today's popular dynamic languages but get all the benefits of static verification.