6 ms·

What strikes me the most is that over long time I developed a crazy notion, which is a kind of build up of frustration I guess, which can be expressed with foll

What strikes me the most is that over long time I developed a crazy notion, which is a kind of build up of frustration I guess, which can be expressed with following words "this should have been solved by now, and it should be simple, darn it is 2021 century..." I do not know how many times I wanted to do some functionality, and then I would realize it is not implemented. Regardless of what my expectations are for some language or library, simply it is not there, so after banging my head and burning hours trying to solve a problem I would realize I need to use some dirty workaround (and I hate those so much I do not have enough words to describe...) Just a few example from JS world: - parser that is simple - jest framework working fast - universal planet wide date time - SCSS compiler that does not require C++ ... - multipart/form-data request which can be interrupted in nodejs - ... For each of above there is some solution, but it looks like a dirty hack ... it seems with time, instead simplifying things we are complicating things that should be simple. The other day I was pondering, how in any other trade people becoming masters, as they becoming good with their tools, tools are becoming part of their body, so they are focusing more on art and creativity, in programming, except for those rare who are blessed with very good and fast memory, tools are always changing ... as soon as you become comfortable there will be new set of tools... and I should not even start with the whac-a-mole of method and property renaming ...

pixl97 5y ago
Eh, your post reminds me of this https://xkcd.com/927/ https://xkcd.com/927/ If the points you brought up were simple, it is much more likely they would already be solved. The problem with these things listed is there is a massive amount of complexity in the edge cases.
- NiceWayToDoIT 5y ago
  Exactly :)
- bsder 5y ago
  That may be true, but I also find that too many things get "rebuilt" instead of "completed". Rust is currently suffering from this in its libraries to a very great degree. Take XML for instance--the Rust alternatives are all missing quite a few features, but so is the wrapper for libxml2. So, what do you choose when you need one of those missing features? You can 1) try to add it to the Rust libraries, 2) try to add it to the wrapper, or 3) just wrap the C library yourself with the features you need. I find myself using Choice 3 (which I'm grateful I can do in Rust) more and more because I'm tired of incomplete Rust libraries that look like they do what I want until I start hitting those "corner cases".
  - hnick 5y ago
    Yeah this is probably related to the 80/20 rule. I do it myself. I get 80% of the way through a project in 20% of the time, see the finish line and what is between it and myself, and kind of check out unless there's someone pushing me. It makes sense that people see a library, notice the problems, start their own - then stop at the hard stuff. And people like yourself who might have the talent to fix it will also have the talent to work around it in much less time with far higher reliability by reusing something else.
- mbar84 5y ago
  I fully expected you to have linked to this: https://xkcd.com/1425/ https://xkcd.com/1425/
  - CRConrad 5y ago
    I was expecting the "Influence the sun so cosmic radiation flips the right bits on disk" -- "Emacs has a mode for that" one.
scoutt 5y ago
Believe me, I truly don't want to sound pedantic, but why are you waiting for someone else to implement those (or other) things for you? What abilities does "that someone else" has, that you don't?
- NiceWayToDoIT 5y ago
  Mostly Time and as time is money that also. When you building custom application, you are trying to do it in most optimal way for the $ paid. So, when you building something for the value $ let say 100 SP (story points), and then when you stumble on a problem in OS usually you do not end up building 100000 SP side projects (worth $$$$$$$ of your time) in order to complete 100 SP project. Especially when you crossing to someone else domain. Everyone has its own domain, so if Google, FB, Oracle, Microsoft have the main code base for Java, C#, JavaScript, React, Angular ... or else, it is expectation that they will listen cries of users, sometimes they do other times they do not. Few years back I was involved in Google Chrome thread about auto-fill feature, at the time I was working at the health organisation, so to cut the long story short auto-fill was populating data and causing issue, in the very long thread I gave number of cases why is automatic form fill bad (and I was proposing some one-click alternatives), at the end Chrome team was sticking with what they wanted, and justification was "Because we are Google team, and you are not, so what ever we say is the best" - end of the story.

pixl97 5y ago

Eh, your post reminds me of this https://xkcd.com/927/ https://xkcd.com/927/ If the points you brought up were simple, it is much more likely they would already be solved. The problem with these things listed is there is a massive amount of complexity in the edge cases.

NiceWayToDoIT 5y ago
Exactly :)
bsder 5y ago
That may be true, but I also find that too many things get "rebuilt" instead of "completed". Rust is currently suffering from this in its libraries to a very great degree. Take XML for instance--the Rust alternatives are all missing quite a few features, but so is the wrapper for libxml2. So, what do you choose when you need one of those missing features? You can 1) try to add it to the Rust libraries, 2) try to add it to the wrapper, or 3) just wrap the C library yourself with the features you need. I find myself using Choice 3 (which I'm grateful I can do in Rust) more and more because I'm tired of incomplete Rust libraries that look like they do what I want until I start hitting those "corner cases".
- hnick 5y ago
  Yeah this is probably related to the 80/20 rule. I do it myself. I get 80% of the way through a project in 20% of the time, see the finish line and what is between it and myself, and kind of check out unless there's someone pushing me. It makes sense that people see a library, notice the problems, start their own - then stop at the hard stuff. And people like yourself who might have the talent to fix it will also have the talent to work around it in much less time with far higher reliability by reusing something else.
mbar84 5y ago
I fully expected you to have linked to this: https://xkcd.com/1425/ https://xkcd.com/1425/
- CRConrad 5y ago
  I was expecting the "Influence the sun so cosmic radiation flips the right bits on disk" -- "Emacs has a mode for that" one.

scoutt 5y ago

Believe me, I truly don't want to sound pedantic, but why are you waiting for someone else to implement those (or other) things for you? What abilities does "that someone else" has, that you don't?

NiceWayToDoIT 5y ago
Mostly Time and as time is money that also. When you building custom application, you are trying to do it in most optimal way for the $ paid. So, when you building something for the value $ let say 100 SP (story points), and then when you stumble on a problem in OS usually you do not end up building 100000 SP side projects (worth $$$$$$$ of your time) in order to complete 100 SP project. Especially when you crossing to someone else domain. Everyone has its own domain, so if Google, FB, Oracle, Microsoft have the main code base for Java, C#, JavaScript, React, Angular ... or else, it is expectation that they will listen cries of users, sometimes they do other times they do not. Few years back I was involved in Google Chrome thread about auto-fill feature, at the time I was working at the health organisation, so to cut the long story short auto-fill was populating data and causing issue, in the very long thread I gave number of cases why is automatic form fill bad (and I was proposing some one-click alternatives), at the end Chrome team was sticking with what they wanted, and justification was "Because we are Google team, and you are not, so what ever we say is the best" - end of the story.