sethev

Of course they’re paraphrases. And since when does 37 warrant constantly mentioning how old you are?

I apologize for not quoting you directly “Then go get some!”. That’s what you said in response to there being no evidence. Would you like a link to your comment?

I worked at a company once that posted h-1b jobs on a piece of paper on a board next to a restroom at the office. That was technically a publicly accessible area (if you had a guest pass).

You're the one in this thread claiming people are responsible for "going and finding the evidence" of other people's unsourced claims. You could have just not replied since you didn't have something to contribute.

IMHO, people making claims should provide the evidence for them. One link is behind a paywall and the other clearly states that it is making informed speculations.

I could make all sorts of claims on the spot here. It doesn't create a duty for people reading this thread to go investigate them.

> They clearly did something crazy at corona

They acquired Cerner, which had ~30k employees.

Sure, but Joel isn't saying that's impossible or that people who do that are crackpots. In fact, he was an advocate of writing specs ahead of time [1] - for people.

At the time "generating a program from a spec" was an idea floating around that you could come up with a "spec language" that was easier than regular programming languages but somehow still had the same power and could be compiled directly into a program. That's the crackpot idea that Joel is referencing - but that's not what a spec language used with an LLM is doing.

[1]: https://www.joelonsoftware.com/2000/10/02/painless-functiona...

Program generation from a spec meant something vastly different in 2007 than it does now. People can and are generating programs from underspecified prompts. Trying to be systematic about how prompts work is a worthwhile area to explore.

It leans on tree-sitter for language handling, so i wonder if they're actually Concrete Syntax Trees.

Yeah, but "it's not X. It's Y" is a common idiom that LLMs picked up from people. That's the point i was making. And it's starting to feel like every post has at least one comment claiming that it was AI generated.

LLMs were trained on stuff that people wrote. I get there are "tells", but don't really think people are as good at identifying AI generated text as they think they are...

>There's always a growth phase but then there's a bell curve of age vs competence

A bell curve tracks the distribution of a single random variable. You're mixing statistical metaphors.

And gain experience

>Contained conflagration, short targeted exchanges, probability of contamination low, material possibility of nuclear escalation.

That's describing something that's not a world war, though. The Russian invasion of Ukraine is already far worse than what you're describing as WW3. (setting aside nuclear escalation)

Folks at Jack's level are just as susceptible to flawed reasoning and trend following as anyone else. Sometimes it feels like more so, possibly because they have so much buffer to absorb the consequences of bad ideas (see how Twitter ended up). A person living paycheck to paycheck has less leeway to veer too far away from reality.

All of this to say. I suspect a lot 10k person companies made up of white collar workers could significantly cut their staff and still survive. By the time you get to that size, there's a large middle management that is constantly looking for reasons to increase their 30 person org to 40, and who will be overbooked whether they have 20 people or 100.

I don't know why but it makes me smile that he did this experiment by having a grad student type the questions for chatgpt and copy the results.

He's not. But he just dismissed a question at a conference, that then somehow got turned into a whole article and a front page story on HN.

The registry did come up, as soon as they had enough information for it to be useful. They were looking for a specific child, starting just from the images that her abuser was sharing on the internet (in which he intentionally tried to hide identifying details).

The registry is just a big list of names and addresses.

Your case #2 doesn't have nearly enough information to say whether it's obviously better for a population of patients. There are a lot of other variables you would need to know:

    - The accuracy of detecting a mass
    - The true distribution of masses in the population
    - The likelihood that of falsely detecting a mass in the same place twice (you seem to implicitly assume that false detections are uncorrelated with each other)
    - The likelihood that a real mass is cancerous (you stipulate that this is 95% in your scenario, but you don't say what other factors are used to determine this - as opposed to just knowing that there's a mass that grew.)
    - The positive effect of treatment in the case of true-positives.
    - The negative effect of treatment or further diagnostics in the case of false-positive.

Saying that doctors are lying about over diagnosis to cope with the fact that diagnostic techniques are too expensive is absurd. They have to actually make decisions in the real world, where your two neat little categories can't be known even if they hypothetically exist.

