goranmoomin

IMO: Transpilers are compilers, but not all compilers are transpilers.

In my book, transpilers are compilers that consume a programming language and target human-readable code, to be consumed by another compiler or interpreter (either by itself, or to be integrated in other projects).

i.e. the TypeScript compiler is a transpiler from TS to JS, the Nim compiler is a transpiler from Nim to C, and so on.

I guess if you really want to be pedantic, one can argue (with the above definition) that `clang -S` might be seen as a transpiler from C to ASM, but at that point, do words mean anything to you?

AFAIK Safari was the first browser to support MathML fully, and FF also supports it. Chromium was the latest IIRC. MathML has been baseline-available since 2023 after Chromium got support.

The big issue is that MathML is designed as a target language, not something directly writable. So we still need a KaTeX equivalent, which compiles either LaTeX equations or other markup languages to MathML.

Regardless, the core issue that you have mentioned is now gone (or will be in a few years even if you want more availability).

I get the gist of what the author tries to say, but the blog is definitely written by an LLM and the blog post is taking the idea too far. Please, people do not ask ChatGPT to refine your thoughts and call it a day. It misrepresents your ideas.

From the case that the article is presenting, I think LLMs are acting as a validation step – the average person who doesn't know how to code creates a minimal, LLM-spaghetti system (e.g. a restaurant menu website) with ChatGPT, validate if this is something that they need, iterate on it, create a specification, and then bring in an actual (costly) engineer that can fix and improve the system.

There's a lot of LLM byproducts that leave us in bad taste (hate all of the LLM slop on the internet), but I don't think this is one of them.

> So are you saying the author updated the implementation and added deprecation warning?

As far as I understand, the author wrote the clamp function by themselves. There is no clamp library that the author is arguing against.

In fact, it seems the library ‘clamp’ in npm is a library that does exactly what the author wants – no validation, assuming that the value is a number, and just returning a number.[0]

[0]: https://github.com/hughsk/clamp/blob/master/index.js

The post is complaining about a library for a problem that javascript had 12 years ago, was not a thing for 7 years, and the ecosystem moved on. Typescript was not a thing back then. (or more exactly, it was a small thing out of the all too many transpile-to-js languages, at least)

Yes, having a library named is-number looks very stupid until you look at the state of javascript in 2014. Look at issue is-number#1[0] if you’re interested.

The library is-arrayish exists because array-like objects are actually a thing in javascript.

About is-regexp: the author mentions that their library supports cross-realm values because it’s useful, but then says that it’s an edge case that most libraries don’t need to care about? The whole reason that the library exists is to cover the edge cases. If not needed, yes the consumers of the library would have just been using the simple instanceof RegExp check.

If you’re arguing that there are consumers of those libraries that are wrong, the post might at least make sense – the presented case here is that the writer of the clamp function is stupid, not the other way around. Having a function that determines if a string is a number is not stupid; it’s importing that function and creating a clamp function with the wrong type signature part that’s stupid. Especially when it’s 2025 and typescript is universal.

All of the libraries that are mentioned are like 10 years old at this point. I don’t think we have to beat the dead horse one more time.

[0]: https://github.com/jonschlinkert/is-number/issues/1

Disclaimer: I’m a South Korean, so I’m gonna be hugely biased.

But with the disclaimer, the whole raid is stupid – I thought the US govt was trying to bring jobs to the states, encourage foreign investments, and move manufacturing over there? And then the very next thing they do is detaining and deporting people who are there to literally do that?

Even if you’re gonna complain about not having the correct visas, at least treat the people who are helping your country in good faith, not like people who got caught while trying to smuggle in across the border.

About the visa situation – quoting a comment from the past article since it explains it more clearly than what I could possible do:

> For people saying "they should have had the right visa", no one does this.

> Any day of the week all of the big tech companies will have dozens of overseas engineers in the US attending meetings, and gasp working on-site (writing code, etc). They all have either tourist visas or visa waivers.

> And it's the same thing when the US engineers visit the remote sites in other countries.

> Regardless of what the letter of the law is, this has long been the practice, because it's the only workable solution and is clearly within the spirit of the law.

