Vaguely2178 (u/Vaguely2178)

Vaguely2178 commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser

zoogeny · 9 months ago

An interesting question you might want to ask yourself, related to this idea: what would you do if your compiler wasn't deterministic?

Would you go back to writing assembly? Would you diligently work to make the compiler "more" deterministic. Would you engineer your systems around potential failures?

How do industries like the medical or aviation deal with imperfect humans? Are there lessons we can learn from those domains that may apply to writing code with non-deterministic LLMs?

I also just want to point out an irony here. I'm arguing in favor of languages like Go, Rust and Zig over the more traditional dynamic scripting languages like Python, PHP, Ruby and JavaScript. I almost can't believe I'm fighting the "unmaintainable" angle here. Do people really think a web server written in Go or Rust is unmaintainable? I'm defending my position as if they are, but come on. This is all a bit ridiculous.

Vaguely2178 · 9 months ago

> How do industries like the medical or aviation deal with imperfect humans?

We have a system in science for verifying shoddy human output, it's called peer review. And it's easier for your peers to review your code when it's maintainable. We're back in the loop.

Vaguely2178 commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser

zoogeny · 9 months ago

There are more elements to a compiler than determinism. That is, determinism isn't their sole defining property. I can compare other properties of compilers to LLMs. No "flip flop" there IMO, but your judgment may vary.

Perhaps it is impossible for you to imagine that LLMs can share some properties with compilers and other properties with humans? And that this specific blend of properties makes them unique? And that uniqueness means we have to take a nuanced approach to understanding their impact on designing and building systems?

So lets lay it out. LLMs are like compilers in that they take high level instructions (in the form of English) and translate it into programming languages. Maybe "transpiler" would be a word you prefer? LLMs are like humans in that this translation of high level instructions to programming languages is non-deterministic and so it requires system level controls to handle this imprecision.

I do not detect any conflict in these two ideas but perhaps you see things differently.

Vaguely2178 · 9 months ago

> There are more elements to a compiler than determinism.

Yes, but determinism is the factor that allows me to treat compilers as a black box without verifying their output. LLMs do not share this specific property, which is why I have to verify their output, and easily verifiable software is what I call "maintainable".

Vaguely2178 commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser

zoogeny · 9 months ago

Well, we're in a loop then because my response was "you don't care about maintainable assembly".

I want maintainable systems you want maintainable code. We can just accept that difference. I believe maintainable systems can be achieved without focusing on code that humans find maintainable. In the future, I believe we will build systems on top of code primarily written by LLMs and the rubric of what constitutes good code will change accordingly.

edit: I would also add that your position is exactly the position of assembly programmers when C came around. They lamented the assembly the C compiler generated. "I want assembly I can read, understand and maintain" they demanded. They didn't get it.

Vaguely2178 · 9 months ago

We're stuck in a loop because you're flip flopping between two positions.

You started off by comparing LLM output to compiler output, which I pointed out is a false equivalence because LLMs aren't as deterministic as compilers.

Then you switched to comparing LLMs to humans, which I'm fine with, but then LLMs must be expected to produce maintainable code just like humans.

Now you're going back to the original premise that LLM output is comparable to compiler output, thus completing the loop.

Vaguely2178 commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser

zoogeny · 9 months ago

Humans aren't deterministic. I've trusted junior engineers to ship code. I fail to see a significant difference here in the long term.

We have engineering practices that guard against humans making mistakes that break builds or production environments. It isn't like we are going to discard those practices. In fact, we'll double down on them. I would subject an LLM to the level of strict validation that any human engineer would fine suffocating.

The reason we trust compilers as a black box is because we have created systems that allow us to do so. There is no reason I can see currently that we will be unable to do so for LLM output.

I might be wrong, time will tell. We're going to find out because some will try. And if it turns out to be as effective as C was compared to assembly then I want to be on that side of history as early as possible.

Vaguely2178 · 9 months ago

> Humans aren't deterministic.

Exactly, which is why I would want humans and LLMs to write maintainable code, so that I can review and maintain it, which brings us back to the original question of which programming languages are the easiest to maintain...

Vaguely2178 commented on A 10x Faster TypeScript devblogs.microsoft.com/ty... · Posted by u/DanRosenwasser

zoogeny · 9 months ago

Lets imagine we are assembly programmers. You have a particular style of assembly that you believe gives you some advantage over your competitors. The way you structure your assembly gives you a lower maintenance burden and faster development speed compared to your competitors.

I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amount of assembly that you generate. And you are probably aghast, what crappy assembly my C compiler generates.

