knappador

Did not eat the 1/3lb hamburger at A&W. Knows math.

Who is building the engine?

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.

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.

Source on Jet A specific heat: http://www.exxonmobil.com/AviationGlobal/Files/WorldJetFuelS...

Source on Lithum Air theoretical specific energy: https://en.wikipedia.org/wiki/Lithium%E2%80%93air_battery

Jet A price: http://www.indexmundi.com/commodities/?commodity=jet-fuel

Lithium Carbonate Price (ev grade): http://www.globalstrategicmetalsnl.com/_content/documents/40...

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.

Safe points, jit, and VM all introduce extra layers of complexity. I bet it's definitely harder in the context of the JVM muddying up the picture.

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.

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.

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.

Right. I had a moment of severe mistrust develop around all the times I've heard the phrase "neural network" mouthed in a pitched voice after I studied the math and realized it was barely cooler than Taylor series approximation. For a moment stacked Boltzmann machines were going to stay in obscurity, but then they became "deep learning" while also solving real problems. If there is one thing I could contribute to the popular programming lexicon, it would be making sure that the phrase "isomorphic" gets used for something other than javascript.

Not two years ago I was having a conversation with an old friend that went approximately:

"Facebook, this whole internet thing, hasn't really..."

"...worked out"

"Yeah, this isn't what we thought it was gonna be. Let's just... "

"...turn it off"

There was a belief implicit in the idea of every human on Earth being connected. Many of the phenomenon that came about have made that belief look vulnerable to a certain cynicism, a cynicism about humanity, that we fear in each other, that we hold towards ourselves. A currency that bound us together face to face became fiat and then failed at scale. It is within the vacuum painted by this fear that the organizing effects of the old-world economy have been fallen back on, but I do not presently fear this cynicism, and I save my currency wherever I can earn it.

Don't count out Kivy for a modern UI toolkit, but speed and no requirement to include a runtime for distribution will not come for Python without a different approach to execution.

Wish there was a part of the airplane that wasn't $400k

Yeah, I recently heard someone talking about taking huge personal financial risk to keep a startup going and suggested maybe it's time to live and learn and start over with a hell of a lot better product-market fit or spend that money on Treehouse and an apartment for a few months to learn how to build something, which could just be their first successful product.

There are too many people willing to seed a decent product to go all-in with anything except time and soul.

Chris Sacca has a pretty damned interesting tale: https://www.youtube.com/watch?v=6VOQnK7O2To

When in C, Python, Java, JS, or anything else does reassigning a variable from the function sig ever work? The symbol is in-scope. Even when overwriting the pointer location in C, you don't just assign; you de-reference and copy over the memory that was there. A novice programmer would make this mistake, not a novice Java programmer.

Novice Java programmer reads title, mutates Java object inside function, later notices side-effects, and curses author of the title.

Second novice Java programmer reads title, wants to pass objects into functions, wants to avoid expensive stack copy and writes &myObject, gets compiler error, Googles "Java pointer," and curses author of the title.

Lesson learned: author of title is either unaware of the consequences such an interpretation will cause or seeks cursing as a source of attention.

Oh come on HN. This is one of the important incremental techs that bridges the risky breakthroughs like metal-air cells. EV's. Quit ironing skinny jeans ^^

Okay, cool. Now that I've finished being uninformed enough to get questions out of the way, I'm guessing you chose Sails because it has some kind of JS DB for prototyping. I would spend time asking if Sails is the desired output format because, although I've only used it during a Startup Weekend fling, it feels like a framework, and don't forget that it's said that while you can plug your code into a library, in Soviet framework, code plugs into you -- I imagine that although a backend dev might be thinking, "Great, Node, kill me softly with 'undefined'" they would still kill if the implementation was really minimal with nothing in their way; if they like another JS framework or want to write a common backend for web and mobile apps, not having Sails' distractions in the way could be big for legitimately doing some of their work for them.

Another big feature would be doing the work to plug persistence into other DB's to make the output DB agnostic to some extent. Migrations would be the next step, but too much of a chore. All you need are to define data models for XYZ ORM/DB adapter to make the machine-generated step hit the right starting point for hand-off. If the ideal use case is in prototyping, I don't think migrations is in the right vein.

Armchair-CTO, signing off.

I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull 300req/s. That's a step beyond just using Heroku, but also a valid competitive option.

How would you position your product relative to Heroku in terms of power and how much schlep you trade for how much ease-of-use? I think it's very okay to be clear for now in order to convert well with your core customers.

How to know if you might be a customer: Did you make a mockup that needs a backend but have little backend coding experience and are sick of including a bunch of the same libraries? If yes, maybe.

In short, they're integrating some commonly used API's and backend programs (Elastic Search etc) and putting a graphical programming model on top of it.

Crappy backends are pretty easy to throw up on a VPS or Heroku these days. It's so easy that I'm likely to select an app server(s) and language based on what library (if any) is most critical to that particular request type.

At first I wasn't sure who the target customer could possibly be. Was it a PaaS service? BackendaaS? A service like this lives in a weird space. It's almost only good for early product dev and when the team's backend devs are green.

