aljungberg

I’ve been told by many many candidates that all work they ever did was under an NDA and so they have no Github profile and not even any code samples. Somehow they never did a single shareable thing in their lives - not at school, not a hobby project, not at work.

Potential employers use all the signals available to make decisions and this is an important one. Many of the other applicants will have solid material. It may not at all be your fault, and yet also be a serious disadvantage.

If the people from Signal start a conversation with you on the number you emailed, how do you know it’s actually them? Couldn’t it be a third party who intercepted your email?

You need to check their “safety number”, and now we’re back to the same idea as with PGP with web of trust and key sharing parties.

At some point you still need some kind of pub-key identity check if you don’t want to accidentally report your vulnerability to PRC instead.

I think this argument assumes that frequent deploys and good CI/CD is a silver bullet for every possible problem with releasing something.

You could release a well tested new feature with perfect ease and see nominal stats for hours after, and still have a problem you don’t see.

Maybe your new Calculator Widget 2000 works great for everyone except Big Enterprise Customer Bob. And maybe Bob doesn’t log on until 7 hours later because you’re in London and he’s in San Francisco. When he starts up the Widget, his mixture of data causes a pathological database behaviour. It’s a performance mistake in your code (that’s hard to find even with rigorous unit testing and manual QA).

Knock on effects follow like your task workers getting overloaded. So you have to saunter back in late on a Friday to fix it. You tiredly misdiagnose it as a usage spike, maybe some big new customer came on. You spin up 20 new worker nodes. Doesn’t help enough, tasks are executing too slowly. You figure it’s one of those mysterious intermittent performance issues in GKE. You begin to upgrade the cluster software in a desperate attempt, your thinking muddled by too many Friday dinner whiskys, to resolve it through the traditional GKE incantations. But cluster upgrades take forever and when you finally see the real problem and roll back your code it’s 2 am and your partner fell asleep on the couch and your kid wakes up at 6 am and God why did you deploy your well tested small new feature on a Friday?

It seems like a work-around for an Australian company would be to always have a non-Australian employee have final say in what's deployed to production.

Now you have to fire him to deploy the backdoor. I expect the law doesn't require you to fire people. Even if it does, he or she is not bound by the gag order and could be a canary to the rest of the world.

Can we expect 1 person to sacrifice their life for every 13 children in need?

Helping every child in poverty requires a long term paced effort rather than a one time heroic one. As inspiring as this rescue was, it doesn't scale.

I don't remember what "Edit Each Line in Selection" does, but JetBrains does have vertical multi-line character selection. Same as in TextMate, hold down alt, click and drag the mouse to select a rectangle. The JetBrains version sometimes feels less polished than that of TextMate but it works well.

Heating (pasteurisation) doesn't make milk free of nutrients[1] -- pasteurised milk should substantially be the same as raw milk in terms of nutrients.

I agree that low-fat (skimmed) milk should be avoided: the fat in whole milk is important as it makes you feel full. Fat free and low fat products encourage over-eating [2][3].

[1]: http://www.sciencedirect.com/science/article/pii/S0956713512...

[2]: https://lirias.kuleuven.be/bitstream/123456789/538238/4/revi...

[3]: http://link.springer.com/article/10.1007%2Fs00394-012-0418-1

Right but in this particular thought scenario it doesn't matter what the government does with the shares. It is still the case that the government constrained your liberty regarding your shares. You wanted Wilt to have them, Wilt didn't get them.

I'm not making a moral statement here. I'm not saying whether it's good or bad for the government to do this. I'm just making an observation that, logically, the parent didn't provide a "solution" to the grandparent's thought experiment.

That's just another way of saying people shouldn't be allowed to give their shares freely. You give your shares to Wilt, the government gives them back to you (assuming the government has no overhead).

So the original argument stands: forced wealth redistribution is incompatible with free will and liberty. The word "force" itself means the removal of freedom.

And to be fair GIF was used in many many places where we now use PNG.

None the less, a funny end result.

You have to admit it's a little funny that if PNG's one goal in life was to replace GIF, they chose to not support the one thing GIF is used for today.

You had one job PNG. One job!

Maybe you are right and there is some subset of mathematics so complex and lengthy that it becomes incomprehensible without a concise shorthand. I don't know enough about high level mathematics to refute that. I do know that the original article we are commenting on is not an example of that.