> In this case LG was fitting out a new batter factory. That is a very complex setup with highly specialized machines. The ONLY way that was ever going to happen was with LG specialists coming over to do the setup and get the line working. And it's almost certain that getting "correct" visas for all these people would have been practically impossible, and has not been the actual practice for many decades.

[0]: https://news.ycombinator.com/item?id=45159119

No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth.

CLI tools, including ones that Apple ships or makes, are not apps on macOS.

I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.

I have my own story over here[0], and I’m pretty sure that there’s going to be a lot of instances similar to what I’ve experienced — blocked from merging or just fizzling out due to the lack of push on features that work on non-free OSes. There’s a reason why there are so many forks and patches for Emacs on macOS that are maintained for years that are not getting upstreamed.

[0]: https://news.ycombinator.com/item?id=44739359

As someone who have tried upstreaming a patch for Emacs on macOS (to add a feature that already existed on Linux), I can bitterly say that at least some of the maintainers do have a disdain for non-free OSes and that it makes it contributing patches for macOS as miserable as possible.

The patch was adding xwidget webkit support for macOS Cocoa[0], which I iterated for the next few months[1], only to side-rail into a discussion on macOS/GCC and GNUStep support policy[2], and I fizzled out.

That was abt 5 years ago, and I’ve never touched on the Emacs codebase since.

[0]: https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00...

[1]: https://lists.gnu.org/archive/html/emacs-devel/2019-07/threa...

[2]: https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00...

Just for people who are reading this and leading to believe that this might be true, the link that this user is providing[0] is produced by a group called KCPAC[1], a blatantly Korean alt-right group.

Rebutting fake news takes so much more time than spreading them.

[0]: https://www.youtube.com/live/p508Q66_zCU

[1]: https://www.cpackorea.com/

This is a blatantly false comment. For the sake of other viewers on HN that is not familiar with Korean politics, this is totally fake (and is probably pushing the views of the Korean alt-right).

United States sharply criticized Yoon after his unconstitutional martial law declaration, publishing pretty strong remarks that it was illegimate[0]. They have consistently spoke (in diplomatic language) that they do not support Yoon until he was impeached.

Impeaching Yoon was supported by 75% of the country [1] and anti-Yoon protests were not seen as anti-US nor pro-China at all.

The newly elected president, Lee Jae Myung, is not seen as anti-US nor pro-China in Korea (he does have a less anti-China stance than his predecessor), and any claims of election fraud claim is baseless[2] and without evidence.

The few paragraphs on telegram groups are groups that are run by the alt-right that send reports of anti-Yoon social influencers to the CIA, arguing that they were anti-US and communists[3] (yes, the red fear and the cold war is still a thing in South Korea, thanks to the North Korean regime, no, we do not recognize North Korea as a sovereign state)

Yes people are affected due to the new visa process, PhD students big among the affected, but no, big businesses are not being blocked sending their workers to the US. Samsung is not struggling getting visas.

This is a totally baseless fake news. Please don’t let this information spread. Thanks.

[0]: https://www.reuters.com/world/us-says-south-koreas-yoon-badl...

[1]: https://en.wikipedia.org/wiki/Impeachment_of_Yoon_Suk_Yeol#O...

[2]: https://factcheck.afp.com/doc.afp.com.36RG6PF

[3]: https://koreaherald.com/article/10019148

———— Not trying to shoot the messenger, but the user has a history of getting flagged with far-right racial comments: https://news.ycombinator.com/item?id=44405917, https://news.ycombinator.com/item?id=44203934, https://news.ycombinator.com/item?id=44203849

They also got flagged previously by arguing the sentiment of the Korean alt-right: https://news.ycombinator.com/item?id=43431867

And also say that they submit AI-generated comments as well: https://news.ycombinator.com/user?id=pkkkzip

I would not trust this person’s comments.

Seems like some people here are taking this post literally, as in the author (Dan Abramov) is proposing a format called Progressive JSON — it is not.

