The proof is in the pudding. Where is Assange right now?
741 karma · joined August 9, 2013
I may be tripping over something here but this doesn't sound right. If you mean polynomial in the real number sense, i.e.
Lu = a0 + a1 Delta(u) + a2 Delta(u)^2 + ...
(where Delta = Laplacian, and a0, a1, ... real numbers), then is this true? The famous wave operator doesn't have this form.
And if you mean "polynomial" as in a series over function space, i.e.
Lu ~ a0 + a1 Du + a2 D^2u + ... (infinite terms, not equality but convergence)
where D is the usual differential operator and a0 is a number, a1 is a 1-d vector, a2 is a 2d matrix, so on, then this is standard calculus of variations on any reasonable function space. Taylor series for function spaces if you want. I don't think that's limited to nice Galilean operators.
A challenge the OP doesn't touch on is the need for individual focus _during_ coordination events. For example, someone is presenting their design ideas to an audience who's seeing them for the first time. In order for the coordination to be productive, the audience needs to be good at focusing in realtime to grok the ideas presented to them. It'd be unfortunate to rely on your team's ability to pull off a burst of focus on demand. Some can do this well, some can't, and you only water down your coordination if you rely on it too much.
I've read about and quite like writing-heavy workflows, e.g. presenter writes and shares a 4-6 pager, or meeting starts with people silently reading a memo. The async-ness and the reliance on written word pulls a lot of weight when there's too much depth/breadth involved; the kind of thing that happens a handful of times a quarter.
But this is hard to pull off consistently every week for small iterations that nonetheless need coordination on cognitively demanding topics.
How do folks deal with this?
- The semantics of CW seem convoluted. But once you stare at API docs for long enough, the core concepts are easy to grok: Metrics (regularly submitted from machine to CW), Alarms (abstractions for defining the logic of an alarm based on behavior of Metrics), and SNS Topics (could be just an email address, for what to do when an Alarm goes off).
- Once you get the data model right, all implementations (click ops, terraform, bash via awscli, boto3, etc) are all visibly identical.
- Some Metrics come for free, e.g. CPU usage is reported by any EC2 instance to CW. For some other Metrics, notably disk and memory usage, you need to configure your instance to report them to CW. This is where the OP's monitoring scripts come in.
- The monitoring scripts and the cron config the OP refers to are deprecated [0]. Instead there's a new CloudWatch Agent [1]: you install the package on your EC2 instances, provide a configuration file to it, and you're set.
[0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scri...
[1] https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori...
- The Manager's Path, by Camille Fournier
- An Elegant Puzzle, by Will Larson
- Team Topologies, by Matthew Skelton and Manuel Pais
- Thinking in Systems, by Donella Meadows
- Also see: references cited in the above and other works by same authors
Disclaimer: Not a seasoned EM and definitely not the first to recommend these on HN.
But there is a line _somewhere_ on the natural spectrum of life forms, from microorganisms, to plants, to bugs and vermin, to dogs, pigs, primates, and humans, where our attitude about loss of life and/or a miserable life changes. Where are you suggesting we put that line?
EDIT: wording
By this standard, there is no such thing as abusing a domesticated species. They're "meant to" satisfy human need X, and everything else is irrelevant.
Here are two other things I've found:
1. Regardless of where you push your run/dry-run dispatch to, the underlying "do it" logic really needs to be factored properly for individual side effects (think functional). Otherwise, you inevitably end up with loads of "if dry-run / else" soup or worse, bugs _caused_ by your dry-run support.
2. You still need safety nets for when someone is doing dangerous operations without dry-run. Pointing and calling [0] is a great trick for this. For example, say your tool is about to delete X, Y, and Z. Instead of a simple "Yes" confirmation which the user would quickly end up doing on auto-pilot, you could have a more involved confirmation like "Enter the number of resources listed above to proceed" and then only proceed to delete if the user enters "3".
Very curious to hear about design idioms folks have come up with!
There's a Wikipedia page dedicated to a list of just what you described, synonymous words with Romance vs Germanic origins.
https://en.m.wikipedia.org/wiki/List_of_English_words_with_d...
I certainly knew nothing about it until I read this feature article [0][1] and the resources it pointed to.
[0] https://www.theguardian.com/lifeandstyle/2020/jul/26/every-b...
[1] HN thread: https://news.ycombinator.com/item?id=23962638
Wasn't trying to make that case, but I can see how my comment could be read that way.
I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.
I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines.
But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?
> If I ask you 3 seconds apart, though [...] would you not expect consistent results?
I completely agree with your original comments about lazy writing by the OP. But these all seem besides the point.
Our bodies and minds go through all sorts of states, some cognitively introspectable, some not.
"Happiness", whatever it may be, is what it is and need not conform to your presumptions. That's the point of studying it. Nothing about its fluctuations or the way these are felt by an individual are a problem per se with the research. It just means it's hard to do, and we may not know a whole bunch about it.
Not to belabor this but to note the irony here: there is probably a similar psychological (ehem) phenomenon that happens to a psyc grad student who lets their presumptions bleed into their interpretation of a measurement.
> The first principle is that you must not fool yourself — and you are the easiest person to fool.
R. Feynman
Our domain is precision oncology. In brief, this is about matching cancer patients with available targeted therapies by examining the genome of their cancer. This is different from how the majority of cancer patients are treated today: surgery and {chemo,radio}therapy.
Here is a problem in our domain where tech is one of the limiting factors.
If you look at the DNA of any cell and compare it against the reference genome, you'll find a lot of differences, aka variants. Typically even more so if you're looking at a sequenced tumour (~1e6 variants). This is your hay stack. And a variant that can be medically targeted to treat the cancer is the needle. The definition of what variant is "clinically relevant" is layered, context-dependent, and (partially) regulated. Software is responsible for automating away the majority of variants, say down to 10-100, in a justifiable, traceable way. It's also responsible for giving tools to the clinician to deal with the remaining ones. This manual step typically involves an informed line of questioning about each variant backed by 100s of supporting data points about it.
Without these two tech pieces, interpreting a single molecular pathology report can and does take many hours of (expensive) expert time, instead of minutes. For a rough sense of scale: human genome has ~3e9 nucleotides (ACTG), has ~3e4 known genes, ~1e6 known gene interactions, and ~1e8 known variants. Typical whole genome sequencing produces > 30GB of raw data (compressed).
This is probably the first problem everyone runs into. There are plenty of other ones, some more challenging and interesting than others. Feel free to send me an e-mail if you'd like to discuss this more! amir[at]streamlinegenomics.com
Shameless plug: I'm CTO at Streamline Genomics, a Canadian biotech startup, and tech is our limit. We're remote-first and we're hiring for a bunch of positions: https://www.streamlinegenomics.com/careers
Notably the explosion of math in Europe from the 1500s.
I wonder if the printing revolution had something to do with this.
Gutenberg died in ~ 1470
One can be quite relaxed but not at all focused and vice versa.
[0]: https://marshallbrain.com/manna1
FWIW I think this is probably many, many decades away from being even possible.
On the general point of shorter sentences, I've found it to be an excellent first approximation rule. Follow it religiously if you're new to making your writing reader-friendly. Later on ... keep following it. But allow your discretion to override it sometimes.
Do you want to build modern software systems at the cutting edge of cancer medicine?
We're creating the precision oncologist's computational toolbox: from data pipelines that sift through tumor genomes and filter and visualize mutations, to collaborative knowledge curation (think wikipedia, but for cancer genomics). It’s still the early days for us and there are plenty of high-impact challenges to solve!
Prior knowledge of biology is not required, but keenness to learn is.
We're a remote-first team with a timezone preference for the Americas. We're hiring for multiple senior positions (Backend, Frontend, Data/ML, Infrastructure/Security): https://angel.co/company/streamline-genomics/
--------
About you: You can comfortably debug across the stack and through system boundaries. You've been around the block and have your ideas about designing for security and performance, leading software projects, and evolving team processes.
About us: We have backgrounds in CS, medicine, and bioinformatics but we're primarily a software team and pride ourselves in our craft: We move fast and iterate, but write tests and have a QA protocol. We enable engineers to run with good ideas and ship, but we write design docs for risky projects and run retros after the fact. All our systems have CI/CD and our release cadence is as fast as we can build.
Current stack: Python 3 (Django, Flask, numpy, asyncio, pytorch), JS (node, d3, React/Vue), relational DBMSs (MySQL, Postgres, SQLite), docker, AWS, terraform, GitLab CI/CD.
Write to us: work [at] streamlinegenomics.com
Genuinely asking: what do you think profitable companies would do to their ML engineers over a product issue like this if there was no law under which they would be sued?
I think accountability without an enforcement mechanism is just a wishful suggestion.
Yes, deciding how to deliver feedback could be a nuanced, delicate challenge.
But a non-obvious related problem I've found is whether to deliver it at all. The mistake there being that people want or can benefit from the feedback you think you would've wanted, were you in their position.
Knowing a bit more now, this gap makes some sense:
1. Neuroscience is really, really hard. Even with the unbelievable recent advances, we're still years away from having a clear understanding of the mechanics of learning and memory.
2. The drift between AI and the broader cognitive sciences started in the 70s, seemingly borne out of pragmatism and the difference in goals between engineer types and scientist types.
I think this is true but I doubt it's anything new. I think the fundamental similarity between religious belief and "trusting the science" is the psychological simplicity of delegation to authority, and probably a deep seated property of the human mind.
Not knowing the right answer to questions we deem important, or worse the mental state of doubting what we've been raised to consider foundational and "obvious", is just too uncomfortable for the majority of people (I would've said all people, but I can't be sure).
match event.get():
case Click(position=(x, y)):
handle_click_at(x, y)
case KeyPress(key_name="Q") | Quit():
game.quit()
What I still don't understand is: does the new syntax magically do this to a user-defined class? i.e. if I say
foo = Click(position=(x, y))
...
case Click(position=(x, y))
edit: typo fix
In Python 2.7 you get this:
>>> my_list = [x for x in 'hello']
>>> x
'o'