I do think by switching to code we don't need to lose the ability to declare new semantic meanings. But instead of inventing new ways to draw things, we can rely on our existing language. We define new functions. That's the beauty of having a standardised flexible language.

You write that mathematicians like to declare new notation. I think that's actually a liability. Like another commenter pointed out in this thread, mathematical notation is sufficiently freeform that there are different "dialects" in different fields of mathematics and it's not trivial to understand one even if you know the other. There is no formal definition, no formal grammar.

At the same time I just don't know if "H^ * (pi_1(RP^2)) with a line over RP^2" is actually better than inducedHomology(fundamentalGroup(OnePointCompactification(Projectivization(RealAffineSpace(dimensions=2))))) nor that it's desirable to want to compress it down to 6 small symbols. Obviously if you are going to use such a formula a lot, just like in programming, you'd "refactor" it into a parameterised function. Now you have reduced the cognitive overhead of understanding every use of this formula going forward. As a reader, you understand that function once and when you see it again you don't have to reparse it or scan for differences from previous similar incantations. DRY applies to mathematics too.

Expressing the math in code, to me, means to express it with a small library of primitives, unambiguously and formally. (Regular mathematical notation is ambiguous, like the multiplication example I mentioned, for example, and can define new primitives as it goes along.)

Now combine that formal code expression with best practices for programming like sensible variable naming, DRY and so on and I really feel there should be some kind of tangible advantage. (That's before we even start to think about the possibility of unit testing parts of a greater work. Have there ever been instances of someone writing a physics paper and having a calculation error somewhere deep inside?)

At the risk of paraphrasing you badly, you write that you just don't think it's worth the time to express all the varied mathematical concepts in code because the math is too complicated. I feel the opposite. Because it's complicated, it'd be good to take the time to express it plainly.

I'm not sure I follow.

sum(vec) is exactly how I'd write it in Python (or pseudo-Python for that matter). It does what you think it does (provided the operation of addition is defined for vectors). I did mention using "sum" instead of "sigma" (combined with a list comprehension) in my OP, did you miss that or are you making a point I don't understand?

I recognise what you say about mathematics favouring conciseness. I feel that's what I'm addressing: mathematics have sacrificed readability in favour of conciseness to an extreme and could benefit from some decompression. It is possible to write extremely concise code but I feel most programmers today agree that's actually not a good thing to do. It's often better to write something a little longer to improve readability than to save those characters.

And like you write, every language, and we can consider mathematical notation to be a language in this context, has tradeoffs. But it's not a zero sum game. You can make an overall better language than another language. And what I like to imagine here is that perhaps mathematical notation is not the most evolved form of logical expression we have today. It's certainly not as formalised or field tested as the big programming languages.

I agree and this was my first thought too. Yet I feel like I do know the mathematical notation. I know what each "thing" does and yet the whole feels needlessly dense.

I definitely agree that once you are "used" to reading the notation it will be faster. That said, just because it's possible to get faster at it, does that mean it's the best possible notation for the job?

In creating programming languages and using them for tens of thousands of man hours per day we have envisioned and tested a multitude of different ways to express logical ideas, formulas and algorithms.

By contrast, how many kinds of mathematical notation has humankind tried and actively used?

If the latter number is substantially higher than the former, how can we be so certain that academic mathematical notation is the best, most clear way to express algorithms and formulas?

I would wager that the amount of logic expressed in programming languages vastly exceeds the amount of logic expressed in mathematical notation, every day. More logic is both written and read in the field of programming, so the medium we express the logic in is more rapidly iterated on.

Again, I'm not a mathematician. I'm a programmer and so of course my opinion about what is easy to read and write is subjective and biased. Yet even thinking about it objectively in terms of "what did we work harder on refining", I think there's some food for thought here. Wouldn't the rapidly iterated and widely used form seen in programming languages be more finely honed and at a higher stage of evolution in terms of understandability and writability?

Right. You could define functions. The function itself is stated in a readable form yet it is concise when later called upon. And just like you desire, this gives the reader a chance to first absorb the idea being expressed by the function (in clear pseudo-code), without making your expressions later overly verbose.

The counterargument might be "but then it's harder to break it down again into components when doing algebra". But that's no different from substituting in identities as needed. Substitute in the function body whenever you need to. As long as you don't need to, don't and you both have concise writing and reduced cognitive overhead. Each time the user sees a function they have previously mentally absorbed and understood they don't need to re-read it in detail to confirm it's still the same idea.

I'd like if this were the norm. I found the pseudocode much more readable than the mathematical description of what it was supposed to do.

I'm (obviously) biased as a programmer rather than a mathematician but sometimes I think the study of mathematics would benefit tremendously from the same kind of "readability is more important than conciseness" thinking we have in software development.

Here's my proposal for a "contributing style" for mathematics:

Don't use short cryptic variable names like "wt". Do use informative full variable names like "weight" and "step".

Don't use a subscript for something like "step": it's just tiny and hard to read, especially once you start doing math in it. You have a series and you want to talk about the nth element? Use programming like array indexing, "weight[step]". It has the added benefit of being writable in pure ASCII without a math formula editor.

Don't omit your binary operators, e.g. "wt(1 + G)". Write it out: "weight[step] * (1 + reward)". You only write your formula once, but it will be read many times. Saving 1 character is not a win in total, especially not when it creates an ambiguous reading (are you using the function wt on 1 + G or are you multiplying? No way to know without resolving wt which can involve backtracking in the text for your reader.) Optimise for reading, not for writing.

Don't use sigma for sums. Again readability trumps terseness. Instead of "S" with a little "t from 1 to T" and a formula like "Rt/B" on the right, just write it out: "sum(R[t] / B for t in range(1, T))".

Actually it would be neat if there existed a Chrome or Safari extension that converted math notation to pseudo-Python. It wouldn't be able to assign sensible variable names automatically but at least it'd save me so much time and leaning in to stare at tiny subscripts.

I might be exceptionally lazy but sometimes when I read a math paper and the dense piles of tiny script formulas begin to pile up my eyes just glaze over even that in theory I understand every component. It's just so much effort to mentally parse it. Like reading sample code in assembly. If readability was improved I'm certain me and others like me would finish reading many more papers and we'd all get a little smarter.

I wasn't saying Tim Cook is lacking in skills. As the CEO of one of the world's most successful companies he certainly has his own unique and impressive skills.

Lisa Su demonstrated an impressive skill not every CEO could pull off and I wanted to highlight that. That's all.

Whether being technically adept is a requirement or not, I'd say no in general for tech companies (and I'd count Apple as one) but for a certain subset of the tech companies (AMD, Tesla) it certainly seems to help.

