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).
"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?
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.
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?
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.
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.