BiteCode_dev

Good software, simple, does what it says.

I rarely need it; now BT mice work quite well, but sometimes, to avoid pairing one mouse with a new device (and losing the previous one), I will use it.

Because HTMX is declarative and the declaration is in HTML, people have weirdly extended the "no need for js+json+rendering for ajax" to "don't use js".

This is making your life needlessly difficult.

HTMX is just a fancy ajax layer with a little event handling sprinkled on top. You can and should script to your heart content even if you use it, when you need so.

I use js in all most of my HTMX powered pages. Sometimes just a few lines. Sometimes a whole lot. Sometimes vanilla, sometimes alpine. I even have one where I load react for one single page because I want a community widget while the rest of the site is pure HTMX.

You can do whatever you want.

20 years.

And we have been able to produce graphene around 2004 I believe, so we are going soon to cross that threshold.

I concur, and this can be solved once you get the hang of actually creating a small bubble inside crowds and accept the FOMO of missing the rest of the event to have a quality conversation for a few hours.

Not everybody is made to ride a wave of people. But you can find a way to enjoy it in a different fashion. I find it true for a lot of situations, actually.

You don't have to follow all the rules.

That's pretty much how all people working on tracking features at GAFAMS, all people working on algo manipulating people's behavior on social networks and shopping sites, and incidentally how people working on the manhattan project, moved.

They get into the interesting problems and miss the forest for the tree.

Plus it's fun to be among smart peers, and well-paid.

The author woke up from this, but many do it for their whole life and see no problem with it.

That's why I rejected interviews from Google and Facebook. Because I knew I would do the same. It's too tempting.

This type of genuine openness mixed with the excitement of passion is so joyful to read, especially from a high achiever with strong technical capabilities and a history of business success.

Salvatore is definitely high on my list of role models.

Specifically for Python, right now, uv is showing the most promises (and mise has an uv backend, btw) for bootstrapping.

They have carefully avoided 90% of the mistakes of all other tools, and I have a long list. They don't live in a bubble.

uv still has problems (like indy greg builds not having headers) and it's still below v1 so I can't recommend to use it yet. But I've been testing it in different contexts for months now, and it's doing exceptionally well.

I usually take a year of testing before recommending a tool, because I need to see it in action in Windows shops, in Unix shops, with beginners, with non coders, with startup, in a corporate settings, with grey beards, etc. Python versatility means the user base is extremely diverse and you find it in the weirdest envs.

I also interviewed Charlie Marsh:

https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...

and it gave me a lot of confidence that he is actually not trying to do everything at once, but quite the opposite, nail to the death very specific problems.

I've tried everything in the Python world, with a good hundred of companies envs, and about a thousand people in trainings. Pyenv, poetry, pipenv, pdm, nix, pyflow, pdm, rye, you name it.

The number of ways they can fail is astonishing.

The uv team quickly identifies when there is friction, and fix it at astonishing speed. They just announced they took ownership of the WHOLE python-build-stand-alone project, and they contribute the improvement to it to cpython upstream.

Their dedication to a good doc and great error messages is quite amazing as well.

I'm impressed.

In all scripting language, packaging problems mostly stem from bootstrapping.

Nvm shims break, python path confusion, gem installed on the wrong ruby interpretters, etc.

Maybe you managed the impossible.

But in 20 years of python I've seen only one tool doing bootstrapping in the right direction, all the other ones have failed.

So I'm suspicious of something that does multiple languages.

In the case of mise, it delegates this complexity to the user. E.g: for python, you have to know the config choices, and choose the right backend like asdf, pyenv, or indygreg.

Then you better understand the consequences of that choice.

To me, that's alreay a leak of the abstraction.

Bootstrapping python incorrectly is the main source of packaging problem.

There is a lot to leak. For exemple, if you install a non wheel compiled extension, you'll need the headers, but some python distro don't provide it.

Then of course, on windows, is your python registered with the py launcher? How does it interact with existing anaconda installations ? On linux on existing system installation ? Is the shim (or path update for mise) affecting /bin/env ? How that works with .pyw association ?

The. what does it implies on the venv creation and activation ? And on using -m ? And .pth files ? user-sites ?

All those questions are linked to bootstrapping.

What happens then is pip install fail or import break, but the user have no idea it's related to his bad python setup because most people don't know how it works.

And now bootstrapping has broken packaging.

This is where most "python packaging sucks" things are born: from unkowingly botching the bootstrapping.

And the vast majority of tools to do it suck. E.g: Shims are all kind of broken (pyenv and rye come to mind).

To suceed, mise would have to know all that, pick the right tool, make a perfect abstraction, create fantastic error reporting, and test all those cases on ci on all platforms.

It's possible, but I know only one project that does this almost correctly. And even this one has a long way to go.

Saying "there is literally nothing to leak" is actually perfectly making my point most people don't know the topic deeply enough to know what they get into.

Then of courses there are all the modes of failure. This article has a good bit about that:

https://www.bitecode.dev/p/why-not-tell-people-to-simply-use

It's cover more than mise's scope, but the idea is there.

My experience with such tools is that when you do everything, you don't do anything right.

The chances that it doesn't leak greatly the underlying abstraction and creates troubles to figure it out when it will invariably fail is zero.

Because most people barely know in depth the packaging challenges for one ecosystem. In Python there are maybe a dozen in the world that have a good hang of __all__ of it.

