mattknox

I've been a customer of theirs for at least 12 years, I think (I have an entry in my password manager from about that long ago, and I might have had an account before that). It's been fantastic, in general: I can get a phone consult anytime I've wanted one, and can get in to see a doc with pretty short notice. They are good at giving me the referrals I ask for, even if they are weird (eg., after listening to Chamath Palihapitiya talk about Coronarary Arterial Calcium scans, I got curious and wanted one, and 1med got me the referral I wanted/dealt with insurance, etc.). About the only downside is that it's a bit harder to keep a very consistent GP, in that 1med seems to have a fair amount of turnover. I don't know if it's hard to keep a consistent GP in other contexts, as I pretty much didn't go to doctors between the time I left high school and when I started using 1medical.

Native retweet on twitter, probably.

I've known at least a half-dozen superb bootcamp grads, but the quality is definitely uneven.

Yeah, a huge number of early twitter folks did exactly this.

I felt that way too, but I have mostly changed my mind. My wife, who has a FT job, a purse company, and 2 kids, plays a SHOCKING amount of Maple Story. She never pays money, but at a reasonable-for-her time value of money, I'm sure she'd be well into 10s of $K/year of cost. Is that malfeasance on the developer's part? I dunno. I'd generally prefer she play less, but she is an extremely functional adult, and she gets to make her own choices.

Thought experiment: if she spent 10X less time but $2K/year on the game, would that be more or less troubling? If she took that trade, she'd be an addict by your lights, but she'd be spending 10-30 min rather than 3-5h/day, and I'd be THRILLED. It's interesting to me that we are generally totally fine with something that sucks up (or alternatively, makes enjoyable) all or more-than-all of someone's free time, but we get upset when it takes even trivial amounts of their money.

Have you looked at SICM? (Structure and Interpretation of Classical Mechanics, the far less popular half-sibling of the SICP) https://mitpress.mit.edu/books/structure-and-interpretation-... -it has you derive classical mechanics, which is to say most() of Newtonian physics up to around 1900, by writing a giant pile of scheme that drives graphical simulations.

() For a curious value of "most" that elides thermodynamics, electromagnetism, etc..

He was rich enough not to need more money before starting YC-the acquisition price for viaweb was $49M, and it roughly ~10x'd between then and the peak in late 1999. (cites: https://www.cnet.com/news/yahoo-buys-viaweb-for-49-million/ https://venturebeat.com/2008/10/08/as-other-tech-stocks-rall... ). I don't know how long he spent there or what fraction of the company he still held, but I'd assume that he'd have stayed long enough to get to his personal Fuck You Money.

More generally, I know many many people (maybe literally tons by weight?) who continue to work long after they don't need to, usually because they're just deeply interested in the domain. I've seen this up close with my father, who continues to farm at 70, and with some founders who keep founding despite having more money than they will ever need. So when someone in that situation says they work on a thing because it is interesting to them, I generally believe them.

Johnny come lately, eh? https://www.reddit.com/user/mattknox :)

If you tend to do this a lot and use Chrome, you might find the tweak this comment inspired for me useful:

open chrome://settings/searchEngines

add a new search engine, called anything you want, with a convenient shortcut. I use "r". The important bit is the search string this expands to: https://www.google.com/search?q=site%3Areddit.com+%s

This does exactly what it looks like: search google for whatever you're looking for, but only for reddit pages. You access it by getting into the URL bar, hitting r<tab>, then you should see whatever you named this, then do your search and off you go.

Sadly, this is substantially better than searching reddit for the same string. (I work at reddit, and hope to help fix this sometime in the first half of next year)

These questions aren't useful for evaluating pg's work (or frankly that of most PL implementors) because it concerns things, like syntax, libraries, user culture, etc., that is outside of the rather narrow domain Atanassow cares about.

He believes languages are utterly defined by their type systems, saying in the LtU comment you linked: "Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language". I'd assume that he would say the same about js, lua, etc.. AFAICT, he's quite knowledgeable about PLT, formal methods, static typing, category theory, etc., but he disregards everything else.

It's worth considering whether he is right to do so. A waspish answer is to observe that companies built on languages he deems to be "in the corner" (c, java, dynamic languages) constitute the entirety of companies with significant market capitalization, and ask (apologies to Aaron Sorkin) "If your type system is so smart, why do you lose so always". A better answer is to note that a bunch of stuff that he deems trivial (generally anything outside of the type system, but specifically libraries, syntax, bindings to existing systems, etc.) matters, so javascript is different than python despite being identical in his eyes. Specifically, js runs in the browser and has a pretty good runtime for building web services, while python has exceptional ecosystem support for data science and machine learning.

have you thought about publishing the full source from then? The HN source was dense but very educational, and it would be really interesting to see internal tools written in arc.

Wetherell was not involved with launching retweet, and didn't implement much (maybe any?) of the code in that Nov 2009 launch. He probably did write a version of the frontend for retweet at some point, and had done some backend code, but all of that was largely rewritten by launch day.