This is more of a post on explaining the idea of React Server Components where they represent component trees as javascript objects, and then stream them on the wire with a format similar to the blog post (with similar features, though AFAIK it’s bundler/framework specific).

This allows React to have holes (that represent loading states) on the tree to display fallback states on first load, and then only display the loaded component tree afterwards when the server actually can provide the data (which means you can display the fallback spinner and the skeleton much faster, with more fine grained loading).

(This comment is probably wrong in various ways if you get pedantic, but I think I got the main idea right.)

If I'm understanding correctly, isn't this introducing a critical dependency on JavaScript during rendering? I get that people might want to draw stuff with code, but why would people use this (and introduce render performance problems inadvertently) instead of using the HTML5 Canvas API?

> Extended thinking with tool use (beta): Both models can use tools—like web search—during extended thinking, allowing Claude to alternate between reasoning and tool use to improve responses.

I'm happy that tool use during extended thinking is now a thing in Claude as well, from my experience with CoT models that was the one trick(tm) that massively improves on issues like hallucination/outdated libraries/useless thinking before tool use, e.g.

o3 with search actually returned solid results, browsing the web as like how i'd do it, and i was thoroughly impressed – will see how Claude goes.

Not related to the project in any way, but I would say that if the hardware is running on CPython bytecode, I’d say that’s as far as it can get for executing Python directly – AFAIK running python code with the `python3` executable also compiles Python code into bytecode `*.pyc` files before it runs it. I don’t think anyone claims that CPython is not running Python code directly…

i don’t actively contribute to Bluesky nor Fedi (i do consume content from both), but it’s pretty frustrating to see BlueSky being argued into a centralized service for the recent downtime.

- The downtime was not relay level, but it was a PDS level. So the point is moot already.

- Because it was decentralized at the PDS level, the outage did not affect anyone with personal PDSes, which contains the data that you care about.

- Even if it was the relay level, relays aren’t centralized, anyone can spin up another relay (because everything on the relay is derived from PDS data). It’s just that it’s going to be pretty expensive and consume much resources. Which is a fair point, and might be argued that the network currently has a single big point of failure, but that doesn’t mean it’s centralized.

And then people now start arguing that the fact that BlueSky-hosted PDSes went down at the same time is now another proof that BlueSky is centralized?

That’s like arguing that Gmail can go down and all @gmail.com mail addresses won’t work, so email is centralized. Or AWS can have an outage and all AWS-powered websites will break down, so the web is centralized.

One can say that there’s a single big point of failure (which the BlueSky LLC is, just like AWS, Gmail, or the mastodon.social instance in the case of Fedi), but that doesn’t make the whole service centralized.

This is a bit tangent, but does anyone know how to block an app from ever deciding to become a file handler on macOS?

Every time I install Chrome on my machine (for testing purposes), macOS decides that Chrome is going to be the default file handler for a bunch of file associations, including HTML, WebP, and so on… and I have to figure out which was which for all of the mappings (which is super frustrating).

I can read Info.plist from the bundle of the specific app (in this case, Google Chrome) that declares all of the UTIs, and then figure out which file associations that Chrome has messed up, but I don’t know how to get the default file associations (if it was not Chrome) before it.

Yeah it’s pretty unfortunate that such capabilities are locked to special entitlements.

From my understanding, you really need only one image – the article is just providing four for your tastes (Fedora/Ubuntu, aarch64/x86_64). The images are linux installers, which “understand” cloud-init (because it’s “industry standard”), so if you place the {user,meta}-data file in the right place (a volume named CIDATA, it seems[0]), they can configure your installation without really having to go through the tedious process of configuring through the installation process, install packages, and so on.

I don’t understand why anyone would go to the route of emulation in 2025, but if someone wants to run an x86_64 image with UTM, well that’s the only route – I’d suggest just going to an aarch64 image. Things were a bit more rough back in 2020, but stuff got much better and I don’t remember any compatibility problems these days.

[0] https://cloudinit.readthedocs.io/en/latest/reference/datasou...

From the title, I hoped so much that this was about using UTM on Apple Silicon iPads – don’t really want the person who always complains about Apple, but it’s really a pity that the iPad has such a strong CPU inside (I own an M4 iPad Pro) and can’t do any realistic development on it.

