megrimlock

Could you construct a closed cycle path of 35 deg internal angles in 3D?

Meta: One funny thing about online discussions is that the activation energy required to make a post means they tend to be by people with extreme positions. The same phenomenon that leads to bimodal amazon review distributions of 1 star / 4.5 stars, or blog posts about how golang sucks/rules, means that an open-minded reader needs to continuously apply this huge smoothing windowed filter over the point-sampled views you read.

Some schools give good industrial training; some are still bemused that machines exist that perform the computations that are so fascinating to study in the abstract. We need both. It's true that schools can't manufacture stars, but they can help train those with latent ability, just as Real Madrid players are certainly helped by coming up through smaller teams.

Likewise, some places (YC startups, or forward-looking splinter groups in larger industry) need rock stars who can do a lot; but there's a huge swathe of megacorps that just need warm bodies that can tab-complete API calls; the problem with debates like this is that arguments are so rarely anchored by a clear context. Are we doomed to always argue straight past one another?

Could you expand on what you mean by "I very rarely trust the author"? Isn't using their work a statement of trust?

Source or binary, you are still embracing their description of tasks for an automated machine to perform very rapidly.

If you are wary of what they have done, it's true that source is somewhat more accessible to examine than machine code, but for any non-trivial program source is still quite expensive to evaluate.

Patrick has put his finger on this concern before, and (I feel) persuasively reframed things to resonate with an engineering mindset:

  http://www.kalzumeus.com/2012/01/23/salary-negotiation/

I've tried to use this same reframing approach when working with people to estimate a software schedule (for complex projects with external promises). Basically, if you can establish that engineering is about tradeoffs -- such as between runtime and memory footprint and code size and small vs large values of N and so on -- then certainly human development time is another resource subject to tradeoffs, where we should identify alternate scenarios and try to aim for the optimal one.

Finding ways to talk to people in terms that resonate is tricky -- and often almost a matter of bridging micro-cultures, where subtle tribal affinity signals are needed to gain trust -- so I was impressed that Patrick could break down salary negotiation in a way that didn't seem skeezy to people who just want to build great things and not worry they are getting shafted.

If my reading of patio11's business of software stance is accurate, I believe he'd say these irate emails are actually helpful signals to you that these people are not a market you want to bother serving! Because they have so little invested in understanding your product and making the most of it, they need to compensate with volume and vitriol. It's better to focus on people who more strongly need and want what you are selling and are willing to signal that with $$.

> I saw at least a quarter of every working day wasted in routine status meetings, in which two or three of the ten or twelve people present spent an hour making a couple of decisions while the rest of us tried not to look too bored..

That sounds horrible. Did you mention your concerns to the people who owned those meetings, in a way that made it clear you were trying to help improve them?

I've had success several times with this in BigCo, with various satisfactory outcomes:

1. "You're right, this meeting is BS! But it has to happen for various reasons X Y Z -- since you don't care about this area you don't need to come, we'll grab you if we need you."

2. "You're right, and other people feel tuned out as well, so let's try cutting it to 10 minutes / mailing out an agenda beforehand / starting exactly on time."

3. "You're right, this is an inefficient way to gather state so we're going to just swing by each person 1-on-1."

4. "You're right, this team is too big so we're splitting in 2/3 smaller groups"

I remember reading that this is what Evan Martin was going to work on after Chrome...

    http://neugierig.org/software/blog/2012/05/new-project.html

(Congrats, Evan!)

Andrew's photography work is beautiful: http://www.reisse.net/

His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind:

* Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and it takes a lot of hard-won experience to become sufficiently critical of your own incompetence. On the other hand, the tools are improving here (helgrind, relacy, threadsanitizer).

* Exception-safety. I don't mean in the weak sense of "won't leak resources" but in the stronger sense of leaving the system in a consistent state after an exception. Again, it's difficult to analyze or induce all the different code paths that might occur, and difficult or expensive (depending on your starting point) to roll back your mutations. Again, there are tools that help with this, like STM or cheap persistent data structures (so you can do a bunch of mutation that is only committed atomically at the end).

Are there others? Can the progress in these domains shed light on how to make crypto safer?

Hey Vinay -- I just wanted to remark that supportfu.com looks great. Even though I'm not in a business where I'd need such a thing, I found your copy compelling enough to imagine myself running such a biz and how to provide the best possible support, and concluded that I'd want something very much like what you offer. Best of luck.

