mrbrowning

That’s a good point. Out of curiosity, how do those constraints get surfaced with hosts running in ASGs?

> We also considered simply abandoning autoscaling altogether and pinning to a calculated value, but this would hide performance regressions in the code by absorbing them into a potentially enormous buffer intended for regional evacuation absorption.

I'm probably missing something here, but why wouldn't performance regressions still be detectable via utilization metrics? I understand the difficulty of determining resource allocation a priori, but I'm not sure how this relates.

Well, that’s the point of the article, isn’t it? The long-time employees that were laid off were almost certainly there out of love of their wares, and the parent business could have put the work into making value out of that distinguishing fact. But beyond that, they had institutional knowledge, both of how the business works and what their customers want. I know it’s hard to imagine that retail work could involve any amount of skill or knowledge, but this is no doubt a loss of value.

Bezos cheerleaders and their ilk never seem to be willing to acknowledge that creating wealth is much harder than extracting it, and either out of bad faith or naivety will misidentify ventures that specialize in the latter as being exemplars of the former. In this case, we have the incalculable loss of so many person-years of experience in a deep topic, literature, that’s being shrugged away as a case of the market moving on in a post facto justification of the actions of some corporate raiders that never even considered alternatives beyond stripping a company of its assets for their own sake. I just wish we could be honest about what actual competition, what actual wealth creation, looks like, because this isn’t it.

Mongo as a business has largely catapulted itself to where it is by making money off of information assymetry more than actual technical superiority. They may have since corrected a lot of the fundamental technical isssues with their product, but that doesn’t change the fact that (contrary to SV dogma) their success doesn’t rest on the creation of wealth, only its extraction from magpie-type customers. Downvoters likely chafe at the notion that such a strategy is laudable or valid.

You can totally reimplement a model that the browser supports natively, but you close off basically every affordance that a page-based approach provides unless you commit to reimplementing things like (among others) accessibility support for screen readers or reader views, usability with nonstandard clients, and interoperability with the client's environment (I guarantee that your custom progress bar doesn't have the same semantics as the loading spinner on my browser tab). Most of these things come effectively for free with regular pages, so I don't see what benefit doing extra work to reduce your product's flexibility has if a page-based model already suits your content in the first place.

> Most of the founders I deal with pay their employees before the founders themselves get a dime of salary. Sure the founders get the bulk of the equity. But they also give their employees equity awards, even though the employees get paid a salary, as well (i.e. they don't take on the same risk).

Employees don't take on the same risk because they typically can't bear the same risk. This is the equivalent of lauding the bravery of a stunt double for jumping off a roof when they've got a big blue safety cushion waiting for them just outside the frame.

Well, you're actually making metaphysical claims more than mathematical or physical ones. One of two assumptions, depending on how literally the sentiment that the universe is a formal system is intended, is being elided here:

1. That the universe _is_ a formal system, rather than being describable in the language of some formal system. It's not evident what the universe being a formal system even means, or how it squares with basic intuition regarding e.g. the fact that physical systems have state.

2. That, dropping the physical system <=> formal system equivalence and given some real system R consisting of some fundamental entities whose behaviors can be described in full in the language of some formal system S, (borrowing a useful construct from Lucas' anti-mechanism argument, even though I don't buy that argument) no machine can be constructed in R which computes theorems of some formal system S' in which all true statements of S are provable, meaning that no state of the system R can be said to contain a description of S', and that S' is therefore not describable by any arrangement of the entities in R (assuming some reasonable predicate over states of R that is true for a state when some arrangement of a subset of the entities in that state describes S'). Intuitively, this doesn't seem to hold up: by analogy, I can describe a universal Turing machine with a computer equipped with only finite memory. You could then attempt to go down the road of claiming that, even if a description of S' is possible in R, that a mind within R would not be capable of formulating that description, but then you're heaping on an even larger tangle of assumptions, unknowns, and things you have to define if you're going to argue the case rigorously.

The point being that confidence about _any_ hypothesis about the nature of reality made on the basis of Gödel's incompleteness theorems is not epistemologically warranted.