And the devs of this tool would need to know so many.

Of course they don't, they wrap existing tools, which implies exactly what I said above.

ChatGPT can't read stereograms yet, so this would be a nice captchas, if only most humans could read them too.

just is not meant as a built tool, just a task runner. Those have vastly different goals.

make is a build system: it has targets, it has file deps, a dag resolver, etc.

But a task runner is basically a fancy aliaser with task deps and arg parsing/proxing.

And just is good at being that. Although I agree I not a fan of adding yet another DSL.

Well, it's also trained on scifi corpus where the ai acts that way. So it'ls logical it's in the weights.

Because it works. Even on you.

No, ads mean bad incentives, you have to please advertisers, not just your audience. It also encourages to ignore externalities.

Then it gives more power to those who already have the most of it.

It also normalizes lying, being intrusive, and manufacturing damaging social norms.

Tracking is worse, but all ads are toxic.

Talk is cheap, they coded it.

The entire AI ecosystem, the scientific stack, the GIS crowd and 3D modeling community disagree with you.

And they went for python, not js, because of this.

If you haven't coded serious projects in at least 5 very different languages, you likely adore one language because you just don't know better.

There is such a variation between js, perl, python, rust, C#, lisp, bash, haskell, erlang and sql that the blind spot is huge.

It's like eating hot dogs all your life and debating food merits with people that tasted japanese, indian and french food.

Maybe zig will become what rust is for python.

But JS needs a better compiled extension story for that to happen. The absence of a standard like wheels makes everything difficult.

I get your point, but once in a while, you get a gem like uv for python.

The fact uv is not in python means it's immune to the many bootstrapping problems the language suffers, which in itself is a huge win.

Granted, it works only because it's well engineered. The python integration is fluid, it respects standards, you never actually feels you are dealing with a separate tech.

This is rare.

Usually the experience is more something like asdf which gets 70% there then left you hanging.

However, when that works, it brings many benefits. An unconspiscious one for uv is that we now have a packaging tool compatible with pip that you can call from any other language with no need for a python runtime, and no risk of breaking if other runtimes exist and move.

That's why they are not unspecified to be optional.

Would buy. But you probably should teach a few live courses before writing it because of expert blindness. Otherwise you will miss thr mark.

Would pay for a decent remote live course intro.

Yes, is performance Pareto, or perception of performance Pareto?

In Python, contract based programming can be only be done properly with asserts:

- You can't use the type system for some constraints.

- Asserts can be stripped in production so you don't pay the price for them.

- There is not other syntax for that.

Unfortunatly, because most devs don't know about "-O" and use asserts for things you should use an Exception for, you can't use it: https://www.bitecode.dev/p/the-best-python-feature-you-canno...

> What would you say to a superior who made a decision that you disagree with, but don't think is worth reversing?

"I don't understand ... it seems it has the consequence of ... My professional opinion in that case would be... and I would advise to... because of... Is there something I'm not seeing here?"

Benefits:

- I'm not faking it.

- I already provide a lot of information up front to limit back-and-forth. This avoids assumptions and also works better for when you WFH.

- The person knows exactly where I stand and where I want to go. It's not chit-chat, it's not politics, it's purely technical and I want to move on the issue.

- If I'm wrong, I can get told right away. If I'm right, it's factual, and we can move on to solving the problem. And if the person's ego/social status is on the line, they can just BS their way out of it, and I'll just add nothing and move on.

- The template drives the conversation enough that they only need a short answer to let us decide if it's worth reversing. And we can conclude on the price / consequence of that and move on if needed.

I'll change that depending on the person. Some people are way better than me, in that case, I'll default to asking what I'm missing because it's likely they see something I don't.

On the opposite, if it's a junior, I'll assume they get it wrong and help them to fix it (unless they can justify it).

And of course, phrasing will depend of how much intimate I am with the person. Good friends will get a playful version, uptight clients will get the more formal one.

Once you have done that several times and people know the routine and the relationship is good, you barely have to speak. You can just nod at something or raise an eyebrow, and start problem solving or get the info.

But note that I can do that also because my clients value my opinion enough, have respect for my professionalism, and also know, because of my past interactions with them, that I focus on the problem to solve rather than blaming.

Depends on the profile, when somebody talks to me like that I immediately cringe in my head and lose all respect for the person.

Probably a matter of culture too.

It's a quantum zoom: it's zoomed in and not zoomed in at the same time.

If you like this kind of things the French state geographic portal (https://www.geoportail.gouv.fr) lets you load crazy tiles like the Cassiny maps (from 1682) and the military staff map from 1820.

It's a blast, but in French only so you'll have to fiddle around a little.

And since it's AI improved, all of th will hurt people because of hallucinations.

I don't trust human to avoid taking shorcuts once the tech is available, it's too convenient to have "information" for so cheap, and less costly to silence the occasional scandal.

I said the same thing, and I'm going to do one more prediction: the banking business will become more and more profitable with very low risk to the point it will take more and more space in Apple's culture.

Also, regulations and the hiring market mean they will have to hire more and more profiles than you typically find in finance. With Jobs dead and an aging Cook that can't willpower himself into everything anymore, nothing will cancel this effect.

Eventually, this will lower Apple taste for innovation and the product quality will go down until they become another average player cashing in on the inertia of its past success.

They will be super profitable, but nobody will look up to them anymore.