tabtab

Anonymous posting has big risks. It gives trolls a green light.

An honest book would explain the trade-offs instead of say "design X is always better than Y". Context and domain matter. One-size-fits-all is wrong.

Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers.

Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.)

I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps.

I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.

I don't yet understand the implications or risk of this, but I'm positive the anti-vaxers will use it to spread their cause.

When a company monopolizes a market, they almost always turn into jerks.

What are the top 2 pain points you encountered?

Although a lot depends on personal preference, in general "root" infrastructure is best on strong typing, while "glue-ish" scripts best as dynamic.

What's needed is a "C historian" who documents all the attempts to rework or compete with C, and make an analysis and summary of the results and trade-offs. I doubt there's a free lunch (no trade-offs), but studying past attempts can tell what's been close.

Stop your bigotry of Kernians.

I bet the forgeries are worth something now that they made the news. I'd like to see a photo comparing them to the original.

> It will give customers options to decide for themselves.

And because of this, more people will add dodgy apps that compromise the phone.

> nothing wrong except that Apple doesn't want to allow them. Like emulators

Emulators add risk of trojans running.

Maybe the trick is to spread sun exposure across the body rather than mostly let our limbs and face take most the sun. Protect those areas, but get fuller body sun more often. The parts of my body on the boundary between heavy exposure and no exposure seem relatively okay. They have a slight freckle-ness to them, but arguably acceptable. (I'm not young; time-tested.)

I have a skin condition that flares up if I don't get sun. At first the doctor told me to avoid sun, but it got worse. Then by accident I got somewhat sunburned, and my skin improved.

I don't understand why co's don't simply give "in office" bonuses and let employees decide their ratio? Why do so many co's make it all or nothing?

Plus ID's often have to be given over the phone for support. Long or complicated ID's will drive both sides bonkers. #BeenThereDoneThat.

Part of Apple's selling point is a well-managed walled garden that keeps riff-raff out. Opening it up will introduce riff-raff. The well-to-do are okay paying more to have better guards.

JSON columns are a kludge. What's really needed is Dynamic Relational (see link). JSON columns are second-class citizens in such RDBMS. Dynamic Relational would make all columns just as powerful. A startup could use something like the Zend business model to make an open-source version and a for-fee enterprise version for scaling. https://www.reddit.com/r/CRUDology/comments/12ari2l/dynamic_...

A fight against a virus is all-out war in the body. In any big war, there will be significant collateral damage. The body has to "bomb" brain and nerve cells to kill infected cells, and obviously if you have enough of them taken out, it will have lasting impact on your function.

Some grow back, some don't, and even those that grow back need to be retrained. For those that don't grow back, other cells and body parts have to learn to compensate.

Please keep up on your inoculations.

> allows potentially complex ETL statements to be handled within a single merge statement. I'm not saying that's always the best practice, but if things are structured in the right way, it may be.

I wonder how often one has the ideal schemas for such. The advantage of an ETL is that it's probably easier to debug, log, and trouble-shoot problems. One-Giant-Do-All-Command is often a recipe for headaches. Being able to "X-Ray" the intermediate pipes really helps troubleshooting.

The X-ray issue is one reason I have trouble debugging functional programming. Maybe there's a way to X-ray better, but I haven't found it yet.

Don't laugh, someday a terrorist or hacker may engineer a fast-eating critter, and half our stuff will become useless in a year. Termites learned to work with gut microbes to speed up wood munching, a home-owner's biggest nightmare.

Agreement is not to be taken for granted: https://www.wired.com/2010/11/1110mars-climate-observer-repo...

Math is merely a mutual agreement. First an agreement on root principles, and then an agreement on notation for these root principles. The rest is built on top of those. Nobody is forced to accept the premises. (Unless you don't want an F in math class.)

Is that the ancient Chinese way of sleeping with stones on the eyes, to flatten the lenses?

Um, I think those were gerbils.

It quickly locked up on me, or at least responds very slowly. I'm curious, what kind of UI is it using? Canvas? SVG?

HTML and DOM lack too many common and expected GUI idioms (see link). If our standards had those, then we wouldn't need to use clunky stuff like React to emulate them. We need a state-ful GUI markup language standard.

https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

Amen! Had a nice chuckle. Kudos for self-deprecating humor on the part of the authors.

Our current web standards are ill-suited for what we really want out of the web (rich desktop-like GUI's), so people keep trying different things in desperation. One thing not really tried yet is a state-ful GUI markup language standard. Also, maybe applets could be done right on a second try, applying lessons of the first.

Whatever it's replaced with will be subject to the turbulence of whims and fads. COBOL is like ancient Latin: it ain't going nor coming.

If they "solve" that then they risk being the next Java Applets.