Comments 100
Отличный рассказ, но у нас всё на много лучше выглядит, правда ?!
Если считать, что DOS да Clipper с Btrieve — лучше, чем COBOL, то да.
Cobol — это 50е-60е годы, а дос — уже восьмидесятые-девяностые. Так что да, у тех у кого дос всё сильно лучше.
Clipper, кстати, вполне себе функциональный язык, похожий по модели данных на JavaScript. В смысле да, функциональный — это то, что вы подумали.
fAdd = &("{x, y| x + y}")
z = eval(fAdd,{1,2})
@0,0 say z // output: 3
fAdd = &("{x, y| x + y}")
z = eval(fAdd,{1,2})
@0,0 say z // output: 3
У нас есть замечательная история.
Система бронирования (продажи) авиабилетов, созданная еще в СССР, работала на неком «большом компьютере». Не мейнфрейм, но его младший брат.
Техника эта выходила из строя… В СССР ее больше не производили, а заграничную покупать было слишком дорого (это же техника класса — для поддержки старых систем, дешевле она с годами не становится).
Написали эмулятор. На обычном персональном комьпютере (мощном, надо полагать) эмулировали старое железо.
Написать эмулятор оказалось проще, чем переписать софт бронирования авиабилетов.
Собственно мы и сейчас подобные вещи наблюдаем — VDS/VPS/Docker…
Потом его, все же — переписали.
Но далеко не сразу.
Он несколько лет успешно жил на эмуляторе.
Система бронирования (продажи) авиабилетов, созданная еще в СССР, работала на неком «большом компьютере». Не мейнфрейм, но его младший брат.
Техника эта выходила из строя… В СССР ее больше не производили, а заграничную покупать было слишком дорого (это же техника класса — для поддержки старых систем, дешевле она с годами не становится).
Написали эмулятор. На обычном персональном комьпютере (мощном, надо полагать) эмулировали старое железо.
Написать эмулятор оказалось проще, чем переписать софт бронирования авиабилетов.
Собственно мы и сейчас подобные вещи наблюдаем — VDS/VPS/Docker…
Потом его, все же — переписали.
Но далеко не сразу.
Он несколько лет успешно жил на эмуляторе.
Конечно! У нас ведь в банках… Delphi! *cool face*
Вы так говорите, как будто это что-то плохое.
Нет. Просто язык объявили мёртвым и похоронили, но он по-прежнему живёт в банках. И надо заметить со своими задачами — прекрасно справляется.
Почему мертвым?
До сих пор выпускается среда Дельфи.
Да, она сменяла пару раз владельцев.
Да, она растеряла былую популярность.
Да, она на фоне JS, PHP — почти никакое количество программистов.
Но почему мертвой-то?
До сих пор выпускается среда Дельфи.
Да, она сменяла пару раз владельцев.
Да, она растеряла былую популярность.
Да, она на фоне JS, PHP — почти никакое количество программистов.
Но почему мертвой-то?
Мертвым он не является, но вот свою нишу они в первой половине-середине 2000х упустили. Пока другие (тот же net) развивались, Дельфи стоял на месте.
Дельфи и тогда и сейчас стоит весьма больших денег, просто появились бесплатные языки программирования (близнец Lazarus, и множество других), плюс демпинг со стороны Microsoft, в том числе переманившей ведущих программистов на разработку C#. Сложно выбрать Дельфи при наличии Qt например.
Не, не по этой причине. Помню как вышли кривые новые версии плохо совместимые с Legacy, что вообще убивало смысл использования Delphi — из-за того что Legacy-код на них зачастую не работал. Что было особенно критично для библиотек с компонентами, многие из которых оказались несовместимы с новыми версия Delphi, хотя до этого таких убийственных проблем со совместимостью и поддержкой Legacy не было. Из-за чего народ вместо этих кривых версий продолжил использовать старые добрые Delphi 6 и Delphi 7, а затем и вовсе стал переходить на другие языки программирования.
Я о том и говорю: они потеряли свою нишу. Под «развивались» имеется в виду не только feature'и, но и увеличение стабильности. У нас в свое время хотели при появлении новой версии перейти на нее с Delphi 7, но оказалось, что IDEшка тормозная и глючная, компилятор медленее, код хуже оптимизирован. Плюс сверху проблемы с unicode'ом. В итоге от перехода отказались, так ядро и пишем на семерке.
Да они охренели в свое время. Их весь дельфовый мир проклинал.
Такая востребованная система как Дельфи — а у Борланда/Инпрайза она была где-то на предпоследнем месте по важности в течение весьма и весьма длительного времени.
Они тогда то ли на БД фокус перевели…
Потом правда вернулись, когда акционеры поняли что пахнет горелым. Но было поздно.
Такая востребованная система как Дельфи — а у Борланда/Инпрайза она была где-то на предпоследнем месте по важности в течение весьма и весьма длительного времени.
Они тогда то ли на БД фокус перевели…
Потом правда вернулись, когда акционеры поняли что пахнет горелым. Но было поздно.
Похоронили, да. И туда ему и дорога. И давайте уже будем честными сами с собой — дельфи так хорош не из-за непревзойденных качеств языка Object Pascal, от которого Вирт открещивается как только может, а из-за возможности лепить кнопки на форму. И какие это задачи, с которыми он справляется? Я хочу, например, иметь обобщенные списки и вообще полноценные коллекции объектов, хочу перемещаться по ним как положено, при помощи итератора, а не как этому вашему компилятору взбредет в голову. Если меня замучает ностальгия, я, так и быть, запилю что-нибудь на FreePascal (если совсем станет плохо — на трупопассале седьмом, но это уже будет клинический случай). И почитаю книгу пейсателя Фленова «дельфи глазами хацкера»
Там не только кнопочки, эти же компоненты делают очень удобной работу с базами данных. Помню, как я однажды, правил программу на Visual Basic, ну так вот кнопочки — там были, а вот работу с базами данных — пришлось всю писать ручками. А в Delphi всё это делается за несколько кликов мышкой — кинуть на форму компоненту для баз данных и подключить.
от которого Вирт открещивается как только может, а из-за возможности лепить кнопки на форму
Опять эти стародвание байки про «ляпнул кнопки на форму и готово». Откуда? Я СЕМЬ лет пишу на Дельфи по работе. За эти семь лет у меня было ровно 2 (ДВА) таска, связанных с окнами. Больше ничего связанного с UI не было вообще — серверная часть.
Я хочу, например, иметь обобщенные списки и вообще полноценные коллекции объектов, хочу перемещаться по ним как положено, при помощи итератора, а не как этому вашему компилятору взбредет в голову
Есть коллекции в этом языке. Итератор — спорная вещь.
В новых версиях Delphi обобщенные типы (generics) есть. И итераторы есть. И свой собственный итератор можно написать. А вы говорите язык не развивается...
Я хочу, например, иметь обобщенные списки и вообще полноценные коллекции объектов
Так я в 2005м году открыл для себя Аду.
Непревзойдённые (почти) качества в языке–таки имеются. Я рассматриваю Delphi как 2 языка в одном, и второй, менее мейнстримный язык, очень привлекателен. В первом языке — ручное управление памятью, единоличное владение и try…finally для объектов, а во втором — счётчик ссылок и RAII. Это можно видеть на примере, как реализаованы мейнстримный TJSONObject с ручным управлением памятью и мой CVariant. Диапазонные типы имеются, пусть даже ими сложнее пользоваться, чем в Аде (В языке Ада цикл от -1 до 0 не выбрасывает исключение нарушения диапазона, потому что система типов двухуровневая, для диапазонов обычно не создаются новые диапазонные типы, с которыми будут проблемы, как в Delphi, а делается ограниченный подтип существующего типа, и арифметические операции по умолчанию возвращают результаты в самом широком подтипе типа). Но даже такая плохонькая система типов может повышать целостность, особенно, если начать диапазон с -1 и не бояться использовать его в for. По крайней мере, в диапазоне от -1 до 15 не затесается 50.
Язык нативный, подходит для низкоуровневого программирования, при этом особенности компилятора позволяют контроллировать целостность. К сожалению, проверки по умолчанию отключены, как если бы каждый первый встречный писал на Delphi видеокодеки, но их хотя бы можно включить, и я видел, как всплывает вот это вот всякое, когда во всём проекте резко врубить все проверки, и как всё оздаравливается, если исправить ошибки, вызывавшие эти исключения. В C++ коде для vector<> вы так просто в проекте проверки галочкой в настройках не включите. Мне приходилось делать другой шаблон, который заменял operator[] на at(). Что касается контроля диапазонов, в Java для сравнения, свой тип нельзя определить, а для встроенных типов переполнение не проверяется. В C# ключ /checked нужно использовать при компиляции, тоже под видеокодекописателей язык заточен, наверное.
Наравне с C++ и Objective-C, Delphi и Ada позволяют в том или ином виде использовать RAII и счётчики ссылок, в то время, как многие разработчики инструментов разработки посходили с ума и заколебали остальных своей сборкой мусора. ARC в Objective-C очень распиарен, но хронологически в Delphi он был раньше, жаль только, что он был в немейнстримной версии языка.
Я рассматриваю Delphi как 2 языка в одном, и второй, менее мейнстримный язык, очень привлекателен. В первом языке — ручное управление памятью, единоличное владение и try…finally для объектов, а во втором — счётчик ссылок и RAII
Золотые слова. Именно этот баланс, возможность когда надо, ковыряться руками, а когда не надо — доверить компилятору и привлекает.
Вы требуете от Дельфи, рожденной около 20 лет назад, того, что является нормой для современного программирования.
Другими словами, Вирт, который создал Паскаль еще в более древние времена, чем 20 лет, должен был, по вашему предсказать тенденции программирования на многие десятилетия.
Имхо, вполне достаточно из достижений Вирта того, что Паскаль серьезно повлиял на многие современные языки.
Другими словами, Вирт, который создал Паскаль еще в более древние времена, чем 20 лет, должен был, по вашему предсказать тенденции программирования на многие десятилетия.
Имхо, вполне достаточно из достижений Вирта того, что Паскаль серьезно повлиял на многие современные языки.
почти все крупнейшие банки в мире работают с мэйнфреймами IBM и COBOL у них — основной язык программирования
Ну еще есть вариант перевести на мейнфрейм несколько (или кучу) БД Oralce и запускать их под Linux'ом.
Вы описали «каким ПО можно занять имеющееся железо».
А дело то не в железе, а напротив — в ПО.
И довольно внятно описано, что это не просто — почитайте то место в статье, где говорится о переходе на DB/2
А дело то не в железе, а напротив — в ПО.
И довольно внятно описано, что это не просто — почитайте то место в статье, где говорится о переходе на DB/2
Многие банки сейчас и так на Оракле сидят. В т.ч. и под AIX.
Ой, слышу я, не было у вас реального проекта хотя бы близко похожего, иначе не бросались бы вы такими словами )
>Ну еще есть вариант перевести на мейнфрейм несколько (или кучу) БД Oralce и запускать их под Linux'ом.
А так оно сейчас и делается. В большинстве случаев, правда, сами базы крутятся под AIX'ами, но тем не менее связка AIX+RHEL+Oracle — работает во многих крупных банках.
А так оно сейчас и делается. В большинстве случаев, правда, сами базы крутятся под AIX'ами, но тем не менее связка AIX+RHEL+Oracle — работает во многих крупных банках.
Главное — кто будет переводить и отвечать, и кто платить за вечеринку, в смысле за работу и за ответственность. Работа ради работы — милое дело для оплаты, нужно ли?
25 лет на одном месте? одна платформа? схожие задачи изо дня в день?
Да, не приведи господь к такому!
Да, не приведи господь к такому!
UFO just landed and posted this here
Вы из тех, что считают, что успешный человек — это сначала фриленсер, а потом владелец собственного бизнеса?
Или успешный и счастливый тот, что сменил 50 мест работы и стал большим начальником?
Люди по разному устроены.
Что плохого, что человек назубок знает свою систему и любой рабочий вопрос решает точно зная что и где искать?
Не всем надо новшества каждый день.
Кроме того там же написано, в статье — она множество новых вещей реализовала. И это ей очень нравилось.
Или успешный и счастливый тот, что сменил 50 мест работы и стал большим начальником?
Люди по разному устроены.
Что плохого, что человек назубок знает свою систему и любой рабочий вопрос решает точно зная что и где искать?
Не всем надо новшества каждый день.
Кроме того там же написано, в статье — она множество новых вещей реализовала. И это ей очень нравилось.
Вот так в один прекрасный день выгонят — и никуда больше не возьмут!
(Хотя складывается впечатление, что замену уволенному программисту на Коболе найти нереально, т. е., чтобы тебя выгнали, это незнамо как надо налажать.)
(Хотя складывается впечатление, что замену уволенному программисту на Коболе найти нереально, т. е., чтобы тебя выгнали, это незнамо как надо налажать.)
ТАКОГО специалиста возьмут. И сразу на золотую зарплату.
Разумеется, не в Гугль.
А только в ДРУГОЙ БАНК.
Разумеется, не в Гугль.
А только в ДРУГОЙ БАНК.
Это еще смотря за что его из предыдущего банка выгнали…
Выгнанного за мошенничество со счетами, к примеру — больше вообще НИКУДА и НИКОГДА не возмут в серьезную контору, служба безопасности которой пробивает своих сотрудников.
В статье даже написано, когда и почему выгонят. Через 16 лет, когда последний модуль переедет с мейнфрейма, программисты на коболе станут не нужны. Или идти в другой банк, или джуниором на ПХП.
1. О да, это очень важно: исходя из того, что самый молодой сотрудник у них рожден 1962 году и следовательно в 2016 году ему будет 70 лет.
2. Я менял в корне языки программирования за свою карьеру уже несколько раз. Никаких проблем, кроме небольшой потери производительности на пару месяцев.
Вы преувеличивайте знание языка программирования.
Это же не человеческие языки, которые можно учить годами только для того чтобы достичь уровня шестилетки-нейтива.
Гораздо большую пользу несет опыт работы программистом вообще, а не на конкретном языке программирования.
В то же время у меня есть коллеги, сидящие по 20 лет на одном языке, которые знают их хуже меня и совсем не стремятся применять какие-либо новые методики, библиотеки, инструменты и пр. и пр.
Знание языка — ничего не значит. Его вес около нуля.
При подборе персонала в серьезные конторы, если только вы не на джуниора идете, никто не будет вас спрашивать об итераторах и пр. вещах имеющих непосредственное отношение к языку.
2. Я менял в корне языки программирования за свою карьеру уже несколько раз. Никаких проблем, кроме небольшой потери производительности на пару месяцев.
Вы преувеличивайте знание языка программирования.
Это же не человеческие языки, которые можно учить годами только для того чтобы достичь уровня шестилетки-нейтива.
Гораздо большую пользу несет опыт работы программистом вообще, а не на конкретном языке программирования.
В то же время у меня есть коллеги, сидящие по 20 лет на одном языке, которые знают их хуже меня и совсем не стремятся применять какие-либо новые методики, библиотеки, инструменты и пр. и пр.
Знание языка — ничего не значит. Его вес около нуля.
При подборе персонала в серьезные конторы, если только вы не на джуниора идете, никто не будет вас спрашивать об итераторах и пр. вещах имеющих непосредственное отношение к языку.
Вообще-то, "знать язык" сегодня означать знать парадигму его использования (в том числе — какие тут приёмы и как их реализуют) и его библиотеку.
Студенты преувеличивают сложность изучения языка программирования.
Трудно изучить только ПЕРВЫЙ язык. Потом все идет по накатанной.
Изучение нового языка, чтобы уже хоть как-то начать программировать на нем — занимает считанные дни (скажем для Go это вообще часы).
Библиотека, особенности методов использования — это и занимает «некоторое падение производительности первые пару-тройку месяцев».
То что человек 20 лет работал на Коболе ни в коем образом не является для него проблемой, из-за которой он умрет с голоду, когда банк откажется от Кобола.
Трудно изучить только ПЕРВЫЙ язык. Потом все идет по накатанной.
Изучение нового языка, чтобы уже хоть как-то начать программировать на нем — занимает считанные дни (скажем для Go это вообще часы).
Библиотека, особенности методов использования — это и занимает «некоторое падение производительности первые пару-тройку месяцев».
То что человек 20 лет работал на Коболе ни в коем образом не является для него проблемой, из-за которой он умрет с голоду, когда банк откажется от Кобола.
Да при чём тут студенты. Если вы десять лет программировали на C, хорошо программировали, в ядро линукс коммитили, то посади вас за незнакомые вам Python и PyQT — за считанные дни вы это точно не освоите. Пару месяцев точно будете писать очень неэффективный и непонятный (то есть, плохой) C-подобный код, из велосипедов и костылей, постоянно чертыхаясь. А потом до вас дойдёт, вы изучите основы библиотки, основные приёмы работы и код начнёт улучшаться, а вы в свою очередь постепенно начнёте писать его быстрее.
Дело не в том, чтобы синтаксис языка выучить. Опять же, это не проблема. Не в этом дело.
Вы — раб что ли?
Кто вас куда сажает.
Не нравится Python — идите писать на Go.
В чем проблема — не понимаю. Неоднократно менял языки, парадигмы и пр. и пр.
Падение доходов за это время было только 1 раз и только 1 месяц продолжительностью — когда я из фирмы перешел на чистый фриленс.
Но это не связано со сменой языка программирования.
Все переходы на другой язык программирования максимум что — останавливали рост моих доходов на пару месяцев. Не более того.
Кто вас куда сажает.
Не нравится Python — идите писать на Go.
В чем проблема — не понимаю. Неоднократно менял языки, парадигмы и пр. и пр.
Падение доходов за это время было только 1 раз и только 1 месяц продолжительностью — когда я из фирмы перешел на чистый фриленс.
Но это не связано со сменой языка программирования.
Все переходы на другой язык программирования максимум что — останавливали рост моих доходов на пару месяцев. Не более того.
Маме памятник нужно ставить при жизни, и это не какая-то там фигура речи. Году в 99-м мне пришлось работать в одном банке на IBM AS/400. Приходилось писать исключительно на RPG, так как весь софт был на этом языке. Был там и кобол, но попробовать его так и не пришлось. Единственное, что доставляло — это DB2, работать с ней действительно одно удовольствие. На мой взгляд, почти совершенная реляционная база. Сегодня, глядя ежедневно на б-гомерзкий мускул, испытываю что-то вроде ностальгии по тем временам.
Немного потрогав продукты IBM, плевался с их монструозности и накрученности. Однако, когда пришлось поработать с DB2 — всё действительно оказалось довольно просто и удобно. Так что поддерживаю.
Высокомерие и чрезмерно раздутое ЧСВ — визитная карточка IBM. Та же OS/400, которая крутилась на AS/400 — замечательно годный продукт, объектно-ориентированная ОС, полностью написанная на С++ (привет этому вашему Линусу), где, в отличие от ущербной философии Unix «все есть файл», исповедуется совершенно иная идеология — все есть объект, что, имхо, более естественно (по крайней мере, для программиста). И почему она умерла? Из-за снобизма руководства IBM, не пожелавшего идти по пути MS и Apple и тиражировать свою OC. И с DB2 та же ситуация — крутится она на банковских серверах как «БД для избранных», а все остальные юзают оракл (кто побогаче) или (тьфу, тьфу, не к ночи будь помянут) мускул. Особняком пока стоит postgres, но стоит уже давно, и до оракла ему, на мой взляд, еще далековато.
> ущербной философии Unix «все есть файл»
В UNIX так никогда не было, это ущербное представление.
В UNIX так никогда не было, это ущербное представление.
Да? А вот некто Э.Танненбаум так не считает. Более того, на страницах своей книги он нет-нет да и упомянет в очередной раз, какая это замечательная концепция — представлять все в виде файла. Ведь тогда и интерфейс нужен единый — интерфейс доступа к файлу, т.е. тот самый, набивший всем оскомину с начала 70х open/creat/read/write/close. Но конечно, кто сейчас знает и помнит Танненбаума. Все знают парня, который нашел (т.е. быстро стырил и ушел) его MINIX и выдал за свое гениальное изобретение. И если в юникс никогда так не было, то покажите мне, пожалуйста, как в этом вашем юниксе, например, примонтировать внешнее устройство, не прибегая к вышеупомянутому интерфейсу. Буду очень благодарен.
Ну раз Linus стырил minix, тогда пусть всё будет файлом.
В вашем воображении.
В вашем воображении.
Укажите, какой файл отвечает в юниксе за сетевую карту? Любой юникс на ваш выбор.
Скажите, зачем потребовались ioctl? Какое это имеет отношение к файлам, когда файлы можно читать, писать, перемещаться по ним?
Про Plan9 я знаю. В нём действительно «всё есть файл», во всяком случае, система гораздо ближе к этой парадигме.
Скажите, зачем потребовались ioctl? Какое это имеет отношение к файлам, когда файлы можно читать, писать, перемещаться по ним?
Про Plan9 я знаю. В нём действительно «всё есть файл», во всяком случае, система гораздо ближе к этой парадигме.
> Высокомерие и чрезмерно раздутое ЧСВ — визитная карточка IBM.
Оно не из воздуха возникло.
Все же вот уже полвека IBM — поставщик мейнфреймов в крупнейшие банки мира.
Оно не из воздуха возникло.
Все же вот уже полвека IBM — поставщик мейнфреймов в крупнейшие банки мира.
> где, в отличие от ущербной философии Unix «все есть файл», исповедуется совершенно иная идеология — все есть объект
ООП — модный претендент на серебряную пулю.
Но со времен Smalltalk прошло много лет. И человечество уже переосмыслело концепции объектов и сочло, что полноценные объекты во многих случаях слишком неудобны (громоздки).
Для этого и в языки программирования вносят изменения: полноценные «классы» нередко урезают до простых «интерфейсов».
Так что я бы не настаивал на том факте, что объекты — это архиудобно для программирования.
ООП — модный претендент на серебряную пулю.
Но со времен Smalltalk прошло много лет. И человечество уже переосмыслело концепции объектов и сочло, что полноценные объекты во многих случаях слишком неудобны (громоздки).
Для этого и в языки программирования вносят изменения: полноценные «классы» нередко урезают до простых «интерфейсов».
Так что я бы не настаивал на том факте, что объекты — это архиудобно для программирования.
Интересно, а существуют Операционные Системы основанные на Функциональной Парадигме?
«Все суть объекты» и не требует полноценности. В принципе, реализацией вашего видения можно считать микроядро. А так — «все суть объекты» — например, NTшный девиз — те же интерфейсы.
Простите, но у вас тут терминологическая путаница. Я о классах и интерфейсах. Когда я пишу что-то вроде template class myClass, то это интерфейс. Но с какого перепугу он вдруг стал урезанным классом? Этот самый класс class T, который параметризует мой класс, тоже может быть параметризованным, и тогда я получу уже иерархию интерфейсов, причем без всякого наследования. А классы-то где, спросите вы. А их нету, выпилены за ненадобностью. Эти мои интерфейсы и знать о них ничего не хотят. И это все происходит, прошу заметить, на этапе компиляции, когда никаких «громоздких объектов» еще и в помине нет. И кто там чего у вас переосмыслил, понятия не имею. Это, может быть, те парни, которые 20 лет писали на чистом Си, затем решили перейти на С++, не поняли, для чего он нужен и спрыгнули обратно? Ну так туда им и дорога, пусть отдыхают в своем раю. Или пускай присоединяются к питонистам и рубистам — те тоже плевать хотели на понятие типа, но чувствуют себя отлично — интерпретатор избавил их необходимости думать.
> И почему она умерла?
Не умерла.
Разработанная для AS/400 не предназначенная для PC она на PC и не переносилась.
До сих пор там и живет для чего разработана.
Не умерла.
Разработанная для AS/400 не предназначенная для PC она на PC и не переносилась.
До сих пор там и живет для чего разработана.
> И с DB2 та же ситуация — крутится она на банковских серверах как «БД для избранных», а все остальные юзают оракл (кто побогаче) или (тьфу, тьфу, не к ночи будь помянут) мускул. Особняком пока стоит postgres, но стоит уже давно, и до оракла ему, на мой взляд, еще далековато.
DB/2 применяется гораздо шире чем вы думаете.
Даже 1С — и та реализовала поддержку DB/2 для своего основного продукта.
Наряду с MS-SQL, Oracle и Postgres
DB/2 применяется гораздо шире чем вы думаете.
Даже 1С — и та реализовала поддержку DB/2 для своего основного продукта.
Наряду с MS-SQL, Oracle и Postgres
Поддержку, да, это хорошо. Хорошо то, что сегодня каждый школьник может организовать такую «поддержку» — взять JDBC, например и указать в строке подключения тип драйвера — DB/2. Я говорю о том, что хотел бы работать с такой базой, как DB2, а не с такой, как (слово «база рука» не поворачивается написать) мускул.
1С — объектная система, но почему-то пихают её исключительно в реляционные БД. Нет бы какой-нить Cache запилили.
AS/400 (и Lotus) до сих пор живет в куче наших банков из 90-х, её тогда продвигали забавными роликами:
Laughing Boardroom
У меня тоже был период общения с AS/400 и RPG в 90-е. Тогда AS/400 казалась вершиной компьютерной эволюции. Да наверно так оно и было — столько новых мощных идей было заложено в эту систему. Кажется, в то время из 100 крупнейших компаний мира 98 использовали эту систему. Да и безопасность у нее была безупречная.
Вроде база DB2 была встроена в систему уровнем даже ниже ОС — OS/400 использовала DB2 для своих задач. Даже в сегодняшних системах такого не припомню.
Вот RPG/400 поначалу сильно напрягал — старый (оставшийся с перфокарточных времен) позиционный язык. Пришлось написать для нее «IDE» на макросах редактора типа Multiedit.
Вроде база DB2 была встроена в систему уровнем даже ниже ОС — OS/400 использовала DB2 для своих задач. Даже в сегодняшних системах такого не припомню.
Вот RPG/400 поначалу сильно напрягал — старый (оставшийся с перфокарточных времен) позиционный язык. Пришлось написать для нее «IDE» на макросах редактора типа Multiedit.
Вдохновляет.
Мне тут знакомый рассказывал историю. Довелось ему работать на одну из американских сетей АЗС cофт которой до сих пор работает на том же КОБОЛе. Копаясь в развестистом и плохо документированном коде он обнаружил каммент своего предшественника к одному из модулей с тестом типа «муй его знает что это делает». По-русски. :-D
Какое-то время назад работал с Коболом — отличный язык для банков, биллинга и т.п. Легко пишется и читается, так что даже непрограммисту понятно что происходит в коде. Javascript-у у Кобола стоило бы поучиться в этом плане. Хотя засады тоже есть конечно (типа случая с забытой точкой в конце оператора IF, стоившей некой страховой компании миллиардов долларов, согласно легенде). Но куда ж без этого.
Сразу скажу, что язык в глаза не видел. По статье и комментариям на Reddit сложилось впечатление, что нет там никакой простоты и удобства. Только за счёт легаси и живёт язык. Не сказать что это плохо — на момент рождения был крут, очевидно. Но понемногу устарел. Из ныне живущих только FORTRAN его старше, как я понимаю.
типа случая с забытой точкой в конце оператора IF, стоившей некой страховой компании миллиардов долларов, согласно легендеВ статье же об этом.
Что тебя больше всего шокировало?
— Мой коллега однажды забыл добавить точку в конце инструкции для программного модуля в самой важной части нашей системы, которую мы называем «кассой». Она отвечает за обработку всех денег. В результате на 16 часов остановилась работа всего банка, исключительно из-за модуля, который продолжал выполняться, хотя должен был остановиться после той инструкции. Это буквально повесило нашу систему, устроив, можно сказать, DoS-атаку самой себя.
Видимо это уже стало фольклором, так как каждый рассказывающий выдает это за произошедшее в их компании, но по вине коллеги, естественно.
Ну или случалось повсеместно.
Ну или случалось повсеместно.
А кобол тут при чем? В этом вашем линуксе, в выражении
$ find. -type f -name "*.sh" -exec rm -fr {} \;
если вы забудете заменить первую точку на слэш, произойдет непоправимое. Это уже не выстрел в ногу, как в примере из статьи, это отстреливание шаров напрочь. И кто здесь виноват, bash, что ли?
$ find. -type f -name "*.sh" -exec rm -fr {} \;
если вы забудете заменить первую точку на слэш, произойдет непоправимое. Это уже не выстрел в ногу, как в примере из статьи, это отстреливание шаров напрочь. И кто здесь виноват, bash, что ли?
Зачем тут заменять первую точку на слеш?
Один rm -rf {} уже пугает (ну или должен) и заставляет пересмотреть очень точно всю строчку.
Да, точно, именно пересмотреть. И изменить. Именно это должен был сделать тот парень, программист на коболе, завесивший банковскую систему на 16 часов. Но произошло то, что произошло. Да и вообще, все закончилось хорошо. Никто не порезал таблиц с транзакциями, не выпилил оттуда юзеров с их счетами. Чистый вин.
Есть пример по-проще. Не так давно в проекте надо было почистить кэш, пальцы делают уже автоматически, но они иногда ошибаются.
В итоге вместо
$ rm -rf app/cache
написал
$ rm -rf app /cache
То есть добавил всего один пробел случайно перед слэшем. В итоге удаленная директория app целиком. Пришлось повозиться немного с восстановлением файлов в IDE, хорошо, что все в истории есть.
В итоге вместо
$ rm -rf app/cache
написал
$ rm -rf app /cache
То есть добавил всего один пробел случайно перед слэшем. В итоге удаленная директория app целиком. Пришлось повозиться немного с восстановлением файлов в IDE, хорошо, что все в истории есть.
молодой человек удивляется, что в таких системах почти все — пакетная обработка и говорит о postgre и mysql и миллисекундах на запрос. Он просто еще не в курсе, что на действительно больших объемах в независимости от СУБД обработка будет по прежнему пакетной. и более того, ни PG. ни тем более mySQL не пустят в ближайшие 10 лет ни в один банк в качестве ядра данных. Имею право так говорить, имя опыт работы в небольшом банке. Как можно себе представить систему с моментальной интерактивной обработкой всех операций, если операций миллиарды в день (для всей мировой банковской системы), размазанные по всей земле? Добавьте сюда все формальные требования к банковском делу по учету…
А по поводу жуткого легаси — это было и будет проклятьем банков (ну ок, может быть это проклятье снимет блокчейн). Потому что невозможно изменять систему на ходу. Зачем и во имя чего переписывать на новые технологии уже оттестированный код в условиях, когда нужно писать и писать свежие формы, отчеты, обработки и тому подобное? Время и ресурсы есть только на то, чтобы позаботиться о стабильности текущего состояния и проверить, что в перспективе стабильность не пропадет.
Да, системы со временем таки обновляются. Но на эти изменения уходят года. Год на планирование, год на выбор новых систем, год на проверку и пару лет на полную замену. Когда новая система вступила в бой — она уже устарела на 2-4 года, а ей еще теперь работать 10 лет.
Маме автора действительно нужен памятник — редкая порода инженеров, способных десятками лет поддерживать систему не забывая о развитии этой системы
А по поводу жуткого легаси — это было и будет проклятьем банков (ну ок, может быть это проклятье снимет блокчейн). Потому что невозможно изменять систему на ходу. Зачем и во имя чего переписывать на новые технологии уже оттестированный код в условиях, когда нужно писать и писать свежие формы, отчеты, обработки и тому подобное? Время и ресурсы есть только на то, чтобы позаботиться о стабильности текущего состояния и проверить, что в перспективе стабильность не пропадет.
Да, системы со временем таки обновляются. Но на эти изменения уходят года. Год на планирование, год на выбор новых систем, год на проверку и пару лет на полную замену. Когда новая система вступила в бой — она уже устарела на 2-4 года, а ей еще теперь работать 10 лет.
Маме автора действительно нужен памятник — редкая порода инженеров, способных десятками лет поддерживать систему не забывая о развитии этой системы
Знаю 2 банка, в которых АБС переехали с Оракла на Постгрес, инфа от коллег, которые там работали.
Это конечно не топ-10, просто региональные банки с парой сотен тысяч клиентов.
Это конечно не топ-10, просто региональные банки с парой сотен тысяч клиентов.
> Да, системы со временем таки обновляются. Но на эти изменения уходят года. Год на планирование, год на выбор новых систем, год на проверку и пару лет на полную замену. Когда новая система вступила в бой — она уже устарела на 2-4 года, а ей еще теперь работать 10 лет.
Занимался автоматизацией средних оптовых фирм. Не банки. Не крупные фирмы.
По моему наблюдению с момента первых изменений до окончания работ по адаптации софта — при внедрении новой версии системы учета — проходит те же 2 года.
Так что не только в банках такие сроки.
Занимался автоматизацией средних оптовых фирм. Не банки. Не крупные фирмы.
По моему наблюдению с момента первых изменений до окончания работ по адаптации софта — при внедрении новой версии системы учета — проходит те же 2 года.
Так что не только в банках такие сроки.
Теперь понятно, почему этот человек ( https://youtu.be/hqCsg4U3iqQ ) так рад, когда выходит с работы. Это из-за того, что на работе ему приходится программировать на Коболе.
UFO just landed and posted this here
Это еще что. При прохождении собеседования в некоторых компаниях в Малайзии вас попросят написать что-то вроде сочинения на вольную тему, например «Что такое успех». На английском, естественно. И количество слов — 300 минимум. А потом ответить на вопрос «в чем ваши слабые стороны». Здесь главное — долго не думать, иначе они подумают, что у вас завышенная самооценка. Я, например, ответил: я не люблю работать после обеда, и это прокатило.
UFO just landed and posted this here
А как вы попали в Малазию?
А что там за фирмы?
А какие плюсы и минусы работы в Малазии?
А что там за фирмы?
А какие плюсы и минусы работы в Малазии?
Малайзийские компании делятся на две большие, никак не пересекающиеся ни по каким параметрам категории: собственно малайзийские и иностранные. Попасть в местную, конечно, проще: требования пониже, процесс трудоустройства занимает не так много времени. Но и зарплата соответственная. Процесс примерно такой: HR звонит вам и задает несколько общих вопросов: образование, опыт работы, языки и технологии и т.п. Затем он просит вас пройти онлайн-тест. Как правило, эти тесты — что-то вроде дилеммы осла, никак не могущего сделать правильный выбор, и результат почти не релевантен вашему уровню знаний. Например, по результатам одного из тестов, я показал хорошее владение ASP.NET, которую я на дух не переношу (как, впрочем. и весь этот микс дельфи и вижл васика, называемый дотнет). Затем, если все хорошо, вас приглашают на собеседование в офис (вариант — по скайпу). Там будут сидеть 2-3 серьезных мужчины и выворачивать наизнанку вашу подноготную. Молитесь, чтобы среди них не оказалось расового китайца. Почему? Вы просто не поймете его вопросов. Например, он может спросить: ват изе джава клас рут, ансеми, ансеми, что можно перевести как answer me please what is the root java class' name. Европейцы, как правило, относятся к нам хорошо и стараются на собеседовании не валить.
Да обычный корпоративный формализм.
Было бы даже подозрительно — если было бы иначе.
Было бы даже подозрительно — если было бы иначе.
Могу со стопроцентной уверенностью заявить, что сегодняшний Фонд гарантирования вкладов Украины, разрабатывает новый софт на Delphi xe+ и Oracle в качестве DB.
Не хотелось бы хвастаться, но наши мамы круче. Моей например 76, она до сих пор работает и создавала с нуля ПО для одного из самых успешных советских проектов. К сожалению взять у нее интервью не получится из-за глубоко вьевшейся привычки к секретности. Я сам узнал чем именно они с отцом занимаются когда мне было уже за 30 и я работал в Москве, из воспоминаний детства остались только бесконечные рулоны бумаги с распечатками восьмеричных кодов. Так что даже не знаю что про себя сказать — то ли я потомственный программист, то ли наоборот, самоучка.
Впечатление от статьи — на мэйнфреймах только COBOL. А это совсем не так, там и С/С++ и HLASM. Опять же не обязательно программировать сидя под ISPF, никто не мешает править код локально и заливать датасеты по FTP.
Также есть такая вещь как UNIX System Services, куда вполне можно подключиться по SSH. А конец эпохи мэнфреймов предрекали уже не раз :)
Также есть такая вещь как UNIX System Services, куда вполне можно подключиться по SSH. А конец эпохи мэнфреймов предрекали уже не раз :)
COBOL — это императивный, процедурный язык, а с 2002 года — объектно-ориентированный.
С датировкой что–то явно не то. COBOL был одним из языков, которые реализовали Direct-to-SOM. Учитывая, что последнюю версию SOM для мейнфреймов выпустили в 1997м году (потом в IBM посходили с ума, прекратили разработку SOM и переключились на Java), и COBOL тут не какой–то, а именно IBM, то объектно–ориентированным он стал ну явно не позже, чем закрыли SOM.
Sign up to leave a comment.
Интервью с мамой, банковским программистом на COBOL'е