nodamage

Uncommon? How many people have a phone in their pocket? Any app that functions offline (for when you don't have cell service) and syncs between devices essentially has distributed nodes minting data.

Indeed. There are a couple billion devices on the planet for which this is a common requirement.

...if you work specifically on web applications with a centralized database.

Some of us don't, so these types of universal proclamations are rather unhelpful.

People are being intentionally obtuse in order to find something to get mad about.

Obviously offering add-ons to your own product is not the same as "showing ads" by any common understanding of the term.

Otherwise literally every app that offers a free version or trial with some form of paid upgrade would be considered "showing ads" because there's an upgrade button somewhere in the app.

If you're going to call that "showing ads" then I would argue you've overloaded the definition to the point where it becomes meaningless.

I don't understand the question. If the model built both apps why wouldn't it also be building the new features on both platforms at the same time?

Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?

You're framing it as lucky timing but if Microsoft had tried to ship a smartphone in 2006 with the same available technology it still would have flopped.

> technology wasn’t there

Until Apple developed it. Those early iPhones employed a lot of tricks to squeeze usability, battery life, and performance out of underpowered devices.

Prior smartphone attempts mostly applied PC-centric concepts to the device, it’s no surprise they ended up failing.

It's worth nothing that all of the studies you linked were performed only on children. It is entirely plausible that DXM is effective in adults but not children because of the difference in dosage or measurement (studies on children often rely on parental surveys).

> This article uses the trick where you pick studies that support your argument and ignore all of the studies that disagree with it.

It's even worse than that, they appear not to have actually read the analysis they cited because two of the three studies on DXM found it was effective in adults. The same efficacy was not found in children but there are other very plausible explanations for this (difference in dosage and measurement techniques).

I don't know if OP changed their link but the one currently in their post (https://pubmed.ncbi.nlm.nih.gov/37232330/) did find DXM to be effective:

"Using objective and subject assessment tools validated in pediatric populations, this study provided evidence of the antitussive efficacy of DXM in children, aged 6–11 years, at the current OTC monograph dose and labeled indication. Compared with placebo, DXM treatment reduced cough rates 21.0% over 24 h (primary endpoint) and 25.5% during daytime/awake hours. In addition, children treated with DXM reported greater reductions in cough severity and frequency in the mornings and afternoons over 3 days than children treated with placebo. These treatment effects were statistically significant despite the study not reaching its planned sample size and are medically relevant."

Also as I mentioned in another comment, the author of original article misrepresents the findings of their own citation. DXM was found to be effective in adults, just not children.

> Most studies have found that dextromethorphan performs the same as a placebo

The citation linked does not support this claim. In fact it suggests the opposite:

"Dextromethorphan was tested in three of the included studies (Lee 2000; Parvez 1996; Pavesi 2001). One report on a series of three successive studies on a total of 451 adults favoured dextromethorphan 30 mg given in a single dose to placebo in terms of cough counts (measured through cough acoustic signals using a microphone on the nose) and subjective visual analogue scales (Parvez 1996). Differences in mean changes of cough counts between active treatment and placebo varied from 19% to 36% (P value < 0.05) in the three studies (up to a net difference of eight to 10 coughing bouts every 30 minutes). This study did not report on side effects.

A study involving 44 participants tested a single 30 mg dose of dextromethorphan versus placebo (Lee 2000). Both treatment groups showed a decline in cough frequency (from 50 to 19 per 10‐minute period in the active treatment arm compared with 42 to 20.5 in the placebo arm, P value = 0.38 at 180 minutes follow‐up). Mean subjective cough scores showed a decline from 2.0 to 1.0 in the active treatment group compared to a decline from 2.0 to 1.5 in the placebo group (mean difference in decline in cough scores 0.5 at 180 minutes, P value = 0.08).

Pavesi and colleagues also tested a single 30 mg dose of dextromethorphan versus placebo (Pavesi 2001). Outcomes were measured through a three‐hour continuous cough recording, measuring cough bouts, cough components, cough effort, cough intensity and cough latency. Average treatment difference was 12% to 17% in favour of dextromethorphan for cough bouts (P value = 0.004), cough components (P value = 0.003) and cough effort (P value = 0.001), with an increase in cough latency (P value = 0.002)."

Two out of the three studies found DXM was effective in adults. The studies did not find the same efficacy in children but that could be due to differences in dosage (adult dosage is 30mg, child doses vary based on body weight) or in measurement techniques (as far as I can tell the child studies measured results via parental survey as opposed to more objective techniques like cough recordings).

Even if you replace ORM generated queries with hand generated queries or LLM generated queries you're still missing a huge chunk of functionality provided by an ORM.

For my projects I would say that the majority of the value an ORM delivers occurs after the query has returned from the database.

But for some reason everyone focuses on query generation as if it were the only feature of an ORM.

I mean there are plenty of projects that don't fit this description, where the database is just a persistence layer for your objects and the database should be subservient to application code.

> Even when you had to do this manually, it was a very minor effort. A one time thing.

Maybe if you’re fetching data from a single table… once you start joining across multiple tables and need deduplicate your result rows it gets pretty annoying to do it by hand though.

Your comment comes across like saying "why would I use an impact driver when my screwdriver does everything I need?"

If you don't actually need those features then obviously an ORM will offer less value to you. That doesn't mean ORMs aren't useful tools, they just aren't useful for the problems you work on.

I tend to work on projects where those features are useful and if the ORM didn't provide them out of the box then I would need to build them myself. In other words using a query builder alone does not adequately solve the problems I need to solve.

Which ORMs are you basing this comment on exactly?

(1) and (3) are not really problems with an ORM that gets out of your way and lets you drop down to raw SQL when necessary, but still helps you hydrate result rows back to objects (and still provides the associated features I mentioned previously).

(2) and (5) can be interpreted as "your ORM does not absolve you from knowing SQL".

I've never personally run into a situation where doing (4) or (6) were desirable.

> The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset

If you work on projects where a full featured ORM can be replaced by a simple query builder then cool, but the rest of the feature set is really useful for the projects I work on so why would I toss them out?

Most of what you've listed I do on my computer not my phone. And some of your items do require internet for useful purposes (at the very least backup and syncing for notes/passwords).

I don't normally order Ubers or scan boarding passes from my computer, no.

I do take photos on my phone but I want them automatically backed up to the cloud so I don't lose them if my phone is stolen.

Editing text/video/music I prefer to do on my computer not my phone.

> virtually none of this requires internet beyond icloud syncing/drive.

That's a weird counterargument. "This doesn't require internet except this feature does require internet."

People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman:

That ORM's absolve you from having to learn SQL.

Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you.

Furthermore, if your objects are long lived (e.g. client-side apps) then ORMs offer you helpful features like identity mapping, unit of work, and change tracking/events.

I'm also convinced most of the people poo-pooing on ORMs just haven't worked on problems where these kinds of features are useful. I mean, if you're writing a reporting tool that just queries the database and dumps the result to a table then yeah you might not need an ORM for that. It doesn't mean that ORMs don't solve useful problems for other use cases though.

> most apps don't have any need to access the internet in the first place

Citation needed.

Looking through my phone the vast majority of third party apps I have installed obviously require internet access:

- Social media

- Travel (rideshare/airlines/hotels)

- Streaming

- Finance (credit cards/banks)

- Shopping

Not counting built-in apps like the calculator I'd estimate 80-90% of the apps I have installed require internet access.

And how exactly are you going to make good coffee if you don't know how to dial in a shot? If you don't know what you're doing your espresso is most likely going to come out sour or bitter. (Under or over extracted. Pulling good espresso is not exactly the most straightforward process.)

Except it's not so easy to get your hands on one these days. They are constantly out of stock. (IIRC they are basically now hand made by a guy out of the UK).

I get the appeal of manual levers to espresso enthusiasts but would strongly dissuade beginners from starting with one. When you are learning to dial in a shot what you want is consistency and reproducibility which is the opposite of what you get with a manual lever.

Also it doesn't steam milk so you need to figure out a separate solution for steaming if you want to make a flat white/cappuccino/latte/etc.

That's not to say you should dump thousands of dollars into a La Marzocco, but there are plenty of entry level machines in the $300-500 range that would suit a beginner just fine.

This seems like an overly cynical take. Is there no value in empirically confirming an assumption? Especially in the exercise world where other long held assumptions ended up being bro-science nonsense?

> although inter-personal coefficient of variation is up to 28.3%

Why does that matter? Isn't the entire point of this study's design to eliminate the impact of the inherent variability between test subjects?

Not necessarily.

For starters, small companies are paying 15%, not 30%.

I'm also not sure where a small company can find a payment processor that will only charge 1%. Stripe charges 2.9% plus 30 cents per transaction.

If you have a $4.99 in-app purchase that will cost you 44 cents per transaction to use Stripe vs 75 cents to use Apple's IAP.

But Stripe does not act as a merchant of record so you are responsible for remitting sales tax yourself. Registering for and remitting sales tax in every jurisdiction where you have nexus adds huge administrative overhead to a small company.

If you want to avoid this overhead, Paddle will act as a merchant of record for you, but then you're paying 5% plus 50 cents which adds up to 75 cents on a $4.99 purchase anyway.

Linking to external payments also reduces conversion rates (https://www.revenuecat.com/blog/growth/iap-vs-web-purchases-...) compared to using IAP.

Taken all together, depending on their pricing structure, small companies may very well be financially better off sticking with IAP rather than linking to external payments anyway.

I think the author of the article really misses the point here. While "true multitasking" might be a neat technical feature, it's not something that the end user really cares about or would base a buying decision on, especially if running multiple apps in the background at the same time came at the expense of battery life. Those early versions of iOS employed a lot of tricks to squeeze performance and battery life out of underpowered devices.

I once did something similar with a recipe from a cookbook where the recipe started at the bottom of one page and continued onto the next page. It correctly identified the first few ingredients present in the photo of the first page but then proceeded to hallucinate another half-dozen or so ingredients in order to generate a complete recipe.

> If I try to do an UPDATE ... SET x = x + 1, that will always increment correctly in SQL. But if read x from an ORM object and write back x + 1, that looks like I'm just writing a constant, right?

This is not specific to ORMs... you can run into the same problem without one.

> Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never?

In every ORM I've used you have specific control over when this happens.

Yes I suspect a lot of the ORM hate comes 1) from people using poorly designed ones or 2) from people working on projects that don't really require the features I mentioned. Like if you are generating reports that just issue a bunch of queries and then dump the results to the screen you probably don't care that much about the lifetime of what you've retrieved. But just because an ORM might not be the right tool for your project doesn't make it a bad tool overall, that would be like saying hammers are bad tools because they can't be used to screw in screws.

I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results:

1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated.

2. Automatic handling of many-to-many relationships so you don't have to track which ids to add/remove from the join table yourself.

3. Identity mapping so if you query for the same object in different parts of your UI you always get the same underlying instance back.

4. Unit of work tracking so if you modify two properties of one object and one property of another the correct SQL is issued to only update those three particular columns.

5. Object change events so if you fetch a list of objects to display in the UI and some other part of your UI (or a background thread) add/updates/deletes an object, your list is automatically updated.

6. And finally in cases where your SQL is dynamic having a query builder is way cleaner than concatenating strings together.

For those who are against ORMs I am curious how you deal with these problems instead.

For what purpose do they make these calls?