To be fair, he probably didn't claim that, but making his involvement out to be more than it was probably did well for the article.

I've actually been treated exceptionally well by the half-dozen or so CEOs I've worked for. This is pretty common in tech, at least in SF and NYC, in my experience.

Here, you should have 2 orders issued events, one order_succeded, and one order_failed (hopefully not with an actual NPE, that would be pretty bad). So much like an SSTable-based system, there are race conditions at the level of deciding what to write to the logs/event stream, but should not be race conditions in replaying the event stream (the same customer would get a failure every time).

It's fascinating to me that people don't point out that you can get many of the benefits of microservices with all your code in a monolith, indeed, all in a single runtime. Of the 4 benefits he lists (1: independent development, 2: independent deployment 3: independent scalability, 4: reusability) you can mostly get 2-4 by deploying your monolith to different server pools that are deployed and routed to independently.

Microservices get to be necessary for large dev teams, but probably a lot later than most teams think.

I ran twitter's new engineer training for a long time, and much of this rings pretty true to me. I would only add 3 things: -1 the skill of teaching is approximately orthogonal to domain knowledge, and the difference between a decent and very good teacher is huge, both in terms of student-reported happiness and in terms of retention of the material covered. -2 history with the company tends to be very valuable, in that new hires are often curious about _why_ the company decided to build system X as it was. My goal was that teachers should be able to answer most such questions accurately, and truthfully say that they didn't know in the other cases. I found (anecdotally, because this data is hard to capture) that the student-reported quality of a class was generally proportional to the maximum length of question/answer/followup q/answer/... chains. -3 the onboarding process is an extremely powerful propaganda platform. During twitter's long transition from ruby to scala, (before I ran it) there were a series of presentations that were forward looking to the point of inaccuracy: they described as existing in the present that which we hoped would one day exist. This confused a bunch of new engineers when the rainbow unicorn scala world promised them did not materialize. On the positive side, many of them were then motivated to help build a scala world.

Twitter never used Jruby in any significant capacity. Note that the article she cited ( http://www.infoq.com/articles/twitter-java-use ) said we were evaluating jruby, but chose not to use it because the tooling around MRI was much better (in substantial part due to the efforts of twitter's backend team at the time).

We probably could have made a great jruby memcached/MySQL/thrift client, but it wasn't clear that doing so would have much performance win, as jruby itself wasn't dramatically faster than MRI. It would have, however, made it really easy for us to offload intense bits of code to java code, which probably would have been a faster upgrade path than rewriting in scala as we did.

I talked with some of the opposition later in job interviews, and they would typically write/modify a program in C that would find and kill our client. Their process tended to be: get a machine with our client, write a program that would find some trace of us and kill it, but not get everything, edit C, reinstall, recompile, repeat.

My process was: get their client installed, poke around in repl until I was confident I could find it and all its friends, write a function to clobber all of that, then iterate if needed. Where they would have to edit/recompile/run, I would just do a new thing in a repl. Then, too, my code was shorter, mostly from scheme vs. c and partly because I had better libraries than they did.

Having had my Milgram immunization, I would probably be able to resist the temptation. :)

That said, I doubt anyone would be particularly interested: all of this is pretty out-of-date: I was pretty good with Wins ME, 98, and XP, but I don't know anything about Vista and more recent versions. It wasn't _that_ hard to figure this stuff out-the TLAs must have vastly better people.

It does make me wonder what's going on in China, though: I'm told they are basically all XP. Is there an insane amount of hacking going on there? I've periodically thought about setting a honeypot to see what's up. It turns out to be really hard: you can't just run XP in a VM, because most VMs are (were?) detectable by even a moderately sophisticated attacker. The best idea I had was to have an external box record all the traffic in and out, and have a process on-box watch for new processes and track them. Maybe I would find some interesting beasties.

I think it's harder to safely do changes to development machines, because the coupling between components is greater. If you want to change, eg., libxml or something like that, lots of processes that you don't know about might be effected, and all hell can break loose.

By contrast, I was generally nuking random userland processes, which no process (or user) would mourn or miss. I think that is a lot safer. There were cases where we would touch something important, like the CreateRemoteThread stuff, but that was a relatively small amount of our code, which rarely changed, and again, it had very little interction with anyone else's code.

It's also possible that we _did_ create a lot of havoc, but I didn't know. I think that's less likely because I think we would have noticed the loss of revenue, but it's possible.

It seems to me that very few organizations () have effective countermeasures against bad behavior, but very little seems to happen anyway.

