Please clarify, OP, did you mean
?
Indeed. Makes it more work to filter the handful of good or even great articles from the 99.99% that use this platform for its apparent ease of money grubbing.
It’ll probably take Valhalla for me, personally.
Or a signal that you’d rather not support the worst way to introduce type systems to frontend dev. While I’m not sure that applies to DHH, I am sure there are other devs that understand compromising all your goals to codepend on Node or even JS itself isn’t that much of a win and rather see support for better options.
I sure hope so, but I’m not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn’t easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.
So unless very specific regulation takes place, I don’t see standardized access to braille displays happening.
Right, that is another item I wished more editors would have picked up. Besides - say - nested language modes.
Original poster is right by all accounts, of course. Now, let’s come up with exotic significant indentations.
function xyz(a, b):
| var x = 2
| if true:
| | do_something()
| else:
| | do_something_else()
| anyway()
Pro: Your editor no longer needs to implement indentation hints.
Con: Looks obstructive if not highlighted like an indentation hint.
Your turn.
That reminds me of those times when back on reddit some dev showed up to present their new GUI library. Bragging about how they were better than Qt devs etc. (even though they didn’t implement the hard parts, like working text fields or tables)
After some time a bunch of people had enough and started bullying those guys into submission about accessibility. After some time, every of those toolkits had support or at least plans for supporting screenreaders. Eventually, AccessKit became a thing.
Good times.
Of course, I might be overestimating how easy it is to get better braille oriented editors
A braille display traditionally is a personal, almost handfitted (estimated by price) device controlled by its screen reader software. Not the editor. This has some unfortunate implications:
So yes, you might be overestimating how easy that is, compared to telling some diva asswipe chucklefuck to use that formatter or work at McDolans.
Thanks!
Is this to rpm-based distros what Mint is to deb-based distros?
From what I can see it is a slightly more detailed take on dependencies, loose coupling etc. Seems like it is formal and a bit weird, though. And a few part seem… extrapolated. So, no wonder it never caught on.
Possibly. Hard to tell how much time that would have bought.
It’s not exactly clear to me who is supposed to be more comfortable.
Anyhow:
And the logical conclusion of this is there is a non-zero chance you get to enjoy the opportunity, no, the priviledge to maintain that 100k loc codebase written in someones personal PHP dialect. Lucky you.
Now, you’re paying for the product, and you continue to be the product.
So this is what “neofeudalism” boils down to?
It was indeed three pawns to introduce it. Nice eye for detail.
I’m glad it doesnt.