stult

The point is that the outputs of the calculator are fundamentally surprising, in the sense that if any individual programmer could easily know all the expected outputs in advance, they wouldn't need the calculator in the first place. Photoshop surprises us by calculating the precise location of millions of pixels based on relatively simple inputs like a handful of clicks on a screen. This logic does not apply to every single imaginable program, but it does apply to the non-trivial ones.

There's a long and rich tradition of scholarship on what constitutes a "good king" in medieval English history that is important (but missing) context for this article. Usually, scholars rate kings in terms of their effectiveness as rulers, rather than according to modern conceptions of morality in order to avoid anachronistically imposing a modern mindset on medieval rulers. So taking an English king and assessing his success and failures according to what his contemporaries would have considered success and failure. Often that consists of some version of these: maintaining a secure and prosperous realm, keeping fractious nobles and peasants in line, acquiring new lands for his followers, building up the church, screwing over the French and Scots, and securing a smooth succession after his death, ideally to his own male child.

The article's title (though less its content) challenges a common generalization about English kings: the more pious they were, they less effective they tended to be. A certain minimum of respect for Christianity was expected (e.g., when Henry II was forced to prostrate himself before the church to beg forgiveness for the murder of Thomas Becket), but on the other extreme, some notoriously ineffective monarchs devoted themselves to Christian worship to an extent that it undermined their ability to engage with the pragmatic, worldly concerns of ruling. Henry III and Henry VI, and to a lesser extent Edward II come to mind as the most obvious examples. Henry III and Edward II spent too much money and time building beautiful churches, neglecting the management of military and more pragmatic fiscal affairs. Henry VI was literally insane, and spent most of his time praying rather than ruling, which directly caused the first of the Wars of the Roses.

Sometimes Edward the Confessor gets lumped in with this crowd, because he was famed for his piety and he failed at the most essential task of any medieval English king: ensuring a smooth succession. Which in turn invited the Norman Conquest and thus the Harrying of the North and a near genocide of the Anglo-Saxon people Edward ruled (and failed to protect by not ensuring a smooth succession).

Ultimately, the generalization is probably flawed anyway (too few examples to identify a real trend, and too many confounding explanations like piety being an adaptation to severe mental illness), but this article does a bad job challenging even the lesser premise that the general rule applies to Edward the Confessor.

It seems pretty evident to me that most successful and popular dynamically and statically typed languages are converging from different directions on a similar set of solutions. Very much reflecting the phenomenon you describe. Some simple examples: C# has moved from very strong typing of the exact sort OP criticizes (`Person person = new Person();`) to increasingly permitting looser/more expressive typing with `var`, anonymous types, pattern matching, etc. From the dynamic side, optional, loosely enforced typing is starting to grow more common (e.g., type hinting in Python, TypeScript in JavaScript) and provides a static but still flexible form of typing. So there's some happy medium where the language balances the permissiveness of dynamic typing and the expressiveness of static typing.

>IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach

Personally, I use VSCode for generic text editing, scripting, taking markdown notes, general purpose review/browsing repos (e.g., opening up a project to review a couple of python classes), etc. It's nice for switching between a variety of languages and use cases. I like the integrated terminal, the directory search feature (so much less clunky than the equivalent Mac Jetbrains IDEs' features), the multiselect text editing experience, the ease of configuration, and the general responsiveness.

But if I need to do a deep dive on a language, I generally switch to a fully featured IDE. For example, if I need to refactor 10000 lines of C#, I'm definitely going to switch to Rider or VS with Resharper where the built-in refactoring, debugging, and static analysis tools are so much more powerful.

So really I see them as different tools for different use cases. VS Code is nice for my fluffier, tech lead work, where I tend to bounce around between fifty disparate tasks in fifty different contexts. Rider, Pycharm, CLion, etc. are more useful for me when I have to fall back into doing deep dive technical work personally.

Journals employ copy editors to address just those sorts of mistakes, why should we not hold software to the same standard as academic language? But more importantly, these software best practices aren't mere "grammatical mistakes," they exist because well-organized, well-tested code has fewer bugs and is easier for third parties to verify. Third-parties validating that the code underlying an academic paper executes as expected is no different than third-parties replicating the results of a physical experiment. You can be damn sure that an experimental methodology error invalidates a paper, and you can be damn sure that bad documentation of the methodology dramatically reduces the value/reliability of the paper. Code is no different. It's just been the wild west because it is a relatively new and immature field, so most academics have never been taught coding as a discipline nor held to rigorous standards in their own work. Is it annoying that they now have to learn how to use these tools properly? I'm sure it is. That doesn't mean it isn't a standard we should aim for, nor that we shouldn't teach the relevant skills to current students in sciences so that they are better prepared when they become researchers themselves.

