Hacker News new | past | comments | ask | show | jobs | submit login

People can learn. I believe most programmers (who build side-projects) fall on the curious side. They explore stuff and thus discover software capabilities. Most people use software for a specific task, and learn only what is required. Making a software usable does not means making it a minimalist art project. It means making it consistent both in time (do not shuffle stuff around) and space (do not put things together randomly).

Learning how to type a letter in a word processor can be done in a day. But learning something like Microsoft Word should take a training. Just like you should buy a book about git or bash if you’re serious about learning them. Let the user figures it out is the wrong direction. As well as reducing the software capabilities (for potential power user) in order to reduce cognitive load for untrained users.




It's not that, it's another point: efficiency vs assembly line. Humans are not build to be robots, they are build to evolve.

If we learn a classic desktop paradigm computer system at school, while we learn all the basic and less basic cultural stuff we learn at school to became Citizens, we can profit from this knowledge for life. We can choose to dig deeper or not, but we have something useful for our entire life.

If we learn the modern desktop paradigm we never evolve. We are not Citizens, we are workers in an assembly line and upon any change from the factory owner our acquired knowledge goes to the bin.

I hope to have successfully described the point in my poor English. To give a simple example, I track my bills (well, like many, nothing special), I've crafted a bit of automation (org-mode notes + BeanCount + a bit of py automation), it took two/three days, MUCH more than most users do with modern tools, BUT thereafter anything goes nearly autonomously so I've spent 2/3 days + few seconds looking at my org-agenda regularly vs few minutes to start than keep spending few minutes all the time. In the short term the classic model is not good, in the middle term it's equivalent but demand more intellectual work, in the long term outshine the modern one so much that's like comparing a runner by feet against one on a jet in a speed race. Actually the effort spent in automating my bills notes it's also useful (at least in some parts) to automated other stuff, a bit at a time, an evolutionary step at a time I've built and keep up my PIM, again all the effort put pay back and I've gained valuable knowledge from doing that. The modern approach seems cheaper at first but it's much more expensive in the long run and gives little to no valuable knowledge at all.

The same model apply to any other aspects of our life, one to remain in economics the "ownership model" vs the "rent model", owning a home seems to be much, much more complex than rent one, it demand much more resources, much more computations and projection up front etc BUT it pay back much more thereafter. The rented home is just a regular expense that pile up year after year and at the end you have nothing. The owned home in most cases (essentially all, with insurances) have a final value, normally a big enough one to pay back the capex + opex of the time passed.

Since we are not made to live a single life but to evolve, doing better things a generation after another, passing knowledge and anything we can to newer generation, the modern paradigm is the slave paradigm, he/she produce a new generation that have no benefit from the old one, get nothing, leave nothing in the end. The classic is the human model, where we build families, passing what we have built and the accumulated knowledge, improving a generation after another.


I completely agree with you. I'm in the process moving from SaaS to a more personal computing space (selhosting, file-based app,…). I believe the dumbing down of user interfaces to sell an idea of "It just works" (magically) is a net negative. It also reduces the capabilities of the general population because there's no longer the idea of expertise (as expertise is not allowed). Maintaining a Arch Linux installation is not as easy as using MacOS but it removes the veneer of magic. And I think it's necessary knowledge if we need further improvement in the personal computing space. Just like C has its foot-guns, but learning it gives you a stabler foundation knowledge on how software works. It may not be for everyone, but removing the possibility is harmful for someone.


Allow me to suggest NixOS instead of Arch, for the same automation reason: NixOS meant a single (normally split in few) file(s) that describe your desired config, nixos-install/nixos-rebuild makes the system for you, so at any point in time if something break you just roll back to the previous build, not need to "emergency fix" something or have a test system aside. It's not a "distro war" but what I call a natural outcome of taking notes: in the same org-mode notes I keep my bills, my mails (ol-notmuch), my files (org-attach-ed and linked), a fully searchable "knowledge base" with just ripgrep, no recoll (xapian) or other indexers needed, but also my NixOS config, zsh config, ... and so on. Again the same automation (well, org-babel-tangle + little stuff) works for anything. The same documentation model works for anything. It's long to start, many things to learn, but it pay back much thereafter.

In my case while migrating toward a local approach I've tried some tools, like the idea of using Zotero for a bit anything, bookmarks, docs, ... it works, but it's not integrable with other tools like ALL modern apps, so I've put most in org-mode, bookmarks included, with Buku + ebuku to manage the SQLite DB from Emacs, org attaching stuff is slower than the Zotero connector but much more flexible, "Copy as Org-Mode" (FF extension) it's not as quick as Zotero notes, but the flexibility of one tool for anything is extreme, a thing we lost loosing the classic desktop model and today we can rediscover but still suffering the lack of development and the rest of the world heading in totally different directions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: