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.
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..
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.
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.