You're comparing one of the strongest economic expansions in US history (1991-2001, brief, small recession, then 2001-2007, stopping at 2005 of course) to a period bookended by two of the worst recessions in US history (2007, 2020). It should be concerning that equity returns don't differ very much. That means they aren't correlated with the underlying economy.

Try washing your lenses with a drop of dish soap. That will help with the fogging.

https://www.npr.org/2020/05/08/853009325/how-to-prevent-glas...

> Police helicopters don't have hellfire missiles as standard optional armament.

I mean, they could. And firefighting planes could be rerigged to disperse chemical weapons, doesn't mean there's anything wrong with them existing.

>Also police helicopters are operated by local/state forces. This is a federal agency which is way out of its jurisdiction.

I'm guessing it's on loan. It's hardly unusual or questionable for the feds to provide assistance to local police during periods of extraordinary crisis. However justified the people of Minneapolis may be in reacting this way to yet another police homicide, what else are the local police supposed to do now except try to restore order using whatever tools are available? Including drones that can provide immediate information about hotspots, crowds, fires, etc.

Whatever your perspective on fad-chasing in software development, some things just suck down through the ages...

Do you do code reviews on committing to develop? Other companies/organizations generally have develop for work in between releases and merge into develop from feature/bug fix branches (primarily owned by one individual) with pull requests. The PR provides an opportunity for team code review and feedback before merging into the shared develop branch. That also allows developers to commit and push unfinished work to their own branches, so that it is backed up on their remote repository rather than just their own laptop. Otherwise if they pushed straight to develop, they'd constantly be breaking that shared branch with non-functional, partially complete code.

Age is an independent risk factor, and richer countries' populations skew older. More old people means more deaths. Assuming similar environmental conditions and infection rates, Italy will see more critical cases purely as a function of population age.

I definitely agree that much of this argument boils down to a set of poorly fleshed out definitions. Though I would argue that you’ve misrepresented the article’s definitions a bit. The article is asking whether the formal system in question can fully explain human intelligence. Which we all agree it can’t. It’s not arguing that no machine in the sense you or I would understand that word can explain human intelligence, the author just assumes implicitly that any machine will consist of a formal symbolic system of the type Gödel studied. Obviously if you challenge that assumption, the argument loses its potency.

But in defense of the OP, if we discard the perhaps unhelpful term “machine,” the argument does raise an interesting question: what distinguishes the formal, mechanistic logic of pure mathematics from what you describe as “intuitive reasoning?”

I think a worse flaw in the argument is the assumption that formal symbolic completeness is somehow required for human intelligence. I’d say the opposite if anything is true. If modern psychological research has provided anything of value, it’s pretty convincing evidence that human brains don’t require any sort of logical completeness or even internal consistency to function.

A slightly more charitable interpretation: DoD hired a bunch of loonies to keep Harry Reid happy and they used the opportunity to evaluate whether public information about UFOs could be used to compromise actual SAP research projects (imagine if the conclusions of the report had been, “yeah this particular set of sightings could easily be explained by this hypothetical near future technology” and the tech described was an actual black project). Which actually isn’t a terrible idea from a counter intelligence perspective, though they definitely over paid for the product. Ultimately that’s on Harry Reid’s shoulders, though.

Yeah this is just another chain of evidence problem. We trust cops not to plant evidence, so long as they follow strict chain of evidence procedures. It’s an imperfect system but it’s largely effective.

Holy crap you've made my job infinitely easier. Thank you!

I find the best way to deal with long running, difficult problems is to (1) document what you are doing and (2) prototype as fast and often as possible. That way you have a measurable record of a systematic attempt to tackle the problem. If the team metrics don’t capture that, you have an easy argument to make that they should and a practical way to do so (commits to a readme or wiki or prototype branch are measurable).

It also helps your teammates and managers identify when you are spinning your wheels and need help. As a tech lead/architect, I find prototypes and documentation about a hard problem extremely helpful for identifying when I’ve made a bad technical decision and selected an approach that simply isn’t efficient or workable. Otherwise, it’s hard to distinguish between that and when the individual dev is simply not up to the job.

It’s also much easier to solicit feedback when you’re stuck if you can offer a record of what you have tried.

My only complaint is I can’t ignore auto-gen’d code like EF migrations in dotCover, so my unit test coverage looks terrible. It doesn’t help that I write terrible unit tests, but still!

>Do fancy refactoring tools update your README and docs/ folder yet?

Yes actually. Resharper plus Swagger handle 95% of that for me automatically.

And I absolutely do not agree with your point about syntactic abstraction. Interfaces, dependency injection, generics, very light use of inheritance/abstract base classes, and extension methods generally provide all the abstraction I need to avoid repeating myself.

