franciscop

I agree, that would've been a much more interesting statement.

In an inflationary economy like the one we have, "the market is at all time high" is not really a useful statement since it's the normal state of affairs.

I was going to comment on the manufacturer's safety margins, but then I found a graph [1] on the variability of voltage vs temperature and it seems to be a lot steeper than I thought/expected, to the point that I'm wondering how these do not require either training or a voltage regulator to install and operate properly:

https://www.researchgate.net/figure/Module-voltage-current-v...

I've had it happened, sure it was with Linux but it was scary taking out a fire brick from my bag and praying it was still working. I had been using Linux for 10+ years until the M1 came out, and for as much as I love Linux unfortunately I haven't looked back, the hardware is just that good.

When it's time to replace my M1 air, if the laptop is still working (I tend to replace when they break), I'll try to install Asahi Linux to see how it is. It feels a bit too experimental/me being too inexperienced with OS to risk it on my main computer.

I've tried to optimize to avoid these before. The problem is that these libraries are normally not used directly, they are usually pretty low in the dependency tree (root?). The farther you go down in the dependency tree, the older the packages are, where rightfully there's some reluctance to update things for the sake of updating things, risking breaking a stable library. It's a tricky thing and not so easy as to just say "don't use npm's `is-array`, use `Array.isArray()` instead", since every JS/TS package author writing code in 2025 knows that already.

It'd be a lot more productive to ask the authors of the (normally bigger, user-facing) libraries that you use nowadays to avoid using these libraries with deep and outdated dependencies. e.g. I stopped using Storybook because of this, but I'm happy to see that they've been working on cleaning up their dependency tree and nowadays it's much better:

https://storybook.js.org/blog/storybook-bloat-fixed/

> Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn.

This is as big as a strawman as I can imagine. Both of these "solutions that won't happen" are already happening:

- The ECMAScript standard already defines a `Strong.padStart()` as part of the "real" standard library of Javascript [1]

- There is a very well known larger package that combines many micro-utilities like this into one, lodash [2]

> No one will learn their lesson. This has been happening for decades and no one has learned anything from it yet. This is the defining hubris of this generation of software development.

Really seems like the author wants to hate on the ecosystem for the sake of hating on it.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://lodash.com/

When I came to Japan in 2015 and was dating here, I was taken to purikuras in multiple occasions and let me tell you it's totally different experience from the Western photo booths. Both the machines, abilities and creativity of pros managing them made me very surprised in many ways.

As johnecheck points out, in a certain level of abstraction, the main way of defining a country is whether other countries consider you a country or not. Even when other countries do consider you a country, what the borders are exactly might not be clearly recognized.

Since countries are political divisions, I'd also argue that this is the main and most important definition.

BTW, even "continents" suffer from this where in the US, Europe and Asia they are defined differently.

What is a country for you? How do you define it? Is the land size that important?

This is probably why I love using Zed for my hobby dev, it doesn't try to be too clever about AI. It's still there and when I do want some AI stuff it can be seamlessly prompted, but for normal day-to-day the AI steps back and I can just code. In contrast, using AI at work with VSCode I feel like the tools get too much in the way, particularly in 2 categories:

- Fragile interaction. There's popups on VSCode everywhere, and they are clickable. Too often I try to hover on a particular place and end up clicking on one of those. The AI autocomplete also feels way too intrusive, press the wrong key combination and BAM I get a huge amount of code I didn't intend to get.

- Train of thought disruption. Since some times the AI long auto-complete is useful (~1/3th of times), I do end up reading it and getting distracted from my original "building up" thinking and now change to "explore thinking", which kind of dismantles the abstraction castle.

I haven't seen either of those issues on Zed. It really brought me back the joy of programming on my free time. I also think both of these issues are about the implementation more than the actual feature.

This seems totally fine though? XSLT 1.0 supporter says the support time is costing heavily, then Chrome says removing support is fine, which seems to align to both of them.

It'd be much better that Google did support the maintainer, but given the apparent lack of use of XSLT 1.0 and the maintainer already having burned out, stopping supporting XSLT seems like the current best outcome:

> "I just stepped down as libxslt maintainer and it's unlikely that this project will ever be maintained again"

Some surprising science fact that many people don't know, an animal egg (chicken, birds, etc) is a single cell, so there's a huge variability in the weight of a cell.

IMHO not really, supply here is the limiting factor since the constrain is in licensing the work. The goal of the right holders is not to maximize access to the work or those stated by OP, but to maximize profit for the company, which when at odds with those other goals still prevails.

e.g. someone calculated/believes that having a big catalog from Disney at X/month is more worth more for Disney than sublicensing to Netflix at Y/month.

I found details of the Impatiens Parviflora and its exploding properties on the Spanish Wikipedia. But digging deeper, it seems the general term for exploding seeds is "Ballocoria" (Latin), only found in a sub-section:

https://es.wikipedia.org/wiki/Dispersi%C3%B3n_de_los_prop%C3...

https://grok.com/share/bGVnYWN5LWNvcHk%3D_e1c522fa-64ae-4864...

