One reason big machines might make a comeback is the increasing capability putting off the super-linear cost growth into the realm of > 100GB in-memory or > 10TB on disk. CPU hasn't kept pace unless you consider GPGPU or Phi parts.
Super-linear disk cost back when disks were already atrociously slow compared to the rest of the machine have largely gone away with SSD's hitting huge capacities and tech like NVMe, solid state RAM modules, and Intel's upcoming Optane tech ensuring that more than ever, scaling horizontally can be put off way more than used to be possible.
If you look at scale-out vs scale-up for any applications that were disk limited, disk performance is now ridiculous - > 1GB/s and IOP's measured in 100's of thousands. I'm expecting a bit of a comeback for HA over HP. More than likely, your app can be served well by a single big machine that is well within the linear scaling regime, and you need several for durability and geo-availability.
Terabyte sized memory will soon be possible with Xeon (if not already), Amazon announced x1 instances with 2TB of RAM + 100 cores. They are using Xeon E7 CPU's:
that thing takes Xeon e5-26xx v3 CPUs which are pretty middle of the road server chips; Nothing fancy. If you want to go quad-socket with E7 xeons or something, you can get even more ram in one box, but the E5 Xeons are dramatically more economical than the E7 xeons.
I mean, the linked motherboard would be money, sure, but it would be the sort of cash that my company would be able to come up with.
Let's look at chemical storage with hydrocarbons in the mix, allowing some as-yet non-commercial (air-metal & combined cycle home generators) to make good food for speculation.
A consumer to operate a small gas turbine and store their energy in the form of hydrocarbons. If this is to be sensible, then 43MJ/kg would have to be enough, because that's what they're going to get with kerosene/jet fuel.
Now let's consider lithium. The problem with metal-air batteries has mostly been poisoning by unwanted gases. Let's assume for a moment that a membrane material is developed that only allows high purity oxygen through, but suffers low throughput. This is no problem for our off-grid solution because we're talking about large storage relative to power, similar to some flow battery applications. Using some method of specific ion or biological style solution, such a membrane is not implausible.
Lithium-air weighs in at 40MJ/kg specific energy. How much does it cost? Given that a metal-air battery uses lithium oxide, the lithium carbonate and lithium hydroxide prices are not quite valid guides, but the price of $7/kg is obtainable for the carbonate of "battery grade." If the pure oxide can be the material used in manufacture, then possibly the $7 value is in the ballpark.
Jet-A is $0.45 per kilogram. 1.41 $/gal / 3.78541 l/gal / 0.820 kg/l
Higher efficiency must be allowed because even with combined cycle at high latitudes where it's cold, we're looking at 90% round-trip for a battery vs ~75% for our Brayton cycle + home heating.
There are external costs to a large tank of kerosene and a pile of lithium carbonate. One requires a gas turbine and the other requires a battery & significant manufacturing. Excepting those two things, we're left with a roughly 7:1 factor of cost for the raw material, so a seven year payoff it is.
Lithium might not be the cheapest rechargeable precursor. It might be great for EV's (high power output is a requirement) and maybe something else will show up as the cheapest energy storage without requiring off-grid people to rely on ARES gravity trains.
Perovskites (new paper just suggested that hot-carrier phonons can be used to raise theoretical efficiency to 66%) throw yet another wrinkle into solar. Both energy storage and generation could become quite a bit cheaper.
All hypothetical, yes, but my napkin does tell me not to rule out off-grid, not that I'm sympathetic to off-grid, anti-social Ayn Rand acolytes =D Whatever matters for off-grid matters for a ton of settings, such as places where there is no grid still. It's tough to say definitively that a straight-renewable energy source won't become cost-competitive even in grid areas of high latitude within the decade.
Credentials would tend to support the practicing endocrinologist. Also, the data Lustig really had to go get was the causal inference where increasing fructose had a delayed response of increased metabolic syndrome. That study has been done now.
I've heard a lot of enthusiastic talk of entity-component architecture from those interested in game-dev. The way of modelling seems very appropriate and well-suited to C++. Things like holding each entity in a component class's static member array and calling the static method to, for instance, update the health component of every health-having entity is just too elegant not to appreciate. Immediately the problem is mapping each component across threads and just trivial to make parallel/concurrent.
To start though you need multiple inheritance likely to get this to work idiomatically. C would also do fine, as would Java, except the Java would look like C because of the lack of multiple inheritance/mix-in, while the C code could result in some type insanity -- although components can be implemented as simple structs in structs for entities, except the whole construction/destruction phase of life.
As an outsider looking in, C++ seems filthily well-suited to game development.
It's incredibly counterproductive to make statements like in the title. If you need your product to be better in terms of how it looks and feels, you get a UX Engineer and expect them to be able to do data analysis, modify analytics on their own, and apply what's learned from that analysis in dimensions beyond the X and Y in Photoshop.
Reducing a task graph is exactly the role that I'd expect a UX Engineer to be perfect at, and yet the article is titled "Engineers Build Ugly Products" while going on to state exactly the expected benefit of having a UX Engineer deeply involved with the product team -- reduced tasks, focused functionality.
Where this kind of thinking blows back on real decisions is when someone says, "Look, I know how you engineers think..." suffixed by some opinion completely drawn from the realm of speculation. Subscribe to such thinking if you want to arbitrarily override the work of your best modelers.
The absolute worst kinds of push-back are fueled by identity politics statements like these bait into. You wake up in a conversation about prioritizing core value and someone pushes on wanting to change the color of the drapes and calls the entire engineering team anti-design like we don't get anything outside of text-highlighting in our code editors. It's infuriating.
The key insight you probably miss to understand the article is that it doesn't regard a "UX Engineer" an Engineer.
The fact that the term "UX Engineer" is not even once mentioned in the article is a clear sign that it talks about regular engineers -- technicians and such building a physical product.
And that's OK, the term "UX engineer" is both quite abused and quite recent. Sometimes it's just some ex-designers pretending to be all serious about HCI -- and not any "engineering" with the traditional, robust, sense.
A referentially transparent, small function, has always been easy to write bug-free assuming the OS doesn't lose a page-table entry, a network interrupt isn't exploitable, and cosmic rays don't flip bits. The issue has never been that we can't write something that's correct.
Getting that correctness to propagate because of the strictness of all the tools involved and accuracy of their construction is the issue, which leaves us with needing to either automate proofs with Coq or prove things in more general ways that lead to undecidable problems etc. Still, the fact that one function can be written bug-free and known to be bug-free does indicate that it's not an inevitability of probability playing out as code grows.
We have null-pointer exceptions and no maybe type. The API's that emit nulls sometimes make me expect sewage to leak from light sockets. It's possible to do better. We just don't, and none of us love it. Rust and Kotlin are at least very exciting. I'd like to understand some Coq more in the context of x86. What routines are strictly necessary to even do Coq? A response based on some statement about how the Y-combinator enables X where X leads to Y would not surprise me.
Also true. Still, purity (just part of referential transparency) should be highlighted as something that helps not just with the function you're writing , but also functions that need to call that function.
> With nicer syntax, nulls are equivalent to Maybe types.
No they're not, since you can't nest NULLs.
Say I have a database of "Users", with "birthdates" mapping a "User" to a "DateOfBirth" and "spouses" mapping a "User" to a "User", I can look up a User's DateOfBirth either using a Maybe or by allowing NULLs:
-- Maybe
getDOB :: User -> Maybe DateOfBirth
-- Nullable
getDOB :: User -> DateOfBirth
I can also look up a User's spouse with either a Maybe or a NULL:
-- Maybe
getSpouse :: User -> Maybe User
-- Nullable
getSpouse :: User -> User
So far they're pretty much equivalent. However, what if I want to look up a spouse's DateOfBirth?
-- Maybe
spouseDOB :: User -> Maybe (Maybe DateOfBirth)
spouseDOB u = fmap getDOB (getSpouse u)
-- Nullable
spouseDOB :: User -> DateOfBirth
spouseDOB u = let s = getSpouse u
in if s == NULL then NULL
else getDOB s
These are no longer equivalent. In the Maybe case we can distinguish between three kinds of values:
- `Nothing` indicates that we can't find the spouse
- `Just Nothing` indicates that we can find the spouse but not the DOB
- `Just (Just x)` indicates that we found both the spouse and the DOB
In the nullable case we can only distinguish between two kinds of values:
- `NULL` indicates that either we couldn't find the spouse or we couldn't find the DOB, but we don't know which
- Anything else indicates that we found the spouse and the DOB
The Maybe approach gives us strictly more information; although we can choose to ignore it if we like, either by using `join` or by replacing `fmap` with `>>=` (AKA "bind", which is a combination of `fmap` and `join`).
Yeah, but you're comparing apples and oranges. The nullable case isn't preserving the information you want, because you haven't written the code to preserve it, while in your Maybe case, you have. The two examples you give aren't doing the same thing.
Your nullable example is better compared to this, which also discards the required information:
spouseDOB :: User -> Maybe DateOfBirth
spouseDOB u = case getSpouse u in
s -> getDOB s
Nothing -> Nothing
Likewise, the nullable case, modified to preserve it (in a language which actually has nulls this time):
> Your nullable example is better compared to this, which also discards the required information:
Exactly. Your version is just doing what `join` or `>>=` would do, which I mentioned at the end; ie.
mySpouseDB u = fmap getDOB (getSpouse u)
-- Using join
yourSpouseDOB u = join (mySpouseDOB u)
-- Using >>=
yourSpouseDOB u = getSpouse u >>= getDOB
> Maybes are just pointers. There's nothing magic about them.
Of course there's nothing magic; `Maybe` just increments types. I was phrasing myself in the context of a language like Java, which has NULL but no pointer manipulation.
> With nicer syntax, nulls are equivalent to Maybe types.
In a language that lacks maybes, but has nulls, what is the equivalent of the type Maybe (Maybe Int)?
> Recent C# for example has the ?. and ?? operators, which are flatMap and orElse.
Even ignoring the lack of composability, flatMap is an operation on a broad category of which Maybe is one example; that generality is a key part of its utility. ?. is a special-case operation on nullables, if you want to use it on any of the other things that flatMap works on (e.g., lists), you need a different operation, so you can't build generic algorithms. So, its not substantively the equivalent of what Maybe provides in languages where maybe is part of some broader category of operations on which flatMap can be applied.
> In a language that lacks maybes, but has nulls, what is the equivalent of the type Maybe (Maybe Int)?
int **
> Even ignoring the lack of composability, flatMap is an operation on a broad category of which Maybe is one example; that generality is a key part of its utility.
While it's certainly part of it, I would disagree that it's the key part. The ?. operator is flatMap in the context of Maybes, and Maybes alone are useful for preventing a class of bug (NullPointerExceptions) even without the rest of Monadkind.
> ?. is a special-case operation on nullables, if you want to use it on any of the other things that flatMap works on (e.g., lists), you need a different operation, so you can't build generic algorithms.
Being able to use generic algorithms like sort() on Maybes-as-collections-of-arity-[0,1], while very cute, isn't actually that useful in real code. Particularly real C# or Java code.
Don't get me wrong, I've written code in Scala, and I love the generality of Maybe and related collection types, even though I have hit some interesting issues where I've needed to call .toSeq on my Maybe in order to get the right thing to happen, because they're not quite equivalent. But being pragmatic, and given that C# (and Java) don't have proper Monadic Maybe, and are unlikely to ever get them, I'd quite like the ?. and ?? operators, please.
I started to answer this as a language syntax question, but it really seems like a big API problem. And yeah, just cram them and learn the signatures well. I'd just read a lot of library code and follow along in some hello-world scale examples.