I like your idea of point allocation (especially if we can include STR, DEX, and INT). But how do we set up the taxonomy of attributes? Particularly with hierarchical relationships (ex: is Machine Learning a subset of AI?) you'd want rough consensus if you're going to run graph algorithms over it and conclude anything beyond data-visualization style "Look, pretty data!" data pron.

That's one of the hilarious things about linkedin attributes; people accrue tags that have vastly different importance depending on context. But hey, it's hard to say no to someone else vouching for my Computer Animation trait, whatever that means. It has the same sort of vague benefit with negligible cost situation as friend graphs. This is why I like your idea of careful scarce allocation, vs. limitless accrual. Information is only meaningful inasmuch as it represents choice.

Evolutionary pressures on spoken language drive common concepts to claim shorter symbols, so it seems fine to pay 18 letters (plus an escape to an alternate language) for this more-rarified meaning of synergy, leaving "synergy" and "disrupt" as depleted membership tokens of the crunchosphere.

It's tempting because that's how we build our skills. You must abuse a tool to understand it, and know when to not use it. Unfortunately in professional contexts, many of us do that learning on the job, exhausting out a turbulent jet wake of too-clever code, upsetting those who follow. Coming across CRTP for the first time is either an upsetting detour or a fascinating David Foster Wallace style WTF-inducing endnote that you must consume before continuing. You appreciate this dynamic more as you play out different roles, both producing and consuming. Some languages try to interdict this state of affairs, shielding us from each other, but the more fun languages let us burn ourselves and our colleagues and finally learn restraint in ways you never learn in languages with training wheels.

Definitely! Of course, argument from authority is still relatively weak in situations where experts disagree, and that's definitely the case with programming languages. We can each find our gurus -- Damien Katz, Rich Hickey, Rob Pike, John Carmack, Mike Acton, Slava Pestov are some of mine -- but there's no absolute truth in programming debates. The best we can hope for is to share interesting insights, motivate them as clearly as we can, and then agree to disagree, each biased by our distinct experience.

Try reading this. It concisely gets at some of the main ideas of his talks regarding values, identity, and perception. http://clojure.org/state

Definitely. Tests are really like a dual to the code, in the sense that they are another way of describing what it is supposed to do. Like you say, as the test grows more complicated, the risk that the test code itself has bugs grows too.

The risk is small with simple declarative tests ("the output of f(x) == y") but with complicated systems with large state spaces, you start writing combinatorial tests to try to cover more of the space and incur a bigger risk your test code is buggy.

Few things are as frustrating as fixing a bug that should have been caught by a test and realizing the test wasn't actually working correctly. This is even more acute when working on code where speed is important (where performance is correctness, in other words) and you realize a test has been measuring the wrong things, such as asynchronous runtime showing up in the wrong place.

TDD has always seemed more like a useful tactic to be applied to certain kinds of problems than as a silver bullet.

Right -- big publishers' size and distribution model requires them to focus on outsized wins. Their overhead is too high to take on the many smaller projects they would require to feed their cost structure. Smaller traditional publishers face similar problems, having to make few and careful bets and so often having to sell out to survive.

Valve provides an interesting contrast here: with Steam/GreenLight they run a scaleable distribution channel for large numbers of small indies, taking a percentage without making particular and huge bets. It's like an index fund vs. managed fund, where the latter does intense research into specific options. Often that research in anchored in comparative analysis where someone has proven a juicy market exists (ex: Guitar Hero having a million clones in its wake).

Thanks for this insightful comment.

