I find it offensive as well. But people are entitled to their free speech, so jabbering on about it is pretty much pointless. But if you like decency enforced by fiat, you could always move to Russia or NK...
I'm pretty sure it's meant hyperbolic. But we've all had this , it doesn't end with a phone call either.
If somebody who wants something from you can't summarize in a few written sentences what they want from you, it's exceedingly likely no amount of writing or talking is gonna remedy that. If you engage clients like that, you'll end up being very, very sorry.
I agree with you when it comes to clients. Clients want to hire you to do a specific piece of work, and in that case vague, open-ended agreements are indeed poison. When it comes to partnerships, however, the mutually beneficial agreement might not be immediately obvious. It's entirely possible that a "get to know you" sort of conversation will be necessary, will turn out to be very fruitful, and would be impossible to have over email. Also keep in mind, they're vetting you as much as you're vetting them. They want to get a feel for you as a potential partner, and if you behave like the author from the get-go, it's likely not in their best interests to not work with you.
To my second point, if you say you're in charge of product development, it's your job to dive into these sorts of conversations on the off chance they might develop into meaningful partnerships. I can be annoying and frustrating, and it certainly can seem wasteful to someone with an engineer's mindset, but that's why it's a job and not a hobby. Expecting people to come to you with perfectly-fitting opportunities gift wrapped in exactly the communication style you use will keep you from ever achieving anything.
So the most grownup thing to do would be to just agree to meet the guy, yes? I can agree with that. But why not answer a few questions like, are you prospecting for people to hire? Are you looking for a partnership? What kind of partnership? What software are you interested in? I have tons, see. No, nothing, you can give me nothing? Alright, bye.
I am not advocating traditional diets, I am pointing out the silliness of demonizing pasta, bread and rice when many groups of people that basically live on these things do not have the problems that staying away from these foods supposedly solves.
In terms of growth, it was definitely the major problem.
People did not evolve to get the majority of their calories from carbs.
Now, the "carbs are absolute evil!!!!" people do take it to an extreme, but it's just a fact that signs of nutritional deficiency (e.g., stunted growth) appear in the archeological record as soon as a group of people move from a high-protein, hunter-gatherer lifestyle to a high-carb agricultural lifestyle.
If there are any exceptions to this, I'm unaware of them.
You're equating bread and pasta that the food industry puts on supermarket shelves, with the bread and pasta people used to make themselves from flour they got directly from the local mill for grains they got from a local farmer. Not the same thing at all.
Past and bread are grain that has been processed before you eat it. Your body doesn't have to work as hard to turn it into glucose -- zoom. The more your body has to work at processing its carbs the better (but don't eat mulch).
My general sense with keto and the carbs-are-evil philosophy is that it's a handy solution for relatively quick weight loss. It really does work for that.
But it's not at all clear if shunning carbohydrates is a healthier option in the long term, compared with a more diverse diet with similar total calories. As you suggest, there's considerable evidence that grains are not evil.
Actually, the world is getting to the height of how humans were pre-agriculture, at around 6 feet. As Asia and ancient Rome has proven, high carb low protein diets do not make for great height.
There is also reason to believe that a height in great excess of 6 feet is not optimal, however. Our physiology - bones and joints - don't allow for it.
That's not the problem with pasta and bread. The problem is what the food industry does to flour and kernels, and that it's become a fools errand to even attempt to buy pasta or bread that's not stuff full of processed carbohydrates.
It's not news (it's been years that this connection has been made). Nick denied ages ago to be Satoshi a long time ago. Failure to use google isn't journalism.
The earlier analyses where also doing writing style comparisons. So if I say, come up with an almost identical way to test newtons laws of motion, but with a slight variation, it'd be news that to discover that a = (v2-v1)/(t2-t1)?
You don't hate PHP because it doesn't have sexy peripheral utilities like other contemporary language hipsters do. You hate it because it's a badly designed language/runtime/standard library. And it's not getting any better although it had had ample time to do that.
The reason it's not called vertex program is because the pipeline is defined in terms of stages (vertex -> tessellation control -> tessellation evaluation -> geometry -> rasterizer -> fragment). Together they are a program. When talking about this structure the choice that OpenGL made is:
"A shader program consists of a vertex shader (VS), tessellation control shader (TS control), tessellation evaluation shader (TS eval), geometry shader (GS) and fragment shader (FS)."
You could instead say this, but it would be confusing:
A shader program consists of a vertex program, tessellation control program, tessellation evaluation program, geometry program and fragment program.
And it would even get more confusing if you drop the first shader:
"A program consists of a vertex program, tessellation control program, tessellation evaluation program, geometry program and fragment program."
So for the sake of it being easy to talk about, a (shader) program is the whole thing, whenever somebody talks about a "program" it's the whole assemblage. And when somebody talks about a shader, it means one of the programs tied to a stage.
Yeah, this has the side effect of making it almost impossible for newcomers to have any clue what the heck is going on until they have several months of (painful) experience trying to figure out each piece.
It doesn't have to be this complicated. Humans just made it that way. I'm just trying to make sure everyone understands that there's nothing mysterious or even especially interesting about these terms. It's complicated like an internal combustion engine is complicated, not like math.
Sure, it did for me. I think mental models are important, and that it's kind of dopey to call something by a confusing name. (I'm looking at you, physics!) But on the other hand, I'm not very smart, and I had to spend most of my time on gradeschool instead of learning shaders. It was also before wonderful resources like stackoverflow/HN/reddit/etc, so there weren't a lot of people to help clarify my mental model.
As I've gotten older it's become easier to think abstractly and accept that names sometimes have nothing to do with what things are. But when you're first starting out, it's natural to want to visualize everything you learn as what it sounds like.
If shaders are hard, it's mostly because they require a full understanding of 3D math, the complete graphic pipeline, texture sampling, image manipulation techniques and how it all comes together before you can actually start doing anything useful; so the learning curve has a slope of 'wat' to almost all newcomers.
If anything, naming is just a nuisance.
they require a full understanding of 3D math, the complete graphic pipeline, texture sampling, image manipulation techniques and how it all comes together before you can actually start doing anything useful
Hm, not really. I learned more from messing with working demos and prototypes than studying theory. But YMMV.
It's absolutely true that the whole pipeline is very intimidating for newcomers, though.
I love that phrase... "the learning curve has a slope of 'wat'."
I don't personally see why this is so confusing. I think that if you're writing shaders you can probably understand that 'program' is a somewhat recursive term. A program is made up of other programs (a function or a module is a program as well).
But even then, you could call them functions (which is practically a synonym for program in a sense, and also obviously recursive, in that functions call other functions).
Either would at least be less obviously 'wrong' in the sense GP meant it.
But I also think "kernel" is a stupid term for GPGPU programs, and definitely increases the barrier to learning what isn't really all that complicated of a thing (at least not at the intro level).
Note that this site lists WebGL as "IE11+". That's false. IE11 has a flavor of webgl that's experimental (prefixed or not) that's reported as version WebGL 0.92 (this is basically an invalid specification conformant string, it's either 1.0 or something not done).
Huge gaps and bugs remain in Microsofts WebGL implementation which make it nearly impossible to use except for specific select usecases that Microsoft optimized for.
It took google and mozilla about 4 years to get a good WebGL implementation (and they're still not done). It'll take Microsoft years to come to bring their implementation on par with the rest of the WebGL world.
We shipped an update to the IE11 WebGL implementation to developers today as part of Windows 8.1 Update. We will roll this out to all IE11 users through Windows Update starting next week. There will be further updates to our WebGL implementation in the summer.
If there are specific use cases that you're interested in support for, please let us know what they are so that we can prioritise the order of our implementation.
Another measure that's also very useful is to run the webgl performance regression test suite every day to see if performance got worse or better with the changes.
Unfortunately there isn't a comprehensive GLSL syntax test suite, but GLSL has been much of a sore point in IE where some syntax that's valid GLSL would work except in IE (such as uniforms separated by a comma).
I've submitted some tickets to IE (and added more conformance tests to cover them) for some of the gaps (gl.SAMPLES, gl.STENCIL_BITS, gl.SUBPIXEL_BITS).
A thing that's also a sore point is IEs lack of support for very common extensions such as OES_texture_float_linear, WEBGL_compressed_texture_s3tc, WEBGL_depth_texture, OES_standard_derivatives, OES_vertex_array_object, ANGLE_instanced_arrays, OES_element_index_uint, WEBGL_lose_context. You can get an overview of the state of support on http://webglstats.com/
A note on floating point texture extensions. If you implement one extension (for instance OES_texture_float) you should really implement the companion extensions as well for texture_float_linear and color_buffer_float. Only the triplet of extensions provides comprehensive overview of support.
I think the demos above are fairly good usecases for gaps that you might have, because they exercise a lot of functionality, they're not bound to some specific framework (like three.js) but they are WebGL conformant.
