1,747 karma · joined July 14, 2014
To say it another way: what we (C++ programmers, stereotypically) don't like about GC is that it incurs long search costs at unpredictable intervals. That long search cost is not dissimilar in nature (i.e. in algorithm) to the cost of this search. So it's not clear to me that the performance characteristics of `internal_ptr` would be much different from those of GC. I'd like to see the performance characteristics of the solution filled out with more detail.
At the extremes, there are two ways to deal with selfishness and laziness. You can let it go, allowing people to make their own choices and face their own consequences, hoping they'll have enough foresight to avoid ballooning dangers. In economics and government this is generally associated with "conservative" politics. Or you can control people through rule-making and enforcement, preventing them from making choices they should know will end up bad and forcing them to take the right actions. This is associated with—somewhat unexpectedly—the "liberal" approach.
It's pretty clear that either extreme is a bad choice. Pure conservatism allows the wealthy and powerful few to exploit the oppressed many, the large corporation to crush the individual, the effective short-term competitor to ignore long-term costs to self and others. Pure liberalism crushes individual choice, presumes the wise choice of those who rule, sustains complex legal and enforcement systems, and adds the profound inefficiency of government to the many expenses a society must bear.
Yet anything in between the two extremes is difficult. Ambiguity abounds. No single choice for a conservative or liberal approach—in health care, for example, or gun control, or airport security, or child rearing—is clearly correct and without serious downsides. People are difficult. Living together is hard.
If there is a clear error, therefore, it is an over-enthusiasm for one extreme or the other, an over-pessimism for the other side of the aisle.
What's more, one's own self-bias is all but impossible to see. This article begins with pretensions of objectivity that the author compares, if vaguely, to mathematics, yet the bias of the author shines through unmistakable. He searches for objective premises from which to argue, yet even the way he frames the questions, even the premises he chooses to expound all but guarantee his conclusions.
And so here we are: difficult people, trying to live together, discussing—or pretending to—how best to do so, yet choked full of our own biases and unwilling (because we are selfish and lazy) to really hear the other side. And that's too bad, because the right answer is surely a blend, a case-by-case blend, of freedom and legislation.
When you compare the laws of the EU to nations contemporary and historical, I think it's pretty clear that it skews liberal and that there is a great deal of legislation: legislation "for their own good." It's possible that the EU has good legislation, a good amount of legislation, and that it is effective in enforcing that legislation such that the member nations have done, are doing, and will do better than they would without the union. (Not just economically better but morally, ecologically, etc.—whatever values we ought to care about. Though that's not clear.) But it also reasonable to wonder whether the EU is incorrectly skewed toward too much legislation, or of the wrong kind, or with bad enforcement, so that the member nations, or perhaps a single member nation, would do "better" (by some sound standard) removing itself from these laws. It helps in making these speculations that the EU, after all, is quite new in historical terms; Britons can look back even in their own memories and know what life without the EU might look like. There's no going back really, of course, but there is some historical basis for speculation. They can also look at their own values and culture and look for broad compatibilities or incompatibilities that might bode well or ill for the ongoing relationship.
It seems to me that the choice comes down to those kinds of questions. Were Britons better off before the EU, and if so, do they have a reasonable chance of returning, post-EU, to a similar or better situation? Is the rule of the EU over the UK, considered historically, abnormally invasive, complex, or incompetent, or is it on the other hand effective in legislation and enforcement?
So I think it's a historical, not mathematical or even—quite—logical question.
I can postulate a universe in which my molecules and everyone else's have been precisely duplicated from this universe in physical terms. I can postulate that in that universe there is no such thing as conscious experience; no qualia or whatnot. I can imagine that universe continuing from the moment of duplication onward, proceeding as dictated by the laws of physics. My duplicate in that universe would probably not act exactly as I will, but will certainly act in some way.
Simply the act of postulating, of conceiving, of that kind of zombie universe is enough to strongly suggest that consciousness is something outside of the physical. The zombie universe doesn't have to be identical in behavior, only identical physically. Because what you've now done is to recognize that a universe in which physical objects and laws are the only elements is a universe in which mental (experiential) phenomena are unaccounted for. You can imagine that those mental phenomena magically, mysteriously re-emerge from the physical, but have given absolutely no reason why they should. Therefore you can equally imagine that they don't re-emerge. So whether zombies behave identically with real people or are merely constituted identically with real people, their conceived existence is enough to show that the mental universe—so to speak—is conceptually detached from the physical and therefore a separate domain.
My advice: if you have skin in this game and need to make real decisions about what platform/language you use, find an article that reasons soundly about what the questions are and convinces you of its answers. Don't listen to this one. And if this quality of thinking is diagnostic of how Ruby/Rails developers think generally... well I'm glad that's a game my skin is safe from.
But surely we believe in "free will" not because we observe it in a lab but because we experience it directly. Pick up a menu at a restaurant. Sure there is mechanistic cause and effect going on in your selection—memories, sights, smells—but there is also the direct experience of choosing. Whatever free will is, it has to do with this experience of bringing a cause into the universe essential ex nihilo, from within yourself.
Science is always compelled to dismiss these individual and personal experiences and perceptions, and as science rightly so. But as people we can take them into account. And so we should. To dismiss the sense of "I" that makes us, in fact, people is to cast away perhaps the most important part of our world. We retain a sense of choice, of free will, not because it's a compelling illusion but because it is in fact in large part what we are and what we recognize others to be. Be careful with that word "illusion": you can call something an illusion, but you then have to account for where the illusion came from and why it functions so powerfully. I'd say that free will is not an illusion so much as a thing that science deals badly with and is therefore tempted to dismiss. Well, dismiss free will from the laboratory, sure, but don't pretend we aren't free-willing things or you'll be left with nothing but a lab, populated by not-quite-people.
The author says that the real attraction of flea circuses included "seeing insects in costumes, pulling carriages, or racing each other." Is he seriously suggesting that fleas were somehow wrangled into miniature suits?
The article concludes with the head-patting remark that the Victorian credulity about flea circuses is "humorous, but not surprising." It's not clear to me that the joke isn't on moderns who believe in that type or degree of credulity from our comparatively recent ancestors.
1. "boom" is not the right name. Explosions. Annoying/scary sonic boom. These are not the associations you're looking for. Try "glide," "zip"—something along those lines.
2. In your very first team picture I see a grumpy-looking fellow with hands in pockets. A few images on he's still there, now joined by another grump with crossed arms. These people look disengaged and/or disgruntled. Call me shallow, but it just doesn't look right for a team supposedly revolutionizing aviation. Ask your team to look engaged when taking PR photos. Or if there's a deeper attitude/team dynamics issue there, man fix it now. I don't want my life "booming" into oblivion because some guy was fed up.
There's an analogy here between inheritance -> interfaces and pointers -> object references as in a language like Java. Object references are pointers, in effect, but syntactically pared down so that it's (much) harder to break them. They are less powerful but safer. Similarly, if you have inheritance—particularly the dreaded multiple inheritance—you have everything interfaces can do and then some, but you also have much more responsibility and a lot greater chance of creating bad designs. In both cases, it makes sense when teaching the concepts to teach the fuller, more powerful concept. In day to day work, however, many programmers will make fewer mistakes using the more limited concept.
To say this a bit more clearly, but perhaps more insultingly: inheritance, properly and fully understood, is useful for a massive range of situations, of which mixins and interfaces are a part. I find that relatively few programmers (and I've worked in development for more than twenty years and taught programming at the Master's level for 7: I've taught a lot of programmers) can really grok proper inheritance to this level; therefore when they try to use it they end up shooting themselves in the foot, then blaming the tool. For them it's better to use the more limited tool. But it's still good to know the broader tool.
To enjoy good inheritance, first learn to think in layers of abstraction. If this is hard for you (it's not easy for anyone), either train yourself to do it or don't use inheritance—but then don't criticize inheritance for your own shortcomings.
Second, make each class properly express its proper abstraction. Abstract things like "items" should be very abstract. They might have a price but have no idea how price is calculated. More concrete things like books and movies should have more concreteness, but no more than necessary. Often, "deep" layers of abstraction really are little more than interfaces. All the major languages have ways of expressing interfaces as distinct from classes as such, but there is no distinction between them at heart: an "interface" is just a very abstract class; that is, it offers methods without (or with few) implementations. Whether you use "interfaces" or "protocols" or "abstract classes", your language probably offers ways of expressing "lots of abstraction" as well as ways of expressing "more concreteness". Think in layers of abstraction and then use all the tools available to express that thinking directly.
When requirements, or insights into the design should work, change, then naturally anything can change, from interfaces to detailed implementations. No tool, language, or technique will prevent change, but a clear mental model of what is being expressed and code that succinctly and directly expresses that mental model is your best basis for coping with change.
Don't blame inheritance. Don't, for crying out loud, praise interfaces when they are simply a purified form of abstract inheritance. Learn to use the tools that have served millions of programmers well for twenty or thirty years and then the tools won't seem so dangerous and strange. Or, if the tools really just don't suit your way of thinking, don't use them; use other tools; but either way don't blame the tools.
Object oriented analysis and design, done well, is not bad: it is good. It's not wrong to design a class, even a hierarchy of classes perhaps, for a toaster program. Whether doing so is helpful or harmful really does depend on the functionality and complexity of the toaster and the skill of the class designer.
So: sure, bad software design is bad. Thanks for pointing that out. But if the implication is that all (or most or "usual") object oriented design is necessarily bloated, overworked, and excessively forward-looking, then no: only when it, like overcooked bacon, is done badly.
There. My 20+ years of experience in software architecture in various fields from games to networking tells me that you now know enough to work out the classes and their relationships in a large software system.
Don't fuss around with "aggregation" or "composition" or whatever. Don't spell out functions (though occasionally I'll jot one below a line to remind myself what the salient feature of the dependency is). And by no means write the class properties, their types, or their access specifiers (public, protected...)—this is way too much detail. A UML diagram is useful in modeling broad object relationships in a system. If you want to work out what properties a class should have, write the damn class. Any software developer worth his salt can figure out the code from a high-level diagram; don't write the code for him. Or do, but then don't call it an architectural diagram.
I know there's a whole culture of software development where architects design code but don't dirty their hands with writing it, then hand it off to underlings who type it up for them, and so on down some kind of techno-bureaucracy Great Chain of Being. Rubbish. Code architecture is a thing and some kind of diagramming is helpful, but UML as such is the sort of busywork and IRS-style hierarchism that marks bloated government jobs, not real productivity or real teamwork.
Give UML a miss and use something very, very simple.
Ultima Online had begun as a small band of junior developers within Origin back in like 1995. The original concept was to build a massively multiplayer game using a variant of the Ultima 6 engine. That was a pretty far throw back considering that Ultima 7 and 8 had shipped with much more advanced features and Ultima 9—fully 3D and "modern"—was on its way. The group of programmers who worked on Ultima Online for the first few years were brilliant, talented, and driven, and they produced a lot of great work. The game would, of course, never have happened without them. But, they were absolutely green programmers, fresh out of high school in some cases, and... well, let's just say that the Ultima Online engine began to sag under the weight of its massiveness by the end of 1996.
One example just to illustrate the idea. In most game engines even at that time there was a conceptual difference between The Camera and The Player. Though the camera would often be attached to the player, you could normally move the camera someplace else—to show an in-game cutscene in which the player wasn't involved, say. But in the Ultima Online engine this distinction was lost. The camera was the player: where the player was, that's what you were looking at. It meant that when we wanted to show a cutscene, or a clairvoyance effect or suchlike, we had to use a hack: make the player invisible and non-colliding, teleport the player to the scene, move it around like a camera, then teleport it back to its original position and reset its usual state.
This sort of thing was commonplace. Imagine this times 100,000.
So here we have several young, gifted, powerful programmers making history—as they know, though hardly anyone else did—building a brilliant but difficult concept into a working implementation, often naively, sometimes shoddily, but effectively, productively.
Late in 1996 Electronic Arts (who owned Origin) woke up one day and realized that they had a massive potential hit on their hands. A game they could sell not just once, but once per player per month. Game subscriptions were a whole new concept, and boy what a tasty one.
After waking, the next thing EA did was to demand that the game ship by summer 1997. That gave Origin about six months to ship a huge, complex, wildly innovative concept that was barely out of the prototyping phase. This was, to say the least, an ambitious goal.
So they threw bodies at it. The Ultima IX team had been working on "the sequel of sequels" for quite a few years. The team was large but progress was slow. Although Richard Garriott would never let the game die, EA had no real enthusiasm for it (and indeed in the end it shipped, and was quite good fun, but buggy and didn't sell well).
EA put Ultima IX on hold and moved all the developers onto the UO team. That more or less quadrupled the size of the UO team overnight.
So now you have a small, brilliant, fast, naive cadre of programmers for whom UO has been their baby for a few years squished together with a large, perhaps less brilliant, slower, but wiser and more experienced pile of developers who are pissed about losing the project they've waited their whole to complete and find the idea of shipping any game, much less the world's first bona fide MMO, in six months positively laughable.
There was fear. There was anger. There were frenzies of productivity. There were frenzies of laziness. There was hope. There was dread. There was culture shock. There were absolutely awful tools. There were absolutely indecipherable codebases spanning Windows and Unix, with no documentation and the only people who understood it were too busy (or just didn't care) to answer questions. There was a game that could never live, could never run, could never be tested or debugged on a single system—a game that was intrinsically an MMO and needed a shard to run.
There were tiny bugs that took many, many, many weeks to find and fix.
This feels like the right time to quote Dickens: "It was the best of times, it was the worst of times." Only it wasn't. It was just the worst of times. And despite all the joy that UO seems to have given other people, it was a loathsome development experience—I can't think of a worse or more accurate word than loathsome—and after it shipped in September (was it?) of 1997, just about on time, miraculously quickly, I never played it again.