I have struggled to find the right ways to think about the phenomena underlying the shared memory abstractions. The limited visibility makes this harder than understanding other aspects of software. You can run instrumented simulations like cachegrind; you can query arcane CPU performance counters (Intel's Nehalem optimization guide was eye-opening regarding how much goes on inside vs. what you might learn in an undergrad CPU design class) -- but at the end of the day you have to be guided by experimentation and measurement. And so many times those leave us with no good theories to explain the observed behavior.

(War story, feel free to skip: One time we were trying to speed up a datafile parser by any means possible -- which was already split into a producer-consumer thread pair, one thread running the unfortunately complex grammar and producing a stream of mutation commands, the other thread consuming that and building up in-memory state. The engineer working on this found that adding NOPs could speed this up, and he measured and charted a range of # of NOPs and chose the best one. Our best guess was "something to do with memory layout?" The outcome of the story was that we tore out a bunch of abstraction layers and ended up with a simpler, single-threaded parser that didn't need such heroic and bizarre efforts, but it also left us feeling a bit of vertigo with regard to memory hierarchy behavior.)

Your pointing out that the shared memory abstraction is backed by message-passing between hardware components (which each represent concurrent processes) is really interesting - thanks!

It kinda has a similar problem to the Hegelian dialectic that Marx built his stuff on. The Singularity argument observes some trends and presumes they will continue along the same profile, carrying our society towards a specific phase-change that we've never seen before. Extrapolating trends is one thing; arguing that some novel configuration is inevitable is another.

Dictators can work well when they are insanely talented, motivated, and tuned into their minions. Being a trusted minion of a powerful dictator has provided the most effective, fun, coordinated experiences of my career so far.

On the other hand, they are a single point of failure. When someone succeeds from outside in pushing the dictator out, chaos ensues. Some will thrive under the ensuing autonomy as they see room to advance their own agenda, but many of the most talented will move on if they perceive that the team is in a degraded state. Worst of all, being a trusted minion of the prior dictator leaves you with a suspect role when a new dictator grabs the throne. Experiencing this is somewhat painful and complicates your weighted decision heuristic for what to do with the rest of your life. Will things get better? How long do I wait? Could I possibly reinvent myself to the degree that e.g. patio11 was able? etc.

That (very nifty) technique only works for periodic phenomena, so it seems hard to apply here.

I'm working on a GUI app in Qt where we use X11 in several places. The main usage is to open multiple connections to the X server for GL widgets, so that we can refresh their time-sensitive contents even when the main Qt event loop is blocked. Another is to query the current X11 virtual desktop as soon as possible after app startup, so we can display subsequent Qt windows there by default even if you switch away to browse the web while our levianthanic app loads. There are a number of less interesting examples, like setting X11-specific attributes on windows, and papering over minutiae that varies between e.g. X11 and OSX. Despite these few things, Qt has served us fantastically well.

You are on the right track here, but consider what the contained object is:

    std::list <person*> people;

You're right that the instantiated list entry (what the article calls "helper") will directly include a value, but the value here is a pointer to a person, not a person.

If you find this observation interesting you will definitely enjoy Maciej's analysis, "The Social Graph Is Neither":

http://blog.pinboard.in/2011/11/the_social_graph_is_neither/

Id Software has been an inspiring example here, open-sourcing several historically significant game engines. https://github.com/id-Software/

However, they typically don't include the full game data; you have to use them with data from the free trial versions or contributed by the public mod community (something else Id really helped foster). Does anyone know if this is necessary for them to retain rights to the IP?

We have a print-out of an N-set Venn diagram on the wall which we use to illustrate the peril of having too many features with subtle interactions. It resonates because many of us have worked on areas of the code preceded by comments indicating which subset of interacting features you need to keep in mind. There's at least 7 such features, so it's not a small space. We've been desperately struggling to make these features more orthogonal and having a succinct diagram of the problem (read: "enemy") has helped us stay motivated.

Thanks for clarifying. I agree there are many environments that would benefit from version control but that lack the technical resources to make it happen with existing tech.

Versions (and Time Machine history) are good steps to part of this, in that they are easily available and understandable, but they don't solve the collaboration aspect. How do you diff and merge your local changes into the NEW_final_v2_UPDATED.xls that was emailed to you? I'd summarize the problems as:

- identfying & organizing versions of the same document in ways manageable by normal humans (i.e. not a set of variably-named files spanning email attachments and shared folders, nor a graph of nodes identified by 20-byte hashes, nor a rigid interface to a versioned-file server)

- diffying & merging non-text document types (images, audio, spreadsheets)

I agree this would be a valuable problem to solve well!

Just curious, what makes you think they don't already use version control prolifically? What opportunity do you see? One studio I'm familiar with has some assets with change history back through to SCCS -- back through RCS, CVS, and P4. These places have long dealt with large groups of people collaborating on shared files that are constantly changing, forking, merging, etc.

The arrows do not represent time. Instead, they reflect the way git represents the commits internally. Each commit is a set of changes to some starting state, identified by the arrow. You could think of it like a citation in a paper that mentions and then extends some earlier findings.

What you describe as a marketing gimmick has let us gradually migrate a 10M line cross-platform C codebase to C++. There are plenty of reasons to dislike C++ but casually disparaging them often means you miss reasons for its continued real-world success.