() google had that guy who stalked people ( http://gawker.com/5637234/gcreep-google-engineer-stalked-tee... ) and I've read that intelligence circles have a whole category called LOVINT for people spying on crushes. That said, they have hundreds of thousands of employees between them, and the incidence rate is probably really low.

I think you're right. If people talk honestly about why they did things and weren't obviously trying to do ill from the start, it's pretty easy to empathize.

I read that the participants in the Milgram experiments were _way_ disproportionally likely to be conscientious objectors later in life, and that they attributed this to having been in the experiments. I hope that I've been immunized like they were.

We were crazy careful about screwing up people's machines, because anything that we did that made it seem to malfunction would likely result in them reinstalling the OS over us, and while we had some ideas about how to persist across a reinstall, it was a few bridges too far.

I certainly can't say that we avoided all catastrophe, but I'm not aware of us ever causing one. We had pretty good abstractions: the stack-shuffling code was fully encapsulated so that it wasn't just littered about our normal code, etc..

We also tried pretty hard to avoid the really dangerous stuff. It sounds crazy to put arbitrary code in some random process, but if you know that it doesn't leak, and it never interacts with other threads in the process, it's not really _that_ risky, really.

One thing that probably also helped is that we had so much feedback from the individual ad clients. So we would know pretty fast if something started happening.

Yeah, I learned tons about Windows internals. Three standouts:

1: We never hit a limit to what you could do to the stack. It was trivial to write a function F that would fake the stack such that you would then "return from" some other function G (that had never actually been called) to yet a third function H that did something you wanted. This turned out to be useful in creating self-deleting executables.

2: There were several cases in which backward-compatibility APIs created opportunities for the clever. One example was the handling of registry strings. They are, internally, WinNT counted unicode strings, but are generally accessed by older Win32 apps, which use C strings. This means that you could create a registry key using the WinNT APIs, where the string identifier for the key had a null byte in the middle. Then Win32 apps (like some written by competitors to kill our apps, and also regedit) would be unable to do anything to that registry key, because it literally could not express the key's name.

3: windows is CRAZY hackable. It supports an API called CreateRemoteThread, which lets you start a thread in some other, random process, running arbitrary code that you specify. This means that if you can get a file down to the machine and execute it, it can load a bunch of bytes into memory, tell other processes to execute them, and terminate, using 1: above to delete itself. This made it a fairly hard target for most removal techniques-you'd have to find all the threads, out of all the threads running on the system, that were running my code, and kill them before they could replicate into another process and/or find the processes that were killing their siblings and retaliate.

Windows also allows random processes to tell the OS that they are SO IMPORTANT that the OS should immediately BSOD on that process terminating. We never used that one.

As far as stuff I still use today, no specific technical techniques, but lots of general things:

- It's crazy how fast you can level up with a hard problem and room to run. I knew basically nothing when I started, and within a year or so, the team I ran and I had done some pretty cool stuff, and beat the hell out of a lot of other companies. For a while, I was told that installing our adware was the best way to uninstall some obscure but horrendous russian malware.

-Tools trump humans. Lots of other companies were trying to clobber us at the same time we were clobbering them. We mostly won, and in several cases completely ran the table against the other company. (by which I mean we wiped them completely off the machines that had both their client and ours, without losing a significant number of machines ourselves). It wasn't that they were dumb or we were geniuses, but we would write like 10 lines of scheme and they would have to write a whole new executable, probably a few thousand lines. Probably lots of coders were faster than us, but not many were 100X faster.

There were probably others, but those are the standouts.

(Possibly) interesting aftermath to this article:

I gave this interview a long time ago to a completely unknown security blogger. (I think her blog had like 10 subscribers at the time). Quite a while later, she published it, and she had gotten at least one more subscriber in the mean time, and that was Bruce Schneier. He reblogged it on his blog, and from there it took off on slashdot, reddit, news.yc, etc..

The article linked to my site, which in turn had my cell phone number on it. I figured that I would get a massive avalanche of death threats, etc., but interestingly, I was only contacted a few times by email, and those were all positive things (offers for consulting gigs that I didn't take, a few conference talks that I did and that ultimately led to me joining twitter a while later, requests for advice).

It was striking to me at the time that the collective reaction of the world was so positive. I had feared that I would be stuck in an adware-developer ghetto forever. We often talk about the fact that Silicon Valley has succeeded in part due to its stance on failure, and I sense an echo of that in how it shook out for me.

Feel free to ask me anything. I figure it's the ongoing part of my penance. :)

Yeah, I can absolutely see what you mean, but I don't think there is as much incongruity as you think.

Had I been working for the russian mob or whatever, that is, an organization that is comfortable with being explicitly criminal, I don't know and fear what would have happened. However, generally, most organizations are not comfortable with telling employees to break the law, most of the time. In particular, it seems to me to be really rare in the private sector-I don't have any real experience with government.

It seems like s7 is a descendant of tinyscheme, and probably wasn't available at the time. Very cool, though. :)

Guy Steele actually mentioned this in some talk or other. The money quote (loosely from memory) was "APL makes you a better Common Lisp programmer. I was doing a matrix-tensor multiplication routine, and I was thinking about the nested loops, and then I realized it was mapcar of mapcar of apply, done." Sadly, I can't find the video.

This was a _lot_ of fun when we did it. Pull requests welcome! (someone should do arc, and clojure!)

how long after threes came out did 2048 appear?

cool-thanks...I'll look at that sometime.