joshkel

The article faults LLMs for not being more creative (riding in the city in the rain, in East Asia, in outer space, etc.). But, if prompted, "Generate an SVG of a pelican riding a bicycle," with no additional details or specification, then I would _expect_ something generic: a side view, nondescript terrain or perhaps terrain associated with a pelican (i.e., beach), little clothing (because birds don't wear clothes) with the possible exception of something strongly associated with bicyclists (a helmet).

The article talks about "the LLM diversity collapse problem," which makes it sound like LLMs are getting less diverse over time, but the linked benchmarks suggest that newer, more capable models are _more_ creative.

Out of curiosity, I tried a couple of prompt variations in Opus 5.5. "Be creative" did a beach scene but added fish to the bike basket and a lighthouse in the background - not too creative. "Pick a unique and creative variation of this concept" resulted in a "midnight circus act" of a pelican riding a penny-farthing on a tightrope while balancing a fishing pole with fish (and, this time, two lighthouses - the tightrope is implausibly strung between them).

I really didn't mean to encourage emotional manipulation, soulless optimization, listicles, etc., although I agree that a lot of writing online falls in that bucket, and it's even likely that the advice I uncritically quoted was aimed at that bucket.

I obviously should have thought more carefully and written more clearly.

But I don't think that "Write each sentence to give the reader a reason to keep reading" and "Actually provide value to the reader" have to be mutually exclusive. Instead, I think of it as (like you said) communicating the value effectively: dispense with the throat-clearing, meandering intros, irrelevant personal details, weak thesis statements, etc., and write tight, well-crafted prose that respects the time and honestly maintains the interest of those who'd benefit from the value you can provide. (I certainly don't claim to be an expert here! Appreciate the video link.)

A year or two ago, I finally gave up:

1. The IDE was simply too slow - notably slower and "heavier" than VS Code in particular - and it seemed to regularly get slower.

2. Bugs - from the complex (TypeScript constructs that tsc itself handles just fine while WebStorm's code analysis kept throwing false positives on) to the trivial and silly (failing to properly handle the <col> tag in React), and often staying open for years.

Meanwhile, VS Code just kept getting better, addressing the complaints I had with it while staying fast.

I work almost exclusively in TypeScript these days; as other commenters pointed out, I'm sure that JetBrains products are still great for other languages.

And their refactoring tools remain second to none. I'm profoundly disappointed in our industry that the VS Code developers apparently looked at JetBrains, with its arsenal of expertly crafted, deterministic, testable refactorings, and said, "Nope, we'd rather make everyone use inherently random language models for anything more complex than Rename Symbol."

Personally, I'd be happy with a larger suite of utility functions (say, most of Lodash / es-toolkit - remove the need for left-pad silliness), probably SQLite bindings (having a good persistence layer is great, it's perhaps the most robust and most widely deployed software on the planet), but not YAML (complex, security concerns, parser differences) or image handling (again, security concerns).

Node.js is, IMO, actually pretty good these days; they're regularly adding useful built-in tools that remove the need for add-on packages. (The ecosystem is so big that getting those updates to filter out is hard.)

Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provide an arbitrary-code `build-backend`, etc., and pip would still function as designed.

I appreciate the clarifications/corrections on PHP.

> Which most people don't install directly, but have already had built for them by their distro.

Yes, but the original claim was that npm is "particularly susceptible to these attacks" because "npm can execute code after install and most package managers don't do that." I don't think that's accurate: we've seen hundreds of NPM packages compromised in multiple high-profile attacks over the last several months, while .tar.gz was used for decades with nowhere near the same number of compromises.

Rather, I suspect it's a combination of factors: Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. And the extreme popularity of JS, the centralization of NPM + GitHub, and increased usage of automation makes attacks more practical and more lucrative.

Taking a step back from that particular debate, I'm very much in favor of changes like what you describe.

Taking still another step back, I'm not sure that even those will be enough. If I download a package, it's because I intend to run its code at some point: if it's malicious, I may be less automatically hosed than if its postinstall script runs, but I'm still hosed at execution time. I trust my distro packages, not because they don't execute arbitrary code on installation (RPMs and .debs both do), but because I _trust my distro_. NPM et al. simply cannot vouch for every package they host.

Thanks for the reply!

Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control.

Native Ruby Gems execute arbitrary code via extconf.rb.

Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time).

PHP Composer packages can ship install scripts or configure themselves as Composer plugins.

The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation.

There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).

I want software that works.

Yet the economics of the software industry, and perhaps the economy as a whole, seem to inexorably push toward the former.

> TypeScript 6.0 arrives as a significant transition release, designed to prepare developers for TypeScript 7.0, the upcoming native port of the TypeScript compiler. While TypeScript 6.0 maintains full compatibility with your existing TypeScript knowledge and continues to be API compatible with TypeScript 5.9, this release introduces a number of breaking changes and deprecations that reflect the evolving JavaScript ecosystem and set the stage for TypeScript 7.0.

Most date/time libraries that I've seen have a only single "date/time" or "timestamp" type, then they have to do things like representing "January 13 2026" as "January 13 2026 at midnight local time" or "January 13 2026 at midnight UTC."

Temporal has full-fledged data types representing the different concepts: an Instant is a point in time. A PlainDate is just a date. A PlainTime is just a time. ("We eat lunch at 11am each day.") A ZonedDateTime is an Instant in a known time zone. Etc.

Temporal draws a lot of inspiration from Java's Joda-Time (which also went on to inspire .NET's Noda Time, Java's official java.time API, and JavaScript's js-joda). This is helpful; it means that some concepts can transfer if you're working in other languages. And, more importantly, it means that it benefits from a lot of careful thought on how to ergonomically and effectively represent date/time complexities.