Yes absolutely, I think that's the key. It's cool to see very tech-y CEOs like this. I feel like many CEOs would defer a hypothetical question about how a product could have been made.

I mean it's like asking Tim Cook about a different strength cellular antenna in the iPhone. Probably he could give a reasonable answer about what the iPhone antenna is actually like and why it's like that, and how many tests they ran to confirm it's the best design or whatever. But could he talk about an alternative antenna that could have been, on the spot?

It's pretty impressive to see a CEO being able to answer a question about CPU vs GPU power envelope targets just of the cuff.

The interviewer asks why there are no CPUs targeting higher wattages, like how CPUs are less than 150W but there are 300W GPU. She says she'll need to think about it but she's pretty sure that the high parallelisation of GPUs makes them easier to scale up in terms of wattage.

Granted, that answer could be wrong (I know nothing about CPU engineering), but either way it's a really well considered one to be thought up when "put on the spot" in an interview with a question you haven't considered ahead of time. I'm sure that's one of the things which separate good from great in CEOs: an understanding not only of the broad market decisions made by their company but even the details of low level architecture decisions.

It's easy to make consistent icons as long as you don't mind them being ugly. What's hard is striking a balance. Apple used to have this balance: reasonable consistency yet beautiful icons with a touch of delight and sense of workmanship.

If we go from what we had to rulers and paint by numbers we might as well forego design altogether and just write a computer program to generate all icons.

Bonus to the kill-and-bring-to-the-hospital method of spider bites: over millions of years genetic pressure will teach spiders their lesson and they'll stop biting humans.

That's what Stripe's CTF3's Gitcoin was like: https://github.com/ctfs/write-ups/tree/master/stripe-ctf3/le...

Google software could use their 99% successful algorithm to filter potential captchas. Then show the 1% they can't crack to humans.

Now the race becomes who can write the better captcha solver, Google or the spammers? As spammers learn to identify things in the 1%, Google will hopefully improve faster and continue to narrow the "hard to solve" band.