No, it does not have to be async.
My impressions from using Squeak regarding this matter:
1. You can send any message to any object. In case the object does not have a suitable handler, you will get an exception: <object> does not understand <message>. The whole thing is very dynamic.
winlister for me. It is like process explorer for windows. When you develop something window related and you have no idea where is a window -- winlister can tell you whether it is hidden, or maybe have left-top out of the monitor
This is a good advice, but I feel to add a few points of mine:
1. the author says "premature optmization", and it has the right context, however I prefer to use "premature abstraction" or even "speculative generalization".
2. YAGNI and DRY can be counter-principles because at times "you aint gonna need that level of abstraction/genericity".
3. Inadequately abstract and generic code hurts simplicity and readability.
Could not disagree more. The author most probably freed the company from its dysfunctional stagnation due to some political issue. It is thanks to his ignorance that he resolved an issue, something that had to be done.
In general, staying out of other people code is a bad idea. It promotes lack of transparency and agenda proliferation. This is because the owners of the code start being a "monopoly", can work less hard, provide exaggerated estimates etc. When people know that others can read there code, maybe hack on it, make something faster or simpler -- well they work harder and tend to be more transparent.
It is mainly a matter of decision making. In my case, no refactoring was ever sanctioned by itself. Devs were having been allowed to refactor anything on a small scale and always backed up by a feature request. So when the desire to somehow "heal" the codebase is met, it is usually because it is already too "dead" to work with in the first place.
It is unpopular opinion, but not all code can be cost-effectively validated by unittests at all.
I have been maintaining codebases where the customer would come and change his requirements on a weekly basis. While I could set up unittests to validate the code that implemented these requirements, doing so would demand significantly more effort than the code itself. I'm talking about some 3d graphics, game logic code. Instead setting up a simple ui (with imgui) to play with the state of the game scene provided much more confidence per man hour.
There is a lot of advice here to do incremental rewrites, refactoring, unittesting, functional/system testing etc.
Undoubtfuly it is all mature and correct advise. However, I feel it is all one-sided and I ought to provide some counter points:
1. The codebase in question may be well beyond the line where any sane person would touch it, seriously.
2. Individuals experienced with the codebase, its structure, implementation, technology stack might be not available (think cobol).
3. Refactoring or incremental rewrite is a process that has to be planned and managed s.t. current product/codebase structure. Oftencase it is this very structure, which demands the full rewrite -- because of it being too convoluted to allow refactoring to take place.
4. You might want to do a rewrite to refresh the tech. stack -- language, design, frameworks -- it is ok to do so.
5. You do not necessarily need to come with the same feature set. Both you and your customers might want to cut down unnecessary cruft. Technical debt usually starts to show its signs with losing flexibility w.r.t user request to change features.
6. Occasionaly you might come up with a separate, different product, with a different name and brand -- which might turn out to be even better!
People usually tend to accept that efforts to build a products are oftentimes underestimated, but somehow accepting the same kind of underestimation is hard. So what?
Even if the rewrite takes more time and money it can still be successful if it substantially reduces costs, relative to the original software.
The important part is to push through the hard part to receive adoption.
They have originated from C++, fine, but it is a different language, different ecosystem, different community, different ideology and -- different idioms
People mostly keep saying that:
1. C++ has at least everything C got, and "other features" so it cannot be worse.
2. C++ is safer than C.
Regarding 1.:
a. C99 and C++11 have diverged. For example, `struct xx x = {0}` has different meaning in those languages.
b. Lack of certain "features" is an advantage. See, C++ is a huge and complex language (r-values, x-values, exception safety, templates, sfinae and so on and so forth). Yes, you can restrain yourself from using them. But can you restrain others working on your codebase, now and in the future effectively? Good luck writing and maintaining code style guidelines..
2. Well, yes, by using smart pointers, STL, RAII, C++ is safer than C for small, fresh codebases. But remember: C++ was designed for backward compatibility with C. It's full of undefined behaviour and pointer arithmetics. Be careless once and all the safety is gone, and then it will be harder to debug than plain old C.
