Disclaimer: I am an application developer, and one of the maintainers of the Drogon C++ web framework.
C++ & apps don’t fit well together technologically these days.
Android? Go Kotlin.
iPhone? Go Swift.
Cross platform? Meh, kind of dislike middleware as they always lag behind the vendor. This was the case three decades ago as it is today.
Usually you are far better off by defining a REST API as your border between platforms, then just use whatever easy (de)serialization techniques the language will give you.
Personally I have a cross-platform C++ stack built on top of Drogon that I can use on multiple platforms, then it’s usually a native UI layer (Kotlin + Compose on Android, Swift + SwiftUI on Apple platforms) on top of the cross-platform layer. This way business layer code can be shared across every platform while only the UI needs to be adapted to its host OS.
Just to give you an example: Some Samsung SSDs have slightly strange TRIM behavior that basically seems to get unnoticed during normal workloads.
But when you build a Hackintosh with a recent version of macOS this exact TRIM behavior results in boot times of several minutes (compared to a dozen of seconds or so on a SSD with a better TRIM implementation).
I’m not saying Samsung will ever fix their TRIM implementation, but in theory this would be fixable by a firmware update.
And don’t get me even started on the crap that TRIM is, why we shouldn’t need it in the first place, and how convoluted its development was.
If it’s about side money, it usually also implies a smaller, side project, not necessarily, but eventually for smaller businesses to whom technological choices don’t matter.
You just define the outcome together with your client, and use C++ if it’s a technological fit.
From my limited understanding not the distance is the problem, but the constant focus at a point in the same distance. That’s the reason why they recommend to look at distant objects every 15 minutes or so. Starring at a tree for ten hours straight would have a similar effect, but woods are so complex that your eyes are constantly refocusing.
Tab cycling can be a productivity killer, especially when you need to cycle between more than 4–5 applications (which can happen quite often, but OP wrote “alt-tab (or otherwise)”.
What works excellent (at least for me, not necessary for you) is to set shortcuts to your most used applications (be it the function key row, or some hjkl combinations). With such a setup you can just press a key / combination from muscle memory, instead of opening the tab switcher overlay, parsing it, deciding how often you need to press tab, and then actually switching to the other application window. Keeping shortcuts to applications feels like you would only have to do the last step.
It’s really fascinating how humanity can twist almost everything around and start seeing it from a bad perspective.
Maybe the author is a very engaged developer who already knows a huge part of the “boring software that supports the world”? Maybe he is so engaged that he wants to follow new developments in his professional area to get even better? Maybe he hopes that he will discover new and interesting algorithms that can help him improve his skills?
I think there is a point that simple algorithms are a better user interface, because of their predictability (although they show their flaws, like he specifically mentions with JS). Just try to remember how much discussion there was about Twitter’s feed and their move away from a classic timeline. They still haven’t abandoned the latter one.
But who knows in the end? Maybe your comment was just an attempt of satire a la The Onion? Personally I try not to prematurely judge and stay positive. To each his own I guess.
A common convention with system administrators is to have the canonical name at www.* and redirect www-less requests to the former. If you argue that a browser implementation should fix uncommon configurations, I would argue that administrators should fix their configurations in the first place.
You don’t have this issue at all for domains that don’t have a www subdomain.
Furthermore it would be extremely confusing to have different content for www.example.com & example.com.
What the heck? A regular user doesn’t understand or care what the technical difference between a “regular” page and AMP is. I wouldn’t call this ignorance per se.
Apple wouldn’t be Apple if they wouldn’t abandon old technologies in favor of newer ones.
This actually splits developer mindset into two camps: those who love the introduction of new stuff and deem it necessary to achieve progress, and those who accuse Apple of planning obsolescence into their products, and deprecating technologies too early (it’s a little bit hard too believe when you compare Android to iOS, but Linux or Windows vs. macOS tells a different story).
When you’re on it, also install Vimac [1]. I’ve mapped it to ⌃Space (similar to Spotlight’s ⌘Space). It’ll make you grab the mouse / trackpad less often.
> "whatever is the latest framework can take advantage of all the latest methods and libraries to become the fastest"
I’m not sure I understand this, i. e. TRANTOR (which is the underlying network library for Drogon) recently merged in a patch that optimizes memory handling in a low level component of its event loop where object construction was minimized (first tests show another performance increase of about 5–10% on top of the current benchmark results).
I fail to understand how such improvements have something to do with “all the latest methods and libraries”?
What makes you say that Drogon isn’t pleasant to work with? Is it some specific framework APIs that can be improved (if yes, how?), or is it a general disdain against C++ and its syntax?
Yes, exactly. When I need HN in dark mode, I open a pre-configured Terminal profile with w3m launched by default, and have a nice greenish font on a dark background.
C++ & apps don’t fit well together technologically these days.
Android? Go Kotlin.
iPhone? Go Swift.
Cross platform? Meh, kind of dislike middleware as they always lag behind the vendor. This was the case three decades ago as it is today.
Usually you are far better off by defining a REST API as your border between platforms, then just use whatever easy (de)serialization techniques the language will give you.
Personally I have a cross-platform C++ stack built on top of Drogon that I can use on multiple platforms, then it’s usually a native UI layer (Kotlin + Compose on Android, Swift + SwiftUI on Apple platforms) on top of the cross-platform layer. This way business layer code can be shared across every platform while only the UI needs to be adapted to its host OS.
Drogon website: https://drogon.org