Now ask yourself: how often do you look at generated assembly?

Compilers don't care about writing maintainable assembly. They are a tool to generate assembly in high volumes. History has shown that people who use C compilers were able to get products to market faster compared to people who wrote using assembly.

So lets assume, for the sake of understanding my position, that LLMs will be like the compiler. I give it some high-level English description of the code I want it to run and it generates a high volume of [programming language] as its output. My argument is, the programming language that it outputs is important and it would be better for it to output into a language that low level native binaries. In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.

Vaguely2178 · 9 months ago

> In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.

A well tested compiler is far more deterministic than an LLM, and can be largely treated as a black box because it won't randomly hallucinate output.

Vaguely2178 commented on Snyk security researcher deploys malicious NPM packages targeting cursor.com sourcecodered.com/snyk-ma... · Posted by u/arkadiyt

hennell · a year ago

You're not really missing anything so much as adding a misguided assumption of competence to NPM.

Npm doesn't really do namespaces. There's just no ownership to prove as most packages are published like "call-home" with no namespace required. This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?

In this case the call home package is namespaced, but the real attack is the packages like "cursor-always-local" which has no namespace. Which can sometimes (?) take precedence over a private package with the same name.

It's not a pretty picture, you were better off missing it really.

Vaguely2178 · a year ago

> Npm doesn't really do namespaces.

Yes it really does. npm has namespaces (called scoped packages) and even explicitly encourages their use for private packages to avoid this sort of attack. From the npm docs: "A variant of this attack is when a public package is registered with the same name of a private package that an organization is using. We strongly encourage using scoped packages to ensure that a private package isn’t being substituted with one from the public registry." [1]

> This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?

npm actively blocks typo-squatting attacks during the publishing process: "Attackers may attempt to trick others into installing a malicious package by registering a package with a similar name to a popular package, in hopes that people will mistype or otherwise confuse the two. npm is able to detect typosquat attacks and block the publishing of these packages." [1]

This thread is full of people demonstrating the concept of confirmation bias.

[1] https://docs.npmjs.com/threats-and-mitigations

Vaguely2178 commented on Ruby 3.4.0 ruby-lang.org/en/news/202... · Posted by u/aaronbrethorst

petre · a year ago

Heh, he's so right in every regard although I use Node.

Worst of all, they made npm packages dead easy, so most of them don't even have a readme file, not to mention inline docs like POD or RDoc. This is how you end up with spam pacakges, malware in npm and lpad disasters.

Vaguely2178 · a year ago

> most of them don't even have a readme file

Given the popularity of Github, and the fact that a readme file is the first thing you see when pulling up a project on Github, most projects these days do in fact have readme files.

> inline docs like POD or RDoc

JSDoc is relatively popular.

Vaguely2178 commented on Ruby 3.4.0 ruby-lang.org/en/news/202... · Posted by u/aaronbrethorst

loloquwowndueo · a year ago

“Node makes it impossible to write blocking code” reminds me of this classic and hilarious piece by Ted Dziuba:

http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance...

Vaguely2178 · a year ago

Not sure why this is considered a "classic" piece. It reads as if the author has just discovered the difference between preemptive vs cooperative scheduling, but hasn't yet found the words to describe his "discovery". Yes, you can write a `while(true){}` loop and block the event loop. That's not some damning indictment of Node. The point is that you don't have to block on IO, so your program doesn't have to halt the entire world, and sit around doing nothing while you're waiting for a hard drive to spin or a network request to complete.

Vaguely2178 commented on Prisma Postgres – Runs on bare metal and unikernels prisma.io/blog/announcing... · Posted by u/gniting

k4rli · a year ago

That's what happens when Javascript developers think they're full-stack.

Vaguely2178 · a year ago

The Prisma engine is written in Rust (and the original product was written in Scala), so your snide comment is actually a bit inaccurate. You've also ironically failed to spell JavaScript using the correct casing.

Vaguely2178 commented on Node.js adds experimental support for TypeScript github.com/nodejs/node/pu... · Posted by u/magnio

magnio · a year ago

I don't use them directly much, but template literal generic and contidiontal types is probably the closest a mainstream language has inched towards dependent types.

Some examples of TypeScript power:

- SQL database in TypeScript types: https://github.com/codemix/ts-sql

- Statically typed raw SQL queries: https://github.com/andywer/squid?tab=readme-ov-file#tag-func...

- (Someone fill in your TS hackery for me)

Vaguely2178 · a year ago

There are various programming language interpreters that run entirely in the type system:

- BF: https://github.com/susisu/typefuck

- Assembly: https://github.com/judehunter/ts-asm