Could not agree more. I recently led a refactor of a monolithic .NET MVC app and took this exact approach. We made all of the controllers thin, with almost no logic at all beyond specifying the route and dependency injection. Then redirected the request to a “service”, which originally was just a reworked combination of the old controller/model logic hidden behind a common service interface. Then, slowly we replaced the C# services with microservices. So we went from ball of spaghetti to monolithic service oriented architecture lite to actual microservices with the monolith converted into an API gateway. If we didn’t have independent motives for going to microservices, sticking to the clean and well organized internal APIs of the refactored monolith would have been totally fine.

I’ve accidentally landed on an architecture like this and I’m actually pretty happy about it. It was driven by a desire to kill a large monolith slowly, by extracting key features into separate services. Sold to the customer as microservices because sexy fad of the moment. Our real motivation was we had way too much trouble recruiting in the monolith stack (.NET) and had a surplus of embedded C++, python, and JS engineers. Anyway, turns out our teams naturally self-organize around four or five domain+language clusters that effectively form separate services that are too large to really be micro, but too dissimilar to play nicely together in a monolith. Eg, python data science module wrapped in a Flask API providing physics calcs, legacy C# service providing simple data models via REST, JS react front end served from a separate node service, a weird C++/python hybrid used for an embedded device sim service, etc. It’s not what I planned as the tech lead/architect, but I think we organically reached what is really the best approach for our team. Definitely an element of Conway’s law in action, but in a good way. We are making the most of our organizational structure rather than fighting against it. Would this scale to google levels? No, probably not. But we don’t need it to, and it’s incredibly unlikely we ever would given our specific business.

What specific “pythonic” habits have you found are more difficult to maintain? Asking out of genuine curiosity, not to challenge the premise. I work with a lot of data science people that really emphasize being pythonic, but coming from the software/static typing side of the house I always find their code style and architecture a little concerning, and I’m not sure if I’m just not getting it or if they really are writing spaghetti.

You never have to pay a large lump sum. So it’s similar to having savings and always covering your own losses. But with the added benefits of covering you even if you have not had time to save sufficiently to cover your losses (or lack the discipline to do so), or are unlucky and suffer multiple large losses in closer proximity than your savings and income can absorb.

Not at all a stupid question. PACER's fees have been a source of controversy for years. They charge $0.10 per page or a max of $3 per document. There's been litigation about the fees[1], but it's still working its way through the court system. A couple of bills that eliminate the fees have been filed to in Congress over the last year or so, but they haven't gone anywhere.

It's also an incredibly technically outdated and user unfriendly system, so even without fees it would be worth scraping.

[1]https://en.wikipedia.org/wiki/PACER_(law)#Litigation_over_fe...

The comment above is true of ROS, full stop. Even in C++ without involving Python. Especially if you have any real time requirements. It uses sockets for interprocess communication, which adds massive amounts of overhead. Replacing ROS and using straight function calls sped up a simulation of a system I was running from 10x real time to 1000x, for example. That's fine for certain applications but just didn't work for my particular use case.

The DoD wasn't going to touch them in any case after they pulled out of Maven

>In order to build a MOSFET, you need to know how do electrons react in the presence of thin barriers, and how thick should the gate oxide be to prevent breakdown while still keeping the field strong.

And yet I somehow managed to produce a pretty complex quantum computer before I was even born: my brain. Or maybe my mom did, but she is nearly as ignorant of quantum physics and biology as I was as a fetus, so the point stands.

The person above was wrong about your implicit assumption about QM and dependency chains. Your real assumption is that interstellar societies will develop technologies intentionally using explicit knowledge that charts such a dependency chain, rather than evolving capabilities via or alongside implicit knowledge, such as the implicit knowledge we all share in which allows us to produce human brains with no intellectual effort whatsoever. We don't and can't know what chunks of those dependency chains are innate for other species, which in turn means we don't know how they will traverse such a chain, even assuming ad arguendo your hypothesis that the dependency graph is essentially linear.

Oregon is a pretty warm climate. Just eye balling the terrain, they look to be at a pretty low elevation and probably won't see more than a few weeks of below freezing weather per year. Not sure this would be practical in a more punishing climate.

Law firms are usually organized as LLPs, LLCs, or PCs these days, but bottom line that means ownership shares can't be freely transferred. You can't sell your stake, so there's no opportunity for a major liquidity event like you might experience as an employee compensated in stock at a corporation when the stock increases in value dramatically and you sell.

Worse yet, lawyers have to keep working to continue to receive equity compensation in the overwhelming majority of cases. So you can't retire and continue to make money from your equity stake. You can't even really cut back on the crazy hours. This answer covers it pretty thoroughly: https://www.quora.com/Do-partners-in-law-firms-keep-a-share-...

Depends on the lawyer and the programmer. I was on the lower end of big law and I'm on the upper end of programming.

This was years ago, and the commercial offerings weren't as well developed.