I do think it's a crazy thing to say, but not because of the amount. I mean, if putting in more money produces more value, why not $10,000 a day or a million? Does adding more tokens after $1000 stop working for some reason?

Forget about agents or AI: the amount of money that it makes sense to spend on software engineering for a particular company is highly dependent on the specifics of that company.

Perhaps for them this number makes sense, but it's kind of crazy to extrapolate that to everyone as some kind of benchmark. It would be far more interesting to hear how they place a value on the code produced.

I have a harsher take down-thread, but the simulation testing (what they call DTU) is actually interesting and a useful insight into grounding agent behavior.

Yeah, it's hard to read the article without getting a cringy feeling of second hand embarrassment. The setup is weird too, in that it seems to imply that the little snippets of "wisdom" should be used as prompts to an LLM to come to their same conclusions, when of course this style of prompt will reliably produce congratulatory dreck.

Setting aside the absurdity of using dollars per day spent on tokens as the new lines of code per day, have they not heard of mocks or simulation testing? These are long proven techniques, but they appear bent on taking credit for some kind revolutionary discovery by recasting these standard techniques as a Digital Twin Universe.

One positive(?) thing I'll say is that this fits well with my experience of people who like to talk about software factories (or digital factories), but at least they're up front about the massive cost of this type of approach - whereas "digital factories" are typically cast as a miracle cure that will reduce costs dramatically somehow (once it's eventually done correctly, of course).

Hard pass.

These analogies (except for DNS, perhaps) aren't very illuminating on the difference between a CP system and an AP system in the CAP sense, though. In banking, there are multiple parties involved. Each of those parties is likely running a CP system for their transactions (almost guaranteed). Same with stock exchanges - you can look up Martin Thompson's work for a public glimpse of how these systems work (LMAX and Aeron are systems related to this).

These examples are closer to control loops, where a decision is made and then carried out or finalized later. This kind of "eventual consistency" is pervasive but also significantly easier to reason about than what people usually mean by that term when talking about a distributed database, for example.

To expand on the 24/7 grocery store example: if the database with prices is consistent, you will always know what the current price is supposed to be. If the database is eventually consistent, you may get inconsistent answers about the current price that have to be resolved in the code somehow. That's way harder to reason about then "the price changed, but the tag hasn't been hung yet". The first case, professional software engineers struggle to deal with correctly. The second case, anyone can understand.

Normally, I'm not a fan of putting the date on a post. However, in this case, the fact that Stonebraker's article was published in 2010 makes it more impressive given the developments over the last 15 years - in which we've relearned the value of consistency (and the fact that it can scale more than people were imagining).

There have been hints in the research that this might be the case-but so far they haven't really beaten the heuristic approach in practice (outside of special cases).

For example there's a class of join algorithms called 'worst-case optimal' - which is not a great name, but basically means that these algorithms run in time proportional to the worst-case output size. These algorithms ditch the two at a time approach that databases typically use and joins multiple relations at the same time.

One example is the leapfrog trie join which was part of the LogicBlox database.

In Clojure, vectors literally are functions. You can supply a vector (~= array) or map any place that a single parameter function is expected. So for example:

    (map v [4 5 7])

Would return you a list of the items at index 4, 5, and 7 in the vector v.

I suspect the answer to this lies in who feels the short term pain vs who benefits from the long term gain.

It's one thing to vote in support of politicians who want to use tariffs to reduce imports / increase the price of goods to support US manufacturing. It's quite another to vote for a politician who wields tariffs in inconsistent and arbitrary ways and claims that it won't increase prices.

Yes, I'm speaking about my experience as I remember it - not what was objectively possible for someone with the right resources and knowledge at the time :)

Yes, that is the context in which I first read it (likely around 1999 when it appeared on slashdot), as a senior in high school with no access to the tools used by most professional programmers at the time.

As you point out in your linked comment, the original essay captured the zeitgeist of the time. It also influenced and inspired many people. From that perspective, it's hard for me to agree that it was bad. However, I don't think the content was original at the time (perhaps that's what you mean by bad?) - in the sense that ESR wasn't out ahead of people blazing some new trail and it also didn't hold up very well factually.