ketozhang

You're asking for something different here. What conda does is package all binary dependencies (e.g., libpq, cuda) that normally should be dynamically linked and provided by your OS.

The pip ecosystem (including uv) doesn't encourage this. Although you could and many have, the build tools don't support it as first class.

For why? Ask what happens if you want an updated version or specific version of CUDA? The library author must add support for runtime linking or users would have rebuild the entire conda package.

In other words:

* /skill may or may not call on the instructed action

* /tool (or @tool) will guarantee the action is taken

This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).

It's determinism, flexibility, and language.

To the LLM, the a skill input is deterministic, inflexible, and outputs natural language.

A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language.

An MCP as an input is deterministic, flexible, outputs natural language.

Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill.

So, Skills + REST API = MCP only if you can deterministically call on the REST API.

You've misunderstood the GIL and Python threads.

For I/O, you can add threads and share the same connection object. Like any other languages, you are responsible for making it thread-safe.

There's also async. Many Python web apps spawn a thread per worker in your web server, not processes. Look into ASGI vs WSGI.

It's more so horizontal vs vertical scaling rather than languages.

You aren't running large scale xact/s on a single node.

Kubernetes isn’t a great example of you can just read it like a document. The resource kind jargon is huge.

Most compose files are small and use familiar linux jargon.

I can give an non-dev IT person a compose file and they can understand every key. I can’t do that with K8s or Quadlet.

I like to think most seniors know to not blindly follow DRY. However, I can tell many of us are uncomfortable with the idea of needing to maintain multiple duplicated sources of code.

To help with that, I think the simple model of two callers depending on a common code needs to be scrutinized. If the common code needs to change because only one of the caller needs it, then it doesn’t belong in the common.

The wrong goal for DRY is attempting to do it with encapsulation. Encapsulation shifts the refactoring work from the caller to the common code. However this is not what you want because there’s a lot more consequence in updating the common code than the caller.

You can avoid encapsulation and still be DRY by having multiple thin abstractions that the caller needs to be aware about is better. In OOP you are taught SRP and IoC for this. In procedural programming, this just comes naturally as code calling series of helper functions.

This assumes the bug exists in both places which might not be true at all even if they both are dependent on the same duplicated code.

If you only spot the bug in path A and not path B, why fix the bug for B?

You could still have security bumps happening (like dependabot).

GTD has the addition that you must create a system of reminders/followups. GTD is great to practice being okay with forgetting stuff and trusting your tracking system.

I think your argument focuses a lot on the scenario where you already have cleaned data (i.e., data warehouse). I and many other data engineers agree, you're better off with hosting it on SQL RDBMS.

However, before that, you need a lot of code to clean the data and raw data does not fit well into a structured RDBMS. Here you choose to either map your raw data into row view or a table view. You're now left with the choice of either inventing your own domain object (row view) or use a dataframe (table view).

We need long running averages and 2023-2025 is still too early to determine it's not effective. The barriers of entry for 2023 and 2024, I'd argue is too high for inexperienced developers to start churning software. For seasoned developers, the skepticism and company adoption wasn't there yet (and still isn't).

The data is surprising. However, I do wish this article looked carefully into barriers of entry as it can explain the lack of increases in your data.

For example, in Steam, it costs $100 to release a game. You may extend your game with what's called a DLC and that costs $0 to release. If I were to build shovelware with especially with AI-generated content, I'd more keen to make a single game with a bunch of DLC.

For game development, integration of AI into engines is another barrier. There aren't that many choices of engines that gives AI an interface to work with. The obvious interface is games that can be entirely build with code (e.g., pygame; even Godot is a big stretch)

You could either delete the .venv and recreate it or run `uv pip install --upgrade .`

Much prefer not thinking about venvs.

The autocorrelation is important to show that it's transformation to D-K plot will always give you the D-K affect for independent variables.

However, the focus on autocorrelation is not very illuminating. We can explain the behaviors found quite easily:

- If everyone's self-assessment score are (uniformally) random guesses, then the average self-assessment score for any quantile is 50%. Then of course those of lower quantile (less skilled) are overestimating.

- If self-assessment score vs actual score are dependent proportionally, then the average of each quantile is always at least it's quantile value. This is the D-K effect, which is weaker as the correlation grows.

-The opposite is true for disproportional relation.

So, the D-K plot is extremely sensitive to correlations and can easily over-exaggerate the weakest of correlations.

The more common experience with autocorrelations are with time series, but what the author said is correct even in that context. A time series autocorrelation relates the same time series function at different times. At the simplest you plot the arrays X vs X where X[i] = f(t[i]). You then may complicate it further by some transformation g(X) vs X (e.g., moving average).

Did you guys considered existing standards when you chose what to use for representing workflow definitions before choosing OpenFlow? For example, Common Workflow Language

Hover your mouse over those and you should get the absolute date. Some if not many are using time tags.

It's not popular because you're mostly hearing from the science community who want more features in their array (vector/matrix/tensors).

Why would you want to use C-like arrays in Python anyways?

It is not deprecated. Calling setup.py directly is (i.e., `python setup.py sdist`)

Modern way of building a package is to use a build frontend. Most notably is the PyPA's build package.

    python -m build .

Most project managers like poetry has this built-in with it's `poetry build` command.

In this particular case. OP had a lot of knowledge which served as a crutch in this journey. The less you are aware of how setuptools used to work, the better.

Here's a packaging guide that answers most of your questions.

https://learn.scientific-python.org/development/guides/packa...

As a TLDR, you have many options 3rd party build tool (aka build backends). Each build tool have different *static* ways to specify compile options that is native to the language or generic (e.g., CMakeList,s Cargo.toml, 3rd party YAML. When it comes to dynamically specifying your extensions, setuptools is still the only option.

In diataxis, a tutorial serves your education and a how-to guide serves your work.

Following this standard, a tutorial may contain a simpler or more contrived example; it may contain things you'd never do in production.

Why? What's your goal visiting the W3C homepage?

It should be to learn who they are and what else the website provides. You're not there to read it's entire homepage. You're there to navigate.

The pages that need to be dense, like the standards document, are.

It works on HN for at least the reason that HN post titles are often relatable. The same can't be said about paper titles even if you're in the field.

The design is horrible and a relic of skewmorphism.

Single tally memory is useful on small screens. I just wish they’d display the stored value somewhere.

I'm way off. I meant 15A. Now I've no clue what the journalist is calculating.

I think the journalist is calculating load capacity. A 1500A @120V kettle requires 0.18 MW. Rounding up, 60 kettles requires 12 MW. It's not how much water you can boil, it's how many kettles you can run at the same time.

Yes you're right, every superposition of quantum systems have a real valued probability distribution for some observable variable.

QM has very specific rules when it comes to how two random variables are dependent. That specific rule comes up when you have quantum interference and this is best described by the conjugate square of two complex functions A^2 + B^2 + A*B + B*A. This is just a special case of the union probability: P(A) + P(B) - P(AB).

> Not to mention in terms of making money, you would be far better off in the industry than spending 6 years in hopes of getting a tenure.

That's true for most technical fields in academia. A physics degree can land you a well paid job as a data analyst/scientist or in quantitative finance.