You're right, and I ought to have mentioned the difficulty of implementing something like that for Clojure. So maybe the issue is more holistic, which is that it's hard to tell how it's positioned: it's not quite the sort of language that drills as deep as possible into the affordances of being a Lisp, but it's also not quite the sort of language that does everything just well enough, given its investment in, for example, immutable data structures. That doesn't stop me from using it, or presumably anyone else who gets value out of using it, but I sort of idly wonder what the cases are that it's uniquely suited to.

It might not matter: maybe being the obvious right choice for some use case in the abstract isn't that important, and contextual factors re who's doing the work and how they think are just as relevant to choice of language. Still, it seems like we tend to talk about languages now in terms of their most indispensable applications, for better or for worse.

I really enjoy Clojure. Persistent data structures, core.async, and transducers have all been really pleasant abstractions to work with. I've been writing in it for fun and utility for maybe five years now, and have used it for one mid-scale contracting project, so I hope that that's sufficient background to prevent dismissal of the following as the gripes of a beginner, but: it's so strange to me, for all of the appeals that Clojure makes to an interactive development process involving the REPL and immediate feedback, that a first-class debugging experience on the level of Common Lisp's doesn't seem to be on the roadmap at all. The type of explorative developing you do in that environment, with the ability to drop into the debugger on error, alter the function body and restart the frame with your new code, seems about as far beyond the standard Clojure workflow as REPL-based development is beyond the save-compile-fix cycle of less interactive language ecosystems.

I can deal with the Java stacktraces and the occasional mystery of which concrete class is actually backing IPersistentMap after however many invocations of assoc, but if the experience of writing code is going to be a pillar of the language's sales pitch, why isn't this sort of next-level debugging experience on anyone's radar? The CIDER debugger is nice, but it's not CL nice.

The article touches on the technical details of this briefly, but the underlying point here is that containers effectively do use the OS, and processes. Like Frazelle says in the article: "a 'container' is just a term people use to describe a combination of Linux namespaces and cgroups." If that's nonsense to you, check out some of her talks, they treat those topics in a friendly way. At the most basic level, though, a container is just a process (or process tree) running in an isolated context.

Sharing library code between processes running in containers is more complicated, since it depends on whether and how you've set up filesystem isolation for those processes, but it's possible to do.

Alain Ducasse recommends allowing a hot take fresh off the pan to cool for half as long as it's been cooked, so I guess I'll open this back up in about two and a half minutes.

That's a good point, and I didn't mean to parrot FUD by implying that that multiple definitely exists; more that, even if die-hard C++ boosters are right about it existing, it's still not the ace in the hole it's made out to be given all of the other factors that likely overwhelm it.

This is myopic in the characteristically self-undermining way that most of these defenses are.

I actually like modern C++ well enough for the niche described here; lambdas (and the control they offer over captured variables), type deduction, ranged fors and the like make it pleasant enough to write for being as performant as it can be. I've written many more lines of C++ than Rust. But it's still apparent that language-enforced invariants are quite a different species from conventions that will enable safe programs if everyone uses them correctly at all times. You can maybe guarantee that for a team, but can you guarantee it for several teams? Can you guarantee it for every external dependency?

I can imagine plenty of pragmatic analyses today ending up with C++ as the ideal choice of language, but the monomaniacal focus on Performance ignores ecological concerns like these and also mostly doesn't grapple with the fact that there's plenty of low-hanging fruit to get to performance-wise in any project before something like a fundamental 1.2x performance penalty on Rust's part really matters, especially considering how domain-dependent that number is likely to be. Pure speed is a pretty poisonous obsession in our field, IMO, and I think we've reaped the whirlwind for it already. It's time for a more holistic outlook.

It's not a totally different thing, it's the same thing with me driving on the left side of the road instead of the right. We don't know if this would cause horrific, fiery tangles of flesh and steel or not.

Unsurprisingly, the answer to "would you react the same way if a totally different thing happened in a totally different context?" is: no.

Preprocessors are uniquely problematic in this regard, though, since they're just simple text-substitution engines. Things like templating (as in C++), in-language macros (as in Lisp variants), or language-level metaprogramming facilities (as in Ruby, Python, ...) all have access to actual entities in the language, which constrains their effects in a way that's safer and easier to reason about.

But testing ensures no such thing, considering that comprehensive testing across the entire space of possible inputs for a unit is infeasible in most cases. Part of the usefulness of static typing is to prevent us from having to negotiate that state space explosion head on by a priori ruling out vast swaths of potential inputs.

