Это называется "системный администратор". Не существует эникейщиков и кодеров. Есть системные администраторы, есть программисты. А есть зазнавшиеся системные администраторы и зазнавшиеся программисты, которые унижают тех, кто не достиг их уровня профессиональной офигенности.
Знание предметной области могут себе позволить только программисты
Если не брать в расчёт какие-то наукоёмкие отрасли (где профильное образование лучше иметь изначально), знание предметной области могут себе позволить любые программисты, которым не влом. Например, автоматизируя клинику, программисту не требуется знать методы резекции прямой кишки, ему надо знать, какие поля должны быть в истории болезни, и кто и в каком порядке их заполняет. Не такая уж и хитрая предметная область.
Автоматизируя бухгалтерию, программисту не нужно знать план счетов наизусть, и налоговое законодательство. Но что такое основные средства, проводки, дебет, кредит, сальдо, амортизация, это ему тоже знать нужно. И это - не хитрая предметная область. И так далее.
Мы практически все работаем над каким-то конкретным продуктом. И делаем его не неделю, а месяцами и годами. В чём проблема понимать то, что пишешь?
А зачем сразу миграцию, да еще и учётной системы, для задачи "оптимизации регулярной доставки товара из пары складов в несколько магазинов"?
Ну если у вас текущая система не позволяет это делать - что вы купить предлагаете, кроме как новую систему? Модуль логистики к текущей системе? Давайте по дефолту предположим, что его нет - потому что если бы был, про это финдиректор узнал бы раньше программистов, и купил бы его. А раз новую систему, то и миграция прилагается.
Дайте угадаю - вы имели в виду те компании, которые еще сохранили собственную разработку для собственных нужд?..
Я имею в виду любые компании, потому что те, которые не сохранили, обратятся к компании-саппорту своей системы, у которой тоже штатного математика не окажется, и внештатного скорее всего тоже. Вы поймите простую вещь: нет на рынке таких профильных специалистов. Их единицы, и никто их нигде не видел. Это будет делать обычный программист.
Я вот много на чём писал. В начале 2000-х на Delphi, потом на Java, потом на дотнете, сейчас проект на TS+React+AWS. И знаете, дотнет - лучше :) Он на порядки архитектурно красивее, чем все та мешанина из мусора с редкими бриллиантами, которая сваливается ко мне в node_modules. Поэтому таким утёнком быть не стыдно.
Ну, например, отсутствие оснований защищать этот код копирайтом. Если я напишу, допустим, плашку для ввода логина и пароля на реакте, и поставлю там своё (с), да ещё и с какой-нибудь ограниченной лицензией - это значит, вам такую же нельзя будет делать, что ли? Или вам нужно будет делать, но каким-то другим способом, и каждый должен новый способ изобретать?
Проблема Copilot не столько в том, что он суёт свой цифровой нос в чужой код, сколько в том, что у него был слишком неприятный баг при релизе - он комментарии не подчистил. Если бы подчистил, никто бы вообще даже и не заметил ничего, просто пользовались бы, и хвалили :)
Я прочитал статью. Я не вижу факта нарушения авторских прав в копировании тривиальных фрагментов кода. Вот я увидел у кого-то в коде запрос на получение курсов валют со стороннего сервиса, и скопировал себе эти десять строчек без указания авторских прав. Я нарушил лицензию? Формально да. Ок, но если я не скопировал его, а написал сам, и он ведь будет такой точно, то в чём разница-то? Что я станцевал бессмысленный ритуал "набери такой точно код самостоятельно", и это как-то добавит моей работе очков легитимности?
По факту Copilot неплохой инструмент повышения производительности, и в том числе и для тех самых разработчиков, которые возмущаются его поведением. Хотя ведь сама идея опенсурса была как раз в том, чтобы делиться своими работами с другими и сообща решать сложные задачи. А теперь мы возмущаемся, что робот кому-то вставил в код пару несчастных циклов из ваших исходников без вашего одобрения :)
...но почему? Ведь Copilot тащит тривиальные куски кода, которые присутствуют во множестве программ, и разница лишь в том, что вам не придётся набирать их самостоятельно. Если подходить с этой точки зрения, то нас всех штрафовать можно будет, потому что кто из нас не копировал десяток строк из чужого опенсурса хотя бы из ответов со Стековерфлоу?
Админ с кастомизацией 1с? ;) Ну да, а еще и картриджи в принтерах менять, разъемы 8p8c обжимать, витую пару таскать, воду в кулерах менять... Проще говоря - "продвинутый эникейщик",
Это называется "системный администратор". Есть, правда, категория системных администраторов, которые работают с более серьёзными продуктами, имеют узкую специализацию, задницу поднимают исключительно в рамках SLA, и они таких ребят не уважают, придумывают для них названия вроде "эникейщиков". Примерно как программист со знанием предметной области унижает программиста, работающего по ТЗ от аналитиков, называя его "кодером" :)
или опять же наймут аутсорсера на сопровождение нестандартной конфигурации
Да, вполне. Это сути не меняет.
Минуточку. Я сказал просто "аналитика", без уточнения специализации. Бизнес-аналитик - это достаточно специфичная профессия
Я уточнил, потому что постановка задач на уровне "как считать эти цифры" - это как раз прерогатива бизнес-аналитика. И бизнес-аналитик, это не профессия, это тоже роль :) Всего лишь ещё более узкая специализация. Не суть важно, в любом случае в 99.99% реальных кейсов не будет ни бизнес-аналитиков со знанием этого, ни сторонних консультантов.
Для начала - надо ответить на вопрос "а зачем тут вообще писать автоматизацию, а не воспользоваться готовым"?
Я могу легко на него ответить: потому что бизнес не готов делать миграцию на другую учётную систему.
Да не работает он тут, я же эту кухню изнутри много раз видел :) Огромное количество времени тратится на "а давайте перепишем вот это легаси", причём во многих случаях, если не в большинстве, полученный результат оказывается неудовлетворительным (ну потому что нельзя вот так взять и переписать два десятилетия старого кода, который зачастую ещё и плохо документированный), потом это кладётся под диван, а к легаси добавляются новые костыли.
Огромное количество времени тратится на редизайн ради редизайна, нередко с тем же результатом.
Очень много времени занимает бюрократия - митинги, согласования, коллы и прочая байда. Вам не приходилось присутствовать на полуторачасовых митингах, где утверждали добавление пары текстовых полей к сущности, а потом неделю их добавляли, тестировали, утверждали, деплоили? И так далее, и так далее...
Я вообще вот что подумал - у @PuerteMuerte логика такая: Программирование = алгоритмы = математика. Хороший программист = хороший математик.
Эм... нет, я вообще ничего подобного нигде не писал, и даже не могу понять, как вы подобный вывод сделали :)
Я писал, что математика в программировании нужна там, где это предполагает предметная область. Точно так же, как нужна физика там, где программист автоматизирует физические процессы, а финансовое образование нужно при автоматизации финтеха. И да, всякого рода оптимизационные задачи - это достаточно обширный раздел математики, и чёрта с два его получится просто погуглить и разобраться, потому что... это я тоже писал :)
Если гуглить - получится как у вас, куча незнакомых методов, с каждым из которых придётся долго и мучительно разбираться, чтобы в конце (в лучшем случае!) понять, что ни один не подходит.
сейчас во многих конторах к компьютерам ни "операторы ЭВМ" (как должности) не прилагаются, ни даже сисадмины как фактическая роль.
Во многих не прилагаются, во многих до сих пор прилагаются. По сути, по эту сторону железного занавеса половина среднего бизнеса, которому недостаточно стандартных конфигураций, по-прежнему держит хотя бы своего админа с функцией кастомизации 1С, по другую сторону за этим чаще обращаются на аутсорс, но там так всегда было.
Но и в профессиональных конторах ситуация ничуть не отличается. Мало кто будет держать в штате профессионального математика и бизнес-аналитика в одном лице, особенно если подобные задачи возникают эпизодически, а не являются прямой специализацией компании.
Вот интересно, сможем с вам докопаться до этих условий?
Легко. Знание математики на подобном уровне напрочь отсутствует в штатном наборе скиллов бизнес-аналитика. Он соберёт требования, ограничения задачи, и опишет интерфейс. Математическую часть аналитик вам не опишет, это должен будет как раз программист подобрать. В частных случаях получится пригласить именно профильного консультанта-математика. В общем - это программист будет сидеть и разбираться. Если с математическим бэкграундом, у него получится быстрее. Если без - то долго и с высокой вероятностью неудачи.
. Оно же не обязательно будет "опираться на знания в области" именно так, как это делает настоящее сложное сознание человека.
Но мы же на самом деле не знаем, как работает настоящее сложное сознание человека. Возможно, нам всего лишь нужно будет значительно увеличить количество кремниевых "нейронов" и усовершенствовать методы обучения, чтобы количественные изменения искусственных нейросетей переросли в качественные.
Потому что новый Word создан с помощью инструментов, порог вхождения в которые ниже, чем тот, что был у Word 2000. Плохо это? Отчасти да, отчасти нет. Новый Word может больше, чем старый
А если рассмотреть это через призму того, что в старом Word от версии к версии добавлялось намного больше функционала, чем в современном, при этом команда разработчиков была меньше в разы?
Т.е. в сухом остатке, у нас новые инструменты, ниже порог вхождения, но продуктивность разработчика наоборот, упала по сравнению с 90-ми годами. В чём тогда прогресс?
впихивание контроллеров во все возможные места даже там, где можно обойтись парой транзисторов.
С этим-то как раз всё просто - обработанная медь сейчас на вес намного дороже обработанного кремния.
Для начала надо ответить на вопрос - а точно ли это задача для программиста?
Да, в общем случае это задача программиста. Конечно же, вы можете попасть в организацию, где роль программиста выхолощена до кодирования спущенных аналитиками алгоритмов, т.к. любую профессиональную роль можно сколь угодно дробить на более узкоспециализированные вплоть до атомарных операций. Но во-первых, таких организаций все равно меньше, чем тех, где круг ответственности программиста всё-таки шире, и программистам дают задание в виде "что надо сделать", а "как" - решается уже на их уровне. А во-вторых, даже если вы и попали в такую организацию - а вам точно это надо? Ведь самостоятельное решение более сложных задач, это и интереснее, и значительно выше оплачивается.
К слову, об аналитиках - я когда-то по подобной задаче (только там были танкеры и порты, а не фуры и магазины) обратился непосредственно к логистам, которые это вручную считали, как они оптимизируют фрахты. Цитирую: "ну... вот этот танкер, он сюда не войдет, тут десять метров фарватер, а танкер - двенадцать, поэтому мы его вот сюда войдем. Понятно?"
И это не исключение, по моему опыту, подавляющее большинство заказчиков в среднем и мелком бизнесе, и очень многие - в крупном, способны задачу поставить программистам примерно на вот таком уровне.
Ну хорошо, это всего лишь умножение матриц. А оптимизируйте мне, плз, регулярную доставку товара из пары складов в несколько магазинов - с учётом сроков доставки, дозагрузки фуры, минимизации простоя фуры (и вообще их количества), расхода топлива. Это уже как раз обычная приземлённая задача для программистов. И ладно, я не прошу задачу решить, нагуглите хотя бы, какой из методов нахождения экстремума функции тут применить, если вы это не изучали :)
Вы намешали в кучу два понятия - высшее и математика.
В отличии от непосредственно программирования, как раз математику без учёбы в ВУЗе освоить крайне малореально. И если предметная область требует наличия математических знаний, надо получать высшее.
что мешает изучить её самостоятельно при обилии материала в интернете? Ничто.
Как минимум,
а) отсутствие учебного плана, по которому можно в нужном порядке изучать различные разделы
б) отсутствие человека, который в интерактивном режиме объяснит непонятные моменты, который в случае изучения высшей математики будет на порядки больше, чем при изучении программирования
в) ничтожное количество профильных форумов, по сравнению с программированием, где можно получить ответы на свои вопросы
г) длительный срок обучения. Стать программистом-джуном за полугодичный курс худо-бедно можно, если вы прилежный ученик. Стать математиком-джуном, это надо несколько лет упорного труда потратить - все эти матаны, терверы, матстаты, их просто много. И если программист может обойтись каким-то одним направлением, в котором работать, бэкграунд математика включает массу смежных направлений, которые все надо понимать.
разговоры о необходимости вышки ведут исключительно те, у кого она есть, тем самым они набивают себе цену
Ну, да, но это работает в обе стороны, потому что разговоры о ненужности вышки вышки ведут те, у кого её нет, и обычно с той же целью :)
Истина тут, как всегда, банально посередине - есть предметные области, где вышка нужна, есть где не нужна. CRUD-формочки клепать можно и без вышки, финтех автоматизировать лучше с вышкой за плечами, причём желательно финансовой/экономической, а не ИТ. Так-то да, если у вас нет вышки, сейчас в ИТ вы без куска хлеба не останетесь, но если у вас она есть, вам будут доступны дополнительные возможности карьерного/профессионального развития, что лишним не бывают.
Неа, в том-то и дело, что архитектура IBM на самом деле была более простая и куда лучше подходила для персональных ЭВМ, чем PDP-11. Система команд х86 - да, была сложнее и запутанней. Но архитектурно... вы помните платы ДВК с кучей рассыпной логики, где каждая плата была по сложности примерно как материнка от PC XT? Там половина всей той логики на каждой плате занималась обслуживанием шины МПИ. Это огромный оверхед в сравнении с ISA, которая требовала всего лишь дешифратора адресов и буферы, и при этом работала намного быстрее. Да, у неё не было возможности подключать платы на расстоянии трех метров от микроЭВМ, но эта функция в персональном компьютере отнодь не была киллер-фичей, в отличии от простоты и быстродействия.
А система команд... да, сложная и запутанная в сравнении с PDP-11. Зато преемственная. С восьмибитных машин софт можно было переносить кросс-ассемблером, с 16 бит на 32 - вообще без перекомпиляции. А т.к. в 1980-е уже писали в основном все равно на ЯВУ, сложности подкапотного ассемблера влияли лишь на очень небольшой круг разработчиков.
Насчёт суперскалярности, это совсем не так. Первые суперскаляры, это самые что ни на есть коммерческие знаменитый Крей 6600 и менее знаменитые топовые машины серии IBM System/360, и это середина 1960-х. Эльбрус от них отстал на десятилетие, и в общем-то Бабаян и не скрывал, что вдохновлялся архитектурой Крея.
Что касается Пентиума, то он принёс суперскалярность в архитектуру х86, не более того. Он даже не был первым суперскалярным микропроцессором.
Потому что в первую Дюну хрен поиграешь - там сложность даже для опытного геймера высокая, что уж говорить за казуалов.
Это называется "системный администратор". Не существует эникейщиков и кодеров. Есть системные администраторы, есть программисты. А есть зазнавшиеся системные администраторы и зазнавшиеся программисты, которые унижают тех, кто не достиг их уровня профессиональной офигенности.
Если не брать в расчёт какие-то наукоёмкие отрасли (где профильное образование лучше иметь изначально), знание предметной области могут себе позволить любые программисты, которым не влом. Например, автоматизируя клинику, программисту не требуется знать методы резекции прямой кишки, ему надо знать, какие поля должны быть в истории болезни, и кто и в каком порядке их заполняет. Не такая уж и хитрая предметная область.
Автоматизируя бухгалтерию, программисту не нужно знать план счетов наизусть, и налоговое законодательство. Но что такое основные средства, проводки, дебет, кредит, сальдо, амортизация, это ему тоже знать нужно. И это - не хитрая предметная область. И так далее.
Мы практически все работаем над каким-то конкретным продуктом. И делаем его не неделю, а месяцами и годами. В чём проблема понимать то, что пишешь?
Ну если у вас текущая система не позволяет это делать - что вы купить предлагаете, кроме как новую систему? Модуль логистики к текущей системе? Давайте по дефолту предположим, что его нет - потому что если бы был, про это финдиректор узнал бы раньше программистов, и купил бы его. А раз новую систему, то и миграция прилагается.
Я имею в виду любые компании, потому что те, которые не сохранили, обратятся к компании-саппорту своей системы, у которой тоже штатного математика не окажется, и внештатного скорее всего тоже. Вы поймите простую вещь: нет на рынке таких профильных специалистов. Их единицы, и никто их нигде не видел. Это будет делать обычный программист.
Я вот много на чём писал. В начале 2000-х на Delphi, потом на Java, потом на дотнете, сейчас проект на TS+React+AWS. И знаете, дотнет - лучше :) Он на порядки архитектурно красивее, чем все та мешанина из мусора с редкими бриллиантами, которая сваливается ко мне в node_modules. Поэтому таким утёнком быть не стыдно.
Ну, например, отсутствие оснований защищать этот код копирайтом. Если я напишу, допустим, плашку для ввода логина и пароля на реакте, и поставлю там своё (с), да ещё и с какой-нибудь ограниченной лицензией - это значит, вам такую же нельзя будет делать, что ли? Или вам нужно будет делать, но каким-то другим способом, и каждый должен новый способ изобретать?
Проблема Copilot не столько в том, что он суёт свой цифровой нос в чужой код, сколько в том, что у него был слишком неприятный баг при релизе - он комментарии не подчистил. Если бы подчистил, никто бы вообще даже и не заметил ничего, просто пользовались бы, и хвалили :)
Я прочитал статью. Я не вижу факта нарушения авторских прав в копировании тривиальных фрагментов кода. Вот я увидел у кого-то в коде запрос на получение курсов валют со стороннего сервиса, и скопировал себе эти десять строчек без указания авторских прав. Я нарушил лицензию? Формально да. Ок, но если я не скопировал его, а написал сам, и он ведь будет такой точно, то в чём разница-то? Что я станцевал бессмысленный ритуал "набери такой точно код самостоятельно", и это как-то добавит моей работе очков легитимности?
По факту Copilot неплохой инструмент повышения производительности, и в том числе и для тех самых разработчиков, которые возмущаются его поведением. Хотя ведь сама идея опенсурса была как раз в том, чтобы делиться своими работами с другими и сообща решать сложные задачи. А теперь мы возмущаемся, что робот кому-то вставил в код пару несчастных циклов из ваших исходников без вашего одобрения :)
...но почему? Ведь Copilot тащит тривиальные куски кода, которые присутствуют во множестве программ, и разница лишь в том, что вам не придётся набирать их самостоятельно. Если подходить с этой точки зрения, то нас всех штрафовать можно будет, потому что кто из нас не копировал десяток строк из чужого опенсурса хотя бы из ответов со Стековерфлоу?
Вряд ли те, кто начал учить эти платформы на заре их появления, пожалели об этом впоследствии :)
Это называется "системный администратор". Есть, правда, категория системных администраторов, которые работают с более серьёзными продуктами, имеют узкую специализацию, задницу поднимают исключительно в рамках SLA, и они таких ребят не уважают, придумывают для них названия вроде "эникейщиков". Примерно как программист со знанием предметной области унижает программиста, работающего по ТЗ от аналитиков, называя его "кодером" :)
Да, вполне. Это сути не меняет.
Я уточнил, потому что постановка задач на уровне "как считать эти цифры" - это как раз прерогатива бизнес-аналитика. И бизнес-аналитик, это не профессия, это тоже роль :) Всего лишь ещё более узкая специализация. Не суть важно, в любом случае в 99.99% реальных кейсов не будет ни бизнес-аналитиков со знанием этого, ни сторонних консультантов.
Я могу легко на него ответить: потому что бизнес не готов делать миграцию на другую учётную систему.
Да не работает он тут, я же эту кухню изнутри много раз видел :) Огромное количество времени тратится на "а давайте перепишем вот это легаси", причём во многих случаях, если не в большинстве, полученный результат оказывается неудовлетворительным (ну потому что нельзя вот так взять и переписать два десятилетия старого кода, который зачастую ещё и плохо документированный), потом это кладётся под диван, а к легаси добавляются новые костыли.
Огромное количество времени тратится на редизайн ради редизайна, нередко с тем же результатом.
Очень много времени занимает бюрократия - митинги, согласования, коллы и прочая байда. Вам не приходилось присутствовать на полуторачасовых митингах, где утверждали добавление пары текстовых полей к сущности, а потом неделю их добавляли, тестировали, утверждали, деплоили? И так далее, и так далее...
Всё-таки в ИТ раньше трава была куда зеленее :)
Эм... нет, я вообще ничего подобного нигде не писал, и даже не могу понять, как вы подобный вывод сделали :)
Я писал, что математика в программировании нужна там, где это предполагает предметная область. Точно так же, как нужна физика там, где программист автоматизирует физические процессы, а финансовое образование нужно при автоматизации финтеха. И да, всякого рода оптимизационные задачи - это достаточно обширный раздел математики, и чёрта с два его получится просто погуглить и разобраться, потому что... это я тоже писал :)
Если гуглить - получится как у вас, куча незнакомых методов, с каждым из которых придётся долго и мучительно разбираться, чтобы в конце (в лучшем случае!) понять, что ни один не подходит.
Во многих не прилагаются, во многих до сих пор прилагаются. По сути, по эту сторону железного занавеса половина среднего бизнеса, которому недостаточно стандартных конфигураций, по-прежнему держит хотя бы своего админа с функцией кастомизации 1С, по другую сторону за этим чаще обращаются на аутсорс, но там так всегда было.
Но и в профессиональных конторах ситуация ничуть не отличается. Мало кто будет держать в штате профессионального математика и бизнес-аналитика в одном лице, особенно если подобные задачи возникают эпизодически, а не являются прямой специализацией компании.
Легко. Знание математики на подобном уровне напрочь отсутствует в штатном наборе скиллов бизнес-аналитика. Он соберёт требования, ограничения задачи, и опишет интерфейс. Математическую часть аналитик вам не опишет, это должен будет как раз программист подобрать. В частных случаях получится пригласить именно профильного консультанта-математика. В общем - это программист будет сидеть и разбираться. Если с математическим бэкграундом, у него получится быстрее. Если без - то долго и с высокой вероятностью неудачи.
Но мы же на самом деле не знаем, как работает настоящее сложное сознание человека. Возможно, нам всего лишь нужно будет значительно увеличить количество кремниевых "нейронов" и усовершенствовать методы обучения, чтобы количественные изменения искусственных нейросетей переросли в качественные.
А если рассмотреть это через призму того, что в старом Word от версии к версии добавлялось намного больше функционала, чем в современном, при этом команда разработчиков была меньше в разы?
Т.е. в сухом остатке, у нас новые инструменты, ниже порог вхождения, но продуктивность разработчика наоборот, упала по сравнению с 90-ми годами. В чём тогда прогресс?
С этим-то как раз всё просто - обработанная медь сейчас на вес намного дороже обработанного кремния.
Да, в общем случае это задача программиста. Конечно же, вы можете попасть в организацию, где роль программиста выхолощена до кодирования спущенных аналитиками алгоритмов, т.к. любую профессиональную роль можно сколь угодно дробить на более узкоспециализированные вплоть до атомарных операций. Но во-первых, таких организаций все равно меньше, чем тех, где круг ответственности программиста всё-таки шире, и программистам дают задание в виде "что надо сделать", а "как" - решается уже на их уровне. А во-вторых, даже если вы и попали в такую организацию - а вам точно это надо? Ведь самостоятельное решение более сложных задач, это и интереснее, и значительно выше оплачивается.
К слову, об аналитиках - я когда-то по подобной задаче (только там были танкеры и порты, а не фуры и магазины) обратился непосредственно к логистам, которые это вручную считали, как они оптимизируют фрахты. Цитирую: "ну... вот этот танкер, он сюда не войдет, тут десять метров фарватер, а танкер - двенадцать, поэтому мы его вот сюда войдем. Понятно?"
И это не исключение, по моему опыту, подавляющее большинство заказчиков в среднем и мелком бизнесе, и очень многие - в крупном, способны задачу поставить программистам примерно на вот таком уровне.
Ну хорошо, это всего лишь умножение матриц. А оптимизируйте мне, плз, регулярную доставку товара из пары складов в несколько магазинов - с учётом сроков доставки, дозагрузки фуры, минимизации простоя фуры (и вообще их количества), расхода топлива. Это уже как раз обычная приземлённая задача для программистов. И ладно, я не прошу задачу решить, нагуглите хотя бы, какой из методов нахождения экстремума функции тут применить, если вы это не изучали :)
Уж поверьте, когда это кто-то будет понимать, про это из каждого утюга сообщат.
Эээ, зачем? О_о
В отличии от непосредственно программирования, как раз математику без учёбы в ВУЗе освоить крайне малореально. И если предметная область требует наличия математических знаний, надо получать высшее.
Как минимум,
а) отсутствие учебного плана, по которому можно в нужном порядке изучать различные разделы
б) отсутствие человека, который в интерактивном режиме объяснит непонятные моменты, который в случае изучения высшей математики будет на порядки больше, чем при изучении программирования
в) ничтожное количество профильных форумов, по сравнению с программированием, где можно получить ответы на свои вопросы
г) длительный срок обучения. Стать программистом-джуном за полугодичный курс худо-бедно можно, если вы прилежный ученик. Стать математиком-джуном, это надо несколько лет упорного труда потратить - все эти матаны, терверы, матстаты, их просто много. И если программист может обойтись каким-то одним направлением, в котором работать, бэкграунд математика включает массу смежных направлений, которые все надо понимать.
Ну, да, но это работает в обе стороны, потому что разговоры о ненужности вышки вышки ведут те, у кого её нет, и обычно с той же целью :)
Истина тут, как всегда, банально посередине - есть предметные области, где вышка нужна, есть где не нужна. CRUD-формочки клепать можно и без вышки, финтех автоматизировать лучше с вышкой за плечами, причём желательно финансовой/экономической, а не ИТ. Так-то да, если у вас нет вышки, сейчас в ИТ вы без куска хлеба не останетесь, но если у вас она есть, вам будут доступны дополнительные возможности карьерного/профессионального развития, что лишним не бывают.
Неа, в том-то и дело, что архитектура IBM на самом деле была более простая и куда лучше подходила для персональных ЭВМ, чем PDP-11. Система команд х86 - да, была сложнее и запутанней. Но архитектурно... вы помните платы ДВК с кучей рассыпной логики, где каждая плата была по сложности примерно как материнка от PC XT? Там половина всей той логики на каждой плате занималась обслуживанием шины МПИ. Это огромный оверхед в сравнении с ISA, которая требовала всего лишь дешифратора адресов и буферы, и при этом работала намного быстрее. Да, у неё не было возможности подключать платы на расстоянии трех метров от микроЭВМ, но эта функция в персональном компьютере отнодь не была киллер-фичей, в отличии от простоты и быстродействия.
А система команд... да, сложная и запутанная в сравнении с PDP-11. Зато преемственная. С восьмибитных машин софт можно было переносить кросс-ассемблером, с 16 бит на 32 - вообще без перекомпиляции. А т.к. в 1980-е уже писали в основном все равно на ЯВУ, сложности подкапотного ассемблера влияли лишь на очень небольшой круг разработчиков.
Микрокалькулятор мог быть и таким (трансформатор - см. левый верхний угол):
Насчёт суперскалярности, это совсем не так. Первые суперскаляры, это самые что ни на есть коммерческие знаменитый Крей 6600 и менее знаменитые топовые машины серии IBM System/360, и это середина 1960-х. Эльбрус от них отстал на десятилетие, и в общем-то Бабаян и не скрывал, что вдохновлялся архитектурой Крея.
Что касается Пентиума, то он принёс суперскалярность в архитектуру х86, не более того. Он даже не был первым суперскалярным микропроцессором.