As can be seen when attaching an image. When you have to look up something in another tab. I now have to first close the file picking modal, before I can use anything in the browser.
It might be Gnome/Firefox only, IDK. But this modal thing is very bad UX.
The alternative is also bad, TBH: where the file picker is now gone somewhere in the sea of open windows. Maybe the middle-ground, where the file-picker is "attached" to the one tab that opened it, and goes away once other tabs and window chrome is engaged, but I guess thats hard to do in a WM?
They have been around for over a decade. Ghost, strapi, grav, etc etc.
Many are far more user-friendly than WP. All are more secure, better performing, most easier to develop on¹ and several have far better fitting architectures and concepts for common use-cases.
Yet WP continues to churn along. It has it's "marketing" going for it. It has a familiar name, it is predictable (you know what cr*p and legacy you're signing up for, as a techie), and therefore it remains a popular choice. Which is a metric many people use to choose a tech stack on, so it's a flyweel.
You've probably not heard about any of the simple, secure, fast, static-file, build-on-CI, nice-UIs CMSs out there. They are there. You can use them to replace your WP. Yes, even if you have a staff of 20+ web-editors that have never even heard about something like "CI", "Git" or commandlines.
¹ I've been Drupal and WP developer from early 2000-s to early 2010-s. I've founded a few webhosting companies specialised in WP hosting. I've helped hundreds, maybe thousands of ppl with "WP stopped working last week, can you have a look". WP development is a ghetto full of dumpsterfires, with, if you know where to look, are very disciplined, avoid 95% of the "streets" (ecosystem), some gems.
It does to me. Well, a 1x developer into a .01x dev in my case.
My conclusion was that pandas is not for developers. But for one-offs by managers, data-scientists, scientists, and so on. And maybe for "hackers" who cludge together stuff 'till it works and then hopefully never touch it.
Which made me realize such thoughts can come over as smug, patronizing or belittling. But they do show how software can be optimized for different use-cases.
The danger then lies into not recognizing these use-cases when you pull in smth like pandas. "Maybe using panda's to map and reduce the CSVs that our users upload to insert batches isn't a good idea at all".
This is often worsened by the tools/platforms/lib devs or communities not advertising these sweet spots and limitations. Not in the case of Pandas though: that's really clear about this not being a lib or framework for devs, but a tool(kit) to do data analysis with. Kudo's for that.
>My conclusion was that pandas is not for developers. But for one-offs by managers, data-scientists, scientists, and so on. And maybe for "hackers" who cludge together stuff 'till it works and then hopefully never touch it.
It doesn't work for me so it can't work for anyone?
No. "It doesn't work for me. Why is that?" "well, turns out Panda's has a clear and well-defined use-case. So using it outside that use-case will bring problems, pain, friction, etc. Using it for something its not intended for, is why it doesn't work for me"
There's no need to have this in the language just to solve the case you describe.
"function current_thing(id: Int, callback: Fn(Int)) {}" and, when you decide you need more you have a myriad of options to add these. From the despised "function current_real_thing(id: Ind, success_callback: Fn(Int), error_callback: Fn(Error)) {}" to "some_namespace:current_thing(...)" via "OtherClass::current_thing(...)" to "load current_thing from NewImplementationOfThing" and so on.
Being strict and explicit isn't opposed to being flexible. And strictness and explicitness is most often a predicament to allow for future change, rather than hampering that future change.
It's far easier to refactor, maintain, test and reason about strict and limited implementations than to do so with dynamic, runtime-magically-changing implementations.
I found this approach works best with languages having method overloading. For PHP it felt quite limiting, and it also requires you to have more complexity and overhead with wrapping.
But I have no hard evidence at hand, only how I experienced that in PHP.
Paying for bounties is paying for exploits. That is to say, choosing not to pay for exploits is tantamount to selling your customers off for a price, the price of the bounty.
(Human) Humor is a far broader spectrum than you describe here too. It can range from "ROFTL because someone accidentally stepped in poop" to deeply layered liguistic jokes like you describe.
> One aspect of humor depends on cognitive flexibility
All humor? (Honest question)
I was under the presumption that e.g. slapstick or schadenfreude humor doesn't need linguistics, and is therefore seen in many animals. Animals that don't have any form of language but do have rather intricate social systems or even ranks and caste systems. but do have humor. E.g. where breaking or pushing those systems is the humor.
I'd presume that a MITM could set, release and read locks, by which it might determine that you have certain sites open.
In general¹, I presume that any API that uses "same origin" as bounding criteria, must be secure. Since there's no way to enforce this "same origin" in insecure contexts.
--
¹ Aside from the idea that maybe just make all new APIs "secure only", just to discourage insecure contexts.
While this comment is a joke, it's tragicomically true as well.
Way too often have I encountered, or hacked in myself, such "business rules".
"Except for these seven transactions from before [random date/time] all transactions made between 01:00 and 01:15, with a round amount, are recurring payments to X. Can we not just use that instead of this data-migration that you've budgetted?" (not literal request, but close enough).
The danger -off course- lies in that this over time becomes actual business logic and that meaning is assigned to (meta)data that was never intended to carry such meaning.
The solution -I've found- starts with what DDD calls "ubiquitous language", where everyone (within a domain!) assigns the same meaning to the same things¹. And model the software around that, never the other way.
¹ So maybe there's a 150 year old rule that states that recurring transactions are those that happen between ...etc. etc. That this is actually a settled and used meaning within the domain experts/users/stakeholders. In that case - IMO - it's far better to lean into it rather than assign some is_recurring_for_x boolean or such that has no meaning in the domain.
Whereas my current "robot", aka my dishwasher, has them done in 20 mins (or 90 mins eco setting).
Specialized automation is there, proven, efficient. It can be improved, sure (easier (un)loading?), but I doubt a generalized, humanoid robot is the best way towards these improvements.
Pretty sure my dishwasher takes a couple hours (maybe always on eco?). I could hand-wash them in 15 minutes though — I would just rather not.
I wouldn't really care if the robot was up all night doing dishes as long as they were done in the morning. And, you know, the robot did their work quietly.
It might be Gnome/Firefox only, IDK. But this modal thing is very bad UX.
The alternative is also bad, TBH: where the file picker is now gone somewhere in the sea of open windows. Maybe the middle-ground, where the file-picker is "attached" to the one tab that opened it, and goes away once other tabs and window chrome is engaged, but I guess thats hard to do in a WM?
reply