Things like having unit tests, scale, completely custom capability etc will drive everyone who makes a successful product out at the very time that they can start to afford paying a lot.

Don't burn all your money yet ;-D

The headline made me expect several things until I saw that it was Khronos, the group that gives us, among other things, OpenGL API's. Looks like the Next Generation OpenGL is getting more ready to show off.

With Metal and Mantle, it was clear that graphics programmers were wanting to use GPU's at lower levels of abstraction to more efficiently utilize the design of GPU's, which have a much different architecture than a decade ago. Without a corresponding option that is standards compliant, low-level API's are threatening to fragment GPU programming.

One operation I didn't see any mention of that seems to have some future role, albeit completely uncertain, is the Heterogeneous System Architecture Foundation spear-headed by AMD and having seemingly every chip-maker except Nvidia and Intel on-board.

As GPU stream processors get more CPU-like but are natural at parallel processing, it is a matter of time before we get the right abstractions so that map gets scheduled across many stream processors and is reduced by a higher-single-thread performance CPU and suddenly computer vision and many other naturally parallel data synthesis workloads are programmed in a less heterogeneous software environment and executed on chips where the stream processors and CPU's share a large amount of commonalities, possibly down to micro-op compatibility through something Nvidia could be pushing towards in their Denver architecture (as yet highly speculative).

To somewhat less than enthusiastic coverage, Nvidia has been building up their partnerships with automakers like crazy. Computer vision is obviously one of the applications that will be required in self-driving cars. Tango and other projects are also quiet beneficiaries of Nvidia tech maturing into the Tegra platform.

We have far from conquered programming and CPU design just because JIT's are good, 8GB of RAM is expected or GPU's can mine MHashes/s etc. We're in some future's bad-old-days. The idea that Khronos is involved in the unification of graphics and computing API's as well only makes the exciting question of who will drive our cars more intriguing.

Shipping with the API calls pre-loaded helps unless you need to fetch additional view code. There's a lot more potential usually for multiple round trips than just API calls. Iso JS frameworks seek to solve the whole range of problems and provide structure for clean implementation. They're greatly aided by the portability of JS. Injecting local-fetched API results as JSON into the page solves one of many potential causes for multiple RTT on fat clients.

I'm fooling around. I'm sure everyone on the project rightfully will get a ton of return on their investment. I'm actually working on a browser UI myself. It's only because of platform OS integration that I'm using Java, but one thing I did learn using a lot of Kivy is how much of a pain it is to be far from the platform libraries.

Unlike Kivy, which is Python, you've chosen JS, so at least your UI is on a more naturally portable layer given that you have a browser runtime right there. Documenting your plumbing into the system libraries will be really critical. The JS community will hack every other piece of the system on their own, but user after user will shy away from the system plumbing because it's not what attracted them initially, so I would prioritize there.

Writing cross-platform UI's may be a pipe dream for now. OpenGL is headed towards a weird place with Mantle and Metal etc while OpenGL Next comes together. The HSA Alliance (Notably missing Nvidia and Intel) might offer some hope that CPU architectures and graphics API's (and GPGPU) will converge again, but right now, HTML5 with JS is probably the best we have for sheer everywhere.

Probably where I would diverge most sharply (and somewhat irreconcilably) with the web community and perhaps even the high-minded ideals of Mozilla is HTML/CSS, but the "superior" tools I find in Android are themselves relatively new. Do I wish that HTML/CSS/JS would go away? Yes, but without need of burial. A technology will displace it someday through sheer elegance that unicorns had not yet fathomed. If it's at all recognizable in what I'm using today, it's an early stage experiment.

In javascript in javascript in javascript... The time when concern seemed actionable has passed; It's clear that the infinite recursion is well underway, and because the arguments are just returns passed in-register, that the call stack will never overflow. I can't tell if there's any logic or reachable return pathways. Is the only way back to reverse time and to have never entered the fractal in the first place? Save yourselves. We can never see the fate of matter that has passed into the event horizon already. The big picture can't be found in the smaller imitations. We can't say that it's over, but we must hold it within our culture that using javascript within javascript is a warning sign, such as curiosity about death or whether the world is a projection of our minds. We must remember that ineffability is effable rather than attempting to reach that effability in all except analytic proofs; even computation of lowly derivatives or irrational numbers cannot be perfectly calculated via machine. Friends don't let friends implement javascript or vehicles for javascript within javascript. It hasn't been proven that there is a conclusion to such exercises. Meanwhile, many have perished chasing truths we can only imagine may be ever even slightly distinguishable from within this universe.

The future of anything we wish was built out of philosophical purism is to be built on crowdfunding.

As for this particular case, SSD > liberty for me. I'd rather boot at a reasonable speed than die waiting to copy files.

I dunno about the fall part. I went into the market headlong with a stripped down concept called Reduce on the Play Store and came out with a job before I could even complete feature additions =D It never fails to pay to build something.

I use malloc and brk :-/

Go correct Wiki.