I think static typing and testing are much more complementary than you're giving them credit for.

This is a remarkably facile understanding of racism, one that ignores both the model minority phenomenon as well as the fact that Asians are significantly underrepresented in management positions in the tech industry [1].

1. http://www.npr.org/2015/05/17/407478606/often-employees-rare...

I had a lot of difficulty getting it compiled too, but this helped a lot:

http://installing-caffe-the-right-way.wikidot.com

That guide is mostly correct, assuming your reply here means that you're also using OS X. It should get you all the way to a working Caffe install. The one thing it doesn't get right is that your PYTHON_INCLUDE and PYTHON_LIB variables should both point to the relevant folders from your Homebrew Python install (I had no luck attempting to compile pycaffe against either Anaconda or system Python, both would just segfault when I imported the module). In my case, that was (assuming you've already installed numpy with Homebrew pip):

PYTHON_INCLUDE := /usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/include/python2.7 \ /usr/local/Cellar/python/2.7.10/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include

PYTHON_LIB is exactly as it is in the example Makefile.config on that page, except adjusted for version number if you've installed Python via Homebrew since 2.7.10 was released.

Safari's speed is a tossup for me, in that opening new tabs and typing in the address bar both are often preceded by several second (!) delays before the UI responds. This persists across multiple instances of clearing all of my browsing data and even migrating to a new laptop. That I continue to use it over Chrome in spite of that implies a lot about the sorry state of browsers in general right now.

As I like to put it: unit tests don't affirm the correctness of code with respect to a specification, they merely affirm that certain implications of the specification hold with the code under test. In that sense, the general tendency to assume correctness in the face of passing test suite is basically an instance affirming the consequent on a huge scale.

Personal anecdote isn't evidence, but I trust it more than handwaving appeals to evo psych. You do realize too that humans at college age don't have fully developed frontal lobes, otherwise known as the seat of planning and discipline?

Consider that the author spent one short paragraph to talk about the OP's choice of pronouns, while you spent an entire comment taking her to task for it; that her criticism was politely stated, while you employ rank hyperbole in describing that comment as "[destruction]"; that you're expecting someone to be polite and dispassionate who by her own admission has dealt repeatedly with the litany of disappointments and frustrations that come with being a woman in a male-dominated field, while not even meeting that standard of even-handedness in your own comment; and then maybe reconsider how you're devoting your efforts in this conversation. From here it looks like thou dost protest too much, methinks.

That's an ideal scenario, though, that implies that all of your view/controller/model through-lines can be isolated vertically from each other. In fact, controllers often coordinate the actions of multiple models to achieve higher-level objectives, and it's at this point that the relatively greater cohesiveness of layers versus features becomes apparent.

I used to work in a pharmacological research lab, and while I'm frequently discomfited by the misalignment between commercial incentives and social good in the pharmacology industry, this statement isn't quite fair:

> Everyone has heard of "mission creep." In the pharmaceutical world, approval creep means getting the FDA to approve a drug for one thing and pushing a lot of other drug approvals through on the coattails of the first one.

This is more accurately referred to as "drug repurposing," and it's hardly the unalloyed evil that it's characterized as here. It's true that drug companies love to repurpose existing FDA-approved drugs, both because it saves them money and because it typically permits them to patent the compound again in a new context, but there are nonetheless real benefits to the public at large when a drug whose side effects are comparatively well-characterized over the long term is put into service to treat a different malady.

But then the mere fact that a computer comes with a browser already installed is not a notable advantage. I can get a Python REPL running on a computer with an amount of effort and know-how comparable to that necessary to install Chrome.

It's not important for students, I just dispute the notion that JavaScript has any special affinity with Scheme beyond that of any other language with first-class functions. Anyway, the major advantage of immutability by default is that it enables under-the-hood optimizations like structural sharing that make FP the paradigm of least resistance. To the extent that JavaScript doesn't do that, it doesn't really deserve to be called a functional language any more than e.g. Ruby.

I don't see running in the browser as a benefit. It means that a required step for a neophyte in producing meaningful output is getting a handle on the utterly brain-dead DOM API.

Immutability-by-default is a necessary, if not sufficient component of the semantics of Scheme that is lacking in JavaScript, and it's that same lack that leads me to think that any comparison between the two languages is basically spurious.