For simple projects you needed now to add rollup or other build system that didn't have or need it before. For complex systems (with non-trivial exports), now you have a mess since it wouldn't work straight away.

Now with ESM if you write plain JS it works again. If you use Bun, it also works with TS straight away.

I'm a small-ish time author, but it was really painful for a while since we were all dual-publishing in CJS and ESM, which was a mess. At some point some prominent authors decided to go full-ESM, and basically many of us followed suit.

The fetch() change has been big only for the libraries that did need HTTP requests, otherwise it hasn't been such a huge change. Even in those it's been mostly removing some dependencies, which in a couple of cases resulted in me reducing the library size by 90%, but this is still Node.js where that isn't such a huge deal as it'd have been on the frontend.

Now there's an unresolved one, which is the Node.js streams vs WebStreams, and that is currently a HUGE mess. It's a complex topic on its own, but it's made a lot more complex by having two different streaming standards that are hard to match.

As a library author it's the opposite, while fetch() is amazing, ESM has been a painful but definitely worth upgrade. It has all the things the author describes.

Thanks! From your article, you might not want/like my library since it's based on a single easing function. I used a cubic function to find out the interpolation values, and the derivative to make sure it's always smooth. The equation looks like this, it's on the source code:

https://www.wolframalpha.com/input/?i=x+%3D+2+*+t+%5E+3+-+3+...

If you wanted some more details please feel free to ping me (email through my website's resume, or Twitter) and I'll dig the handwritten equations.

I also didn't like when a new easing happened _while_ another easing was happening, which often felt very jerky. Had to do a bunch of calculus (derivatives) by hand and wrote a small library for it in JS:

https://github.com/franciscop/ola

Note: ola means (sea) wave in Spanish

I expect CVEs to be directly proportional to project usage and popularity, and inversely proportional to maturity, which makes things a lot more complicated.

That totally flew over my head, sorry! Violence in the train didn't even occur to me while reading the comment, I thought they meant something on the lines of "the driver will have better visibility when opening/closing the doors on the front train so it's safer to go there so they cannot accidentally close them on me" or something similar. Now of course they meant there's less chance of violent behavior near the train driver, and the comment makes a lot more sense for me now.

Note: I do take the train daily, just I live in Tokyo

How do other cities around the world make this work and make it safe then?

I know, I'm totally fine with that, but then don't bring money into the article like those people are burdened economically by these tourists, you cannot have it both ways.

I've been 10 years on-and-off, and 10% sound way too low _if we include_ Suica/Pasmo. Credit card is another story and I'd agree.

I find Japan a bit strange about these "making profit" topics. I still don't fully grasp how it's possible so many of these business that "poured much of their life savings into opening these places, taken out loans" don't rejoice and raise their prices (a bit? a lot?), making them able to do this thing they are doing, much better. Heck invite the regulars to the 2nd drink with that extra money that is coming in now if you want, or give them a discount.

Here there is the opportunity of a lifetime, and many Japan business are straight out rejecting the money that comes pouring in. Meanwhile Japan economy is the worst it's been in 40-50 years, and virtually every week there's articles about the bleak future. It's too frustrating seeing articles complaining about how business are closing down with no money, and at the same time how these people trying to give them money are being rejected.

Background: living in Japan 5-10 years, I'm from Spain so it's not "in my blood" to think about profit also, but heck it's just too surprising some times.

PS, I'm for reducing tourism overall here actually, I'm just baffled at Japanese rejecting money.

It's a very well controlled study about... what the study claims to do. Yes, they didn't study a different thing, for _many_ reasons. Yes, we shouldn't haphazardly extrapolate to other parts of Engineering. But it looks like it's a good study nonetheless.

There are some very good findings though, like how the devs thought they were sped up but they were actually slowed down.

Yes, I've seen this multiple times personally, it's often better to copy/paste and give detailed prompts in the standalone apps for higher quality than in the coding agents in your codebase.

Because at the beginning I didn't trust it and verified it in many different ways. I've got a fairly decent understanding of what LLMs hallucinate regarding language learning and levels, and luckily/unluckily I'm far enough for this to be a concern. e.g. I asked recently differences between 回答 vs 解答 and it was pretty good.

I also checked with some Japanese and my own notes contain more errors than the LLMs output by a large margin.

I am learning Japanese (again) now and it's such a stark improvement vs when I first tried. When I don't understand something, LLMs explain it perfectly well, and with a bit of prompting they give me the right practice bits I need for my level.

For a specific example, when 2 grammar points seem to mean the same thing, teachers here in Japan would either not explain the difference, or make a confusing explanation in Japanese.

It's still private-ish/only for myself, but I generated all of this with LLMs and using it to learn (I'm around N4~N3) :

- Grammar: https://practice.cards/grammar

- Stories, with audio (takes a bit to load): https://practice.cards/stories

It's true though that you still need the motivation, but there are 2 sides of AI here and just wanted to give the other side.

I live in Japan and am not yet fluent enough, so need to use a VPN to get the Google Search English results, otherwise it's totally unusable. Heck even for programming I pull my hair since I get the translated docs when searching. Just give me the (original) English ones please. I did search in English have Google set to English, but still get the Japanese ones even for those that have English resources.