Also, dependent types, IE value-based dispatch. Which can be incredibly useful when dealing with enums. That alone is enough to make me curious to try it!
997 karma · joined March 21, 2015
https://github.com/Badg
https://nickbadger.com
@nbadg
Just because your local car dealership(s) didn't opt for hail protection nets isn't on its own evidence for or against their effectiveness. There are a great many factors that go into such a decision and, unless you were privy to the decisionmaking process itself, whether or not nets were considered -- much less their effectiveness -- is pure speculation on your part.
The point I'm trying to make is just that there are a lot of off-the-shelf (or nearly so) hail protection strategies that seem like they might have better economics than single-axis-tracking installations, which might improve the cost effectiveness of a fixed panel installation to the point where, even in hail-prone regions, it might be doable.
To be clear: anti-hail nets are already a COTS product, just not for this application (as far as I'm aware). Nets are just really, really good at absorbing kinetic energy. I mean, that's effectively what kevlar ("bulletproof") vests are made of -- netting with a very small cell size. But it seems to me like some kind of roll-out kevlar or dyneema netting could be really effective at protecting panels, though I think you'd need some kind of better strategy for safely dispersing the hailstones after they were caught, so you don't end up with a huge collection of hailstones on the net.
I agree that there's probably too much light blocking to leave them up continuously, and I'd also be worried about UV damage. But remember that the comparison here is to single-axis-tracking installations; I think automatic deployment of anti-hail netting could easily be made at least as reliable as the tracking system, if not significantly more so. Maintenance and testing would also be very cheap in comparison, since you could do it at night (ie without affecting power production), and damage to the protection system could be repaired without taking panels offline.
The more I think about it, the more I'd be interested in seeing it deployed.
I mean, think about how many stars had to align to catalyze our first steps on the moon. Now, 53 years later, we're just starting to put serious effort into going back -- not because there's any market reason to do so, but because (once again) there's political pressure for it. Which would suggest that the best case scenario for the current exploration efforts are something along the lines of what we already see in Antarctica: a well-staffed scientific presence that does really cool/valuable work, but nothing remotely approaching even a single major city in terms of human presense.
It seems to me that one of the unwritten priors to the Fermi paradox (at least in popular discourse) is that technology is the only prerequisite to expanding a civilization; in other words, if you have the technology, then interstellar expansion is only a matter of time, and that all civilizations will inevitably eventually develop the technology. And that... seems like a pretty big assumption, if human history is any indication.
It is indeed possible to have a so-called "kein-Mann GmbH" where the company has bought back all of its shares, though my understanding is that it's a bit of a legal grey area, and certainly not settled law.
I agree that the legal infrastructure is almost certainly there, at least in the sense that there are absolutely plenty of lawyers and lawmakers that specialize in this area. My point is simply that, because it's so much less common, basically every situation ends up being unique, which means that the work that the lawyers are doing is almost always a one-off, which makes it really expensive. And so it's just not worth the effort.
What I mean by legal insulation is more that, in this holding construct, the GmbH ceases to have any financial relationship to the founders. Stiftungs are sort of... headless financial pools governed strictly by their founding documents, completely divorced from the people that created them, and the GmbH would simply be an asset in that financial pool. That means that, for example, were someone to sue the founders, even for something completely unrelated, there is no possible way that shares in the GmbH could possibly end up someone else's hands. Typically when we talk about the liability limitations in corporations, we're talking about them in terms of shielding the founders from the actions of the company, but the inverse is in my opinion just as important (if you're truly interested in forming a self-governing social organization pursuing a social good). I'm not sure if there's any examples of shares in a gGmbH being assessed as assets in a civil case; that would be another interesting question to inform the decision.
That being said, one of the reasons that I'm so interested in the idea of a Stiftung holding, is that I think it also opens up options for actual democracy within the leadership of a company, which is a fascinating idea. That isn't a requirement in a Stiftung holding relationship, but I do think it's an interesting possibility.
At any rate, I think probably the primary downside of this idea is that, like I said, I've not seen any examples of it discussed publicly. Which means you'd need to be doing a lot of the legal legwork on your own -- which means lots of time spent talking to lawyers, which would be really expensive. But I think there's some really interesting possibility for innovation in terms of corporate governance here, in a way that, like I said, wouldn't be legally possible in the US, and it definitely seems like the structure that gives the social purpose the maximum possible protection.
But that's not what I'm asking about. Unlike in the US, Stiftungs in Germany (both family and public-purpose) can own an unrestricted percentage of shares -- including all of them -- in normal companies (Kapitalgesellschaften). And I'm specifically interested *not* in restructuring a GmbH as a Stiftung, which is what Ecosia decided against, but rather, I'm wondering if there are any resources available discussing pros and cons of forming a Stiftung as a holding entity, fully owning a GmbH subsidiary (such a construct is not legally possible in the US).
From my perspective, this holding structure would provide much better legal insulation (in both directions) from the founders, preserve the operational flexibility of the (operational) GmbH, while allowing distributions from the GmbH (which would, by definition of being a 100% stakeholder, flow exclusively into the Stiftung) to be distributed by the (purely administrative) Stiftung, according to the founding documents. But I've never seen such an arrangement discussed in depth, which is why I'm asking about it.
That being said, it might be possible to get to "better than nothing" with transfer learning, by training a model to detect both "there are children here" as well as "this is pornography". I have no idea what the success rate would be, but there have been some pretty impressive generalization results in recent years with classification models.
I'm aware of eg NSFWJS, which is a tensorflowJS model [1]. Is there anything else that, say, can also do violence/gore detection?
I relatively recently was looking for a new job, so I was curious to see how well my own search process compared to this. Then I was mildly annoyed to discover that they require email signup to actually view any details about the company or the job. So I give them my email. And then I was even more disappointed to discover that they require you to pay money to even see the link to a single actual job posting. Sorry, not gonna do that if I'm just trying to scratch the curiosity itch. So then I go to delete my account, and... nothing. No can do.
Honestly one of the quickest turnarounds from "oh, neat" to "jeez, what a disappointment" that I've had in recent times.
I'd be curious to see some kind of sociological studies about risk aversion amongst criminal prosecutors. Clearly an acquittal (and the associated trial) is still a huge burden to a person, so a strong motivation to only take cases you're confident you'll win makes sense to me. But especially in situations where the circumstantial evidence is so strong, I think most people in the US would consider it unjust not to pursue a trial at all.
To be completely honest, the first thing that crosses my mind is that the prosecutor might be a racist, since the story is (it seems) about an immigrant family. To be clear: I have absolutely no reason to suspect that. But something about the situation sounds off to me, and that's definitely one of the first questions that start lurking in the back of my mind.
Long story long: the optics here definitely aren't good.
Assuming we take the OP's story at face value (obviously something you wouldn't do in a courtroom!), surely there's enough evidence here for a case, even if the defendant isn't, at the end of the day, convicted? Or is Sweden more averse to questionable cases than the US? At least according to this thesis [1], the difference in conviction rate between Sweden and the US doesn't seem to be large enough to support that idea.
[1] https://dc.etsu.edu/cgi/viewcontent.cgi?article=4835&context...
At any rate, sorry for the misinterpretation. To be completely honest, I wasn't even aware that private prosecution was an actual thing, I assumed it was just a mistranslation or colloquialism for a civil tort case.
[1] https://en.wikipedia.org/wiki/Private_prosecution#United_Sta...
This is incorrect. Far from unheard of, the civil justice system in the US is, in fact, frequently used as a secondary route of recourse by private persons, regardless of the existence or outcome of a criminal prosecution. The legal test used to determine liability (in civil justice) is different from the legal test used to determine culpability (in criminal justice), and therefore, you can also have mixed outcomes. Furthermore, civil law in the US focuses on "making the plaintiff whole", vs criminal law which focuses on sanctioning the defendent. As a result, civil cases might be the only way in which a victim of a crime could get any form of compensation from the perpetrator.
One extremely high-profile case in the US was, of course, that of OJ Simpson [1], who was found not guilty of murder in a criminal case, but liable in a civil one, for the exact same action.
[1] https://en.wikipedia.org/wiki/Murder_trial_of_O._J._Simpson
> Python chooses to provide (3) because Python is slow anyway so why not at least provide the least surprising container given how slow the language is. The existing Python dict was so awful that OrderedDict is actually faster (not fast in the wider scheme of things, but faster than that) so that's good enough.
The python dict implementation is actually extremely optimized, and used in very critical hot paths throughout the interpreter and object model (for example, ``object.__dict__``). Additionally, python dicts (in cpython) are implemented in C, so any "slowness" there is going to be the result of the python code written to use the dictionary, and not the dict itself.
Up until python 3.6, cpython dictionaries were not ordered. At version 3.6, cpython dicts were made ordered, but only as an implementation detail. And at version 3.7, the preserves-insertion-order property of dicts was officially made part of the language spec, so that all python implementations need to support it.
The 3.6 change was made purely for performance reasons (and the stdlib already included an OrderedDict anyways). It was then made part of the language spec in 3.7 for several reasons: reduced maintenance burden for OrderedDict, convenience to developers using python, reducing the chance of accidental footguns of people relying on the implementation detail as if it were actually part of the language (and it then being removed later and breaking things), etc.
The decision was made as part of this thread[1], if you're curious.
[1] https://mail.python.org/pipermail/python-dev/2017-December/1...
Alternatively, though, SVGs in ``<svg>`` elements could just, yknow, retain their stylability. (is there a reason they don't? this has been a long-running frustration of mine)
In python you generally have two kinds of randomness: cryptographically-secure randomness, and pseudorandomness. The general recommendation is: if you need a CSRNG, use ``os.urandom`` -- or, more recently, the stdlib ``secrets`` module. But if it doesn't need to be cryptographically secure, you should use the stdlib ``random`` module.
The thing is, the ``random`` module gives you the ability to seed and re-seed the underlying PRNG state machine. You can even create your own instances of the PRNG state machine, if you want to isolate yourself from other libraries, and then you can seed or reseed that state machine at will without affecting anything else. So for pseudorandom "randomness", the stdlib already exposes a purpose-built function that does exactly what the OP needs. Also, within individual tests, it's perfectly possible to monkeypatch the root PRNG in the random module with your own temporary copy, modify the seed, etc, so you can even make this work on a per-test basis, using completely bog-standard python, no special sauce required. Well-written libraries even expose this as a primitive for dependency injection, so that you can have direct control over the PRNG.
Meanwhile, for applications that require CSRNG... you really shouldn't be writing code that is testing for a deterministic result. At least in my experience, assuming you aren't testing the implementation of cryptographic primitives, there are always better strategies -- things like round-trip tests, for example.
So... are the 3rd-party deps just "misbehaving" and calling ``os.urandom`` for no reason? Does the OP author not know about ``random.seed``? Does the author want to avoid monkeypatches in tests (which are completely standard practice in python)? Is there something else going on entirely? Intercepting syscalls to get deterministic randomness in python really feels like bringing an atom bomb to a game of fingerguns.
This is definitely a python gotcha. In fact, it's literally one of the canonical ones [1]. But it's purely the interaction between the way that names/variables work in python, and late-binding closures.
More explicitly: it's best to think of "variables" in python as "names", because in code, you refer to names, but the underlying variable might change. This is also why python is best described neither as call-by-reference nor call-by-value, but rather "call-by-assignment" or "call-by-object": you're passing a reference to a variable bound to a particular name. Unless you're writing C extensions, you never actually have a reference to the variable itself -- instead, to the name.
Meanwhile, closures in python are always late-binding: they are themselves "live", mutable objects, in the sense that they're just a reference to the namespace they're closing, and *not* a copy. So if you mutate that namespace between establishing the closure and making use of it, you'll see the mutated version.
[1] https://docs.python-guide.org/writing/gotchas/#late-binding-...
def loop():
for number in range(10):
def func_w_closure(_num=number):
return _num
yield func_w_closure
[1] side note, closures in python are always late-binding, which is what causes the behavior in OP
I'm aware, particularly given that I live there.
Post-tax, post-essentials income comparisons are absurdly complicated and always depend on the individual. For example, dual-income families in Germany can tick slightly ahead of similar families in the USA because of how much more expensive it is to raise children in the US and how many (cash and societal) benefits you get from the social support system in Germany. But even this is a can and not will; that will also depend on your specific tax situation, and a whole host of other things. And whether the discrepancies in income levels are balanced out by different standards of living is also something you can really only evaluate on a case-by-case basis, because it's different for every job. For example, the income differential in software engineering is way higher between NA and Europe than it is for, for example, healthcare workers. In my specific case, when I moved from the US to DE, my gross decreased by 2/3 and my post-tax, post-essentials decreased by 1/2 -- and by post-essentials, I'm including things like massively higher rents in the US.
> a lot of European countries welcome skilled migration like Germany
I'm an immigrant to Germany and I would absolutely *not* consider it welcoming to immigration, skilled or otherwise. And given the results of the past few elections here (and elsewhere in Europe), which have been dominated by extremely negative discussions of immigration (with the notable exception of most/all of the Scandinavian countries), I don't really think your comment is painting an accurate picture.
I've never lived in Canada and have no experience with immigration there, so I can't speak to Canadian immigration policy beyond what I've already said -- that the current government is very pro-immigration and has policies in place specifically meant to compete with the US on skilled workers. What I can say though, is that much of what you're saying is very contrary to both my lived experience as an immigrant to Europe, as well as much of my experience with several very close friends who've been through the H1B -> green card lottery in the USA. Also, from an economic perspective, I would neither describe US immigration policy as "smarter", nor "better" than Canada's. And I would absolutely *not* describe it as a "strong procedure".
Europe is also an option, though it's not as pro-immigration as Canada (and has lower salaries as well).
I think the fundamental question here is "how easily can you construct (write or generate) a parser that matches your intent?". And to answer that question, I think you have to look at the entire process.
What good does it do you to hear "your intent isn't clear; try again" if you don't understand where the ambiguity is? Presumably, if you knew where the ambiguity was, you wouldn't have written it -- since you know it can't create a grammar. So really what that message is telling you is, "you don't understand your own grammar" or "you don't understand how to write rules for your PG". And in my experience with several different PGs, the failure messages returned in those cases are... less than helpful. So you end up spending hours banging your head against your desk trying to figure out where the ambiguity is, even with a grammar you know back-to-front.
Furthermore, even if you use a CFG, you still haven't gathered evidence that the resulting parse matches your intent. For that you need test cases. And as soon as you write a test case, you get immediate feedback that your intent isn't clear, regardless of PEG, CFG, or anything else: you see that your resulting parse doesn't match with the expected one.
Given both of those things, it seems to me that issue at hand really does boil down to "which feels more natural, PEG, CFG, etc", which is always going to be a personal preference.
To use the example from the article: spreadsheets could use strongly-typed columns, but guess the column type automatically based on the values entered. When things go right, it'd be just as easy as today, but if things go wrong, you always have an escape hatch: with a little more work, you can manually specify the column type. Problem solved. That gives you the increased productivity you want for the happy case, without the frustration of trying to find a workaround for the corner case. This kind of approach needs more architecture work at the beginning of a project, but it's almost always feasible.
That being said, I think your frustration is warranted, although I think it's much more pervasive than tech. At its core, I think the problem is that, in your example, the CEO and the programmer are having two different conversations without really realizing it. The CEO wants a problem solved, but the programmer wants the tools to solve the problem themselves. The CEO thinks that ML should be able to solve their problem, but the programmer sees that ML as a tool has serious limitations, and won't help solve under-specification. And then they both end up talking past each other.
It seems that a lot of (at least western society) is built around the idea that when someone asks for help, what they "really" want is, metaphorically, to be given a fish for dinner, instead of learning how to fish. That's the CEO in your example; the presumption is "I want help" means "solve my problem", not "make it easy for me to solve my problem myself". It's one of my biggest frustrations, because it inherently robs you of agency and in many cases can be downright condescending -- for example, when I was working as a mechanical engineer, there were shop floor guys ignoring the tolerances I specified on my drawings because they assumed I was over-specifying them, because they lacked the context of the rest of the design, and weren't willing to sit down to hear the bigger picture. But when I had to send the parts back for re-work, they acted like it was my fault.
Anyways, this is all a really long-winded way of saying, I think this is largely a social problem, not a technological one. But I don't think it's inherent in humans; I think this is something we've learned as a part of our culture.