• Записи 40
  • Теги 29
  • Комментарии 235

О Сети и о жизни

Конфликт старого и нового

Всегда считал себя человеком, достаточно открытым к новым знаниям и легко усваивающим новое. Но недавно заметил, что есть ситуации, когда это новое вызывает полнейшее неприятие и отрицание. Задумался, почему, так происходит. Перебрав несколько ситуаций, осознал: новое вызывает неприязнь тогда, когда обесценивает какие-то уже имеющиеся у меня умения и навыки, делая их неактуальными или ненужными. Кстати, впервые я с этим столкнулся еще в подростковом возрасте при переходе от MS-DOS к Windows 95, когда обесцененым оказалось умение писать файлы config.sys и autoexec.bat с экономией памяти и загрузкой всех нужных драйверов.
Наблюдали ли вы за собой подобное? И вообще, как считаете, можно ли примирить старое и новое так, чтобы одно не отрицало и не обесценивало другое и в то же время не стояло на пути прогресса?

5 комментариев:

MadTechGuy
0

У меня наблюдается подобное, причём прямо сейчас, причина та же самая. Это к вопросу об эволюционном развитии и революционном. При эволюционном развитии новое не ломает старое, разве что за редкими и небольшими исключениями. А вот революции как раз тем и опасны, что многое приходится создавать заново. И зачастую "лечится" меньше, чем "калечится". Поэтому всевозможных революций нужно избегать всеми доступными способами. А чтобы не возникла необходимость идти революционным путём, нужно подходить к разработке предельно предусмотрительно, продумывая наперёд возможные варианты развития. Но дано это далеко не всем, поэтому имеем то, что имеем. И кстати, это является одной из главных причин того, почему я стараюсь как можно меньше использовать готовые решения и почти всё пишу сам.

4X_Pro
0

К сожалению, иногда революционного скачка не избежать. Скажем, тот же переход к GUI был таковым. Другой вопрос, что не нужно было с ним так торопиться, а лучше бы подождать конца 90-х, когда памяти уже стало по 64-128 Мб, а также стало понятно, что будущее за вытесняющей многозадачностью (в Windows есть немало кривых решений, связанных с тем, что ранние версии были с кооперативной многозадачностью и нужно было обеспечить обратную совместимость), и оставить разделение на ядро OS и командную строку и отдельно запускаемую оболочку (впрочем, в Linux оно и сейчас есть).

MadTechGuy
0

Да, иногда бывают тупиковые ситуации, которые совершенно никак нельзя предусмотреть заранее. Но вот, к примеру, сейчас я наблюдаю тенденцию отказа от shell-скриптов в системах на базе Linux и иногда несоблюдения философии UNIX, которая меня совсем не радует. Непонятно, чем так не угодили shell-скрипты. Если тем, что большинство shell-скриптов написаны криво — то язык в этом не виноват и это не повод от него отказываться, зато это отличный повод довести код до ума. Если не устраивает их производительность — значит не нужно писать на shell-е те части кода, которые требуют высокой производительности, для этого есть awk и sed.

4X_Pro
0

А что приходит им на смену?

MadTechGuy
0

Сложно сказать, сам хотел бы знать ответ на этот вопрос. Скорее не на полную смену, а частичную. Возможно NodeJS и Python. Вот, к примеру, взять тот же DBus — как с ним полноценно взаимодействовать из shell-скрипта? Даже если и есть способ, то наверняка с помощью какой-нибудь сторонней утилиты, которой в репозиториях какого-нибудь дистрибутива может и не оказаться. А ещё все эти Ansible, Docker, Kubernetes и т.п. создают такое впечатление. Если посмотреть вакансии системных администраторов, то среди многих вакансий в требованиях будет указана необходимость знания вышеупомянутого ПО, архитектура которого у меня вызывает отвращение. А раньше достаточно было понимания философии UNIX, знания POSIX-утилит (в том числе sh) и прочих базовых вещей.

Написать комментарий
Прикрепить файлы: (не более 4 файлов, не более 102400 Кб каждый, 102400 Кб всего)


Задать вопрос