Last time I checked, there really isn’t any way to virtualize ARM machines on the iPad with UTM (unless you’re on a lower iOS version), and emulating x86_64 machines were slow enough (even on M4 iPads) and not really usable.

I’m on an environment where iPads are fine but equivalent MacBooks aren’t (stupid rules), and got this machine for hope that I might tinker development with iPads, but I gave up running stuff locally and just boot up an EC2 instance whenever I really want to do something. It’s a pity.

(BTW, from the article, why would anyone really emulate a Linux machine with UTM on Apple Silicon? From my experience ARM64 Linux images are really good at compatibility…)

It feels so wrong that there are so many blogs and websites that are based on GH Pages and they all died at once…

Seems like they’re back up though. Or at least the Rust blog is back up.

Seems like sites based on GH Pages were down, but are back up (i.e. the Rust blog).

While I’ve never actually used `with()` that much, I do feel that it’s a lost opportunity b.c. `with()` was basically the only way to get dynamically scoped variables (instead of lexically scoped ones) in JS (and tbh, in other ALGOL-derived languages as well).

Dynamically scoped variables are a much better solution to global variables… so for example, in Common Lisp you can have a STANDARD-OUTPUT variable that you can use to log things in your code, and then if you want to temporarily redirect your logs to a file, you can just do:

    (let ((*STANDARD-OUTPUT* file))
      (your-code-runs-here))

And the code in the block will automatically redirect your output to the file.

I'm still on the fence on whether I think this is a good idea or not…

It does feel like frabricating/buying github activity with money… but it also does feel like I can't argue that they are doing something with malicious intent…

> That moment shouldn't be awkward if you have a legitimate reason for taking that photo.

Think of for example quiet libraries with a bunch of students quietly studying. They do not like other people making noise, however legitimate the reason is.

> you can record a video...

Video recording also has a mandated start/stop sound, FWIW.

As a Korean, I can say definitely so.

A common example that I can give is when you want to take a photo of a document for future reference (or maybe even PDF submission) in a quiet office or room. I can definitely say that the mandatory shutter sounds create a lot of awkward moments.

So for people (like me) who were surprised by how modern the Java code looked like… here are the following features/JEPs involved in the Java code:

Finalized features:

- JEP 395: Records, finalized in Java 16: https://openjdk.org/jeps/395

- JEP 409: Sealed Classes, finalized in Java 17: https://openjdk.org/jeps/409

- JEP 441: Pattern Matching for switch, finalized in Java 21: https://openjdk.org/jeps/441

Preview Language Features:

- JEP 430: String Templates, preview language feature since Java 21: https://openjdk.org/jeps/430

- JEP 445: Unnamed Classes and Instance Main Methods, preview language feature since Java 21: https://openjdk.org/jeps/445

I get that this is a satire post on the usual criticisms of Mastodon, but honestly the points on Email is valid, and the reasons are a big point on why non-business Email usage is declining…

Especially the points 'there's no real way to migrate between email servers either, so whatever I choose is going to be my permanent home' and 'I can't run my own server' parts are very valid criticisms of the Email system…

I was ready to be excited from the title, but was utterly disappointed :(

IMO these aren’t macros in the Lisp-sense of the word (or Rust, or even C); yeah they run code at compile time, but that’s where the common ends.

Macros should be able to apply syntactic transformation on the code. Lisp is famous for allowing that by representing code as lists. Rust has a compiler-level API to give tokens and run arbitrary code, then spit new tokens out. C macros operate on the tokens level, so with enough magic you can transform code to the shape you want.

This… isn’t any of that.

A pretty good example (and something I’m still sad that it didn’t take off) of macros in JS is Sweet.js[0]. Babel macros[1] are a bit higher level, where macros require the input to already be a valid AST, but that’s also something I’d call macros.

This… I’d say it’s more of a compile time code execution feature, not a macro feature.

[0]: https://www.sweetjs.org/ [1]: https://babeljs.io/blog/2017/09/11/zero-config-with-babel-ma...