Комментарии 45
Python ... поддерживает ... объектно-ориентированное (прототипное) ... программирование
А мужики-то не знают.
Вот кто-то же прочитает и пойдет "учить NoSQL". А потом в Сбер на собес пойдет. И скорее всего возьмут.
R
Месяц назад начал изучать Swift думаю что до конца года стану его обладателем
Оказалось, что американская система страхования была перегружена из-за всплеска заявок на пособие по безработице, что привело к задержке в обработке дел, так как было недостаточно программистов, знакомых с языком из эпохи динозавров.
Правда, потом расследование показало что проблемы были на более высоких уровнях - тех, что написаны на "модных фреймворках", а сами сервера работали как часы.
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, «в куске плохо написанного кода на Java». Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.
https://habr.com/ru/post/532554/
"ложечки нашлись, но осадочек остался" (с)
Отличная сказка от тех, кто не разрабатывает, для тех кто не разрабатывает.
Если 40 лет полировать легаси на жабе не добавляя значимый функционал, всю разработку вести на других ЯП, а лучше и на других хостах (ну или докеры/виртуалки во все места), то проблемы будут где угодно вокруг, только не в легаси, ага. Мёртвый язык в этом случае можно заменить на что угодно. У меня вот нет проблем с латынью. Не потому что я её знаю, а потому что общаться ни с кем не нужно на ней вообще.
А знали бы латынь, то за полгода-год смогли бы изучить на выбор итальянский или испанский, или португальский, или даже румынский язык!
И как это отменяет тот факт, что легаси работает и замены не требует?
ПОказательный пример - банк содружества Австралии и Океании. Запотимело им "избавиться от легаси". Которое работало.
Потратили 5 лет, $750млн, получили огромную кучу багов (в какой-то момент обнулилась вся задолженность клиентов по кредитам). И что в результате? А то, что все переписанное через пару дет снова перейдет в разряд легаси. Потому что появятся новые стеки, придут новые мальчики с горящими глазами и начнут старую песню - а давайте все опять перепишем на новый современный стек.
При том, нет понимания что это легаси написано на специализированном языке, созданном под конкретные задачи. А мальчикам просто лень во все это вникать и им хочется написать все это на чаем-то знакомом. А знаком им ЯП общего назначения, который для этих задач изначально не предназначен.
А оно работает? А оно будет работать после переноса на новую инфраструктуру? Сколько там реально живого кода, который реально используется в ежедневной работе от общего объёма кода? Уверен, что и по количеству кода, и по количеству фич чаще используется вот тот код, который живой и меняется, чем полторы протухших функции которые "ну, пока как-то работает, а переписывать и тестировать нам лень, подождём пока громко бахнет и потом под дымок доблестно будем фиксить, заодно попиаримся"
Знаете, лет пять назад я бы с Вами согласился. Но сейчас, поработав 4 года с коммерческими middleware серверами (платфhонма IBM i на серверах Power9) могу сказать, что это совсем другой мир, живущий по своим правилам.
Во-первых, сама платформа заточена на одновременое выполнение многих изолированных заданий (job).
Во-вторых, все это заточено под выполнение коммерческих задач. Там БД (DB2), компиляторы языков разработки, все средства администрирования и управления идет не просто "из коробки", а является неотъемлемой частью системы.
В третьих, это очень специфическая, ни на что не похожая система где "все есть объект". Почти ничего общего с миром Win/*nix.
В четвертых, любой программный объект там кроме исполняемого кода, содержит еще т.н. TIMI (Technology Independant Machine Inctructions) код и метку под какой процессор сгенерирован исполняемый код. При первом запуске программы система сверяет эту метку с тем, какой процессор реально установлен и при необходимости перегенерирует исполняемый код из TIMI под текущий процессор.
Т.о. при переносе программ на новый сервер (за мое время работы у нас такое уже было - переходили с Power8 на Power9) гарантируется что все они при первом же запуске будут автоматически пересобраны с оптимизацией именно под этот процессор.
Эта область крайне консервативна - все, что работает, никто без нужды трогать не будет. Это просто очень дорого. Не потому что "легаси", а в принципе дорого - стоимость часа простоя (нелоступности) очень высока. Поэтому там достаточно высокие (относительно других областей) значения T2M (Time-to-Market). Не за счет времени на разработку, но за счет большого объема тестов (у нас обычно сначала компонентное тестирование, потом бизнес тесты, потом нагрузочное тестирование и интеграционное - оба уже на копии промсреды, установка на prelive и только потом на прод).
Понятно, что если смотреть на всю систему в целом, то она не будет однородной. На таких серверах работает только само ядро системы, там сплошное легаси, вылизанное годами, крайне стабильное и эффективное. И часто изолированное от внешнего мира. А вокруг него уже куча "внешних систем", общающихся с ядром через вебсервисы или очереди. Внешние системы уже на других, более традиционных, платформах и "современных" стеках.
Вероятность того, что что-то "бахнет" на уровне ядра мизерная. Код там предельно оптимизирован, вылизан и очень тщательно оттестирован. Любое изменение - это "нейрохорургия" с последующими глубокими ретестами. Любое расширение, введение новых модулей также связано с глубокой проработкой архитектуры, соблюдением единых стандартов разработки ну и тестированием, естественно.
Внешние системы, конечно, меняются более динамично. Но там и цена ошибки ниже.
Если говорить о примере выше, то там все проблемы были именно на уровне внешних систем, но не ядра.
Говорить о том, что что-то лучше, что-то хуже я бы не стал. Это разные уровни с разными требованиями и разными подходами, но все они работают в едином комплексе. Это как компьютер в целом - есть ОС с его ядром и драйверами, предоставляющая набор пользовательских API и есть набор прикладных программ, выполняющих конкретные задачи. Никому не нужна "голая" ОС, но программы без ОС тоже работать не будут. Здесь тоже самое, но на более высоком уровне.
Если говорить о примере выше, то там все проблемы были именно на уровне внешних систем, но не ядра.
Если говорить о примере выше, то там все проблемы были именно там где что-то меняется, а там где всё вылизано, поперекрыто тучей избыточных тестов и дорого менять - почти ничего не меняется, изменения дорогие и очень болезненные как для разработчиков, так и для внедренцев. И вы это только подтвердили. Если бы вот это вот покрытое мхом решало одинаково успешно и с не разительно превышающей стоимостью поставленные задачи как вот те "падучие и ненадёжные штуки", никто бы не внедрял вот те "падучие и ненадёжные штуки"
Ну я вроде бы подробно расписал что и как. Попробую еще раз.
Вы можете написать хоть одно пользовательское приложение на "современном стеке", которое будет работать на голом железе, без ОС и драйверов? Нет. Не можете. Если вы пишете на Java, то вам потребуется хотя бы JVM. Потом еще куча фреймворков, компонент и библиотек. Т.е. на своем уровне вы просто работает с "конструктором лего", который кто-то для вас сделал.
Так вот это самое "поросшее мхом и вылизанное" выполняет роль ОС и драйверов, фреймворков. Предоставляя пользовательским приложениям на модных стеках готовые интерфейсы для выполнения нужных запросов. При этом ядро будет одно, а приложений множество. И "поросшее мхом" вполне успешно справляется с обслуживанием множества запросов от "современных модных приложений". Именно потому что он вылизано годами, в том числе и в плане эффективности использования ресурсов и быстродействия.
Вот теперь вообще ерунду написали. Ни в каком месте оно не выполняет роль ОС и драйверов. Про эффективность и быстродействие тоже весьма спорно. Скорее там просто нет оверхеда на кучи проверок, защит от переполнений, стектрейсов, защит от спектра и т.д. и т.п.. Но вы и дальше будете педалить за то тухлый кобол который лишний раз тронуть страшно - хорошо, а новые разработки - плохо и нестабильно.
Вы слышите то, что хотите слышать, но не то, что я говорю.
Попробую в последний раз. На конкретном примере.
Есть банк. У него есть автоматизированная банковская система. Которая реализует всю бизнеслогику работы банка (поверьте, это более чем дофига чего всего наворочено - тысячи хитросвязанных между собой таблиц, десятки, если не сотни тысяч индексов и достаточно большая нагрузка - у нас оценивается в порядка 3млрд только изменений БД в сутки, не считая чтения). При том, что изменение в одной таблице обычно тащат за собой цепочку изменений в других.
Это не считая режима постоянной работы - когда наступает время перехода на новый день, все текущие операции преключаются на "юнит ночного ввода" и проходят там. А с переходом в новый день в основной юнит идет перенос всех изменений за ночь.
Так вот основная часть логики реализована на специализированных языках. Раньше это был только Кобол, сейчас есть другие. Но суть в том, что это специализированные языки под коммерческие расчеты. Там нативные типы данных с фиксированной точкой (мы вообще с плавающей не работаем), поддержка множества форматов даты и времени (можете, например, сказать что такое дата в формате CYMD?) и встроенных функций работы с ними. Достаточно развитые операции для работы со строками. Все это на уровне самого языка, а не каких-то внешних зависимостей. И все это - полноценные компиляторы, не требующие виртуальных машин, байткода или чего-то еще.
Ну плюс еще механизмы обработки ошибок, исключений и т.п.
Это "ядро"системы. Быстрое, стабильное, надежное, вылизанное до блеска. Оно фактически изолировано от внешнего мира. Добраться туда извне практически нереально т.к. там хранятся все клиентские данные (в том числе)
Дальше уже вокруг него различные внешние системы. Которые общаются с ядром на уровне "запрос-ответ". Через ESB шину (вебсервисы) или очередь.
Внешние системы уже на других платформах и других стеках. Но там практически нет такого количества бизнеслогики. И нет такого объема данных. Они посылают конкретные запросы и получают конкретные ответы. Им не надо знать структуру хранения данных в ядре, все тонкости что с чем и как связано.
Про ОС и драйвера - это аналогия. Когда вам нужно что-то нарисовать на экране или получить с клавиатуры - вы не одумляетесь как это реализовано на уровне железа. Так и внешние системы не одумляются тем, как хранятся и обрабатываются данные - они просто "говорят" - "дай нам список операций клиента за такой-то период дат". И получают его в готовом виде.
Или "хочу добавить нового клиента - вот его данные". Что за этим стоит уже не их дело. А стоит очень много чего. Начиная от проверки человека по спискам росфина, санкционным спискам, определения уровня клиентских рисков и т.д. и т.п. и заканчивая созданием счета, установкой на него нужного бухрежима.
Все это происходит в ядре. Которое по ходу действия еще и текущие работы выполняет (платежи, проводки и прочее).
Короче говоря, я не говорю что на внешних системах все плохо и нестабильно. Там просто другие требования. И к ресурсоптреблению и к скорости и ко всему остальному. Если приложение на телефоне начинает тормозить и жрать ресурсы это вызовет недовольство одного пользователя, но на работе банка не сказывается никак. Если какой-то из компонентов ядра начнет вести себя аналогичным образом, возникает лавина - тормозит начинают все. Задержки прохождения платежей, отказы "истекло время ожидания ответа от банка" у людей, которые расплачиваются картами в магазинах и т.д. и т.п.
Так что то, что работает "снаружи" - это одно. То, что работает "внутри" - совсем другое. По всем параметрам. Это разные уровни, разные стеки, разные инструменты. И тут нет "хуже-лучше". Просто разное.
И тут нет "хуже-лучше". Просто разное.
Вот - это то, что нужно было признать с самого начала, вместо того чтобы пытаться писать бред о том, что "это модные фреймворки виноваты". Если применять определённые требования долгое время к любому стэку, то рано или поздно под такими требованиями он будет ничем не хуже древнего кобола. И вы сами признали, что там не только кобол. Короче перестаём приравнивать говно мамонта к качеству
Есть банк. У него есть автоматизированная банковская система. Которая реализует всю бизнеслогику работы банка
Не знаю о банке какой страны вы говорите, но из ваших слов следует что эта страна не выпускает никаких новых требований к деятельности банков (иначе вылизанность, избыточное покрытие тестами, и отсутсвие большого числа специалистов по конкретному языку это очень серьезная проблема), что не выглядит правдоподобно (для примера на сайте ЦБ РФ опубликовано порядка 200 актов за 2021 год, часть из них несомненно не касается непосредственно деятельности банка, но часть точно касается).
Собственно современный тренд как раз и идет в сторону отказа от вендорских платформ обеспечивающих "все что вам нужно для работы из коробки" в пользу железа и ПО общего назначения (и основной вызов тут как раз в том как обеспечить нужный уровень отказоустойчивости и качества разработки, например один желтый банк писал тут у себя в блоге про свое железо и ПО ~года 2 назад), а вы так рассказываете как будто вендорлок это что-то хорошее, как будто это преимущество.
Ваши примеры "специализированности" языка совсем странны - по числам с фиксированной точкой похоже что можно вообще пользоваться целыми числами (например для рублей считать всегда в копейках), форматирование даты в какой-то вид (хоть строковый хоть бинарный) тоже не проблема в современных языках общего назначения, это все не вопросы специализированности языка.
> При этом С# опустился с 7-й строчки на 23-ю
А на картинке №6
Вообще смешно прислушиваться к мнению Сбера. Пусть в начале вклады наших родителей вернут, потом поговорим.
Лично для меня есть тройка компаний HR которым я принципиально не отвечаю: Сбер, VK, Яндекс.
Из за таких как вы, они поэтапный ребрендинг проводили:
Сберкасса -> Сбербанк -> Сбер.
Чтобы от негативного шлейфа избавиться.
Это еще полбеды, оказывается при среднем сроке ипотеки 10-15 лет, они бумаги архивы по ним держат только 5 ! И когда по окончанию ипотеки в 10 лет, тебе нужна справка, что маткапитал использован 7 лет назад - тебе говорят селяви... Архивы уничтожены
Особенно порадовало, что про недостатоки языка только про java написали, причем недостаток несуществующий:
Язык относительно медленный во время выполнения.
Программы на Java транслируются в байт-код Java, выполняемый виртуальной машиной
Все перечисленные Вами языки, кроме C и С++, тоже работают в виртуальной машине.
В java байткод транслируется только в первые секунды запуска приложения пока компилируется JIT'ом в машинный код. Дальше код выполняется нативно без трансляции.
В Java JIT один из самых продвинутых и обогнать Java по скорости довольно сложно. Java однозначно быстрее питона, джаваскрипта и не медленее C#.
На счет питона — это единсвенный язык в списке, где нет JIT'а и который на несколько порядков медленее других перечисленных языков.
Реальный случай из Сбера образца 2017 года. Часть нашего отдела писала с нуля один сервис. Однажды к тимлиду пришли люди из бизнеса пообщаться насчет этого сервиса. Происходит диалог:
-- На чем пишете?
-- Java 1.8
-- Джава? Вы что, она же медленная! Мы такое на баланс не примем! (и пересказывают весь этот бред про джаву родом из начала 2000х)
-- И на чем же нам тогда писать?
-- На C++ само собой!
ну С++ то всё же быстрее и на месте последние 20 лет тоже не стоял
Как показывает мой личный опыт, С++ это код, который пишется в 3 раза дольше, имеет в 3 раза больше багов и работает в 1.5 раза быстрее, чем Java 1.8. Зная ЗП разработчиков, дешевле купить чуть больше железа.
Есть отдельные задачи, где эффективность куда выше конечно, но тут лучше написать на плюсах маленький кусочек и встроить через JNI в java, чем вообще все на плюсах хреначить.
Вы не поняли юмора ситуации? Не щеголеватым манагерам решать, какой язык использовать, и не на основе шуток 20-летней давности.
Надо еще учитывать сложившуюся "экосистему" для написания этих самых сервисов. Если все написано на Java, куча зарплатных специалистов работает на нем и всех все устраивает, какой смысл "именно этот" сервис писать на другом языке? Только потому, что люди из бизнеса так решили? Есть же целый штаб аналитиков и архитекторов, чтобы решать подобные вопросы.
На счет питона — это единсвенный язык в списке, где нет JIT'а и который на несколько порядков медленее других перечисленных языков.
Если не быть столь категоричным, то есть PyPy
Надо отталкиваться от предметной области при выборе языка: анализ данных, ML - R, Python; биллинг - C, SQL во всех вариантах и т.д. Универсальных языков нет. Если человек начинает, глядя на зарплаты и рекламу курсов, учить Python, не зная азов матстата и тервера, он попросту теряет время и деньги. Познай суть, а слова найдуться!
Учебный план, личные интересы и рабочие таски располагают к тому, чтобы писать на Haskell, C, ASM x86_64, а также скрипты на bash
Язык программирования С, как и С++ — это хорошее решение для разработчиков виртуальных игр. На Си можно создавать приложения, используя 3D-движок Unity, но в современной веб-разработке этот язык не используется.
Что за бред написан? С каких пор на Си пишут игры? Виртуальных игр... странно звучт. И в Юнити чистого Си отродясь не было. Было подобие js
Вот когда научитесь нормально закрывать ИИС с переносом в другой банк, тогда и будете рассказывать нам что-то про ИТ.
Go
Что то прочитал, но что и для чего не понял, херня какая то
> C. Порог вхождения — Относительно высокий.
Вот уж интересно. Совсем одинаково, чоуж.
На мой взгляд, в JS порог вхождения самый минимальный из всего перечисленного, что и частично объясняет его популярность. Другое дело, что хорошо на нём писать — весьма непросто.
Популярные языки программирования: что учить?